<d1b2>
<josHua> I have convinced scopehal-apps to compile on my Mac, after fighting quite a bit with homebrew, and I have connected it to my dho4000. I get, so far: ERROR: RigolOscilloscope::GetSampleRatesNonInterleaved not implemented for this model ERROR: RigolOscilloscope::GetSampleDepthsNonInterleaved not implemented for this model ERROR: RigolOscilloscope::GetInterleaveConflicts not implemented for this model [... and then a lot of the
<d1b2>
GetInterleaveConflicts message, at one per frame or so ...] when I go to the timebase config menu, and nothing in the dropdowns available
<d1b2>
<azonenberg> @fredzo_72653 ^
<d1b2>
<azonenberg> @josHua so what's happening there is that the driver doesn't include the table of legal sample rates, memory depths, or which channels conflict with interleaving
<d1b2>
<azonenberg> And thus it can't control the timebase. Few if any scopes provides APIs to query this
<d1b2>
<azonenberg> so you need a hard coded table in the driver based on model names
<d1b2>
<azonenberg> does the scope otherwise work as long as you aren't trying to control the timebase (i.e. setting up timebase via front panel controls on the scope)?
<d1b2>
<josHua> it does acquire a waveform, but the trigger is not aligned with the trigger on the Rigol's display. I would take a screenshot from the Rigol's display but the Rigol's web interface has locked up
<d1b2>
<azonenberg> So maybe the driver isn't pulling the trigger position correctly either
<d1b2>
<azonenberg> RigolOscilloscope::GetTriggerOffset() is the function of interest
<d1b2>
<josHua> this does indicate that the trigger position does not quite seem to be correct, though
<d1b2>
<azonenberg> Is the position offset by half the total acquisition memory length?
<d1b2>
<josHua> let me zoom out on the scope for that matter and see if the timebase is correct
<d1b2>
<azonenberg> there is often a mismatch in formatting here
<d1b2>
<azonenberg> a lot of scopes reference trigger position to the center of the display
<d1b2>
<azonenberg> while scopehal references it from the start of the acquisition
<d1b2>
<azonenberg> so sometimes you need to add/subtract half the memory length from the trigger position to translate between the two APIs
<d1b2>
<azonenberg> So if you put the trigger position just right of the center of the plot and scopehal shows it just after the start of the waveform, that's the bug
<d1b2>
<josHua> the timebase does seem to be correct (i.e., the capture is 20us wide, and it is also 20us wide on my display)
<d1b2>
<azonenberg> Yep. It's just missing the table of which values are legal in the dropdown
<d1b2>
<josHua> I think I may be missing some bits of precision here (the waveform on my display seems 8-bittier than it is on the scope's display)
<d1b2>
<azonenberg> i.e. an array of all possible sample rates, all possible memory depths, etc
<d1b2>
<azonenberg> very possible, i dont know if the rigol driver supports >8 bit waveform transfer yet
<d1b2>
<azonenberg> I wrote the original rigol driver back on my DS1102D in 2010 ish
<d1b2>
<azonenberg> and since that scope broke have relied on other people to maintain it 🙂
<d1b2>
<josHua> let me see if I can figure out how to adjust the trigger position on the scope. I am embarrassed to say I have not done this before on this unit. usually capturing off-center triggers or trying to use the actual memory depth of the scope makes the scope unbelievably slow
<d1b2>
<josHua> this is the downside of a scope-of-cheap
<d1b2>
<azonenberg> anyway, by all means file tickets against scopehal for the specific problems so we can work on them
<d1b2>
<azonenberg> by "we" i mean fredzo probably since i dont have a DHO to test with
<d1b2>
<josHua> I think my conclusion is that the driver simply has no idea what the trigger position is
<d1b2>
<josHua> I messed with it on board the unit and did achieve an off center capture that still indicates that it starts at 0 fs
<d1b2>
<azonenberg> If you change trigger position on the scope, scopehal has no way of knowing that
<d1b2>
<josHua> yeah I hit the 'resync' button
<d1b2>
<azonenberg> All of our drivers aggressively cache settings clientside
<d1b2>
<azonenberg> ah ok
<d1b2>
<azonenberg> Pop open the SCPI console and send :TIM:MAIN:OFFS?
<d1b2>
<azonenberg> see if you're getting a value that matches what the driver is expecting?
<d1b2>
<josHua> and in fact, typing '10us' in the trigger window and hitting enter causes it to immediate return the text field to 0fs
<d1b2>
<josHua> interestingly, when I adjust the horizontal position on the scope, but do not recapture, the :TIM:MAIN:OFFS? changes, so that is at least not an entirely reliable representation of 'what was the trigger offset of the most recent capture'
<d1b2>
<azonenberg> Yep. This can happen with gain/offset too
<d1b2>
<azonenberg> keeping things synced can be an adventure
<d1b2>
<josHua> oh yeah, also, model number is not a reliable way to know what bandwidth is available on a Rigol scope
<d1b2>
<josHua> especially on a Rigol scope, for that matter
<d1b2>
<josHua> my scope reports itself still as a DHO4404, but, uh, has a key installed to make it 800MHz capable
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> is there an option command or something to ask what the actual BW is?
<d1b2>
<josHua> yeah I was just about to pop open the SCPI programming guide for it to see
<d1b2>
<josHua> I think you have to ask it about each option independently by asking it :SYS:OPT:STAT? BW2T4 (and BW2T8 and BW4T8); 0 means 'no option', 1 means 'yes, option is installed'
<d1b2>
<azonenberg> lol lovely
<d1b2>
<azonenberg> well, if you wanna write some option identifying code for rigol, send a PR
<d1b2>
<azonenberg> Just sync up with fredzo if yo're gonna be doing any significant work on the driver so you don't step on each other
<d1b2>
<josHua> also you have to ask it :SYST:OPT:STAT? RLU to know whether you get the memory depth option
<d1b2>
<josHua> what is the usage of GetSampleDepthsInterleaved vs. NonInterleaved? for example, on the dho4xxx, you get up to 500M samples in one channel capture, up to 250M samples in two channel capture, and up to 125M samples in three or four channel capture
<d1b2>
<azonenberg> Sooo on scopes that support 4-way interleaving it gets tricky, we actually have an open ticket for exploring ways to improve the API
<d1b2>
<josHua> aha, you can get the X offset with :WAVeform:XORigin?
<d1b2>
<azonenberg> fundamentally the way we normally have done it is that interleaved is with 2-way interleaving (4 channels -> 2)
<d1b2>
<azonenberg> while non-interleaved is with all channels active
<d1b2>
<azonenberg> and doing this in scopes where you explicitly turn interleaving on/off, like lecroy
<d1b2>
<josHua> aha, yeah, the dho4xxx is all-interleaved-all-the-time
<d1b2>
<azonenberg> For scopes like pico where it's done for you, and can vary, what we've done instead is made the interleaving always report "off"
<d1b2>
<azonenberg> and then have the table be dynamic
<d1b2>
<josHua> that makes sense
<d1b2>
<azonenberg> so the list of memory depths and sample rates it shows is adjusted on the fly based on which channels are active
<d1b2>
<josHua> hm ok I am looking at this: //Set up the capture we're going to store our data into auto cap = AllocateAnalogWaveform(m_nickname + "." + GetChannel(i)->GetHwname()); cap->Resize(0); cap->m_timescale = fs_per_sample; cap->m_triggerPhase = 0; cap->m_startTimestamp = time(NULL); double t = GetTime();
<d1b2>
cap->m_startFemtoseconds = (t - floor(t)) * FS_PER_SECOND; I assume startTimestamp has nothing to do with the trigger? is there som eobvious member variable I should fill with :WAV:XOR??
<d1b2>
<azonenberg> So that is actually slightly incorrect, we should be usding floor(t) to set m_startTimestamp
<d1b2>
<azonenberg> tl;dr start timestamp is the wall clock time of the beginning of the waveform
<d1b2>
<azonenberg> as UTC seconds in time_t format
<d1b2>
<josHua> got it. which this scope can't really know, so we fake it.
<d1b2>
<azonenberg> start femtoseconds is the fractional time since the UTC second, in femtoseconds
<d1b2>
<azonenberg> Yep
<d1b2>
<azonenberg> If the scope doesnt report a server-side timestamp we use clientside time
<d1b2>
<azonenberg> but yeah that code gets the time twice
<d1b2>
<azonenberg> so there's a race condition if the second rolls over between those two lines
<d1b2>
<azonenberg> (you should fix that as long as you're poking at it)
<d1b2>
<josHua> yeah I just did
<d1b2>
<azonenberg> the timestamp should also be the same for all channels in the waveform
<d1b2>
<azonenberg> so if you're grabbing several channels the GetTime() call should be moved outside the loop
<d1b2>
<azonenberg> all channels in the acquisition*
<d1b2>
<josHua> hm so m_triggerPhase is meant to be used for trigger-to-ADC-clock
<d1b2>
<azonenberg> Correct
<d1b2>
<azonenberg> as with the timestamp, we use a value the scope reports if it has one
<d1b2>
<josHua> but... can it be used for capture X offset?
<d1b2>
<azonenberg> if not, some drivers do clientside sub sample interpolation
<d1b2>
<azonenberg> You mean offsetting the start of the capture from time zero on the timeline?
<d1b2>
<josHua> yes
<d1b2>
<azonenberg> yes, we do that routinely for deskewing multiple scopes or channels relative to each other
<d1b2>
<josHua> ok. the documentation says it should be 0 to 1 sample-ish, but is not always
<d1b2>
<josHua> and in this case it will be like 5,000s amples
<d1b2>
<azonenberg> it can be arbitrarily large and all filters should handle that properly
<d1b2>
<azonenberg> (if you find anythat don't it's a bug and should be reported as such, however some filters do expect that both inputs have similar trigger phase values... this is a sort of precondition we should document better)
<d1b2>
<azonenberg> i.e. things like the multiply filter just do pairwise multiplication of samples
<d1b2>
<azonenberg> and assume the inputs are aligned in time
<d1b2>
<azonenberg> while most of the digital decodes will handle inputs with arbitrary skews relative to each other since the first thing they do is normalize all of the inputs by sampling them on edges of the clock
<d1b2>
<azonenberg> and that sampling is done in absolute time units not sample indexes
<d1b2>
<josHua> well, the triggerPhase should be the same for all channels
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> Its only an issue if you have math between channels from different scopes
<d1b2>
<josHua> ok this is good. the trigger position is not correct but the xoffset is now at least
<d1b2>
<fredzo_72653> Hi @azonenberg @josHua sorry I'm late for the party !...
<d1b2>
<josHua> no worries, I probably should go back to doing real work anyway
<d1b2>
<fredzo_72653> Yes @azonenberg I had noticed that trigger setup window was throwing "not implemented" logs, but did not touch that part on my patch
<d1b2>
<azonenberg> looks at ngscopeclient decoding client data at work
<d1b2>
<josHua> let me put up a PR for what I have, hopefully I will not step on anything you were working on @fredzo_72653
<d1b2>
<azonenberg> why not both
<d1b2>
<azonenberg> :p
<d1b2>
<fredzo_72653> Not working on anything right now, all my work has been merged by Andrew, no worries
<d1b2>
<azonenberg> Ok well just make sure to coordinate if you're both working on the same driver
<d1b2>
<fredzo_72653> So at least @josHua the fix on model number detection did the trick for your DHO4000 ?
<d1b2>
<josHua> my DHO4000 did successfully detect. it detected the wrong bandwidth, I have a patch for that that I will put up in a second
Degi has quit [Ping timeout: 255 seconds]
Degi has joined #scopehal
<d1b2>
<fredzo_72653> Yep saw that, there is a comment in the Siglent driver too about BW option detection... well done !
<d1b2>
<josHua> @fredzo_72653 maybe some of this can be reused on DHO1000 too
<d1b2>
<josHua> I have like 23847329 projects right now so I don't promise that I am going to come back to any of this in a timely fashion. but I figured since I saw some activity on DHO4000 I would come in and show my support at least