New Rigol 16-bit function generators DG800/900 series

[joeyjoejoe]

Thanks The wording suggested it was not.

Skipping that step, just got my magic USB stick, finishing Ultra Sigma download now... wish there was an easier way with linux, I tried PyVISA but it didn't seem to respond to commands.

[joeyjoejoe]

Update - thanks Luckygecko, tv84 and vtech. DG821->DG992 complete.

[TurboTom]

After @nctnico's review of the Tektronix AFG31022, I just had to have a more detailed observation of my "DG811+++'s" inter-channel phase accuracy behavior. So I hooked up both channels of the AWG to my 53310A modulation domain analyzer, configured as a high-speed timer. Channel 1 would start the measurement, Channel 2 would stop it.

Since I wanted to analyze a possible "phase drift" at whole-number multiples of frequencies between the two channels, I always configured channel 2 to output a whole number multiple frequency of channel 1. I experimented in "couple mode" with both frequency and phase coupling enabled or disabled with little observable effect.

The result was disappointing: depending on the frequency pairs, I can find a phase drift, regardless of the coupling parameter, at factors sometimes as low as ten between the frequencies. I didn't dial in ultra-odd combinations. 60kHz and 1.2MHz for example walks away at approx. 100ps per minute. Other combinations are drifting even faster.

Seems like Rigol didn't get the phase accumulator math exactly right. I'ld expect that the "phase coupling" has some real effect, even if the frequencies are not identical but whole number multiples. Otherwise, the "frequency copupling" should work accurately to multiples of at least 1000.

IMO, the DG811 "hacker's delight"  is still a good AWG for its price, but never ever pay the price for a higher model in the range, especially not the DG900 or DG2000 series. For that kind of money, the performance will be disappointing, and there are better choices available.

I'm quite curious if we'll eventually see a firmware update that takes care of this... IMO it would be sufficient to reset (re-align) the phase automatically each time when the multiple of periods has passed. The additional phase noise in the faster channel should be neglible. It may not be necessary to modify the math routines that probably, due to rounding inaccuracies, cause the phase accumulators to drift.

[sequoia]

Anyone succeeded "downgrading" back to v1.08 firmware on unit that came with v2.05 firmware from factory?

I tested modified 1.08 firmware update and unit detects it and prompts for upgrade. However, if you choose "ok" it just spins in the waiting screen for a while and then the animation freezes and after a while whole upgrade window goes away (unit does not reboot). Then it will prompt again for upgrade....


UPDATE:

I was able to use the official 2.04 firmware to "downgrade" from 2.05 -> 2.04 firmware.  However, no change in behaviour if attempt to downgrade to 1.08 firmware....

[TK]

Anyone succeeded "downgrading" back to v1.08 firmware on unit that came with v2.05 firmware from factory?

I tested modified 1.08 firmware update and unit detects it and prompts for upgrade. However, if you choose "ok" it just spins in the waiting screen for a while and then the animation freezes and after a while whole upgrade window goes away (unit does not reboot). Then it will prompt again for upgrade....


UPDATE:

I was able to use the official 2.04 firmware to "downgrade" from 2.05 -> 2.04 firmware.  However, no change in behaviour if attempt to downgrade to 1.08 firmware....

When you downgrade from 2.05 to 2.04, doesn't the model change to DG992?  What do you mean by "no change in behavior"?

[sequoia]

Anyone succeeded "downgrading" back to v1.08 firmware on unit that came with v2.05 firmware from factory?

I tested modified 1.08 firmware update and unit detects it and prompts for upgrade. However, if you choose "ok" it just spins in the waiting screen for a while and then the animation freezes and after a while whole upgrade window goes away (unit does not reboot). Then it will prompt again for upgrade....


UPDATE:

I was able to use the official 2.04 firmware to "downgrade" from 2.05 -> 2.04 firmware.  However, no change in behaviour if attempt to downgrade to 1.08 firmware....

When you downgrade from 2.05 to 2.04, doesn't the model change to DG992?  What do you mean by "no change in behavior"?

No, model stayed as DG811.  No change in behaviour when trying to upgrade (downgrade) to 1.08 firmware.  "Waiting" screen shows up after clicking "OK" and the animation spins for a while before freezing...


