New Rigol 16-bit function generators DG800/900 series

[Hobbit13]

Hi Thomas,

After I did a successful hack on the DG811, I'll try to download the calibration files of the DG2052. I first want to have some confidence in mangling with this series, in order to minimize chances of bricking the device of my employee.

Please mind that the DG2052 is a 50MHz  - 250 MS/s unit, the 50 to 100 MHz range might still be missing from the calibration. ( I do not see a software unlock to increase this model to 100 MHz on the Rigol page )

[TurboTom]

The DG800, 900 and 2000 sreies of AWGs share the same hardware (except for the factory-installed LAN socket -- but that's available on the DG800/900's main PCB as a foorprint as well). Moreover, the firmeware for these AWGs is identical -- you'll even find this information in Rigol's current DG2000 update package. It's a guess that the DG900 and the DG2000 series instruments may all be calibrated up to the full 100MHz, but it's worth a try anyway. If we're successful, we may all benefit from that.

Of course, take your time and get familiar with the instrument. Once comfortable with it, you may try the cal file backup.

Thanks and all the best,
Thomas

[Hobbit13]

The DG800, 900 and 2000 sreies of AWGs share the same hardware

For me there is quite a significant difference between the DG9** and DG20**: the DG20** has direct buttons for the different waveforms. I do like this above having to use the touchscreen to go from sine to square.
Another difference is the counter input: on the DG8/9** it is specced to +/- 2.5 Volt and for the DG20** it is specced to +/- 5 Volt.

I "upgraded" my DG811 to dual channel without any issues. Used HxD64 under Windows 10 to create the "magic" USB Stick. I did notice Windows was not able to fully format the "magic" flashdisk afterwards. A quick format works, but still it might run into trouble when it wants to write the magic sector again. I would advice to use a cheap USB stick and not use it after the hack for anything important anymore.

You can find the calibration files of the DG2052 via the following link:
https://hobbit13.stackstorage.com/s/PFm6GXUblfaGp4oK

Hope they are of use.

I have access to another DG2052 from the same batch, but that one is still in the sealed box.

[Hobbit13]

I have access to another DG2052 from the same batch, but that one is still in the sealed box.

Here it is:
https://hobbit13.stackstorage.com/s/rLOwnYmqYikRAqjV

[CeD]

really curious to see where this will lead, I wish I could help. let me know if I can test something which is the best i'd be able to do.

[TurboTom]

I just uploaded Hobbit13's first set of CAL files onto my DG811+++, and indeed now get a pretty accurate amplitude up to 100MHz, yet with a DC offset of a few tens of millivolts.

So it appears that a hybrid CAL file might actually do the trick. I may try to replace the blocks of 0x00 that are present in my original cal file with the values from Hobbit13's cal files. Since these are located in many places, doing that manually isn't feasible and some kind of parser / filter would need to be set up to look for consequent blocks of at least four 0x00 in the original cal file and only replace those with the values from the DG2052 cal files.

One more peculiarity I found out about firmware 02.05: Rigol has changed the SSH encryption key vs. F/W 02.04, so in order to use @rea's login approach, it's necessary to downgrade the firmware to at least 02.04.

[SMB784]

I just uploaded Hobbit13's first set of CAL files onto my DG811+++, and indeed now get a pretty accurate amplitude up to 100MHz, yet with a DC offset of a few tens of millivolts.

So it appears that a hybrid CAL file might actually do the trick. I may try to replace the blocks of 0x00 that are present in my original cal file with the values from Hobbit13's cal files. Since these are located in many places, doing that manually isn't feasible and some kind of parser / filter would need to be set up to look for consequent blocks of at least four 0x00 in the original cal file and only replace those with the values from the DG2052 cal files.

One more peculiarity I found out about firmware 02.05: Rigol has changed the SSH encryption key vs. F/W 02.04, so in order to use @rea's login approach, it's necessary to downgrade the firmware to at least 02.04.

So the old (really old) version of the DG2000 (different from the current one) has an entire calibration routine for just the DC offset.  Thus, it would seem to me that there should be a specific entry in the calibration data for DC offset.  If all other parameters work ok with the exception of the offset then maybe we can replace the DC offset calibration data from the DG2052 cal file with the data from the DG811.  Attached is the calibration manual for the older model DG2000s describing the process for those units (this process does not work for the newer DG8xx/9xx/2xxx) demonstrating that the DC offset should occupy its own data entry in the calibration data.

