Products > Test Equipment
DG4000 - a firmware investigation
Gandalf_Sr:
I tried Ted's open, no change, save CAL technique (on HFLAT only) but it does not seem to have worked; at some point, the values that self-populated for the steps took a jump from 16's to -2's. I get significant drop in output level (Vpp) when going up to 100 MHz and more at 200 MHz. I guess I'll have to do a real CAL :-BROKE
ted572:
--- Quote from: Gandalf_Sr on August 11, 2014, 05:13:10 pm ---I tried Ted's open, no change, save CAL technique (on HFLAT only) but it does not seem to have worked; at some point, the values that self-populated for the steps took a jump from 16's to -2's. I get significant drop in output level (Vpp) when going up to 100 MHz and more at 200 MHz. I guess I'll have to do a real CAL :-BROKE
--- End quote ---
Gandalf:
Please read all of the below so that you know what to expect:
For a DG4202 the CW RF Output should be flat up to 200MHZ within +/- 0.8dB after the Calibration recovery has been completed. Note that the Sine Sweep Mode is still limited to a maximum frequency of 160.000,000 MHz for a flat RF Output. Any Stop frequency above this at all, will screw up the frequency response even below 160MHz. So if want to go beyond 160.000,00MHz do it in Sine CW mode only.
Still think your DG4202 has a problem:
Check that your DG4202 is Set for (under Utility, Settings) 'Power, Default', Not 'Power, Last'. Then I suggest going back to FW 00.01.06. Verify that you still have a DG4202 model installed per the DG's 'Utility', 'System', 'Information' menu. If not use the appropriate CEN file to change it to one. Perform the Calibration Recovery routine for Amp-AC*, LFLAT*, and HFLAT. Then go back up to to FW 00.01.08. How is it now?
Note: * Cal for Amp-AC and LFLAT Cal. may not be required, but I do it to prevent other potential glitches. I had a few people tell me that doing this fixed some issues for them, but I don't have any conclusive evidence. It's easy to do, but you can always go back and do these two later (if you chose to) after you have determined your unit is now working Ok in manual CW mode to 200MHz.
The above is what I have successfully done and has worked for others, but if there is something unusual with your unit (i.e. FW/hardware) I'm NOT responsible. I think you will be OK, but I live far, far away, so don't come looking for me.
If you have questions, but no bitching please (Ha Ha), feel free to contact me via a PM.
Good luck, Ted572
TooOldForThis:
One thing I found is that when using a DG4062 (FW rev 1.07) to measure ~1 second periods, the value displayed on the LCD and the value sent over the USB interface don't match. The value that comes back from ":counter:measure?" is always ~13.5nS higher than the value on the display.
For example, LCD value = 1.000,000,001,1 while the USB value = 1.000000014E+00
This problem doesn't happen at higher frequencies.
I reported this to a Rigol app eng. The last I heard from him was "I have reproduced the issue. We are investigating. I'll let you know what I find." That was six months ago.
ted572:
--- Quote from: TooOldForThis on August 27, 2014, 03:27:16 am ---One thing I found is that when using a DG4062 (FW rev 1.07) to measure ~1 second periods, the value displayed on the LCD and the value sent over the USB interface don't match. The value that comes back from ":counter:measure?" is always ~13.5nS higher than the value on the display.
For example, LCD value = 1.000,000,001,1 while the USB value = 1.000000014E+00
This problem doesn't happen at higher frequencies.
I reported this to a Rigol app eng. The last I heard from him was "I have reproduced the issue. We are investigating. I'll let you know what I find." That was six months ago.
--- End quote ---
Install FW 00.01.08 and then try this again. There were some bugs in .07 that were fixed in .08. Even the installation of FW .07 was a little different than normal. In fact several reported that they didn't think the installation completed properly. Although the DG reported that FW .07 was installed (via. Utility, System, Information). I don't know that the issue you found was fixed, but you certainly do want to go to .08.
TooOldForThis:
I had updated to 1.08 in July. It didn't help.
Here are the results using rev 1.08 firmware:
Setup: Measuring the period of a GPS pulse-per-second output. The DG4062 is running on an external 10MHz Rubidium time source. Gate Time = 10sec. HF suppression on.
Front panel period measurement = 1.0000000011 (dang, off by 1.1nS ;) )
At the same time, the SCPI output for “:counter:measure?” is
9.999989975E-01, 1.000000014E+00, 1.000000047E+01, 1.000029678E-01, 8.999970466E-01
(Frequency, Period, Duty Cycle, Positive Pulse Width, Negative Pulse Width)
The problems are:
The period value displayed over SCPI is always 13-14nS higher than the value on the display.
The period and frequency values in the SCPI data are not reciprocals of each other.
On the plus side, the Positive Pulse Width and Negative Pulse Width values add up nicely to the Period value in the SCPI data.
When test equipment gives you conflicting data for the same measurement, which data, if any, should you believe?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version