New Rigol 16-bit function generators DG800/900 series

[Njk]

What i read, the Chip supports 2 USB Ports, but only one is exposed in Hostmode.

Anyway only one USB type A socket is available. With DG8xx/DG9xx devices, that creates the inconvenience as it's not possible to connect a USB-LAN adapter and a thumb drive (e.g. with the magic key for v.1.8 FW) to the device simultaneously. Usual way would be to use a USB hub for that purpose. But I can't find any mentioning of a USB hubs in the Rigol documentation. So this may or may not be actually supported.

In AM335x, AFAIK, whole USB stuff, including the drivers, is of Mentor Graphics IP. If there were a USB-related defects, only MG could fix them. Looks like they did it. With the latest AM335x Debian system SW for BeagleBone Black, USB hubs are supported with no apparent problems. Not sure about the old SDK version used by Rigol. That's why it would be interesting to find out if a USB hubs can be used with that DGs.

BTW, one issue with a hub can be in total current consumption (the hub plus 2 downstream devices). IIRC, according to USB2.0 spec of that time, a USB device is allowed to withdraw no more than 400mA steady current from one host port (so called high current device). On the hi-res images for the CoreBoard, the USB current switch TI TPS2553DBV (U5) is clearly visible. The current limiting resistor R115 of 52.3 kOhm is located nearby. According to the TPS2553 data sheet, that resistor value corresponds to USB Vbus min/max allowed current value of 453/557mA respectively. The min. value leaves little margin over 400mA. So it'll make sense to use a self-powered USB hub for experiments.

[thijsdebont]

Quick question regarding the DG800/900's amplitude. The spec sheet states a max amplitude into a 50 ohm load of 10 Vpp. Most generators in the same price range use this figure, but also deliver 20 Vpp into a high-Z load. Rigol states 10 Vpp for this as well. Seems odd. Can somebody confirm the actual max Vpp into a high-Z load?

I mainly ask, because I'm still on the fence deciding between a DG800 and Siglent SDG1032X

[thm_w]

Quick question regarding the DG800/900's amplitude. The spec sheet states a max amplitude into a 50 ohm load of 10 Vpp. Most generators in the same price range use this figure, but also deliver 20 Vpp into a high-Z load. Rigol states 10 Vpp for this as well. Seems odd. Can somebody confirm the actual max Vpp into a high-Z load?

I mainly ask, because I'm still on the fence deciding between a DG800 and Siglent SDG1032X

Yes 20Vp-p into high-z, there is no real other way to do it.

50R load
≤10 MHz: 1.0 mVpp to 10 Vpp
≤30 MHz: 1.0 mVpp to 5.0 Vpp
≤60 MHz: 1.0 mVpp to 2.5 Vpp
>60 MHz: 1.0 mVpp to 1 Vpp

[tatel]

Yeah, exactly as thm_w said. See attachments.

For square wave, 20 Vpp @ 10 MHz and 10 Vpp @ 25 MHz. They look very ugly on my scope at 1x, I guess somewhere in Chine there are a couple of BNC adapters for my probes.

[thijsdebont]

Thanks all for clearing this up. It's strange though. Some webshops state the 10Vpp regardless (without giving load impedance). Even go as far as advising e.g. the Siglent "if you need higher amplitudes" 

Anyway, with the info given above, I got the DG812 (DG811 was out of stock). 'Liberated' it and must say I'm pleasantly surprised! It's a more compact and solid package than the design and productimages suggested to me. Plus, I was a bit hesitant because of the touchscreen, but it's more functional, responsive and intuitive than I imagined.

[eeeee]

Hello,
 I decided that it was my turn to venture into the fray of upgrading... 

I'm just trying to understand what I'm doing wrong.

