<![CDATA[Measuring timestamp on plan text serial data with CR end of line]]>Hi

Is there a way of reporting timestamp for each character received or displaying a line terminated by CR and reporting the timestamp of the end of line, rather than hex line of 16? We tried setting the line length to 1 but the minimum seems to be 4 in hex, and 8 in plain text.

We have a feed from a serial source with variable length messages terminated by CR and I need to be able to determine the time received for each line. (EOL specifically). Ideally I could then export them to a file so our software could read that and we can use it to replay the feed in our test simulation software.

Thanks
Brett

]]>http://64.23.185.212/forum/topic/50/measuring-timestamp-on-plan-text-serial-data-with-cr-end-of-lineRSS for NodeMon, 08 Jun 2026 20:59:29 GMTWed, 04 Jan 2023 01:30:19 GMT60<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Fri, 10 Feb 2023 02:51:56 GMT]]>Excellent stuff!!! Replay log works like a dream... this will be an invaluable regression test tool.

My confusion regarding required components was about getting purchase permissions: based on Replay web page, I got permission to buy the ioninja.layer; only once it was installed did we discover it wouldn't work until we also bought jancy.io.serial (back for purchase permission). All well and good now... and I highly recommend this to anyone writing RS232 based code (and need to test it).

]]>http://64.23.185.212/forum/post/219http://64.23.185.212/forum/post/219Fri, 10 Feb 2023 02:51:56 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Wed, 08 Feb 2023 02:37:18 GMT]]>Actually, everything is correct there.

Replay Log is a layer -- it can't make any assumptions about which transport is used underneath it (RS232? TCP? UDP? SSL?).

If you plan to use it with a serial port, then you attach it to a Serial session. Hence, you need org.jancy.io.serial.

]]>http://64.23.185.212/forum/post/218http://64.23.185.212/forum/post/218Wed, 08 Feb 2023 02:37:18 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Tue, 07 Feb 2023 21:16:37 GMT]]>@vladimir Hi again, here is the page you may want to tweak:

7e335eaf-f82b-4489-b6b6-e1ea63dae211-image.png

]]>http://64.23.185.212/forum/post/216http://64.23.185.212/forum/post/216Tue, 07 Feb 2023 21:16:37 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Mon, 06 Feb 2023 03:58:23 GMT]]>Hello,

The web site says Serial s part of org.jancy.io.file, which should be included and free

Hmm... Which page says that? Might be a mistake on the website if so.

The "Serial" plugin doesn't really need org.jancy.io.file; but it does require org.jancy.io.serial, as stated on the plugin's page:

2e74fa5d-f03f-48dc-a800-23c25fe59dbd-image.png

All other plugin pages also show both required and optional capabilities right below the page header (as can be seen in the screenshot above).

]]>http://64.23.185.212/forum/post/213http://64.23.185.212/forum/post/213Mon, 06 Feb 2023 03:58:23 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Sun, 05 Feb 2023 04:06:02 GMT]]>Replay Log... I might need some help. The replay button is disabled.
My investigations include the following:

  1. I record with Serial Tap (all good)...
  2. I replay with Serial

Serial is locked in my session... so I can't replay.
The web site says Serial s part of org.jancy.io.file, which should be included and free... but isn't.
I'm feeling a bit dumb at the moment... any obvious hints I've missed?

]]>http://64.23.185.212/forum/post/211http://64.23.185.212/forum/post/211Sun, 05 Feb 2023 04:06:02 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Sat, 28 Jan 2023 05:31:24 GMT]]>Glad it worked for you!

Yes, com.ioninja.layer is the capability that enables "Replay Log" and all other layers.

]]>http://64.23.185.212/forum/post/207http://64.23.185.212/forum/post/207Sat, 28 Jan 2023 05:31:24 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Fri, 27 Jan 2023 02:57:23 GMT]]>Thanks Vladimir, looks perfect.
To get the Replay plugin, is this what we need to buy?

com.ioninja.layer

