Only forward methods：
U32 Advance( U32 num_samples );
U32 AdvanceToAbsPosition( U64 sample_number );
Can provide a fallback API interface？
Only forward methods：
@578645671 Our Protocol Analyzer SDK was designed to traverse the data stream forward, but not backwards, as mentioned in the “Basic Traversal” section in our API documentation below:
Can you provide an example fallback scenario? We may be able to provide a workaround for you.
By the way, sorry for the late reply! Several of our team members were out of office since last week due to the Thanksgiving holiday.
I second this proposal and can also provide a scenario: I am currently trying to implement an analyzer for a transmission with changing and/or unknown datarates. As such, I first try to detect transmission blocks, would then run a datarate detection and eventually extract the data. I could of course copy all detected edges from the stream to my own object, analyze everything there and then go back an annotate the stream, but this is quite some overhead.
I probably could also work with a function that allows me to get a certain sample in the future and eventually building my own code to find more than just the next edge without advancing the pointer (although that would probably be not as efficient), of course.
Sorry for hijacking this thread, though …
@XRM You bring up a great use case, and great point!
Let me see if there might be a workaround for this right now. I know we used to implement an Autobaud function for our Async Serial analyzer in the older legacy software. I’ll look into how we did that and will check to see if this is something that can be utilized in your case.
According to what I found, the Autobaud function only works on already visited data, doesn’t it? And it probably wouldn’t help with changing frequencies (i.e. changing during the sample recording), I guess?
I did implement the analyzer the way I described it previously (by extracting and saving the edges to a vector<tuple<U64 (Sample), BitValue, BitValue>>). That works, but lacks the comfort of the existing functions and - as said - is quite a bit of overhead.
@XRM It looks like my memory had served me incorrectly. Our old Autobaud feature simply ran the analyzer twice upon saving the settings (1st run - it looks for the narrowest pulse. 2nd run - it applies a baud rate based on the previously noted narrowest pulse).
Sorry for the overhead that causes. I’ll likely create a new idea post to start tracking interest in this before we commit it to the roadmap. However, I’ll double check with our team here first in case there may be a more efficient workaround.
@XRM, your solution by saving history to a vector is what I would have suggested. We did something similar with the Manchester decoder, since a string of 0s and a string of 1s look identical until an opposite bit is encountered. However in that case I cached the temporary results at a higher level.
Unfortunately, we disabled the feature that allowed analyzers to optionally trigger a re-run after analysis was complete, which is why we removed autobaud support from the async serial analyzer. Your approach of computing the baud rate as you go is a better choice, especially for signals that change baud rate one or more times.
Longer term, we want to re-write the API from scratch, but it’s a very large project. So in the meantime, we’re collecting feedback and suggestions on the API and filing those away for future review.