Continue Capture if ReadTimeout occurs

Voters 9

J
B
P
F
K
K
+ 3 voters
B
M

Open
Subscribe

Tim

In case a ReadTimeout error occurs, it would be great to continue the capture.
- Perhaps leave gaps in the capture when ReadTimeouts occur
- Automatically re-start the capture upon a ReadTimeout error

A quick solution with current hardware might be to autmoatically stop and restart the capture in case a ReadTimeout occurs. The downside to this is that, depending on how quickly and often the ReadTimeouts occur, the app might attempt to create too many new capture tabs when captures keep restarting, and this could get messy quickly.

The limitation right now is that time can’t be tracked in between captures, and therefore, we wouldn’t be able to combine captures together while keeping track of how long the gaps are.

-----
For reference, please refer to the ReadTimeout error in the support article below:
support.saleae.com/troubleshooting/device-not-able-to-keep-up

05-01-2022 -

Activity Newest / Oldest

Tim

(#80896)
Note: We could certainly use this feature to get around the ReadTimeout errors the user is experiencing below when using our Automation API.

"I simply repeated 1200 measurements with a time of 20 seconds and 10 seconds delay between these measurements. On saleae there is nothing connected (not even connectors), so there is no signal to measure except low level.
...
There was 13 times the ReadTimeout."

Ben

Hi Tim,

This is a follow-up to our email exchange yesterday.

I may be wrong here or maybe it's just not possible but if time cannot tracked in-between captures, why not initially capture the system time at the very begining of the capture in the software when the start button is pressed?

Then, if/when a ReadTimeout occurs, capture the system time again at that specific time and then just before doing the automatic restart, get the system time for a third time and with these three time values, you'll know how far you should restart the capture on the graph...?

Really, getting the time and restarting at the right place in the graph is just a visual thing... So if getting the system time is not an option, then the other option I can think of is to simply restart in the graph where it crashed and that's it. At least this way the user will know that a crash occured at some point in time without knowing when.

From a user standpoint, I'd rather see a capture restart in the same session rather than a different tab. But, getting the system time and plotting these in the same graph could also show if the timeout is a recurring pattern at a certain interval.

Also, I see your last post that this is an excerpt from our email exchange from yesterday: this goes back to keeping the crashes in the same session; if the crashes cannot be plotted using system time, then a red vertical line indicating with an exclamation mark in a triangle could be added and if system time is an option, then a green vertical line indicating with another exclamation mark in a square could also be added further at the correct location on the graph. Just ideas...

Tim

Thanks for providing several alternatives/ideas! We'll keep your notes in mind.

Tim

(#69228)
"perhaps another thing you guys could do is automatically recover/restart/continue the sampling when a USB timeout occurs and mark-it in the captured data, just like the vertical yellow line with a ‘T’ indicating where the trigger occurred, then perhaps it could be a red vertical line with an exclamation mark indicating that a timeout occurred and the label would indicate the amount of time/data missed.

This way, no more babysitting... start and forget!"

Tim

discuss.saleae.com/t/scripting-socket-api/108/13
"Just an idea for some basic built-in automation could be very useful in your cases (and also in mine) without the need for complex capture segmentation:

Save and repeat: if the trigger occurs, the software will finish the current capture (post-trigger capture and pre-trigger trim), then save the capture to pre-configured file (adding counter to avoid overwriting the last file), and start the capture again.

Restart after failure: if the capture is stopped by any other means than the user clicking the stop button (buffer overflow, timeout, USB error, system reboot), the software will save the current capture (if possible), and try it’s best to start the capture again (if USB error, try to reset the hardware, if everything fails, try to reboot the system).

This would allow running the captures for weeks and months without the need for a human checking every few hours."

Peter

A discontinuous time bar wouldn't be a deal breaker, especially if the first sample in each block can be synchronized with PC time with moderately low jitter. Even a few tens of ms sync error between blocks would be good enough for most purposes, and way better than missing the data altogether!

Peter

A work around for the "too many capture tabs" issue is to continue recording into the same tab and insert a "record break". In practice that would look like a vertical bar in the data at the point where recording stopped then started again.

This technique would be very handy for capturing a series of blocks of data that are related and where separate capture tabs are clumsy.

Tim

Thanks for the insight! Would it still be helpful for you if each "record break" section lost track of time? Rather than one continuous time bar throughout all ReadTimeout instances, the time bar would be broken (i.e. each "record break" would be followed by a new capture section that starts at t=0s).

Tim

discuss.saleae.com/t/ignore-errors-during-capture/1411/5
"Is there a way to ignore errors during capture? Frequently I use the live capture view as a “signs of life” for my DUT. For this use case, I want to ignore any read timeout, buffer full or any other errors. It is much more important to me that the live capture continues to scroll.

If that option does not exist, is it possible to get this feature added in an upcoming release?
---
I do not want the ability to adjust the sample rate.
I only need the ability for Logic 2 to ignore the error and keep capturing. Would that be possible? BTW, I have seen two errors so far: read timeout and buffer 90% full. For this request: I would like all errors to be ignored.
(I have a Logic 8 device)."

Tim

(#66825)
"ISSUE: I keep getting a ReadTimeout error during capture.

I am attempting to capture an I2C bus error so I have SCL on CH0, SDA on CH1 and a trigger signal on CH2 that goes high when the bus error occurs. The error only happens 4-6 times per day so I end up starting a trigger capture and monitoring it occasionally to see if the error has occurred. Just about every time (except for the rare occasion that the capture does catch the bus error), I get a ReadTimeout error. I tried several of your suggestions but due to the physical arrangement of my desktop PC and my test bench, I must go through a USB 3.0 hub.
1) I feel that the error occurs far to often to be a random occurrence and 2) each time I get the ReadTimeout error, I simply re-start the capture. I have an i7 PC with SSD so it runs fairly fast.

Please see if you can a) improve the capture so that the error does not occur or b) ** simply add a feature to automatically re-start the capture if a ReadTimeout occurs."