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?
Thanks & regards,
Bruce
@bruce.p.clemens Unfortunately, we don’t have a way of adjusting the sampling rate on the fly. I do like the idea of having some sort of “signs of life” mode where the sampling rate may dynamically adjust. A potentially quick solution for us might be to add the ability to automatically stop and restart the capture in the case of a ReadTimeout.
Do you find that you are noticing ReadTimeouts often? Also, which Saleae Logic model do you own? Some of the most common causes for ReadTimeouts are described below:
Hopefully one of the troubleshooting steps above helps.
Hi, Tim. Thank you for the information.
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).
Thank you a best regards,
Bruce Clemens
Hello, I replied to your questions, but my reply has been captured by your akismet system. Would you please check that system and release my reply so we can continue this thread? Thanks & regards, Bruce Clemens
@bruce.p.clemens Sorry about our asikmet system blocking your previous message! I’ve re-opened it. Let me discuss this idea with our team over here. I certainly see your need for this, and we’ve received similar requests from other users in the past as well.
@bruce.p.clemens I had a few chats with the software team about this since we last spoke. Ultimately, we might need to brainstorm a solution for this via new hardware. 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.
In case you would be OK with automatically restarting the capture upon ReadTimeouts and splicing these all together, would you also be OK with losing track of the time from the start of capture? Every new capture would start with t=0.
@bruce.p.clemens I went ahead and added a comment/vote for you in the idea post we are tracking for this below:
Apologies again we don’t have an immediate solution for you. In the meantime, we’ll continue to track user need for this in that idea post before we commit it to the roadmap.