Layers
Enables attaching layers to sessions and logs
$20 PROMOTION

Regards, Mike

]]>http://64.23.185.212/forum/post/206http://64.23.185.212/forum/post/206Fri, 27 Jan 2023 02:57:23 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Wed, 18 Jan 2023 03:21:10 GMT]]>@vladimir Hi Vladimir, thanks for this, we'll try it out. Brett

]]>http://64.23.185.212/forum/post/198http://64.23.185.212/forum/post/198Wed, 18 Jan 2023 03:21:10 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Wed, 18 Jan 2023 02:11:40 GMT]]>First of all, let me answer your questions about post-processing log files.

If you need to save a captured log as plain text, you can do it via Menu -> File -> Save Log, then choose the *.txt format. FYI, in version 5.2.1, a regression causes Save Log As Text to get stuck at 0%. A fix is already staged for the upcoming release next month; in the meantime, you can work around this issue by using "Save Log Selection" instead.

However, saving a log as text is really not necessary (and even counter-productive) for log post-processing. The format of *.njlog files is much more efficient for parsing and processing than a text file. All the related *.njlog declarations are open-source and available at scripts/api/log_RecordCode.jnc, log_RecordFile.jnc. So you can simply "walk" over a *.njlog file with a Python script (or use any other language of your choice) and do all the necessary actions.

But even before starting to work on all that.

Did you try the Replay Log plugin?

f77639ed-015f-4f2b-a384-eb35f547bff1-image.png

This plugin allows you to re-send the previously captured TX, RX (or both) records with respect to timestamps. You can even proportionally "stretch" or "shrink" delays between packets!

15ba5a5e-09d3-4e13-b82d-931bee74407d-image.png

To replay only a portion of log, first save it into a dedicated .njlog file via "Save Log Selection", then replay it with the "Replay Log" plugin.

I suggest you try this plugin first -- it might just do what you need.

]]>http://64.23.185.212/forum/post/197http://64.23.185.212/forum/post/197Wed, 18 Jan 2023 02:11:40 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Tue, 17 Jan 2023 03:08:35 GMT]]>From the flat file, we would be able to build the simulation data source.

]]>http://64.23.185.212/forum/post/196http://64.23.185.212/forum/post/196Tue, 17 Jan 2023 03:08:35 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Tue, 17 Jan 2023 01:28:36 GMT]]>We wish to be able to capture a trace of characters from a customer device which will be connected to our controller, and then using our test harness, play them back into our controller to be able to regression test software changes and simulate real life situations. Some of the customer equipment is very large, some expensive and some simply one off builds - most are remote and cant be taken offline - which makes it hard to regression test software changes at our end without simulation capability. Play back doesnt need to e perfect timing wise so data block granularity is fine. It would be nice to output the capture to a flat file with ascii or hex and appropriate timestamps where blocks start and/or end.

]]>http://64.23.185.212/forum/post/195http://64.23.185.212/forum/post/195Tue, 17 Jan 2023 01:28:36 GMT<![CDATA[Reply to Measuring timestamp on plan text serial data with CR end of line on Thu, 05 Jan 2023 08:15:18 GMT]]>There are no individual byte timestamps in most IO Ninja plugins. Changing the line size won't help here (even if it were possible to set it to one) -- timestamps are assigned to the data blocks upon receiving them from the operating system; not based on the line size.

However, getting a sequence of bytes received as a block means that they arrived in quick succession, i.e. "fast enough". Therefore, timestamps give a relatively accurate (to the order of milliseconds) time of receiving bytes in this block. Normally, if a protocol depends on timing, then the delays involved are much higher than that. Otherwise, protocols are designed in a way that allows finding the beginnings and endings of packets without relying on timestamps.

Could you explain why exactly you need individual byte timestamps? Maybe, there's an alternative way of achieving what you need.

]]>http://64.23.185.212/forum/post/193http://64.23.185.212/forum/post/193Thu, 05 Jan 2023 08:15:18 GMT