[TurboTom]

I compared the CAL files more thoroughly and as it seems, there's more to it than just copying some contents of the DG2052 cal file over the existing "zeros" of the DG800's. The structure is the same, as is the size, but it seems that some blocks contain identical byte sequences but placed at different offsets. So there may be "table descriptors" that are relocated which will make a blind copying of values futile.

I'm afraid, as it appears right now, the idea of generating a hybrid CAL file to solve our 100MHz dropoff problem appears to be more difficult to realize than anticipated.

At least, switching CAL files finally proves that the hardware of the DG800 series is absolutely capable of produceing a flat output up to 100MHz.

I guess we've got to continue trying to find a method to calibrate the instrument...

[tv84]

Well, CalibrationInfo.dat is precisely the same file as in a DG811. Only changes the date.

The mac.dat has the difference of MAC address.

So differences are all in CalibrationData.dat. Nonetheless it is very similar. I'll do a visual map.

[SMB784]

I compared the CAL files more thoroughly and as it seems, there's more to it than just copying some contents of the DG2052 cal file over the existing "zeros" of the DG800's. The structure is the same, as is the size, but it seems that some blocks contain identical byte sequences but placed at different offsets. So there may be "table descriptors" that are relocated which will make a blind copying of values futile.

I'm afraid, as it appears right now, the idea of generating a hybrid CAL file to solve our 100MHz dropoff problem appears to be more difficult to realize than anticipated.

At least, switching CAL files finally proves that the hardware of the DG800 series is absolutely capable of produceing a flat output up to 100MHz.

I guess we've got to continue trying to find a method to calibrate the instrument...

Perhaps this is a naive question, but what is the significance of the offsets?

If it's only the offsets that are different, and the byte sequences are the same, how would this correspond to a different calibration value?

[tv84]

I don't think the offsets are different. It has a little more things as one would expect.

See attachment.


Edit: added a 4x amplification. Each byte corresponds to a 4x4 pixels square.

[TurboTom]

Superficially, it looks very similar.. But within the blocks, there seems to be some data inserted that shifts other part of the data to different locations. Have a look here, left column DG2000 and right column DG800 (the locations that contain different data are hilighted red):



DG800, address 0x46BF: 54 CE 09 23 01, to be found in DG2000 at address 0x46CF, 16 bytes of different data are inserted before. Then, the data blocks until "0x16" in the fourth column are identical, keeping the offset of 16 bytes. After that, additional data is present in the DG2000 file where the DG800 file contains "00". But if I'ld just blindly copy the the data for the DG2000 file to the places where the DG800 file contains all zeros, the proper sequency would be lost. So I'm pretty sure it won't work that way. This is just an example, there are many such instances in the cal file, too many to sort them manually without exactly knowing their meaning.

That's why I think it may be more rewarding to actually try to figure out how to properly calibrate the instrument. Even if we'll be able to generate a hybrid cal file that preserves (rearranges) the existing calibration and fills the "blank spaces" with donor data, it's still a makeshift solution that requires a lot of effort nevertheless. This effort may be better spent on figuring how to cal the instrument properly.

[tv84]

Superficially, it looks very similar.. But within the blocks, there seems to be some data inserted that shifts other part of the data to different locations.

Tom, we can perfectly see that in play if we look carefully at the bitmap map that I posted. Look carefully at the pixels colors and you see the extra info.