1. Downgraded to 1.08.01 (Used a GEL that I hex edited and one that was posted by another member)
2. Meter showed DG922 (This seemed super odd to me since I thought that a SCPI command was required to change it)
3. Ran the GEL from Finish_Upgrade 2.04 (It's my understanding that this is required if your generator shipped with 2.04 or above; Mine shipped with 2.06)
4. Tried to upgrade to 2.04
I get:
Waiting...
Detects the upgrade file, upgrade? (OK)
Waiting...
[Reboots]
Upgrade from NAND
Found and loading image.
Bad script
upgrade failed!

I've redownloaded the 2.04 firmware, tried a couple drives. (Also tried upgrading during boot by pressing Help).

Am I doing something wrong?

(Note: I've not fixed the S/N yet... just because I don't have a USB cable nearby... that's next on my list)

[Njk]

The generators are equipped with frequency counter. But its input looks mysteriously.

First, there is yellow marking on the front panel near the input connector, that warns about max. input voltage. For DG900, it's +/-2.5V, while for DG2000 it's +/-5V. Perhaps it's just a typo as the official FAQ states that both series has exactly similar performance. And the specifications are similar. According to the spec, disruptive discharge voltage for the counter's input is +/-7V.

No idea what is the meaning for "disruptive discharge voltage" in that context. Perhaps there is some kind of Zener diode and the intention was to mention its breakdown voltage. Indeed, it the specification, that is provided with the performance verification guide, this parameter is called "breakdown voltage".
Or this is a voltage at which a latch-up event can take place somewhere inside the device.

Fortunately, good images for the PCB are provided it the thread making it possible to re-construct a wiring diagram for the counter's input circuit.

It seems the protection is implemented as a couple of diodes that dumps the excessive voltage to 7V DC power rails through 50 Ohm resistor (see the image below). Actually, there can't be neither breakdown nor latch-up. The protection circuit can tolerate an input current of hundreds of mA. So I think it should be okay to measure a signal of an amplitude greater than 14V PP, but in that case, it's the user's responsibility to limit the current, to prevent the 7V power rails from rising up by the input signal.

[Flare]

Hello,
 I decided that it was my turn to venture into the fray of upgrading... 

I'm just trying to understand what I'm doing wrong.

1. Downgraded to 1.08.01 (Used a GEL that I hex edited and one that was posted by another member)
2. Meter showed DG922 (This seemed super odd to me since I thought that a SCPI command was required to change it)
3. Ran the GEL from Finish_Upgrade 2.04 (It's my understanding that this is required if your generator shipped with 2.04 or above; Mine shipped with 2.06)
4. Tried to upgrade to 2.04
I get:
Waiting...
Detects the upgrade file, upgrade? (OK)
Waiting...
[Reboots]
Upgrade from NAND
Found and loading image.
Bad script
upgrade failed!

I've redownloaded the 2.04 firmware, tried a couple drives. (Also tried upgrading during boot by pressing Help).

Am I doing something wrong?

(Note: I've not fixed the S/N yet... just because I don't have a USB cable nearby... that's next on my list)

I followed this post verbatim with no problems (I started off with 02.05).
https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3719032/#msg3719032
The only thing that post didn't make clear to me is that you have to press help during boot for the downgrade step but you already knew that.

Did you upgrade using:
https://mega.nz/file/L51wBJrA#ZTDJ6_mi-U4N03YW7YrRVj-pgHYRTdB4z1yaSQmmD3I
After downgrading?
I don't think I needed to use SCPI other than to change the serial no. back.

It would be really useful if there were sticky posts within threads for definitive posts like the one I linked.

[beltet]

I also have great troubles with upgrading my DG811.

I followed the instructions in post #809 by mandor:
https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3719032/#msg3719032

First the backup scripts does not work. Could not make a backup. I get an "Error: Bad Script!"

I can downgrade to the 01.08.01 firmware and get DG992 unlocked.

But then you update to 02.06 and it reverts to DG811.

If you try to apply the script in the last post(that who is supposed to convert to DG992) I get "Error: Bad Script!"

Seems like the scripts needs to be updated...

I tried to untar the GEL files, but the script files is just gibbersih in a text editor. Do you need to unencrypt them or something?

EDIT: Also, in every step, the generator did never prompt me to upgrade, I always needed to restart it and push the Help button.

EDIT2: Now it worked. What I needed to do is that I changed to another USB stick and formatted it with msdos partition table and FAT32. Then it could promt me with upgrades.
The scripts(those who is not full firmware files) can't be run when booting up.
When I changed the USB drive, everything went really smoothly.

[Njk]

Edit: Did some more testing and indeed, I found a very weird behavior when using custom arbitraries! The instrument drops out of external reference mode with an error if "interpolation" as filter mode is selected. When using "step" or "smooth" filter response, EXT Ref stays enabled and the instrument uses it. Must be a peculiar firmware bug! Rigol, you've got a job to do... 

An old post but the thing seems abandoned anyway.
From the spec analysis, it can be concluded that the filter setting makes great impact on the device operations, and this setting controls not only the low pass filtering. No matter what the rendering mode is (DDS or AWG), the RMS jitter in an output waveform can be of up to 200 ps. But with "step" and "smooth" settings it drops to 5 ps. It's quite small number for that price. How do they do it? Is it true? Any theories?

[nikitasius]

Well folks, 1st of all i wanna say thanks to member from that forum.
2nd i wanna say thay USB STICK matters 

Well,
1) i backup my cals (but idk how to restore and idk if i need to restore ) like in this post https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3719032/#msg3719032
2) then i used a downgrade to 1.08 from this post https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3157600/#msg3157600
3) cause i had animation and nothing happened i turned-off the AWG, plugged my sandisk 32Gb into, turned on and spammed "help/local" button to run the update
4) i got DG992 with resetted SN on 1.08 firmware
5) i use linux, so plugged my Sandisk 32Gb into laptop, formatted into fat32 4b/sector `mkdosfs /dev/sdb1 -s 8 -F 32`, checked `dosfsck -v -n /dev/sdb1` and did a `dd` like in this post, but used by sdb1 name https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg2420391/#msg2420391 .
6) then i booted to win10, ran Ultra Sigma from there https://www.rigol.eu/En/Index/listView/catid/28/tp/5/wd/ultra%20sigma and did advices from this post https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3157600/#msg3157600 , setup SN, checked (using write, then read but NOT write&read), changed to DG992.
7) and here i faced sick issues, cause fix from that post did not wanted to run, just animation and nothing happened https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3119264/#msg3119264

