[Siglent SDS2000X Plus] Partially broken 8/10-bit mode switching; Slow data acquisition in 10-bit mode

[hansemro]

Setup

• Arch Linux
• scopehal-apps (master: 18a4876430)
• scopehal (master: 148899e)
• SDS2104X Plus (with no software upgrades) connected via lan
  • Hardware revision: 05-05
  • Tested versions:
    • v1.3.9R10
    • v1.3.9R12
    • v1.5.2R3

Issue Description

• The :WAVEFORM:WIDTH setting does not update between BYTE and WORD when changing between 8- and 10-bit ADC modes, respectively.

  • Get/SetADCMode should have sent the command to set width, but the setting does not change.
    • Need to investigate why it fails and where it should be set.
    • Use :WAVEFORM:WIDTH? in SCPI console to query the width after changing the setting.
  • This results in invalid waveform rendering and timescale when WIDTH is not correctly assigned.
  • Example invalid 8-bit waveform with WORD width:
  • Expected 8-bit waveform with BYTE width:
    
  • Can be fixed temporarily by manually setting waveform width in SCPI console after changing ADC mode.
  • Python script to reproduce bug: https://gist.github.com/hansemro/e5d3fd1bca6d77f0093db05071f69991

• [minor issue] Get/SetADCMode should not expect a reply when sending a set command.

  • Fixing this eliminates some Socket read failed warnings and improves minor slow downs when switching between modes.
  • https://github.com/glscopeclient/scopehal/blob/148899e23459d7417414a6cc3727053ade69ae77/scopehal/SiglentSCPIOscilloscope.cpp#L3245
  • https://github.com/glscopeclient/scopehal/blob/148899e23459d7417414a6cc3727053ade69ae77/scopehal/SiglentSCPIOscilloscope.cpp#L3251
  • https://github.com/glscopeclient/scopehal/blob/148899e23459d7417414a6cc3727053ade69ae77/scopehal/SiglentSCPIOscilloscope.cpp#L3281
  • https://github.com/glscopeclient/scopehal/blob/148899e23459d7417414a6cc3727053ade69ae77/scopehal/SiglentSCPIOscilloscope.cpp#L3286

• Slow data acquisition while in 10-bit mode due to expecting twice more data than received from the scope.

  • Data acquisition and processing (for single trigger) takes ~15.5 sec per enabled channel!
  • Issue related to hdSizeWorkaround in SiglentSCPIOscilloscope::ReadWaveformBlock.
    • With the versions tested and tracing enabled, I see that the waveform data length doubles when switching from BYTE to WORD waveform width. I suspect the broken SetADCMode lead to the current size workaround.
      • BYTE: [SiglentSCPIOscilloscope::ReadWaveformBlock] INITIAL PACKET [000010000]
      • WORD: [SiglentSCPIOscilloscope::ReadWaveformBlock] INITIAL PACKET [000020000]
  • Data acquisition in 10-bit mode always results in Socket read failed warnings due to increased data length.
  • By not doubling length of data, we can reduce data acquisition and processing to 228.6 ms per enabled channel!

Relevant Development Branches

• https://github.com/hansemro/scopehal/commits/siglent-sds2000xp-10bit-fix

[azonenberg]

The current hdSizeWorkaround (tested on 1.3.9R6) is caused by the waveform data length not doubling in size on older firmware revisions. Presumably Siglent fixed the issue (we reported it to them).

So we'll need to add a conditional to the code to enable it only on versions older than XX (may need to try a few versions and/or read release notes). That was always the intent, however at the time I wrote the code it was unfixed and I was using a loaner scope, so I haven't been able to test any newer versions.

[hansemro]

Unfortunately, since I have a newer hardware revision (05-05) and cannot downgrade to versions below 1.3.9R10 (due to rollback protection), I cannot confirm the bug in older versions. Release notes do not clearly specify fixing this bug, but it seems fixed from what I can tell.

For now, I will just assume versions 1.3.9R6 and older will require the workaround.

[hansemro]

Updated post with python script to reproduce :WAV:WIDTH bug.

[azonenberg]

• @mubes

Can you test this on your older hardware rev 2000X+?

[mubes]

Yes, I'm on vacation the end of this week so should have some time.

…

On Mon, 24 Jul 2023, 20:50 Andrew Zonenberg, ***@***.***> wrote: - @mubes <https://github.com/mubes> Can you test this on your older hardware rev 2000X+? — Reply to this email directly, view it on GitHub <#784 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD4H6LEAFEL5YMGVN2LXR3GX5ANCNFSM6AAAAAA2VBRUFE> . You are receiving this because you were mentioned.Message ID: ***@***.***>