Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Hello. Thank you very much, Vladimir! Now it is not convenient to install this version in the field device, because just this days we have changed the "DUT" and it is important to acquire data in the same fashion that we have been doing it before. But, as soon as I can, I will try it and provide feedback. I take the opportunity of this post to wish you Merry Christmas! Regards
Perfect! Thank you again. Regards
I cannot tell 100%, because I am not user of SPI/I2C tap, but I agree that it is confusing of the "non-users" of that tap. And I agree about the consistence (and "the right thing"). I also I agree that simplify is usually good so I think that your proposal is perfect (btw, about simplify, in fact there is a Einstein quote : "Everything should be made as simple as possible, but not simpler") Regards!
Perfect. Thank you!
Hello! Just a small additional remark, if possible/feasible/reasonable, consider the options of splitting by size (eg. each "n" MB) and by time (eg. each "t" minutes). It is just an idea... perhaps it seems more logic just consider the size, but -eg. for my case- it is more convenient to have captures of info more or less time aligned (eg. daily aligned... in fact, I am currently splitting them each 6 hours) Regards! Josep
Hello again Vladimir, Of course, if you could send me the internal build, I am still with the field device installed and I will tried it! Thank you again Regards !
Hello again. Ok! And thank you for the premier on the new HW, I look forward for having it available! It is good to know about its capabilities. About my problem: ok, I was able to solve it with a simple inverter (mosfet) and I managed to get the Vcc I needed
If this is something you could add "for free" to your new development, great! If not, well, I think that this is no a common case, in fact, I found it very weird (but "real" indeed).
Ok! Please, eventually, consider the option of being "transparent" when power-off, in my case, it is a really must. Regards!
Ok. Thanks! now clear, but a little confusing indeed ... perhaps simply with a hoover tooltip, or other help, would be enough
Hello Vladimir, you are right! but I would have sworn I tried that (in fact, after writing the post I thought I have forgoten comment that "the issue" seems related to an UTF issue) Sorry and thank you! Regards Josep
Hello, I'm trying to colorize an hex log, and I find a estrange behaviors. E.g. I can colorize ok some bytes:
but others are not colorized at all
and, in a weird case, a value (0x77) colorize two bytes (0x77 and 0x57)
It seems that colorizes better low values (below 0x80) than high ones.
Another thing that could affect (?), could be that the log has been captured using "odd" parity... but ... not sure about it, as it colorizes correctly if I use 0x01 or 0x03
Regards! Josep
Ops...and a very simple question, what is the "Dual Hex Line size"? I tried it, and I -very quicly- try to find if there is any place where is described, but I do not find out. Thank you, regards!
And hello again! as today I am here writing is there any news about a new version on Ethernet Tap? I think you were working on it.... for me the real needed feature that I need for this kind of device it that it should be "transparent" in poweroff state. In our applications, it is critical do not cut the communications in any case, so if we install a -eg- EthernetTap it is importat that the communications do not cut even if the serialtap goes off.
(and, problably, this new Ethernet Tap would include other improvements... some memory for catching the packets, Gb,...)
Hello again
One of the devices that we want to monitor has a TTL serial port, but with a strange customization. Its RX circuit is "regular", but the TX circuit is "inverted"... I do not know why... perhaps there is a real reason, perhaps they try to avoid use standard components...
Anyway, I am interested in capturing this communication using the SerialTap. I know (I did it before in lab) I could simply use an transistor in order to invert it, but this solucion is inconvenient when used in field (with real devices in operation), as we want that the setup that stands installed be clean and simple (and, eg, using the transitor solution, I have somehow to find a "5V Vcc")
I do not know it it would be possible to add an option in order to do this at "serialTap" level (eg. add an option to be able to consider some signals inverted, and apply some kind of "xor 1" over this circuits).
Hello! Again I am capturing in a remote location, without good communications, using a simple raspberry and a Serial Tap. It is permanently capturing as we are trying to catch a "sporadic" issue. As communications are bad, we are "chunking" the logs, in order to be able to download just the piece of log in which the issue eventually occurs. Now, we are chunking it "restarting" the ioninja-hwc process every 2 hours. It is easy using the systemd capabilities (using RuntimeMaxSec), but a side efect is that we have to set a minimun restart timeout (2 min), in order to avoid that the unit goes permantly disabled if a error happens (mainly, during installation, the raspberry is powered up before the serial tap is connected...).
Well, my point is, perhaps you could consider to add an option in the "ioninja-hwc" in order to allow "fragment" the logs (some similar, or simpler, to the opcions "-C" / "-G" available in tcpdump).
Regards!
Hello! About your last post (2-jul), I will try it! And about the previous one (1-jul; 04:16), sorry but I did not see it and I write my post -later- without been aware of it (I did it very quickly, and I was a bit confused at that moment because I spent some time finding the the thread and wandering if all was a dream (I am getting older, and I am not sure of nothing ). All in all, my post was not very coherent with what you said about having "mutable" dynamic layouts, well, I think that this could be useful, and if it is something possible without a really big difficulties/chages, I think that could be eventually useful in some cases, as you point out. Regards! Josep
Hello @vladimir Thank you very much for your detailed explanation, as always it is very illustrative!! Ok! More or less, I have the feeling that it was going to be as you comment, that the main purpose and utility of this construction is for parsing (in fact, my first impression is that it should be used inside the ioninja app (for ioninja scripts), and could not be used in "plain jancy", I was happy when I see that in fact could be used "alone"). As you said, I was thinking of using it for parsing and generating frames (IEC60870-5-103 frames), but, as you point out, it is perhaps not really very useful when constructing a frame. Again, thank you! Regards! Josep
Hello! I tried to use dylayout in "plain jancy", as it seem possible and in the changelog it is declared that replaces dynamic structs (that are interesting! but in some cases falls a bit short... I remember asking you -sometime ago- because I tried to implement a IEC103 frame generator, and it was not directly possible)
Well, I perform a quick try of the dylayout solution, and it seems even more interesting!! but I have some doubts about its use. At a very basic level
For instance, for the following code
int main() { char *aa = new char[10]; aa[0]=0x01; jnc.DynamicLayout layout(aa,4); dylayout (layout) { dyfield int16_t myChar; printf("%04d",myChar); // myChar = 3; // (q1) cannot store into const location } // printf("%d",myChar); // (q2) out of scope (expected...) // printf("%d",layout.myChar); // (q2) not a member (also quite expected... but then, how?) return 0; }
That works well. But,: q1. is it possible to assign a value to a "dyfield"? q2. is it possible to access to the "DynamicLayout" elements outside of the dylayout section?
I confirm that the Easy Way works perfectly. Thank you and regards! Josep