If i forced i had "bad script" error. But thanks this post https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg4788428/#msg4788428 and mention that changing USB STICK could help. So i found my old Sandisk 16Gb, formatted it into fat32/4kb `mkdosfs /dev/sdb1 -s 8 -F 32`, copied fix from https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3119264/#msg3119264, plugged into AWG and.. got animation and request to install an update.
Well, i told okay, it's patched, rebooted.

i copied 2.06 firmware to that 16Gb stick, plugged, AWG asked for update, updated and now i have DG992 in the body of DG811.

So USB STICK is matters! Personally i will buy another 16G or 8Gb stick if thisone will die one day.

[nikitasius]

Btw surprised that awg have a sensor screen lol!

[hedehede81]

I have attached my calibration data, I'm working on making some sense of it but I don't read chinese  very well.  I ran a "file" command on it and it tells me that its a dBase III DBT file.  So I downloaded dbview and tried to run it on the file, and it tells me that version 192 is not supported.  So it appears that its some sort of .dbf file, but I dont know how to work with it yet.  Maybe one of you will have better luck than me.

One interesting thing to note: When I entered the SCPI command :CAL:DATE 09/09/2020 as mentioned earlier in this thread, it actually updated the calibration date in the CalibrationInfo.dat file.  So, we know that at least some of those CAL SCPI commands actually do something.

