Data rate reduced after running DLT-receive more than once

[ja518]

Hello all,

I'm trying to create a GUI-based replacement for a console tool that uses DLT-receive (under Windows) to diagnose issues with a radio, but I'm hitting a wall with how to terminate the process correctly.

From looking at the running processes, the original tool seems to use WSL to call DLT-receive, and as far as I can tell the data rate stays constant. The tool has other deficiencies I'm trying to avoid by calling DLT-receive directly under Windows.

My problem is: I noticed that the number of log lines received from the device I'm "talking to" gets reduced substantially the 2nd time I run DLT-receive (either from command prompt or from my GUI). The drop can be as much as going from ~180K log lines per minute to ~20K. This data rate reduction is not present when using DLT-viewer under Windows, though.

I can go back to the original data rate by turning the device off and back on, so it looks like there things are not being cleared up correctly when DLT-receive is terminated using CTRL+C under windows (or killing the process programmatically).

I tested DLT-receive under Linux (using WSL), and I can see a data rate reduction as well, just not as dramatic as under Windows.

Upon checking the code for DLT-receive, I found there's some cleanup code that gets called when DLT-receive receives the SIGINT signal (which I understand gets sent when you press CTRL+C under Linux). My problem is that Windows doesn't process "signals"(as far as I know), so I can't seem to trigger this "elegant exit".

Has anyone here noticed the same data rate reduction after running DLT-receive more than once?
Does anyone have pointers on how to avoid this issue, in particular under Windows?

Thanks!

J

[lti9hc]

Hello @ja518,
you can modify the source code of dlt-receive when calling it under window
I suggest using signal(SIGINT, signal_handler) function to handler signal