Created attachment 677 [details] Pulseview screenshot after a successful USB capture lacking D1 LA pin Both D0 and D1 show up consistently on the oscilloscope physical screen, but apparently D1 is not showing up on PulseView. Enabling all LA channels does not show any stray signal, so it doesn't seem to be a matter of data channel labelling? Also, perhaps unrelated, but the CLI doesn't seem to work well (while Pulseview itself finds the oscilloscope and several attributes with no problems): $ ./sigrok-cli -d rigol-ds --scan sr: scpi_usbtmc: Failed to claim interface: LIBUSB_ERROR_ACCESS.
Created attachment 678 [details] Rigol MSO5072 showing both LA channels
Created attachment 679 [details] Closeup of both D0 and D1 channels
Hello, the screenshots unfortunately aren't very helpful. Please set the log level to 5 and re-do the acquisition. Then, please attach the log output as a text file.
Created attachment 680 [details] Level 5 debug of pulseview with Rigol MSO5072 and LA
The log level is correct there but no acquisition was performed, you probably didn't click "Run".
Created attachment 683 [details] pulseview ran from console with level 5 debug as instructed, then clicked Run, then Stop. No channel D1 seems to be present when it actually should.
sr: [00:17.444613] rigol-ds: Starting reading data from channel 1 sr: [00:17.445019] scpi_usbtmc: Successfully sent SCPI command: ':WAV:SOUR D0'. ... sr: [00:17.897897] session: bus: Received SR_DF_LOGIC packet (1000 bytes, unitsize = 1). ... sr: [00:17.898396] rigol-ds: Starting reading data from channel 2 sr: [00:17.898718] scpi_usbtmc: Successfully sent SCPI command: ':WAV:SOUR D1'. ... sr: [00:18.356682] session: bus: Received SR_DF_LOGIC packet (1000 bytes, unitsize = 1). ... sr: [00:18.357521] session: bus: Received SR_DF_FRAME_END packet. With that, the driver isn't actually muxing all logic channels together but sending 1000 samples for every logic channel, which is obviously wrong. The reason D1 doesn't show up is because its sample data follows the 1000 samples that were sent for D0, making it appear as if it were part of D0.
The PLA2216 is an active LA probe: https://www.digikey.com/product-detail/en/rigol-technologies/PLA2216/2211-PLA2216-ND/10468148 https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0914/0/-/-/-/-/PLA2216_users_guide.pdf Could it be that it's actually sending those inputs in parallell instead of muxing them? Or you mean it forcibly has to mux those 16 digital signals on the USB comms between scope and computer?
The scope and probe are ok, it's the libsigrok driver that's messing up.
I agree on the analysis from comment 7. It's OK to gather logic data from the acquisition device in multiple SCPI requests, but then the driver should combine these sample values and send _one_ logic packet which communicates _all_ logic channels at the same time to the session. It's a driver bug.
And it's actually the same symptoms as bug #1191 is showing with the Rigol MSO1xxx series (back in 2018): https://sigrok.org/bugzilla/show_bug.cgi?id=1191 And perhaps tangentially related with some recent GLScopeClient bugs: https://github.com/azonenberg/scopehal-apps/issues/146#issuecomment-661896030
Soeren, Gerhard, At a high level, how would you implement a fix for this? Would it make sense to have a queue/ring buffer that keeps some sort of order?: https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/hardware/rigol-ds/api.c;h=426b9f9072339bff1bad95a53d82705720a17fdf;hb=HEAD#l1012 That would impact the Live view performance though, so a bit torn... I'm not acquainted with the codebase (yet) and also wonder if other drivers that you might know or vaguely remember have solved this very problem already in the past?
I opened PR#95 (https://github.com/sigrokproject/libsigrok/pull/95) Could you please try, if this fixes the issue for you? It is a cleaned-up version of my github repo you already looked at about 2 weeks ago