Now if only I could actually decode what exactly was going on in these CalibrationInfo.dat/CalibrationData.dat files...

Would it be possible to compare these to DG992 calibration files, maybe they would help, do you happen to have those?

[Njk]

The missing manual
https://www.dropbox.com/scl/fi/6okm6dry8q9akrfjk4iws/DG900_UG_2023.pdf?rlkey=rg03d9oglp32ert3bh48gjwn2&dl=0

[TurboTom]

Regarding the "missing" built-in arbitrary waveforms with the latest F/W version, see page 52 of the aforementioned manual.

Notes:
...
— With the current firmware version, not all listed special types are available.

How embarrassing is this for Rigol? Instead of fixing the problem, make it a "feature" 

[Njk]

How embarrassing is this for Rigol? Instead of fixing the problem, make it a "feature"

That's the most innocent problem, I think

[tv84]

How embarrassing is this for Rigol? Instead of fixing the problem, make it a "feature" 

 

Tom, let's consider they didn't make it a feature, they just acknowledged it. Interesting, nonetheless.

[optotester]

Hello,

I spent some time to try to understand the calibration process for that device and I made some progress. It appears that the device uses 16 different types of calibration, some containing factors for multiple frequencies (slot 14). It is possible not all of them are in use though.

The commands are:

:SOURce<n>:CAL:SETVALUE:[cal_slot]:[P2]:[P3]:[P4]

:SOURce<n>:CAL:MEASVALUE:[cal_slot]:[P2]:[P3]:[P4]

:SOURce<n>:CAL:STORE:[cal_slot/"FILE"]:[P2]
If a cal_slot is provided, P2="DEF"/"ALL"/"NO_ALL"/"SAVE"
If "FILE" is provided P2="CDV"/"CDF"

:SOURce<n>:CAL:RECALL:[P1]
P1="ALL"/"NO_CAL"/cal_slot
Note: NO_CAL option is equivalent to calling :SOURce<n>:CAL:STORE with NO_ALL option (which clears calibration data)

:SOURce<n>:CAL:HIGH:[P1]
P1 is optional and can be set to "HIFCHECK". This command does alter FRAM content.

:SOURce<n>:CAL:RANGNUM:[cal_slot]:[P2]:[P3]
I did not really check what this function does but it may display some message on the UI as it seems to call Qt libraries.

The probable sequence for calibration is to issue a SETVALUE, send a MEASVALUE with a reference measurement provided, and then a STORE.

Calibration slots are one of the following:

• 0 - FREQ?
• 1 - B/K Calibration
• 2,3 - B/K Calibration
• 4 - B/K Calibration + AC Offset
• 5,6,7 - B/K Calibration
• 8,9 - B/K Calibration Low Freq
• 10,11 - B/K Calibration High Freq
• 12 - Offset Calibration
• 13 - Not used
• 14 - B/K Calibration Inner Freq
• 15 - Not used

For SETVALUE:
[P2]
cal_slot=4,10,11 -> Open24DbAttenuation is set to 0 if P2=1 and set to 1 if P2=2
cal_slot=12 -> Not used

[P3]
cal_slot=5/6/7 -> If P3=1, AcAmplFirstPointCal = 1 is set
cal_slot=14 -> P3-1 corresponds to the InnerSlotID

[P4]
cal_slot=0 -> P4 corresponds to the PWM Width
others -> P4 is most likely the set/measured value

My advice is to backup your calibration info + calibration data before playing with this. I will not investigate further for the moment as I do not have the device.

Here are the inputs used in the calibration test function:
5:1:1:2010000
5:1:2:3500000
5:1:3:4500000
5:1:4:5900000
5:2:1:6100000
5:2:2:10000000
5:2:3:12500000
5:2:4:15000000
8:1:1:1000000
8:1:2:431000
8:1:3:331000
8:2:1:1000000
8:2:2:431000
8:2:3:331000
(maybe it can give some hints on which kind value to use)

