-
Notifications
You must be signed in to change notification settings - Fork 125
WIP: Rigol oscilloscope refactor #1017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Differentiate between scope families and then group their common behavior in switch statements. This is more flexible approach and allow more fine tuned, per family behavior than immediately grouping them by protocol. - use smart pointers where it makes sense - use vector/array rather than C arrays DS1000Z - implemented memory/samplerate configuration - improved download speed - improved trigger poll performance/robustness Other families should have same handling as before.
to make sure all scope families are handled everywhere
When trigger offset was beyond memory range, at least DS1000Z never received trigger.
This is necessary, because samplerate changes timebase. While TB changes, Rigol oscilloscopes keep the trigger position constant relative to the capture mid point. Because scopehal reference point is at start, the trigger has to be updated to keep it constant from scopehal's POV.
As interleaving done automatically by scope is not considered to be an interleaving feature, see ngscopeclient#1014
This is happening with the pico-bridge, too, so probably a bug of ngscopeclient itself and not specific to any make or model of 'scopes. |
Initial tests with 1 channel and 1 MB chunks worked fine. Later tests with 2 channels failed, but 500 kB chunk size worked fine, but failed for 3 or 4 channels. It looks like the chunk size (maxpoints), also depends on the amount of enabled channels. There may be still some margin, but it's not worth chaseing it.
Proper resource locking was missing at multiple places. It may not be 100% complete yet.
- change verbose logs to trace - add more trace logs - print detected options - remove purely development logs
There are DHO4000 series scopes, which support 250 MHZ BW limit.
- all the series/model -> limiters logic is now in `GetChannelBandwidthLimiters` - `SetChannelBandwidthLimit` uses values from `GetChannelBandwidthLimiters` and uses nearest higher limit
it is more complicated than expected, no obvious rules
- deduce whole trigger state from data preamble rather than status - resilient against fast triggers skipping transitions - properly handles busy(wait)/armed(run) states
…ies::MSODS1000Z as there are also MSO scopes
MSODS1000Z was the only exception and it works there.
- recognize MSO1000Z as MSODS1000Z (tested) - recognize DHO800/DHO900/DHO1000/DHO4000 (untested)
only `double` for now, but templating allows easy addition of more
…nnel configuration - it may touch channels and it caused bugs when adding LA support
most of necessary includes are already included indirectly
- developed with MSO1000Z series - MSO5000/DHO900 implemented, but not tested
…o `std::optional`
|
@diggit where are we on this, is it ready to review and merge? Are we waiting on more testing? I'd like to get this in for v0.1.1 if possible. |
|
Oh, I did not think, such large code change would go into 0.1.x. It is not just a bugfix as it adds new features. DHOs are still untested and I am pretty sure I broke their support (unintentionally). I'll try to get access to one DHO800 this week, but no guarantees. Except testing, I am finished for now, unless we progress on some linked issues in OP (triggers, timebase updates). |
|
If you want to target 0.2 that's fine. I don't want to push you just checking in on status. |
note from release notes was misinterpretted 5M != 50M
…n `GetSampleDepthsNonInterleaved()` (Rigol scopes do not support interleaved mode)
…levant series and is is not clear, it is is even strictly necessary
no need to match for supported rates as this is already checked at the beginning
… take effect At least on DHO800 series, the scope has to do at least one trigger after new samplerate (time base) is set, before it starts returning thenew value. RUN mode is not enough in this case.
…ger time offset in RUN mode When in STOP, device limits the trigger offset changes to very limited range (at least DHO800)
not sure why it always returned `nullptr` unconditionally
… at once these scopes can send all at once making the transfer significantly faster (half the time)
the only difference are legacy DS1000 series
in recent commit, `maxpoints` got always updated from preamble, while it should happen only when it is zero
this way, we can have invalid value even for integral types
…to set lowest known mdepth and re-read this may happen if the scope memory depth i in AUTO mode and we can't work with that
for safety reasons
…series because at least `ngscopeclient` starts the download when the scope enters triggered state, but the data are not ready yet. So we interpret `TD` as `TRIGGER_MODE_RUN` and flip to triggered/stop later
…mble` just in case so we don't read some garbage
|
DHO800 was mostly working. Some quirks were added. |
|
MSO5072 with upgrade for 4 channels and 200MHz here. |
|
hi @Wiljan1, yeah according to the web, MSO5072 has only 2 analog channels, so the behavior is as expected. I am surprised the model number did not change with mentioned upgrade (upgrading DS1054Z to 100 MHz BW changes the model numbert to DS1104Z). I am not aware of any way how to inject some per instance overrides, so I will look into some alternative way, how to detect available channels. Thanks for the feedback! Though this driver changed a lot since 0.1, this logic did not. |
|
Hi @diggit ,
I think the :SYSTem:OPTion:STATus? can be used to check number of Analog channels, BW :
Let me know if you want me to test something? Thank you |

This is a Rigol Oscilloscope driver refactor.
Related issues #943
I need testers for most scope families (see below).
Refactor
Supported devices and new features
Known issues (TBD):
non device specific
Triggers
Not yet supported devices