I was finally able to run the downgrade to 1.08 firmware. Starting upgrade when unit was already running (on 2.04/2.05 firmware) didn't work. But booting up unit and pressing "Help" key rapidly during power on, seemed to trigger some kind of "firmware recovery" mode that started the firmware upgrade automatically... This way downgrade to 1.08 firmware was successful.

[SMB784]

I verified today that the JTAG interface only works with the Xilinx Spartan6 FPGA, but I did notice something interesting on the under side of the "core board"

Does anyone have any idea what this set of 7 pads might be for (see red box in attached image)?  Maybe a JTAG interface for the TI AM335x CPU?  If so, maybe we can hook into that and download the contents of the NAND flash to get the CalibrationData.dat file specific to one of our units.

[rea]

No luck here either

Looks like we will need a custom firmware or figure another way into root shell.

Another way: http://codelabs.ru/firmware/rigol/dg8xx-9xx/2.05.00-enable-ssh/

[SMB784]

No luck here either

Looks like we will need a custom firmware or figure another way into root shell.

Another way: http://codelabs.ru/firmware/rigol/dg8xx-9xx/2.05.00-enable-ssh/

Ok this is intriguing!  The readme claims that this technique wont survive an update, but in our case that's not really a problem because all we are trying to do is get the calibration info/procedure.  My bet is that if we can update the calibration info with the correct values using this access procedure you have linked, I suspect that these calibration values will likely persist between updates back to stock firmware with the DG992 upgrade in tact.  At the very least I can try to get the contents of the firmware.

Now I just gotta figure out how to SSH into this thing via USB... do I need to get a USB->ethernet adapter for that?  If so, any recommendations?

[rea]

G'day.

Do I need to get a USB->ethernet adapter for that?

Yes.

If so, any recommendations?

I am good with Realtek 8152-based adapter (it came with ASUS notebook).  The list of USB device identifiers can be consulted here: https://code.woboq.org/linux/linux/drivers/net/usb/r8152.c.html#rtl8152_table

ASIX-based adapters are also supported, here's the list: https://code.woboq.org/linux/linux/drivers/net/usb/asix_devices.c.html#ax8817x_info

[tv84]

I think I posted this in the past...

This should allow a dump of some internal files, including the calib ones.

And dump the NAND...

No need to mess with root shell for these.

[rea]

No need to mess with root shell for these.

There are many ways to skin a (net)cat...

[SMB784]

I think I posted this in the past...

This should allow a dump of some internal files, including the calib ones.

And dump the NAND...

No need to mess with root shell for these.

Ok, how does the dump procedure work?  I assume since it doesn't require root shell access that there is some command that allows one to extract the desired files?  How does one input that command and collect the desired files?

G'day.

Do I need to get a USB->ethernet adapter for that?

Yes.

I am good with Realtek 8152-based adapter (it came with ASUS notebook).  The list of USB device identifiers can be consulted here: https://code.woboq.org/linux/linux/drivers/net/usb/r8152.c.html#rtl8152_table

ASIX-based adapters are also supported, here's the list: https://code.woboq.org/linux/linux/drivers/net/usb/asix_devices.c.html#ax8817x_info

I assume the adapter will need to plug into the USB host port with the type B connector, so I will find an adapter for my USB ethernet adapter. 

[tv84]

How does one input that command and collect the desired files?

Execute those update .GELs.

[SMB784]

Alright, tried the reboot with help/local pressed method when the USB was plugged in and it gave me a Error: Bad script message and wouldn't boot.  Took out the USB, booted it up, put the USB back in, and executed the update.  Its currently stuck on the waiting screen, I assume that its downloading somethign to the USB but I'm not sure.  I'll give it a few more minutes before I kill it and reboot it.

*** EDIT ***

Killed it, got the cal data now (all in chinese, so this will be interesting).  Thanks for the script!

[rea]

I assume the adapter will need to plug into the USB host port with the type B connector

No: it can go into Type-A slot, the same place as for the USB drive.  So if you have the adapter, just plug it in and see if the scope will turn on USB icon, show LXI icon and show dialogs about network configuration being initialized.

[SMB784]

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...

[SMB784]

I've tried identifying the contents of these files via few methods, some of which is somewhat illuminating, others contradictory.  I have attached the outputs in this reply.  If this looks familiar, let me know.

[TurboTom]

Anybody succeeded with @rea's approach to get access to the "running" dg800?

