Hacking the Rigol DHO800/900 Scope

[Randy222]

On topic of little cooling fan, I did some poking around, unless the litlle fan is voltage controlled by i2c regulator or the like, I believe the fan is simply attached to fixed voltage.
The "pwm_fan" driver is commented out in the start_rigol_app.sh script.

[Randy222]

I took 804 (fw 01.02) to 914 via vendor bin file.
Then applied the BW15T25 option code, unit now says it's a 914 BW250.
Ran a self-cal.
I don't see any DC offset issue.

Are others seeing dc offset issue with the 250 option applied?

[t_i_t_o]

Yes with v01.01, not with v01.02.

[AndyBig]

Just a note The vertical calibration files (cal_vertical.hex) are significantly different between versions 01.01 and 01.02. In version 01.01 the file size is 205084 bytes, while in version 01.02 its size is 538300 bytes. The structure of these files is also clearly different.
I tried to quickly view the file structure of version 01.02. It is not clear what is what in its structure; all that is clear is that there is a file header and some identical records of 56 bytes in size. It seems that each entry contains a number in double format (64-bit floating point), a number in int64 format (64-bit integer) and some other obscure values that I could not clearly identify. If you look at these entries throughout the file, you can see that the file is clearly divided into three equal parts of 179 KB, each with approximately 3200 entries. At the beginning of each part, the double number has a value of approximately 10.5, and by the end of the part its value decreases to approximately 1.0. The int64 number in the first record has a value of 100 000 and with each record it increases in steps of 2 000 to a value of 200 000, then in steps of 5 000 to a value of 500 000, then in steps of 10 000 to a value of 1 000 000, then in increments of 20 000, and so on until the value of 10 000 000 000 in the last entry. And so on in all three parts of the file. I have no guesses as to the purpose of all these numbers. Maybe someone will have some idea what these numbers are.

[Randy222]

Just a note The vertical calibration files (cal_vertical.hex) are significantly different between versions 01.01 and 01.02. In version 01.01 the file size is 205084 bytes, while in version 01.02 its size is 538300 bytes. The structure of these files is also clearly different.
I tried to quickly view the file structure of version 01.02. It is not clear what is what in its structure; all that is clear is that there is a file header and some identical records of 56 bytes in size. It seems that each entry contains a number in double format (64-bit floating point), a number in int64 format (64-bit integer) and some other obscure values that I could not clearly identify. If you look at these entries throughout the file, you can see that the file is clearly divided into three equal parts of 179 KB, each with approximately 3200 entries. At the beginning of each part, the double number has a value of approximately 10.5, and by the end of the part its value decreases to approximately 1.0. The int64 number in the first record has a value of 100 000 and with each record it increases in steps of 2 000 to a value of 200 000, then in steps of 5 000 to a value of 500 000, then in steps of 10 000 to a value of 1 000 000, then in increments of 20 000, and so on until the value of 10 000 000 000 in the last entry. And so on in all three parts of the file. I have no guesses as to the purpose of all these numbers. Maybe someone will have some idea what these numbers are.

You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.
It looks like blocks of cal data, I just not sure what all the numbers mean.

Although I don't see DC offset, the noise levels on ch1 and ch4 seem to drift way higher than ch2 or ch3. Put on some Vrms in Analyse using various modes (AC vs DC couple, etc), and I'll see ch1 ch4 be in 1-2mV area while ch2 ch3 are in 600uV area. At one point they were all in uV area, then ch1 ch4 got into the low mV area.

ch1 ch4 seems to drift some, at least away from ch2 ch3.

It's been talked about some, 01.02 FW might be for some production that had perhaps new chips (same function) that needed new cal file. Add to that Rigol yanked the 01.02 from all downloads. So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?

[AndyBig]

You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.

But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values ​​stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.

It looks like blocks of cal data, I just not sure what all the numbers mean.

Yes, I don't understand this either. And I don’t understand why the file is divided into three identical parts, and not into four according to the number of channels. And why are there so many records with these values - more than 12,000 in total.

Add to that Rigol yanked the 01.02 from all downloads.

Yes, but at the same time version 01.02 began to arrive on oscilloscopes via OTA

So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?

Yes, my DHO814 oscilloscope, which came with firmware 01.01, works quite well after updating the firmware to 01.02. Moreover, with the new firmware it has been successfully upgraded to the DHO914 model without channel offsets.

[Randy222]

You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.

But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values ​​stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.

Well, try xxd convert and then look at the hex. See anything?

[AndyBig]

Well, try xxd convert and then look at the hex. See anything?

I don't have Linux to try. But I still don’t understand what it will give. It simply converts binary to hexadecimal, and I already see hexadecimal on the screen in the hex editor, as in the screenshot above

[Randy222]

Well, try xxd convert and then look at the hex. See anything?