Disclaimer: I am not responsible for any malfunction caused by the previous commands.

[optotester]

Hi all, please note I did a major correction to my previous post, as I forgot to mention that 1 is substracted from P2/P3 before being passed to any function so it is 1 indexed and not 0 indexed.
I also added the setpoints used by the service calibration check function.

When we look at all DG2xxx calibration manual, we can see that there is 200+ points to calibrate. It would probably take a lot of time to get the full calibration process right.

[tv84]

@optotester did you do any analysis of these calib files, using that knowledge?

[optotester]

I did check them a bit and the preliminary analysis in this topic was really interesting (some assumptions may not be 100% correct though as some factors are 4 bytes and not 8 ). But with the amount of calibration factors, the effort to get the offset of each parameter would be huge so I stopped.

Though I think that to try to have high frequency calibration you must start by putting this cal file on your device and then recalibrate it. This way, the inner points for slot 14 would be already defined.

It may be possible to add them with RANGNUM function, but someone would really need to play a bit to understand the process better.

I do not own this device so I will not perform any additional analysis.

[tuxfanx]

I received my DG812 today (fw:2.06.00.01) and was able to upgrade it to a DG992 following mandors guide https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3719032/#msg3719032 without any problems.
I did not need any intermediate upgrades or the magic USB stick.
However, I had to skip the two optional backup steps because the respective .GEL files were not recognized by the DG812.
Thanks to everyone who made this possible.

[eloso]

Hi,

Just taken delivery of DG811 which is destined for better things. Before making any changes to it I have checked its performance against the oft quoted performance documentation. Up to 100khz using SDM3055 the amplitude is spot on. Above 100kHz I have the choice of using an SDS2000X+ scope or an SSA3021X+ SA.

Both of these instruments register a fail against the 5 and 10Mhz amplitude and they are more or less in agreement with one another.


Flatness is way off  - see db relative to 1Khz which is spot on at 1Vpp into 50ohms.


1Khz           0
10Khz   0
100khz   -0.21
1Mhz   0.15
5Mhz   0.54
10Mhz   0.72

At 10Mhz the amplitude is 0.72dB down measured on the spectrum analyser. and is a similar value measured on the scope.  This appears to be outside of the values expected in Rigols's own performance document.

Has anyone else had these results prior to upgrading ? I am holding off on the upgrade until I decide whether to return the instrument, a decision I will make over the weekend.  I also need to decide whether to go for replacement or money back.

I don't mind if the calibration is out on higher frequencies in the upgraded unit - that is to be expected, but I don't much like buying a unit that falls at the first hurdle.   I am only a hobbyist and it probably wouldn't matter, after all I can apply my own correction where its necessary but  that's not the point.

Any comments ?

Thanks

Eloso

[thm_w]

Here are some measurements from mine 1Vrms: 1khz 1.003V, 100kHz 1.010V, 1MHz 1.002V, 5MHz 1.002V, 10MHz 1.006V, 50MHz 0.965V.
Its not clear what you wrote by flatness, was -0.21 high by 0.21dB? Or were they all down?

[eloso]

Thanks for that and yes, I expressed it  poorly.  Rigol specify flatness relating to level of a 1Vpp sine wave at 1Khz. So the table for my machine is:


                Vpp          Vrms         dBm       dB  relative to amplitude at 1kHz
1Khz         1.002       0.3544       4            0
10Khz       1.002       0.3544       4            0
100khz     1.0269      0.3634       4.21        0.21
1Mhz        0.9852      0.3483       3.85       -0.15
5Mhz        0.942        0.333        3.46        -0.54
10Mhz      0.9226      0.3262       3.28       -0.72

If I do the upgrade I am guessing that the higher frequencies will be even further out since the machine doesn't even start with a proper calibration.  The 10Mhz output should be within 0.2dB of the reference level (the 1kHz output level). It is actually 0.72dB down on the reference level.

regards

Eloso