I ran the .gel script which apparently worked and then tried to log into the instrument with a USB-network adapter via a putty client. Trying on port 5555 stalls the client, port 22 seems to work half-way, which means I get a login prompt. But the supplied password won't get me in. Could it be possible that I didn't configure the encryption settings properly? If I try to access port 22 with telnet, I only get some unreadable garbage as return which indicates to me that the encryption via putty is probably working. But I'm just not too experienced with this networking stuff. Maybe I should add: Communicating with the DG800 over this connection with SCPI commands (ID, screenshots and the like) works beautifully so the link itself seems to be operational.

It's not that I really need this but peeking around a little in the instument may be fun 

Cheers,
Thomas

[rea]

Thomas, good day.

I ran the .gel script which apparently worked and then tried to log into the instrument with a USB-network adapter via a putty client. Trying on port 5555 stalls the client,

... which makes sense: port 5555 isn't running SSH.

port 22 seems to work half-way, which means I get a login prompt. But the supplied password won't get me in. Could it be possible that I didn't configure the encryption settings properly?

In order for SSH access to work, you should get the provided SSH key, http://codelabs.ru/firmware/rigol/dg8xx-9xx/2.05.00-enable-ssh/id_rsa-rigol-dg, and make your SSH client to use it for logging in (as user "root").  For Putty the import of the SSH key can be done like described here: https://devops.ionos.com/tutorials/use-ssh-keys-with-putty-on-windows/#use-existing-public-and-private-keys

If I try to access port 22 with telnet, I only get some unreadable garbage as return which indicates to me that the encryption via putty is probably working.

This "garbage" isn't a complete junk.  The first line should read "SSH-2.0-dropbear_2016.74" and the second (that is much longer) should have something like "[email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,[email protected]#ecdsa-sha2-nistp521,ssh-rsa,ssh-dssgaes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,3des-ctr,3des-cbcgaes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,3des-ctr,3des-cbc;hmac-sha1-96,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-md5;hmac-sha1-96,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-md5none" in it.  In fact, that's the beginning of a standard SSH server protocol exchange.

HTH.

[SMB784]

Anybody succeeded with @rea's approach to get access to the "running" dg800?

I ran the .gel script which apparently worked and then tried to log into the instrument with a USB-network adapter via a putty client. Trying on port 5555 stalls the client, port 22 seems to work half-way, which means I get a login prompt. But the supplied password won't get me in. Could it be possible that I didn't configure the encryption settings properly? If I try to access port 22 with telnet, I only get some unreadable garbage as return which indicates to me that the encryption via putty is probably working. But I'm just not too experienced with this networking stuff. Maybe I should add: Communicating with the DG800 over this connection with SCPI commands (ID, screenshots and the like) works beautifully so the link itself seems to be operational.

It's not that I really need this but peeking around a little in the instument may be fun 

I havent tried yet, it's next on my list of things to do.

On a different note, after trying and failing to make heads or tails of the CalibrationData.dat file I decided to hex dump the file and see if that helps anyone get an idea of what is going on with it.  Hex dump is attached.

[tv84]

On a different note, after trying and failing to make heads or tails of the CalibrationData.dat file I decided to hex dump the file and see if that helps anyone get an idea of what is going on with it.  Hex dump is attached.

I think those files are unique to this instrument. They don't seem to follow any format.

The only way, besides reversing the whole thing, is trial and error. Unless someone sees any similarities with other instruments.

I think it would be important to study the impact of SCPI commands on their contents.

[SMB784]

On a different note, after trying and failing to make heads or tails of the CalibrationData.dat file I decided to hex dump the file and see if that helps anyone get an idea of what is going on with it.  Hex dump is attached.

I think those files are unique to this instrument. They don't seem to follow any format.

The only way, besides reversing the whole thing, is trial and error. Unless someone sees any similarities with other instruments.

I think it would be important to study the impact of SCPI commands on their contents.

I am beginning to think the same thing.  I was gonna start trying some of the SCPI commands I dug up in my earlier dumps and your script that spits out the cal files to see if I can induce any change.

Just so I feel better about this process, do you think it's possible to put together a script that would allow me to overwrite any changes to the CAL file with the original cal file I posted in this thread?  I would like to be able to restore any changes I might make in case I screw something up.

[tv84]

I'll have a look.

[SMB784]

I'll have a look.

If not, I can probably just use the SSH script to telnet into the unit and directly replace the files via ssh.