-
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`
|
I got testing this tonight, ran into a small issue with the build. This was due to GetMso5000AnalogBankUsage not being declared. I've attached my commit for reference. murdoa@42dc699 Great work! It was a lot of fun testing out the DS1054Z on ngscopeclient with your contributions. |
|
@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. |
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