I don't have Linux to try. But I still don’t understand what it will give. It simply converts binary to hexadecimal, and I already see hexadecimal on the screen in the hex editor, as in the screenshot above

Not clear to me if the cal files are encrypted with TEA like the vendor bin file.

[AndyBig]

Not clear to me if the cal files are encrypted with TEA like the vendor bin file.

Absolutely not. Encrypted files cannot contain long sequences of the same character.
Today or tomorrow I will try to write a utility that will extract records from cal_vertical.hex into a readable text form. At least those fields that are definitely numbers.

[enson72]

You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.

But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values ​​stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.

It looks like blocks of cal data, I just not sure what all the numbers mean.

Yes, I don't understand this either. And I don’t understand why the file is divided into three identical parts, and not into four according to the number of channels. And why are there so many records with these values - more than 12,000 in total.

Add to that Rigol yanked the 01.02 from all downloads.

Yes, but at the same time version 01.02 began to arrive on oscilloscopes via OTA

So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?

Yes, my DHO814 oscilloscope, which came with firmware 01.01, works quite well after updating the firmware to 01.02. Moreover, with the new firmware it has been successfully upgraded to the DHO914 model without channel offsets.

Interestingly, the firmware v00.01.01.00.01 is posted everywhere, and on the Chinese website v00.01.01.00.02

[Randy222]

From what I can see, they version it using 5 sets of 2

00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.

and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.

The 1st two I think are just v01.01 FW's, could actually be the same exact FW.

One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02

[enson72]

From what I can see, they version it using 5 sets of 2

00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.

and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.

The 1st two I think are just v01.01 FW's, could actually be the same exact FW.

One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02

If it is the same firmware, then it is not logical to write separate release notes 00.01.01.00.02 in the Release Notes file. There is no correction item 00.01.01.00.02 in this file on the Rigol global server.

[AndyBig]

In this version 00.01.01.00.02 the size of the cal_vertical.hex file is the same as in version 00.01.01.00.01 - 205084 bytes.

I figured out a little about the header of the calibration files. This applies to all calibration files in all versions.
At offset 0 is the checksum (CRC32) of the header itself, with the exception of the length field - 4 bytes.
At offset 4 is the length of the header in bytes, starting at offset 8 (checksum and length fields excluded) - 4 bytes.
From bytes 12 to 20, I couldn’t figure out what was there. There is some pattern in them among different calibration files, but I don’t understand what it is.
At offset 20 is the size of the data in the file excluding the header - 4 bytes.
At offset 24 there is a checksum (CRC32) of the data in the file excluding the header - 4 bytes.
After this, the data itself begins, because The header size is 20 bytes everywhere (plus 4 bytes of checksum before the header).

[Randy222]

From what I can see, they version it using 5 sets of 2

00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.

and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.

The 1st two I think are just v01.01 FW's, could actually be the same exact FW.

One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02

If it is the same firmware, then it is not logical to write separate release notes 00.01.01.00.02 in the Release Notes file. There is no correction item 00.01.01.00.02 in this file on the Rigol global server.

I concur, there should be 4 distinct FW's for DHO800/900
Just seems odd that the 1st 3 are in the 01.01 line, then all of a sudden comes a 01.02, why not name the last one "00.01.01.00.03" or something like that. Perhaps just very bad versioning.

From 01.02 release note

Code: [Select]

Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2023/11/2

[Updated Contents]

v00.01.02.00.00  2023/11/2

1. Self calibration optimization update
2. Solve the problem of UltraLab startup connection failure
3. Solve the problem of failure to save waveform in wfm format
4. Add education model equivalent settings
5. Solve the problem of unresponsive touch on startup screen

v00.01.01.00.02 2023/09/12

1. Self calibration optimization update
2. Update Help Documents

v00.01.01.00.01  2023/08/10

1. Remove all time-related displays on the instrument
2. To modify the vertical interface, click the wiring diagram to modify the AC coupling function
3. Modify the delayed scan Chinese display as Zoom
4. Modify the order of the menu in the upper right corner, put the measurement in the front and Default in the back
5. The probe ratio interface is removed, and the probe ratio option is added to the vertical first-level menu


v00.01.00.00.19  2023/07/24

1. The first version is released


-Released the production version.


[AndyBig]

I have attached a program that reads values from the cal_vertical.hex files of versions 00.01.01 and 00.01.02. The archive with the program contains, for example, the original file cal_vertical.hex and the file with the read values cal_vertical.hex.csv:

 calhex_read.zip (193.28 kB - downloaded 26 times.)

The program saves everything to a .csv text file in the same directory. This is a console program for Windows. Just give it the file name cal_vertical.hex as an input parameter; this file must be in the same directory as the program.
As it turned out, cal_vertical.hex in version 00.01.02 is divided not into 3 parts, but into 12 parts. But in version 00.01.01 it is divided into only 4 parts.

