<d1b2>
<azonenberg> (oops discord bridge didn't tag you... @louis)
<azonenberg>
MP tells me you're working mostly on the Tek MSO5/6 driver so far
<azonenberg>
found a few bugs/segfaults? I'll take PRs for any small fixes whenever you're ready to send them
<azonenberg>
also interested in performance data from MSO5 with most recent firmware as a benchmark for comparison
<azonenberg>
both against future/past firmware and the MSO6 we did initial dev against
<azonenberg>
I'm also curious if you're using the LXI or raw SCPI ("lan") transport and, if so, whether you've seen significant performance or stability differences between them
<azonenberg>
my recollection from initial development was that both were unstable, but the failure modes varied between them
<d1b2>
<louis> Just PR-ed my initial changes that fix some segfaults and gets scopehal talking to our MSO5 at least 🙂
<d1b2>
<louis> Not at the office anymore but I'm happy to run the perf stuff against the MSO5. I've been using the raw SCPI transport; haven't tried LXI
<d1b2>
<louis> Haven't observed any scope firmware crashes, but have observed some connection instability ("Socket read failed (errno=11)") and poor-ish UI performance
<d1b2>
<louis> Also, crashes so much as to be unusable on my iGPU (inside iris_dri.so) but works (albeit not great responsiveness) on my Nvidia (M2000M) dGPU
Oberon4278 has joined #scopehal
Oberon4278 has quit [Ping timeout: 256 seconds]
Oberon4278 has joined #scopehal
<azonenberg>
re GPU, interesting. I have noticed some instability on intel cards in the past but i thought that was fixed
<azonenberg>
I'll look into it
<azonenberg>
louis: as far as perf stuff, it's pretty simple. just pick a few representative combinations of memory depth and number of enabled channels, run for a little while, and look at the WFM/s counter in the status bar
<azonenberg>
also let me know the exact FW version you're running
<bvernoux>
Mbps means Mega bits per seconds but I think you want to say Mega Bytes per sec so MBps
<bvernoux>
or just clarify Mega Bytes per sec
<bvernoux>
Also I doubt Pico 6824E really output 3127 Mega Bytes per seconds (3.1GigaByte/s) which is impossible with USB 3.0 which is limited to 5Gbit/s so I suspect for that measurement you want to say it is 3127Mbits/s
<bvernoux>
After check the number seems to corresponds to Megabits/s
<bvernoux>
I confirm Rigol MSO5k reach max <6Mbytes/s so about 60Mbit/s
<bvernoux>
which in most case is < 50Mbit/s
<bvernoux>
maybe it will be great to clarify it anyway
<Degi>
Can the Rigol reach that continuously? When I try to read longer waveforms it waits for a few seconds (presumably transferring the data somewhere internally) and then sends at 50 Mb/s for a bit
<bvernoux>
No it cannot
<bvernoux>
it is BEST case ;)
<bvernoux>
The firmware is clearly buggy for SCPI
<bvernoux>
What is bad is with 10Kpoints or 1Mpoints it is about same speed about 1WFM/s
<bvernoux>
I was in discussion with Rigol R&D but they do not provide any update now
<bvernoux>
they was pushing release of new firmware for Rigol MSO5k multiple time and now they do not provide any feedback ...
<bvernoux>
So yes Rigol are not serious to support their Oscilloscope ...
massi has joined #scopehal
someone-else has joined #scopehal
massi has quit [Remote host closed the connection]
<d1b2>
<mubes> That's a terrible shame...in so many respects it's one of the best of the cheaper class. I only see the Siglent/Rigol competition ending up one way if that's their attitude to bugfixing and enhancement :-(
<Degi>
To be fair, it might be a hardware bug (as in too little bandwidth between the different processing units, like if they're just connected by a single lane 50 MHz SPI link)
<Degi>
Though not entirely, that wouldn't explain why 10 kSamples is still slow
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
<azonenberg>
bvernoux: i very much mean megabits
<azonenberg>
that's how network traffic is normally measured
<azonenberg>
as far as the MSO5K, this is a perfect example of why i have separate data in the chart for each memory depth etc
<azonenberg>
The bandwidth in the charge is a long term average
<azonenberg>
i.e. if you have deep memory and record total WFM/s and bits transferred per frame
<azonenberg>
the peak transfer rate will be slightly higher because of the internal freeze
<azonenberg>
and yes, i fully expect siglent to flatten rigol long term
<azonenberg>
based on how serious siglent seems to be about high quality products
<Degi>
Hmm, so maybe the data rate should be lower for the MSO5k, as it doesn't spend all its time transferring data. I think for large depth it should be approximately half and for small depths, much much lower.-
<azonenberg>
The data rate in the spreadsheet is calculated from reported WFM/s and the size of a waveform
<azonenberg>
in both samples/sec and bits/sec
<d1b2>
<MP> @louis let me know when you want me to swap out the MSO5 you’re working on for the MSO6 (but please use the 5 as long as possible I need the 6 ;p)
<bvernoux>
azonenberg, Yes I have seen it is automatically computed so we understand it is Megabits/s
someone-else has quit [Ping timeout: 240 seconds]
<bvernoux>
I'm doing some USB3.0 test on my side ;)
<bvernoux>
with an ASIC
<bvernoux>
So far I reach 328.2 MBytes/s with USB Bulk Read
<bvernoux>
and 249.9 MBytes/s with USB Bulk Read
<bvernoux>
using libusb with libusb_bulk_transfer and buffer of 4194304 Bytes
<bvernoux>
I'm pretty sure I can improve that as on ASIC embedded size it just use 4KB buffer per EndPoint IN/OUT
<bvernoux>
size->side
<bvernoux>
The fun with USB 3.0 is it consume less than 1% CPU for such ultra fast Data Transfer
<bvernoux>
on my very old PC ;)
<bvernoux>
It is clearly day & night when compared to USB 2.0 HS
<azonenberg>
usb 2.0 is an objectively awful protocol :p
<bvernoux>
yes clearly ;)
<bvernoux>
USB is a mess on driver side anyway especially on Embedded ;)
<bvernoux>
On Windows/Linux with libusb it is trivial
bvernoux has quit [Quit: Leaving]
<d1b2>
<louis> I see no support for any coupling options other than AC, DC, "DC Reject, when supported by probe" for any of the Tek MSOx stuff in the programmers manual
<azonenberg>
Ok
<azonenberg>
in that case, delete it
<azonenberg>
On some scopes "DC" coupling grounds the input, and is used as a self-test or to measure noise floor
<azonenberg>
i.e. completely disconnected from the probe
<azonenberg>
What does the "DC reject" feature do?
<azonenberg>
how does it differ from AC coupling?
<azonenberg>
We don't have such a thing in the APIs yet but we can add it if it makes sense
<d1b2>
<louis> Hm. So reading the user manual, it mentions GND coupling in passing, but there isn't any mention of it in the programmers manual, and it doesn't appear on our MSO5. Mistake, maybe.
<azonenberg>
Yeah possibly
<d1b2>
<louis> The user's manual also never mentions the term DC Reject Coupling... so who knows what that means.
<azonenberg>
For now then just report AC and DC
<azonenberg>
Re the null deref, IIRC MSO6 has a dedicated external trigger channel, so i probably assumed there would always be one
<miek>
i'd guess that you need a suitable active probe plugged in for it to show up. it's explained more in the probe user manuals: "When using an active probe, users should use the probe’s offset control. Probe offset can be used to subtract out the DC component of the signal in the probe amplifier. With the DC portion of the signal removed, the user may now accurately evaluate and measure the AC portion of the
<miek>
signal. On select differential probes, Tektronix offers a feature called DC Reject. DC Reject automatically generates an internal offset that cancels the DC component of the signal."
<azonenberg>
if MSO5 does not, then yeah that would pose problems
<azonenberg>
miek: interesting. wouldn't the DC component be rejected by it being differential though?
<d1b2>
<zyp> how so? you can still have differential DC even if the common mode DC is rejected
<azonenberg>
oh so this is for rejecting a DC offset on a *differential* signal?
<azonenberg>
that's an interesting idea but it seems like it would usually be undesired
<azonenberg>
as an actual differential input stage normally would pass that on
<_whitenotifier-e>
[scopehal-apps] azonenberg c4891ef - Refactoring: Removed all calls to IsOverlay()
<_whitenotifier-e>
[scopehal-apps] azonenberg 20ca987 - Make sure to properly handle initial input connections for filters when the inputs are not changed in the dialog
<electronic_eel>
maybe the "dc offset" feature works by replacing one of the differential probe legs with a generated dc signal and it is just documented badly?
<electronic_eel>
some differential probes and amplifiers offer such a feature. but usually you can control the dc offset value.
<electronic_eel>
maybe they use some kind of servo feature in the scope to automatically set it instead of having the user enter an offset voltage
<azonenberg>
i think the latter makes more sense
<azonenberg>
as far as replacing leg with dc signal, that is actually what i plan to do in my scopes
<azonenberg>
I want to make the scope frontend have two inputs per channel
<azonenberg>
inP/in and inN/ignored
<azonenberg>
in diff mode the first stage amp outputs inP - inN
<azonenberg>
in SE mode it outputs inP - internally generated offset
<Degi>
How does that compare to adding a differential offset?
<azonenberg>
This would not support offsets for differential mode signals
<azonenberg>
doing that would require a second amplifier somewhere
<electronic_eel>
what would the usecase of adding a differential offset be? are there any kind of signals where that is needed?
<azonenberg>
If you had a differential signal with an offset of some sort, maybe. the only scenario i can think of would be a DC coupled differential measurement of laser intensity for a fiber optic system
<azonenberg>
where you modulate between two laser intensities rather than on/off
<azonenberg>
but i think such gear ~always has single ended AC coupled outputs
<Degi>
Hm yes, how would you even make that differential
<Degi>
Maybe a polarization modulated receiver heh
<azonenberg>
yeah idk
<azonenberg>
anyway, point is, i had no intention of supporting offsets on diff channels because i couldn't see a use case for it
<Degi>
Though the ones in SFP modules are differential sometimes
<azonenberg>
yeah but those are ac coupled and centered on zero
<Degi>
yeah
<azonenberg>
and they're output of a limiting amplifier
<azonenberg>
not raw laser intensity
<Degi>
Yes, usually even the photodiode inside has a builtin limiting amplifier
<electronic_eel>
hmm, maybe it could be useful in some physics experiements, where you measure miniscule changes behind a diff amplifier
<azonenberg>
like, dont get me wrong i'm sure you can come up with a use case
<azonenberg>
whether it's worth the extra engineering effort is another question
<azonenberg>
and all the evidence seems to say no
<Degi>
Hmm yes, for signals with small RF part and large LF / DC part which you could track and essentially increase your dynamic range