What I suggest, as a raw comparison, is to make a hex dump with 80 hex bytes linesize (as the picture that I've shown). That allows to have a better comparison of what values are inserted.

Also, a 1st approach would be to use a half from a file and the half from the other to see if the one channel gets calibrated and the other remains. (I think the CRC at the beginning would have to be corrected.)

Here is a dump in decimal (Uint64 in little endian), of the bytes shown by Tom:

Code: [Select]

000046AF - 000.390.625.000
000046B7 - 001.171.875.000
000046BF - 002.343.750.000
000046C7 - 003.515.625.000
000046CF - 004.882.812.500
000046D7 - 021.093.750.000
000046DF - 035.156.250.000
000046E7 - 048.828.125.000
000046EF - 068.359.375.000
000046F7 - 078.125.000.000
000046FF - 097.656.250.000
00004707 - 117.187.500.000
0000470F - 156.250.000.000
00004717 - 195.312.500.000
0000471F - 234.375.000.000
00004727 - 253.906.250.000
0000472F - 273.437.500.000
00004737 - 292.968.750.000
0000473F - 312.500.000.000
00004747 - 328.125.000.000
0000474F - 343.750.000.000
00004757 - 359.375.000.000
0000475F - 375.000.000.000
-------------------------
0000483F - 001.171.875.000
00004847 - 002.343.750.000
0000484F - 003.515.625.000
00004857 - 004.882.812.500
0000485F - 021.093.750.000
00004867 - 035.156.250.000
0000486F - 048.828.125.000
00004877 - 068.359.375.000
0000487F - 078.125.000.000
00004887 - 097.656.250.000
0000488F - 117.187.500.000
00004897 - 156.250.000.000
0000489F - 195.312.500.000
000048A7 - 234.375.000.000
000048AF - 253.906.250.000
000048B7 - 273.437.500.000
000048BF - 292.968.750.000
000048C7 - 312.500.000.000
000048CF - 328.125.000.000
000048D7 - 343.750.000.000
000048DF - 359.375.000.000
000048E7 - 375.000.000.000
000048EF - 390.625.000.000

Pretty clear the calib points. I would say that, if we divide these values by 4000, we get  the freq. points. Example: 390.625.000.000 / 4.000 = 97,656250 MHz

Similarly, the DG800's last point 0x1B48EB57E0 (117.187.500.000) / 4.000 = 29,296875 MHz

So the DG800 shown by Tom is only calibrated up to 30 MHz.

EDIT: interesting detail: 3,33333333 x (30 - 29,296875) = 100 - 97,65625 So the points are precisely at the same relative position regarding the max BW (30 and 100).

So, we have 23 calibration points. Looking at the initial rectangle blocks (visible in my maps) it, seems they have 46 pixels in height. Now, let us imagine that those are 2 lines per calib point. If this were true, we could assume that the rectangles already have the information for 23 calib points even in the DG800 file (let's disregard the rectangles width for now).

The only thing needed would be to add the freq points in the areas signaled by the yellow ellipse. This would tell the gen to consider 23 calib points from the rectangles above.  (I hope you understand my wild guessing...)

Another possible test is to replace the rectangles area in the DG2000 file (with the ones from the DG800) and see if the offset (observed by Tom) disappears.

[TurboTom]

@tv84: That sounds plausible. Since basically the numbers contained in the DG800 calibration can also be found in the DG2k file, it makes sense that they may be the frequency calibration points. Just for fun, I ran my DG800 without any calibration files and as expected, all the amplitude as well as the frequency figures are off by some margin (instrument showing "Not Calibrated" in Utility->SystemInfo). I'm not too sure if the first two bytes of the cal file are a check sum -- they could just as well be the frequency calibration, which would make sense since they get repeated at the beginning of the second half (copy) of the file (0xB448, strangely not present in your bitmap visualization).

The DG800/900/2k has ten possible configurations of the output attenuator / amplifier, and there's some considerable tolerance between the seams, so I guess there will have to be a CAL point for each frequency and for each end point of the spans of each of the amplitude configurations, so there will be 20 amplitude cal points for each frequency. I'm not too sure if each of these amplitude configurations also requires a (zero) offset calibration (which of course needs to be kept when modifying the cal file). Since there probably are two possible output amplifier configurations, also only so many AC offset cal parameters may be required, and they would be independent of frequency.

Then we've got the separate offset voltage DAC that is utilized to actively position the output waveform at an arbitrary DC level. It's also used for DC output. This may require two or three cal parameters for each output amp configuration, so maybe six in total  (+1v / 0V / -1V and +10V / 0V / -10V). Maybe the zero calibration is identical with the aforementioned AC offset compensation.

My best guess is that the two (curretnly identical) halves of the cal files are there for a custom calibration and still keep the factory one so a "Reset to Factory Defaults" during a cal procedure would be possible.

[tv84]

What I show in my images are just half of the original .dat files.

Because both half are the same.

And, each half has its CRC at the beginning (i think it's a crc).

BUT, as we see in the pics, each half has itself 2 similar halves which i suppose are the 2 different channel settings.

[tv84]

The DG800/900/2k has ten possible configurations of the output attenuator / amplifier, and there's some considerable tolerance between the seams, so I guess there will have to be a CAL point for each frequency and for each end point of the spans of each of the amplitude configurations, so there will be 20 amplitude cal points for each frequency.

As I suggested based on the rectangles area sizes, each freq point should have 160 bytes (2 lines of 80 pixels).

I attach a pic of the mapping with 160 bytes per line. We now perfectly see the 23 calib freq lines (in that rectangles area),

So, there are 4 x 20 bytes for each freq with valid information. Or , as you say: 20 x 4 bytes (amplitude cal points).

[tv84]

The "two possible output amplifier configurations" are probably the inverted L shape zones at the beginning of the map.

I didn't find any way to replicate the initial 2 bytes CRC. So, no proof that it is a CRC. I don't see that in the app code also.

[TurboTom]

I tried copying the calibration point list to my Cal file as suggested by tv84, I also added in some of the missing data of the following two blocks that appear to have very similar structure. The result was worse than with the unmodified file, with a very distinct amplitude jump (drop) at exactly 25MHz (i.e. when stepping from 25 MHz to 25.000 001 MHz. Moreover, the amplitude droop towards 100MHz was as pronounced as when I ran the generator without any calibration file, i.e. it dropped by half. With the original ("incomplete" -> 30MHz) cal file, it's much better and droops only by round about 2.5dB, while with the DG2000 cal file, it doesn't droop at all vs. frequency  but has other inaccuracies (DC offset, general amplitude and frequency figures).

Edit: The divisor for the cal frequency list appears to be 3906.25, resulting in cal points (among others) at exactly 30MHz and 25MHz, which my test described above suggests. Since by replacing the cal point list of my original DG800 file with the DG2000 file, the cal points got shifted down by 16 places, the 25MHz calibration will now point to a place that may not be specified (even though I filled in some data from the DG2000 file that I assumed to be cal parameters), resulting in the "jump". This means, there has to be a "hard" correlation of cal file locations regarding frequency / parameter allocation.

The "second" calibration frequency table, located at 0x438f, starts in the DG800 file at 500kHz and as the last two frequency points, holds 30MHz and 100MHz, whereas the DG2000's file starts at 300kHz and has the additional "Low End" cal points 600kHz and 900kHz. From 1.25MHz to 30MHz, the cal points match between the two while between 30MHz and 100MHz, the DG2000 cal file contains 11 more points. This quantity of cal points and also the presence of more low-end cal points on the DG2000 makes me assume that this instrument is calibrated to a higher accuracy vs. the DG800 / DG900(?) series, legitimating its "higher rank" in Rigol's AWG product range. Maybe the customers are paying for calibration accuracy rather than for hardware value. Just a wild guess, though... 

The blocks following the Cal Points, starting in 0x451e and 0x45e6 appear to hold the calibration constants, consisting of little endian DWords. The number of entries matches the number of Cal Points and apparently, the value of the constants is continuously rising (which makes sense as when the frequency increases, the gain drops). The presence of two such cal blocks for each channel makes me assume that these two blocks calibrate the two output amp configurations. I've now got a pretty good idea of what's going on there and could possibly fit a curve on the DG2000 cal points to extrapolate the existing cal point ensemble of my DG800 in order to generate the missing ones between 30 and 100MHz. If I find some time, I'll give it a try...

Edit 2-3/8: I started analyzing the cal data and it appears more complex than anticipated. The first blocks of cal data don't appear to make much sense, neither in Integer32 nor in Float32 format. The second blocks may very well be cal factors in Float32 format. But maybe, the two cal blocks are meant to be used in combination, either to describe a starting value and a (linear) slope or the like, or maybe as a quotient or similar to improve resolution. I attached an oversize PDF and a zipped Excel file (converted form OpenOffice) of the lists. Maybe someone is interested in having a go at the puzzle...

Edit 3-1/4: Unfortunately, my recent experiments prove that only patching the cal file locations that I analyzed in my PDF, won't suffice to "smooth out" the upper frequency range. I copied the upper end cal data of the DG2000 that better matches my existing DG800 cal file, taking good care that there's no improper interval specification, and the result is worse than with the original cal files. The AWG will perform flawlessly up to 40MHz and show a sudden level drop there by about 10% (when crossing the 40MHz -> 40.000001MHz border), drooping further when frequency is increased. This droop is once again way worse than with the original cal file. The only explanation for this is that calibration information in other locations of the file is missing for a complete upper end calibration. With this information, it may be advisable to look again more closely at a proper SCPI calibration... Bummer! 

[Hobbit13]

The "second" calibration frequency table, located at 0x438f, starts in the DG800 file at 500kHz and as the last two frequency points, holds 30MHz and 100MHz, whereas the DG2000's file starts at 300kHz and has the additional "Low End" cal points 600kHz and 900kHz. From 1.25MHz to 30MHz, the cal points match between the two while between 30MHz and 100MHz, the DG2000 cal file contains 11 more points. This quantity of cal points and also the presence of more low-end cal points on the DG2000 makes me assume that this instrument is calibrated to a higher accuracy vs. the DG800 / DG900(?) series, legitimating its "higher rank" in Rigol's AWG product range. Maybe the customers are paying for calibration accuracy rather than for hardware value. Just a wild guess, though... 

If I'm bored I could make a accuracy comparison between the DG811 and DG2052 connected to exactly the same scope.

The datasheets of the DG900 and DG2000 list exactly the same accuracy specs, and up to 35MHz all specs are also identical for the DG800. I would not expect them to differ in output accuracy for the range below 25 MHz.  And between the DG900 and DG2000 I do not expect any difference. Pricing is almost the same, the DG2000 is just the direct successor of the DG1000 range (Same housing etc.) and the DG900 is a new range.
Due to this Rigol's range is now a bit weird, with a 16bit generator as low end, and 14 bit above that. Don't get why they are still promoting the DG1000 as an active product.

[rf-loop]

just for...





ETA: Forget info about signal. Cable between DG and SA 30cm RG316 so its effect to this curve is nonsense..

[SMB784]

just for...





ETA: Forget info about signal. Cable between DG and SA 30cm RG316 so its effect to this curve is nonsense..

Is this a spectrum of the upgraded DG811?  Or is it a spectrum from another model?  If it's from a DG811, how did you successfully calibrate it?

[TurboTom]

Is this a spectrum of the upgraded DG811?  Or is it a spectrum from another model?  If it's from a DG811, how did you successfully calibrate it?

  This is just what you get when you analyze a factory-calibrated DG800 series intrument that's "liberated" to 100MHz. Mine doesn't perform much different. Slightly more than 2dB level drop at the top end... @rf-loop's specimen may perform slightly better than average.

[rf-loop]

just for...





ETA: Forget info about signal. Cable between DG and SA 30cm RG316 so its effect to this curve is nonsense..

Is this a spectrum of the upgraded DG811?  Or is it a spectrum from another model?  If it's from a DG811, how did you successfully calibrate it?

DG811 what have dementia and do not remember she is DG811 and think name is DG992.
Any kind of "calibration"? No more than what is inside out from box new DG811.
If look Rigol specs for DG992 it is not far from its limits. Up to 80MHz inside limits.

[CeD]

Small question

Is there a way to change the way numbers (and especially thousands) appear on the DG8XX DG 9xx series ?

It's extremely errorprone (for me) to see "90 Hz" written as 90.000,000 Hz

[CeD]

I'm answering myself,
that seems to be inside
 Utility  System Setting  Delimiter

I'll try that ! It seems it won't get rid of the useless zeroes, but it's a start.

By the way, my "upgraded" DG812 displays a very good sinusoid at 80Mhz, at 2Vpp, after that I have a small drop in amplitude but the signal remains a serious sinusoid up to 100Mhz.

Strangely enough, I've got a bit of an higher amplitude around 60Mhz (as other people have reported) so hitting 2,2Vpp. I guess this is the part that would benefit calibrating, but quite frankly, as a pure signal generator, the upgraded DG812 is usable at least up to 80Mhz.