I justed released the Rigol DHO series oscilloscope driver on github, supporting the DHO800, DHO900, DHO1000 and DHO4000 models. The driver originally was a byproduct of the Keysight EXR driver, but some difficulties prevented it to be released earlier with many restrictions still in place as I finaly gave up to find circumventions.
From the github release notes, with additional details added here:
The averaging function is implemented, but the end of averaging must be determined by appropiate trigger timeout as there is no way to either request the amount of successful triggers or to retrieve a respective trigger state that signals that all necessary averages were captured. This is one of the details were the price of these instruments shows, I guess.
Sampling rate is set by memory depth automatically. The SCPI protocol of the Rigol simply does not offer setting the sampling rate manually. Again, you get what you pay for. At least, the AUTO mem peth setting seems to work reasonable to the accrodingly chosen sampling rate seems fine for the usual jobs.
LAN access is very slow compared to USB and this difference caused one problem: for the trigger timeout to work roughly equally well in both cases, a stopwatch is used to gurantee at least 1s between trigger checking cycles as the fast USB access would be much faster otherwise. This way, the trigger timeout value at least is somehow in the ballpark of representing a time in full seconds (my measurements show LAN trigger loop cycle to be roughly around 1.1s).
The biggest decision I had make was regarding the source of data and this is a point I would like to discuss. The released version of the driver uses data from screen, a choice I made after much back and forth argumentation with myself. This has some advantages:
WYSIWYG as the layouters say (What You See Is What You Get). The retrieved data represents whats visible on screen.
Fast transfer: the amount of data is comparatively small, so low transfer times and small data files on harddisk.
There is an alternative choice for data download: accessing the data in the RAM of the scope. This is has one powerfull advantage (if required by the usecase):
Full data will be supplied by the scope in the sense that each single sampling point will be transfered, up to the full 100E+06 points that are available on some models via RAM option.
This however will come with some disadvantages:
Waveform data can grow really huge, especially it does so sometimes as a surprise when the memory size is set to AUTO.
WYSI not WYG: in some cases, depending on memory and timescale, the transfered waveform will include also data outside of the displayed waveform part, which can cause confusion.
The memory access strikly requires the scope to be in STOP mode. This makes the aquisition of the waveform data only possible for SINGLE aquisition that goes into stop mode afterwards or for continuous triggering in which an aritifical stop command is called out after the trigger state is being detected as in “TD” state, essentially making continuous triggering not any different from single triggering.
What do you thing about the decision? What functional advantage and disadvantage weights most?
thanks again for the contribution and let me try to give you some first feedback to your questions/comments:
Averaging: I would guess that there is a register byte to check whether acquisition is still running or often there is a function to ask whether an acquisition is already complete. I guess you already checked for that.
Sampling rate: Auto sampling rate is for most users quite convenient and if there is no other option, one could only contact Rigol to ask for. Somtimes, they might update the firmware.
LAN communication: Typicall Ethernet/TCPIP communication is quite fast. Can you make sure that you do not run into any communication timeout where you always wait for 1 second after each command?
Data: I also think that taking the data on the screen is the better solution. Typically, the Scope module is configured to exactly have the correct time span and voltage ranges. All other Scrope drivers then also return the shown data. If a user needs more data one can extend the time range or the voltage ranges.
Let me know whether you would like to discuss further points. The code itself I will have a look at and answer on GitHub.
Averaging: I would guess that there is a register byte to check whether acquisition is still running or often there is a function to ask whether an acquisition is already complete. I guess you already checked for that.
In the manual, only the GPIB standard registered and their commands are mentioned and while they aren’t explained in detail, I tried all of them but saw no change in their values once the amount of averages was reached.
LAN communication: Typicall Ethernet/TCPIP communication is quite fast. Can you make sure that you do not run into any communication timeout where you always wait for 1 second after each command?
So, it looks like the terminator character is not correct in case of LAN/TCPIP connection. It is possible to set individual terminator characters for TCPIP using self.port_properties. Maybe this helps to solve the problem.
No, I mend the delay. I guess this was entered by me in a debugging state and forgotten. After removing the delay, everything works fine. I already modified my commit accordingly.
Right, I see now that the Delay and not the Timeout is highlighted. I was a bit too quick with my interpretation.
As a side information: The delay was introduced as a parameter to adjust the time between two consecutive commands sent to an instrument. Older instrument sometimes need 50 or 100 ms to process a command until the next one can be accepted. The delay is used by the port manager to delay sending the next command until the given time has passed.