[AndyBig]

Hmm, the sequential numbers in the entries seem to correspond to the vertical scale adjustment steps in fine mode.
Numbers: 100000,102000,104000,...,198000,200000,205000,210000,215000,...,495000,500000,510000,520000,530000,...,980000,990000,1000000,1 020000,1040000 and so on up to 10000000000, that is, 5 circles with a zero added to the end after each circle.
Increasing the voltage scale in fine mode:
1.00mv,1.02mv,1.04mv,...,1.98mv,2.00mv,2.05mv,2.10mv,2.15mv,...,4.95mv,5.00mv,5.10mv,5.20mv,5.30mv,... ,9.80mv,9.90mv,10.00mv,10.20mv,10.40mv and so on up to 10V, that is, the same 5 circles with the same step.

In version 00.01.01 this is repeated 4 times - we can assume that this is for 4 channels. But I don’t understand why in version 00.01.02 this is repeated 12 times. Three times per channel?

[Randy222]

Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.

Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.

I'll now try to make inline filter using ferrite and some Henry.

Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. 

[AndyBig]

Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.

Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.

I'll now try to make inline filter using ferrite and some Henry.

Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. 

But why? If this is not reflected in the input channels?

[AndyBig]

Interesting. Changing only one value (out of 9612) in the cal_vertical.hex file leads to a zero shift for all four channels, and by different amounts and even with different signs.

[Randy222]

Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.

Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.

I'll now try to make inline filter using ferrite and some Henry.

Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. 

But why? If this is not reflected in the input channels?

Why? Because I can, I have all the parts needed, plus I am making usb-c spliiter to fit into a 3d printed frame that will hold a 92x14mm fan on rear vesa mount. I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.

[AndyBig]

Why? Because I can, I have all the parts needed

Ah, well, I agree, that’s a pretty good reason

I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.

In fact, this is an extremely convenient option. I myself did not understand all its convenience until I tried it. It greatly adds comfort to working with the oscilloscope - you can rotate, raise, lower, or move the oscilloscope as convenient at the moment. I work sitting closer to the computer, or sit down at the next table, or stand next to the workstation - I can always move the oscilloscope for comfortable work
I was also worried about the permanence of such a fastening, but the bracket I purchased turned out to be able to quickly remove and install the device, just unscrew a couple of wing nuts

[Randy222]

Why? Because I can, I have all the parts needed

Ah, well, I agree, that’s a pretty good reason

I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.

In fact, this is an extremely convenient option. I myself did not understand all its convenience until I tried it. It greatly adds comfort to working with the oscilloscope - you can rotate, raise, lower, or move the oscilloscope as convenient at the moment. I work sitting closer to the computer, or sit down at the next table, or stand next to the workstation - I can always move the oscilloscope for comfortable work
I was also worried about the permanence of such a fastening, but the bracket I purchased turned out to be able to quickly remove and install the device, just unscrew a couple of wing nuts

I just got the 804 short time ago, was looking to replace an older Owon unit, but I wanted full built-in battery operation like my Owon has, along with good FFT. Micsig probably would have worked for me, but I got the 804 at a good price, plust now it's a 914 250BW. I often times take my Owon from desk to garage to probe automotive stuff. I'll use the 804 for same thing but it has no built-in batt. So my scope travels around more than most do. I will perhaps keep using Owon in garage, but some of the knob "pots" need ixing. If I do an arm I'll need to think about rigging up a good quick disconnect so I don't have to unscrew things.

As for the calibration file, I wondering if that cal file has dedicated sections depending on specific hardware found in the unit by FW?

[AndyBig]

As for the calibration file, I wondering if that cal file has dedicated sections depending on specific hardware found in the unit by FW?

Looks like no. The firmware update supplied for all 8xx/9xx models is the same, and the default calibration file in this update is also the same for all models.
I believed that this file contained correction factors for each vertical scale step for all channels in various modes. But judging by the fact that changing one single value in this file leads to a displacement of all channels, and on many vertical scales, everything there is much more complicated. We need to conduct a lot of different experiments with this file, then perhaps some understanding will emerge.

[AndyBig]

I often times take my Owon from desk to garage to probe automotive stuff. I'll use the 804 for same thing but it has no built-in batt.

As for the frequent transfer of the oscilloscope to the garage... If I had to often take the oscilloscope from the workshop to work without mains power, I would probably assemble a 4S4P battery pack from 18650 cells and think about quickly mounting it on a VESA plate, which is screwed to the oscilloscope. I removed the oscilloscope from the bracket (unscrewing the two wing nuts is only 10 seconds), screwed the battery pack to the plate on the oscilloscope using the same wing nuts and took it to the garage or somewhere else