save a part of the log, as njlog file

Hello again! I have a new question -users are never satiated-.
This is quite simple, so perhaps the problem is just that I did not find how to do it.
Now have a quite big njlog files -coming from the serial tap-, but I just want to save a small relevant part. Is it any way to "save" o "cut/paste" just a part of the log. The output file should also be a "njlog" file, as I want to keep the timestamps and -last but not least- to be able to open it with IOninja and use your log engine.
In fact, it is not critical to have this feature for me-I do not have problem to open the big file- but seems something "logical" to be available. In fact, as I commented, I have daily logs -each about 500MB (50 MB after compression)-, and at the end of the day, It was just a little part what I interested to keep.
Thank you and regards!
Josep

Hello again, Jose!

Just like your previous requests, this one totally makes sense. As a matter of fact, we already received requests for such a feature in the past, so we will do our best to add it to one of the upcoming service releases in the near future. Stay tuned!

Regards!

Jose,

Which platform do you usually use IO Ninja on? I can provide you with an internal pre-release build that supports saving parts of the log (both as .njlog and as .txt).

Let me know!

Hello Vladimir!
For this kind of things, I usually use (50%) Windows 64-bit and (50%) a SBC arm32 (a raspberry, with Arch Arm Linux).
For this application (manage big log files...) I think I would prefer to have the version for the big machine, that is for Windows.
Regards and thanks!

Here you go:

https://tibbo.com/downloads/archive/ioninja/.internal/ioninja-prerelease/ioninja-5.2.0-a-windows-amd64.7z

Let me know what you think!

@vladimir
Happy to help! Regards

Hello. Just a few words, in order to tell you that I tried it, and I worked to me perfectly. Even I see that it adjust the line last byte timestamp.
Thank you! Regards

Thanks for the feedback, glad to hear it worked for you! The next service release is scheduled for this week, and this feature will be included.

Not quite sure what you mean by the adjustment of the last byte timestamp, though. When we write to the new log, we preserve all the original timestamps. Every line shows the timestamp of the last record in that line, so actually, the last line timestamp should remain the same. If it's not, could you share the screenshot to demonstrate the issue?

Hello.
Yes, I did not explain it well. And in fact, I think it is not a very realistic use... I just tried to save a selection that does not include the full line of the last record (it does not include the last records/bytes of the last line), and so I sew that the timestamp of this line changes.

This opens a totally different topic, but quite interesting: How accurate are the timestamps in the logs? (obviously, respect of the time in the host device (PC/SBC/...), at which the tap is connected). And exact value probably is impossible to give, and perhaps depends on the host/the USB connection/etc... but you could give an order of magnitude? could be in the order of ms? or hundreds of us? (... I saw that it is possible to define (using %c) "microsecond" level timestamps in the log)
Regards!

I think it is not a very realistic use... I just tried to save a selection that does not include the full line of the last record (it does not include the last records/bytes of the last line)

Well, that's quite a realistic way of using this feature. And yes, in this case, the last line's timestamp can change (the line timestamp is the timestamp of the last record in this line).

How accurate are the timestamps in the logs?

The timestamp format used in IO Ninja is Windows FILETIME, so the technical limitation imposed by the format is 100 nanoseconds. However, of course, that's not the actual timestamp precision in the vast majority of cases -- we need to consider where those timestamps are coming from.

In the case of Serial Tap (which is basically a dual USB-to-UART adapter), the timestamps are generated on the PC side upon receiving data or line change notifications from the tap over USB; the expected precision would be of the order of milliseconds.

However, the planned FPGA-based Serial Tap Pro would timestamp individual bytes before submitting those to the PC; here, we can reach the microsecond precision.

Hello. Ok! That accuracy around milliseconds is what I suspect (and expect). Thank you!

... and about that "Serial Tap Pro", the forced question is -obvously- is there any tentative/aprox release date?

Also, an idea for that kind of device... a long time ago I used another serial tap -also quite nice- and one possibility was to control -in some quite limited way- the circuits of one side. It was nice and allowed me to perform some things that I had to do at that time. Sadly, the functions were done at host (PC) level, so the control was quite -functional and time- limited. I, specifically, remember at that time that it would had been quite useful to me to be able to introduce errors in the serial comunications line -eg. with some probability- and that was not possible. The idea is similar to what it is possible to perform with tc-netem (https://man7.org/linux/man-pages/man8/tc-netem.8.html), -well netem is quite powerfull, but perhaps some basic funcions could be incorporate... well that was just brainstorming obviously, the first requirement for that is that the tap has to be able to drive the lines, and I do not know if this is the case.

Anyway, we look forward to have more information about this device!
Regards!

Yes, the cability of packet injection is on our TODO list for Serial Tap Pro. More complex testing scenarios such as the ones you mention would still need to be controlled from the PC. But we do have in-app scripts in IO Ninja, so quite a lot should be doable.

As for the time frame -- well, I know, it's been in the talks for a long time Unfortunately, there were lots of circumstances that cut the line so to speak. However, this time it does look like we are (finally) starting the hardware development process early next year.