Capture rate not working in the rust SDK (Picoscope 2207)
Fallstop opened this issue · comments
Hi there,
I have noticed using the Rust SDK example code with a Picoscope 2207, that the capture rate is not changing depending on the capture rate chosen in the CLI. It streams at a non-consistent rate, as low as the data points being ~75 ms apart (13Hz), to the fastest I have seen of the data points being ~3 ms apart (300Hz), quite below anything useable for my purposes.
Proberly related, the prompt misses the 1Gz option, and the 100 MS/s errors when chosen with this error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: PicoError { status: INVALID_SAMPLE_INTERVAL, context: Some("start_streaming") }', src/main.rs:108:42 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Panic in Arbiter thread.
I haven't tested if this issue is still a problem in the feat/improve branch, let me know if you want me too, or anything else.
Other than the capture rate weirdness, this is an amazing library that is a whole lot better than the official libraries from Picoscope, I really hope I will be able to use this than switching languages to use the official libraries.
Edits: Updated the actual streaming rate info
I haven't had a chance to look into this yet but here are a few things to keep in mind.
When running the example CLI or any Rust examples looking at throughput or performance, ensure you're compiling in --release mode. You might already be doing this but it's often overlooked.
Since this SDK currently only supports continuous gap-less streaming, the capture rate in this mode is device and USB specific. Assuming you have the discontinued 2207 in the blue case, the datasheet says the maximum streaming rate is 1MS/s.
More modern Pico devices are capable of much higher streaming rates. For example the 2206B/2406B devices can stream at 31MS/s and most of the USB 3 devices can stream at over 100MS/s.
Block Mode
Pico devices support much faster capture rates in Block Mode but for this mode to be useful we would need triggering too. I've not implemented either yet.
I will look into doing some testing on the official libraries, and confirm that is not just my outdated oscilloscope being broken.
Suggestions
Definitely not the --release tag, I tested that before when I noticed the performance degradation wasn't caused by the console output.
datasheet says the maximum streaming rate is 1MS/s
I didn't see that, it would be a bottleneck, but not nearly a 13-700Hz bottleneck.
Block Mode and Triggering
This sounds quite interesting and would be a great way to implement the stuff I am currently working on (If it isn't crazy complicated to implement).
I have also taken a deeper look into the data points and found they where running oddly consistently, coming in a consistent ms apart.
Hopefully, we can work this out.
Just tested my Picoscope using the official python library, highest reading was 998kHz in streaming mode, actually close to your stated 1MS/s limit in streaming mode.
Can you share some example code that demonstrates what you're describing?
In my testing, I get data to the callback every 50-100ms but for every callback I get multiple data points.
Cool, I will adapt the example code to add the relevant measurements.
After a long time of not touching it, then coming back, I realised the library is actually amazing, and the example was tripping me up because I kept this piece of code from the example CLI:
Which threw away everything after the first voltage point. Fixed by swapping it out for scale_samples(), and now my speed measurements match up with the ones your library generates. Thanks anyway, issue resolved.