Rigol dho support #246
Open
Rigol dho support #246
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…c Kuzmenko) in this PR : github.com/sigrokproject/pull/176/ Created a new protocol version "E11" matching the latest Siglent SDS Scope programming guide. Reduced the read-wait time from 7sec to 50ms for better performance (achived by looping on read sample logic to consume the data has it arrives). Tested with SDS2504X HD model connected via Ethernet cable.
Based on the work of Diana Ellefson (OrionOth) : sigrokproject#229 and RemiNV : sigrokproject@3430e8e
|
I'm getting a DHO924 for work and was previously doing some testing with a cheap LA and this software. I'm so exited that I can use this software in future with the DSO as well. Btw @fredzo, @i404788 also opened a PR that seems to address one of the limitations you had. This would certainly be cool, if it were merged/included here as well. 👍 Currently thinking, if it's worth the effort to figure out how to compile and use it on Fedora already. Was thinking of making a RPM out of it, but have never made one, just compiling and force-loading the lib for pulseview might work as well. If I do that, I can also give some results on whether it works for me or what is not working. |
|
I managed to get it to build and run this on Fedora (+ the patch pr). I'll test the Oscilloscope later. I'm currently on Fedora 40 KDE Spin. I needed to rebuild pulseview as well or got a linking error on launch, so it is also included. For building, I followed RedHat's Tutorial on Building RPMs. So this is pretty much a Hello-RPM for me. You can download the rpmbuild folder here. It included all sources, adapted spec files for building as well as the built srpm and rpm files. So just download it, optionally rebuild it and overwrite your existing libsigrok by installing these RPMs (
|
|
I tested it yesterday. The DHO924 gets instantly recognized, when attached via USB. Seems to work fine. Also tested TCP/IP connection with success as well. 👍
|
|
I noticed one crash: When I'm connected via USB, using Data source "Memory" and stop the run before everything was downloaded (and it auto-stops), the next time I press "Run", the program gives me this popop. When I press okay, it segfaults:
Stack-Trace:
Text (full GDB Log with all messages)I'm assuming, that early stopping puts the device in some kind of unexpected state. I need to disconnect and reconnect the USB, otherwise this keeps happening every time. I tested a bit around. Only USB with Datasource "Memory" or "Segemented" can trigger this. USB with "Live" as well as all modes over TCP/IP don't cause this. No matter how hard I abuse the Run/Stop button. |
|
Messages: Hitting backspace, when channel name is selected: First typing something over the marked area, then clearing it again with backspaces: (This was using TCP/IP and the default data source "Live") Edit: Actually, this happens even with a Demo Device for me. So it's either me mixing some wrong verions, or some other software back. Probably due to me compiling it most likely not properly. So it's not specific to this PR. |
|
Otherwise works very well. TCP/IP with Memory view is perfect for me. Seems the Firmware on the DHO is either outdated or otherwise misconfigured as it struggles to decode a SPI signal often. (EDIT: I think this was actually user error, is an aside anyway) But with Pulseview this worky very well now!
The first crash probably needs to be addressed first (the 2nd is either my fault or not specific to this specific version). Otherwise I think this is good to go. Can anybody else reproduce the first crash as well? |
|
I've eventually come around testing this too lately. What I am missing most yet is setting the trigger level from within pulseview (I presume this is a lack in the driver not PV but I haven't checked). I can also confirm that the memory capturing is somewhat broken as mentioned above. In my case it completely freezes. -l5 output: |
|
I've played around more and the memory mode is almost completely broken. The first retrieval somewhat works: PV receives and displays data, but the transaction never stops. Manually stopping it ends in an error, and even worse, after that the USB device is not opened correctly anymore without reconnecting the cable. It's very weird though because apparently it can send SCPI IDN commands just fine and thus detects the DHO but the reply to CHA1:DISP? trips it then... NB: I am running the patches on top of some others etc. so I am not sure if it's this PR's fault alone. Will investigate more... |
|
I have printed the fields that Most of the IDN? replies at startup do have a tag of 2. However, I noticed that there is also a similar error there too. It is just benign in my case: Any hints welcome. I have to get some actual work done now... :) |
|
Hi @stefanct, |
|
It's broken with TCP as well. It's just not as broken afterwards but I would assume this is because of the nature of the socket connection rather than the underlying problem. I currently don't have the TCP path instrumented but here is the ordinary debug output that already looks quite fishy. This is also after a first successful (interrupted) acquisition. I've seen some possibly related errors when enabling the memory mode the refer to the sample rate (also with USB and TCP): |
Yeah that's a known issue with the original Rigol driver, which is not fixed by this PR: if you interrupt an acquisition, the scope will keep on sending data which are not consumed by the driver and gets in the way for the next command (see "Got response: '������������..." which is binary data from the previous capture). When this happens, the only solution is to close the session and start over :-/ |
|
Fair enough, but should acquisitions in memory mode end by themselves? Another funny data point: I removed the NB: That's with TCP and using Edit: Disconnecting the ethernet cable from the rigol didn't help - but rebooting it did. I am pretty sure the rigol firmware is very much involved in what I see... |
|
Yeah I can confirm that Rigol's firmware can get in an unstable state regarding SCPI communication, to the point that you have to reboot the scope to get it back on track... |
|
I have a DHO804... and I made the grave error of updating the firmware now from 00.01.02 to the latest from 2024-11-22 (version 00.01.04.00.02). live mode now is broken with... The other modes are not exactly in good shape either :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
This PR is based on the work of Diana Ellefson (OrionOth) : #229
and RemiNV : 3430e8e
It's been discussed on EEVblog forum and tested by different users on DHO 800, 900, 1000 and 4000: https://www.eevblog.com/forum/testgear/new-sigrokpulseview-hardware-support-(siglent-sds-hd-rigol-dho800-)/
I've tried not to change any behavior of the original driver.
Please let me know if you have any comment.
Best regard,
Frederic.