<azonenberg>
electronic_eel: there will be a switchable filter in the BLONDEL afe
<azonenberg>
There has to be. with all channels in 12 bit more nyquist is <100 MHz
<azonenberg>
So i'm gonna have a switchable 50 MHz filter that is mandatory in 4ch 12bit 125 Msps mode and can optionally be enabled at higher freqs
<azonenberg>
unsure at this time if i'm going to cascade it with the existing 100 MHz filter in series/bypass, or have an A/B mux
<tverbeure>
An interesting datapoint on my Tek 420A scope: fetching the 4 waveforms in one go (4x 30k points) takes 0.7s. WFMPRE?, which gets the settings for the 4 channels takes ... 1s. WAVF? which combines WFMPRE? and CURV? takes 1.7s.
<tverbeure>
So transferring a string of 800 bytes with just configuration data takes 30% longer than transferring the 120000 bytes of data that you really care about.
<azonenberg>
tverbeure: lol. settings is probably polling all kinds of i2c registers or something
<azonenberg>
Can WFMPRE? change under you or is it constant?
<azonenberg>
modulo instrument settings
<azonenberg>
I generally cache settings aggressively to minimize polling of the instrument and round trip times
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #scopehal
Degi_ is now known as Degi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #scopehal
futarisIRCcloud has joined #scopehal
<azonenberg>
tverbeure: so how is the siglent driver working for you at this point?
<azonenberg>
fairly stable? any major missing features etc? do you have sample rate or memory depth control/querying yet?
<azonenberg>
also miek/degi re agilent/rigol stuff, where do we stand on feature completeness? last i heard they worked pretty well in read only mode but were still missing some set calls
<azonenberg>
Error_404: when you get a chance can you try out tverbeure's siglent improvements on your scope?
<_whitenotifier-f>
[scopehal] azonenberg opened issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing - https://git.io/JfHLv
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing - https://git.io/JfHLv
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing - https://git.io/JfHLv
<tverbeure>
WFMPRE is essentially the same as WAVE:DESC, which you do fetch for each AcquireData. So it changes when you touch the controls of the scope.
<tverbeure>
About the Siglent driver: it's still very beta.
<tverbeure>
It doesn't split up large waveform fetches into smaller parts that don't time out.
<azonenberg>
well i mean that applies to the entire project :p (very beta)
<azonenberg>
and so it looks like my lecroy stuff, that i've been complaining about the performance of
<azonenberg>
is actually pretty fast compared to a lot of other hardware lol
<azonenberg>
curious how a modern keysight or something would compare
<azonenberg>
like an infiniium x series
<tverbeure>
It's also very much one-way: if you set the controls on your scope, the acquisition will usually be fine. But weird stuff can happen when you set v/div etc.
<azonenberg>
possible that's due to cached settings?
<tverbeure>
I don't think so.
<azonenberg>
hit the refresh button on the toolbar to clear the cache and see
<tverbeure>
glscopeclient displayed its first Tek waveforms, BTW. So there's that.
<azonenberg>
Awesome
<azonenberg>
Let me know when you've got something to merge
<tverbeure>
Nothing at all! Most of the stuff is stubbed out with fixed values. :-)
<azonenberg>
Lol
<azonenberg>
Thats about what i figured at this phase
<tverbeure>
Also, the waveform is inverted for some reason. Probably due to unsigned vs signed (again.)
<azonenberg>
Once we have the tek and siglent drivers both reasonably stable and complete, though, i'd love if you'd do a test of the multi-scope support between the two
<tverbeure>
I started out with the Agilent code.
<azonenberg>
so far all of the multi-scope stuff has been tested between my two lecroy's
<azonenberg>
i really want to get a test of different vendors' scopes at some point
<azonenberg>
but not a rush, just know it's on the roadmap
<tverbeure>
Just tried it. The moment mouse-roll-out in the Y axis, things immediately go bad. Like going from a range of 0 to 3V to 0 to 30V on the display, nothing triggering anymore, the scope getting a settings of 11.2V/div etc.
<azonenberg>
Lol
<azonenberg>
so definitely some bugs to work out :p
<tverbeure>
Which makes me wonder: when changing the range on the Y axis in glScopeclient, is it supposed to retain the same steps as the scope? (IOW: not 11.2 V/div?)
<azonenberg>
so that's something we need to think about. internally i zoom with fairly small steps, i think +/- 10% of nominal
<azonenberg>
lecroy handles this fine but i dont know how well other scopes do
<tverbeure>
The moment you set something like 11.2V/div, the scope UI drops all its regular steps and when you turn nobs it goes up in steps of 0.2V or something, instead of something logarithmic. Really annoying.
<azonenberg>
so it works fine then
<azonenberg>
you probably just have to check a coarse/fine adjust knob in the scope UI
<azonenberg>
thats how it works in lecroy at least
<azonenberg>
"variable gain" is what they call it
<tverbeure>
Well... I learned something new today! :-) Pressing on the knob toggles between coarse and fine.
<azonenberg>
glscopeclient prefers fine steps so you can maximize waveforms to use all available ADC range / screen real estate
<tverbeure>
Yes. But right now there's a major disconnect between glscopeclient and the scope when you make changes. This will requires a bit of debugging...
<azonenberg>
i know most of the drivers right now aggressively cache settings and the UI doesn't flush that cache until you hit refresh. i've experimented with flushing on a timer every X seconds or something
<azonenberg>
but that caused disconcerting lag spikes at higher trigger rates
<azonenberg>
the fundamental problem IMO is that the scope has no way to push "setting changed" notifications to you
<azonenberg>
and polling every setting every waveform is slow
<azonenberg>
this is unfortunately an API limitation at the SCPI layer and not something we can solve in software
<azonenberg>
right now i cache everything with ~unlimited lifetime, the rationale being that you are probably either using front panel controls or glscopeclient but not both at once
<azonenberg>
then i allow explicit flushing when you change settings on the scope
<azonenberg>
But i'm open to suggestions to make it configurable etc
<tverbeure>
It's not the cache. The scope isn't armed. I simply scroll in the Y axis. glscopeclient sets a certain new range, the scope updates the image, but ranges are all wrong. Or so it seems.
<azonenberg>
interesting
<tverbeure>
Also: "reload configuration" doesn't do anything until you do a waveform acquire again. Is that expected?
<azonenberg>
Hmm
<azonenberg>
it flushes the cache but new values aren't loaded until you query the instrument
<tverbeure>
Ok.
<azonenberg>
what happens if you click reload then trigger a redraw by, say, scrolling the timeline or resizing the window?
<azonenberg>
any Get*() function with an empty cache shoudl hit the instrument
<tverbeure>
Doesn't query. Only when I restart.
<azonenberg>
Hmm
<tverbeure>
BTW: I think I see what happens. Wrt to the scale.
<tverbeure>
Starting point: 1V/div. all is fine.
<tverbeure>
I scroll out one click. SCPI command: VOLT_DV 1.1111
<tverbeure>
However, scope shows: 11.2V/div!
<azonenberg>
That sounds like a command formatting issue
<tverbeure>
Could this be due to 10x ratio of probe?
<azonenberg>
or parsing
<azonenberg>
i dont think so
<azonenberg>
i think this is more likely related to VOLT_DV being parsed or formatted strangely
<tverbeure>
"C1:VOLT_DIV 1.1111"
<tverbeure>
It's hard to screw that one up with parsing.
<azonenberg>
You'd think
<azonenberg>
what happens if you send VOLT_DIV 1 or VOLT_DIV 1.0?
<azonenberg>
does it jump you to 10V?
<azonenberg>
also what do you get back if you send C1:VOLT_DIV?
<azonenberg>
(at 1V/div)
<tverbeure>
It returns "1.12E+01"
<tverbeure>
Maybe it always needs to be exp notation?
<tverbeure>
Checking the manual.
<azonenberg>
waait
<azonenberg>
e+1? not e0?
<tverbeure>
Yes.
<tverbeure>
So what it returns matches what's on the scope V/div screen.
<tverbeure>
At least that's consistent...
<azonenberg>
oh so you're at 11.2 v/div not 1 for that
<tverbeure>
Yes.
<tverbeure>
Ok. I do this: "C1:VOLT_DIV 1", it returns "1.00E+01" (IOW: off by 10)
<tverbeure>
Ok. I do this: "C1:VOLT_DIV 1E1", it returns "1.00E+02" (IOW: off by 10)
<azonenberg>
sooo it seems like you have to set taking into account probe gain, but not when you get??
<azonenberg>
that's really weird
<tverbeure>
Right.
<azonenberg>
try setting the probe to 1x and see if that changes it
<tverbeure>
Yup.
<azonenberg>
If this is indeed the case, definitely put a comment in the code to this effect because this is VERY not obvious behavior
<azonenberg>
(if you've read the lecroy driver you've probably seen some of my comments complaining about their derpiness too)
<tverbeure>
Ok. After I change it to 1x, it behaves as expected.
<azonenberg>
So confirmed probe gain is multiplied in when setting, but not querying, channel gain?
<azonenberg>
this is tek, not siglent?
<tverbeure>
Siglent.
<azonenberg>
oh
<azonenberg>
we'll need to try with other siglent models
<azonenberg>
i strongly suspect this is a bug in specific models' firmware
<tverbeure>
BTW: the Siglent has probe settings of 0.1X, 0.2X, 0.5X, 1x, 2x, 5x, 10x all the way to 10000x
<tverbeure>
I don't get it.
<azonenberg>
for high voltage maybe?
<tverbeure>
But you'd expect some relays clicking in that case?
<tverbeure>
It seems like a pure SW thing.
<azonenberg>
It is, these are not changing anything in the scope
<azonenberg>
they're scaling factors for the probe
<azonenberg>
i.e. does 1V at the input correspond to 1V at the DUT, 10V, 100 mV, etc
<azonenberg>
with a 10x probe you see 100 mV at the scope input for 1V at the DUT so the scope multiplies by 10 to compensate
<tverbeure>
Yes.
<azonenberg>
but there's no actual gain going on in the scope
<azonenberg>
when you ask for 1V/div you get 100 mV/div on the ADC, then it just scales in software
<azonenberg>
you dont actually get 10x the frontend gain
<tverbeure>
Don't advanced scopes automatically detect that your probe is 10x or 1x?
<azonenberg>
Yes. Generally there's two ID schemes used
<azonenberg>
one is a ring around the BNC that has an pin that mates with a ring on the scope, just a passive resistor to ground
<azonenberg>
scope has a voltage divider to read one of a bunc hof standard values
<azonenberg>
the other is I2C via a proprietary connector for active probes, to either read the constant gain or even configure a frontend gain stage
<azonenberg>
But in no case does the probe gain change anything the scope does
<azonenberg>
the scope sees 100 mV at the input, digitizes it, and it only gets displayed as 1V at the very end
<azonenberg>
if you have a 10x probe and tell the scope it's 1x it will happily tell you that you have a 100 mV signal
<azonenberg>
and it wont know the difference
<tverbeure>
I just plugged/unplugged some probes: the V/div automatically changes. Except for the one for which I changed it manually.
<azonenberg>
anyway, what i think is happening is that the siglent firmware is not applying the probe gain compensation in one direction, but it is in the other
<tverbeure>
Right.
<azonenberg>
on the scpi interface
<tverbeure>
Sigh.
<azonenberg>
So it's a firmware bug, and one we need to work around
<azonenberg>
but definitely comment what scope you saw this issue on
<azonenberg>
because i suspect it's only this model and a few siblings
<azonenberg>
and when the next guy with a siglent has this problem in the opposite direction we'll have to start adding if(model == foobar) checks
<tverbeure>
Yes.
<azonenberg>
this is what the initial *IDN? is for, lol
<azonenberg>
I already have a bunch of quirks in the lecroy driver, it's about time we started having some for siglent :p
<azonenberg>
it's almost like they don't test these things :P
<tverbeure>
Well, there's still the signed/unsigned thing.
<azonenberg>
ah true ok so we had quirks already
<tverbeure>
Right now, I only treat it as signed for the SDS2000X series. But I think it's signed for almost everything (if not all.)
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfHtU
<_whitenotifier-f>
[scopehal] azonenberg 569547a - Added ParseString() to Unit class, as inverse of PrettyPrint()
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfHtT
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfHtZ
<_whitenotifier-f>
[scopehal] azonenberg 47761de - Removed Oscilloscope::PollTriggerFifo() since HasPendingWaveforms() basically does the same thing. Fixes #143.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #143: Remove Oscilloscope::PollTriggerFifo() since it basically duplicates HasPendingWaveforms() - https://git.io/Jfyix
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfHt6
<_whitenotifier-f>
[scopehal] azonenberg c03b494 - Eye pattern: allow center voltage to be specified, so we can plot eyes of signals with a DC offset. Fixes #1.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #1: Eye measurements: allow eye position to be defined somehow - https://git.io/JfHti
<azonenberg>
woo the oldest ticket on the bug tracker is now closed
<monochroma>
:D
<azonenberg>
#2 might be a while, it's about allowing measurements to display overlays on the signal showing the thing being measured
<azonenberg>
e.g. the 20% and 80% voltage levels for a rise time filter
<azonenberg>
there's a lot more thought needed on how to integrate that
<azonenberg>
lain: have you tried recent scopehal with deep captures off your DDA?
<azonenberg>
Re scopehal-apps:#79 i'd like to close as wontfix since i think i fixed a bunch of the big slowdowns
<lain>
azonenberg: have not tried, no
<azonenberg>
i think you'll be pleasantly surprised at how much faster it is now
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #149: Adjust VOLT_DIV if initial try is incorrect. - https://git.io/JfH2p
<azonenberg>
tverbeure: 8 divs/screen is pretty industry standard for scopes that work in divs rather than absolute units
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #149: Adjust VOLT_DIV if initial try is incorrect. - https://git.io/JfH2p
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JfHaT
<_whitenotifier-f>
[scopehal] tomverbeure ff1a2e1 - Adjust VOLT_DIV if initial try is incorrect.
<_whitenotifier-f>
[scopehal] azonenberg 7ac5671 - Merge pull request #149 from tomverbeure/siglent_volt_div_bug Adjust VOLT_DIV if initial try is incorrect.
<tverbeure>
So after this change, things works when you adjust the Y axis while the scope is idle. But it still has the 10x wrong when you're in continuous update mode.
<Error_404>
azonenberg: backlog ack
<tverbeure>
It seems as if the probe bug only manifests itself when the scope is not armed!
<tverbeure>
Or it only manifests itself sometimes.
<tverbeure>
I can work around that by bailing out early: if the value is in the right range after the first try, then don't do the adjustment.
<azonenberg>
tverbeure: makes sense, and wow
<_whitenotifier-f>
[scopehal] azonenberg opened issue #150: RGMII decode only works when link speed is 1 Gbps - https://git.io/JfHVH
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #150: RGMII decode only works when link speed is 1 Gbps - https://git.io/JfHVH
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #150: RGMII decode only works when link speed is 1 Gbps - https://git.io/JfHVH
<Degi>
Hmh maybe we can support 14 bits too
<Degi>
offset etc was in ps right
<azonenberg>
Degi: yes all timestamps are int64 picoseconds
<azonenberg>
this should be documented in Oscilloscope.h in the doxygen comments for each function
<azonenberg>
(if it's not, send a PR to clarify)
<Degi>
yeah it is
<Degi>
Huh now I get a warning td::bad_alloc
<Degi>
Executing make again helped
<Degi>
How do I show what it sent over the connection again?
<azonenberg>
--trace SCPISocketTransport
<Degi>
Ok now I get a std::bad_alloc error which I didnt get before, weird
<Degi>
I wonder why there's two mutexes in GetChannelVoltageRange
<azonenberg>
Degi: one for the cache and one for the scpi link
<azonenberg>
the idea is not to block on access to the scpi if thedata is in cache
<azonenberg>
also you should be locking the cache mutex when updating m_channelVoltageRanges
<azonenberg>
writing to a std::map is not atomic
<azonenberg>
use separately scoped blocks, since by this point there's no need to have the scpi mutex (m_mutex) locked anymore
<azonenberg>
you want to hold that lock for as little time as possible because it causes contention between the ui and waveform download
<azonenberg>
and only grab it if you're certain you need to do scpi stuff, i.e. the data in question is not in cache\
<azonenberg>
and avoid holding both at once
<azonenberg>
because if you hold the cache mutex while waiting for the scope then you're preventing the whole point of the cache
<Degi>
A block is a thing encased by {}?
<azonenberg>
yeah
<azonenberg>
the lock_guard locks the mutex in the constructor and unlocks in the destructor
<azonenberg>
much cleaner and more idiotproof than explicitly calling lock and unlock
<azonenberg>
since returning early or throwing an exception will still unlock it
<Degi>
Hmh ye
<Degi>
s
<azonenberg>
there really should be some dev documentation with this kind of info
<azonenberg>
but i've been busy enough trying to keep the user docs up to date
<Degi>
Can I somehow make the error output more verbose?
<miek>
easiest is probably to run it in gdb & break on the exception
<azonenberg>
yeah that's what i'd do
<azonenberg>
std::bad_alloc is a stl exception thrown saomewhere i wasnt expecting it
<azonenberg>
probably means you have some size massively wrong
<azonenberg>
gdb "catch throw" should break on an exception
bvernoux has joined #scopehal
<Degi>
Thread 5 "ScopeThread" hit Catchpoint 1 (exception thrown), 0x00007ffff6269062 in __cxxabiv1::__cxa_throw (obj=0x7fffdc000f20, tinfo=0x7ffff6393ee0 <typeinfo for std::bad_alloc>,
<Degi>
78/build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory.
<Degi>
dest=0x7ffff6267330 <std::bad_alloc::~bad_alloc()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:78
<azonenberg>
and back up a bit?
<azonenberg>
"bt" gives a backtrace
<azonenberg>
look at the actual scopehal function that triggered it
<bvernoux>
azonenberg, if you are interested I have done full check of SouthWest Microwave connectors bought on ebay for about 5USD/unit with shipping
<miek>
Degi: hang on 'WAV:DATA?' probably means ReadRawData is requesting more than the rigol is sending, so it sits waiting for more
<Degi>
Well it tries to read the right amouint at least
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfH1B
<_whitenotifier-f>
[scopehal-apps] azonenberg 381dbdc - ScopeSyncWizard: Fixed a few bugs. Multithreaded cross-correlations for faster deskewing of deep waveforms. Limited max allowed skew to 10K points.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfHM3
<_whitenotifier-f>
[scopehal-apps] azonenberg 8dc9f32 - Fixed crash during shutdown
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JfHM4
<_whitenotifier-f>
[scopehal] azonenberg 529be21 - RGMII decode: added support for in-band status
<_whitenotifier-f>
[scopehal] azonenberg a7c62c9 - EthernetRGMIIDecoder: now correctly use single or double-rate sampling depending on clock rate. Fixes #150.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #150: RGMII decode only works when link speed is 1 Gbps - https://git.io/JfHVH
<azonenberg>
ok so i think i've done what i can do on the RGMII decode, time to dismantle the test setup and free up some bench space
<azonenberg>
SGMII / 1000base-X is still an open ticket re ethernet
<azonenberg>
but i dont have a board with that readily available right now - there's one but its' a big virtex board racked on the other side of the lab that i dont really feel like moving
<monochroma>
azonenberg: grab a cheap media converter :D