Rigol DG1022 frequency counter error (to a lesser extent the 1054Z as well) - Page 1
Forum section: electronics / testgear

author: ormandj
author_rank: Unknown
timestamp: February 12, 2016, 05:52:05 am
content: Hi,I have a new Rigol DG1022 received this week. I've got it connected to a BG7TBL 10MHz (sine wave) GPSDO via the external reference port (enabled, and the DG1022 displays a message on power on indicating the external reference was found). When I send the 10MHz output of the DG1022 from channel 1 to channel 2, the frequency counter is off by a significant margin (I was using 3V amplitude). If I connect the BG7TBL GPSDO directly to the DG1022, it is off by the same margin. If I connect either to my 1054Z, the frequency counter on it displays 10.0000 to 10.0001, so a little error there too (perhaps rounding up an even smaller error than displayed ?).Is this expected behavior? The DG1022 counter is +40ppm @ 10MHz if I'm not incorrectly reading/understanding something. I couldn't find specifications for the frequency counter, so perhaps this is within the margin of error designed? I expected better with an external frequency reference, but perhaps it's unused for frequency counting? I'm very new to all of this, so please excuse any ignorant misunderstandings.Picture attached to show the counter error on the DG1022. I used the 'auto' button, but manually adjusting the options doesn't seem to make much difference. futz with the settings manually, sometimes it will drop 100Hz closer (and often jump back up), but it's still 300Hz off at best, and 400Hz off with 'auto', unless I'm mis-reading the display somehow.I appreciate any input regarding this, I may be doing something incorrectly leading to the errant results. The DG1022 has been powered up for over 30 minutes, in case that matters. Thank you!

author: alsetalokin4017
author_rank: Super Contributor
timestamp: February 12, 2016, 07:49:34 am
content: According to the Datasheet, the "frequency accuracy" is +/- 50 ppm in 90 days and +/- 100 ppm in 1 year. I assume this applies both to the generated waveforms and to the frequency counter. This is from 18 degrees C to 28 degrees.http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-001b/0/-/-/-/-/file.pdf

author: TheSteve
author_rank: Unknown
timestamp: February 12, 2016, 09:39:35 am
content: No matter the spec that is a pretty huge error considering you're feeding a reference in and then effectively measuring that same reference. I'd have thought the error would be in the milliHz range at the most.

author: ebastler
author_rank: Super Contributor
timestamp: February 12, 2016, 11:09:37 am
content: Quote from: TheSteve on February 12, 2016, 09:39:35 amI agree. The "frequency accuracy" spec should be dominated by the limited accuracy of the internal reference clock. If you generate a signal internally, and then feed it back to measure the frequency, the result should be near-perfect, since generation and counting refer to the same reference clock. (Hence the result should be perfect even with a bad reference clock!)An firmware error which causes deviations of that magnitude in the generator or frequency counter seems unlikely. Maybe the counter is registering some spurious pulses? I am not familiar with this counter model. Are the output and input both properly terminated with 50 Ohms? Can you change the hysteresis of the input (maybe via a menu item called "noise rejection" or similar)?

author: alsetalokin4017
author_rank: Super Contributor
timestamp: February 12, 2016, 03:22:21 pm
content: I'm surprised that it only has six digits of resolution. That's 100 Hz for the 10 MHz measurement.Not real great for a counter, but then I'm used to my ancient Philips PM6676 with ocxo reference oscillator, which gives 8 digits (1Hz) resolution with a 1 second gate time and 9 digits with a 10 second gate at 10 MHz.Nevertheless, I interpret the 400Hz error at 10 MHz to be within the +/- 50 ppm accuracy specification of the DG1022. Just barely.

author: pa3bca
author_rank: Regular Contributor
timestamp: February 12, 2016, 03:47:24 pm
content: Something is very wrong with your setup, IF the counter is indeed locked to the GPSDO it is measuring.Are you _very_ sure the counter has a (valid) lock to the GPSDO? If so there should not be such a large error.If I measure my GPSDO with my DG1032z (locked to same) it measures a _very_ precise 10 MHz..I get the same precision if I measure the output of the DG itself. As is to be expected.Error should not be more thane one pulse per gate time.

author: ormandj
author_rank: Unknown
timestamp: February 12, 2016, 03:59:10 pm
content: Quote from: alsetalokin4017 on February 12, 2016, 03:22:21 pmWould you expect this error even when using an external reference? I would have thought using the external reference, you would remove a lot of the error, but that's clearly not what I'm seeing. I just spoke with Rigol tech support and they didn't have an immediate answer for me, and are supposed to get back to me soon.

author: Orange
author_rank: Frequent Contributor
timestamp: February 12, 2016, 04:09:27 pm
content: Quote from: pa3bca on February 12, 2016, 03:47:24 pmIt is not the set-up. It is the DG1022 ! The counter is not locked to the external ref. Only the generator is locked. It is a bug in the DG1022. I have the same error on mine......The counter in the DG1022 is only for approximate freq. indication

author: alsetalokin4017
author_rank: Super Contributor
timestamp: February 12, 2016, 04:10:31 pm
content: Quote from: ormandj on February 12, 2016, 03:59:10 pmI don't know what to expect from the Rigol FG used as a counter, except what I read on the spec sheet.My Philips can accept an external reference but I don't have one to give it, it's my "master instrument". And the cheapo DDS FG that I have has too much jitter to be trusted. I can say that the hardware counter in my Rigol DS1054Z agrees precisely with the Philips whenever I have compared the two using a clean signal, fwiw.Have you tried running the self-calibration routine (I assume the DG1022 has one...)? Maybe it's just a temperature-related issue or something simple like that.(We are assuming that your GPSDO source is accurate, have you been able to check this using a different counter?)

author: PA0PBZ
author_rank: Super Contributor
timestamp: February 12, 2016, 04:13:39 pm
content: Quote from: Orange on February 12, 2016, 04:09:27 pmIf that is the case then with internal reference the error should be gone. Easy to test

author: ormandj
author_rank: Unknown
timestamp: February 12, 2016, 04:16:40 pm
content: Quote from: PA0PBZ on February 12, 2016, 04:13:39 pmIt's still off, but closer. Alternates reading "9.999,92" and "9.999,98".Does anybody know if the DG1032Z/DG1062Z have the same problem, or will they more accurately count with an external reference attached?

author: pa3bca
author_rank: Regular Contributor
timestamp: February 12, 2016, 04:19:05 pm
content: Quote from: ormandj on February 12, 2016, 04:16:40 pmSee my message above......

author: ormandj
author_rank: Unknown
timestamp: February 12, 2016, 04:22:52 pm
content: Quote from: pa3bca on February 12, 2016, 04:19:05 pmOh my, somehow I missed that. Thank you so much! Sounds like I have a solution.

author: pa3bca
author_rank: Regular Contributor
timestamp: February 12, 2016, 04:32:50 pm
content: Quote from: Orange on February 12, 2016, 04:09:27 pmSounds more like a design error (rookie mistake at that). Why not use the same clock for the both the FG and the counter? Saves at least a crystal. Even when measuring the FG on the internal clock the output is significantly off.Or possibly the counter is an afterthought and they used a cheap complete Aliexpress counter unit ($2,45)?

author: ormandj
author_rank: Unknown
timestamp: February 12, 2016, 05:40:49 pm
content: Quote from: pa3bca on February 12, 2016, 04:32:50 pmJust talked to TEquipment, the DG1022 is going back and a DG1032Z is on the way. Thank you again for the tip, it'll be nice to have a counter that works as expected. Looks like a much better unit overall, too - probably should have gone this way from the start.

author: TheSteve
author_rank: Unknown
timestamp: February 12, 2016, 10:13:40 pm
content: I tested a DG1022 I have access to - the frequency counter behaves the same as yours did no matter the reference used.

author: jpb
author_rank: Super Contributor
timestamp: February 13, 2016, 11:36:20 am
content: I seem to remember that Rigol just use a binary counter for frequency measurement so there is an intrinsic quantisation error however accurate the reference is.If you look at the gate times for the Rigol DG4000 (from the manual) :GateT11.310msGateT210.48msGateT3166.7msGateT41.342sGateT510.73sGateT6>10nsYou can see that they are not round numbers in base 10 - this is to fit in with whole periods of the underlying binary counter I think.

author: mimi
author_rank: Newbie
timestamp: February 13, 2016, 03:14:27 pm
content: My theory: The DG1022 firmware thread holds a calibration instructions document. From that it appears that you can adjust the frequency by measuring the output frequency and then type the results back into the DG1022. That is, instead of adjusting the actual reference clock the calibration works by multiplying the entered frequency by some factor (say 1.0 +/- 100ppm). While this holds true for the generator the counter may not use the same type of correction. Can you check that that the output is in sync with your connected 10MHz reference if FG is tuned to 10.0 MHz. I am afraid it is not (will always slightly off because of the calibration adjustment).

author: ormandj
author_rank: Unknown
timestamp: February 13, 2016, 03:30:39 pm
content: Quote from: mimi on February 13, 2016, 03:14:27 pmI've already returned the 1022 to exchange for a DG1032Z so I can't test this for you unfortunately. I do know the counter error seemed to scale with frequency, so it seemed to be off by a stable factor. I didn't test a lot of frequencies to calculate the error. Hopefully someone else in this thread can answer your question.

author: uncle_bob
author_rank: Unknown
timestamp: February 13, 2016, 03:38:21 pm
content: Quote from: mimi on February 13, 2016, 03:14:27 pmHiThat's the way many modern counters do calibration. It is not a lot different than DVM's or other gear. No tweaks at all, just data in an eeprom. The problem is still the same. You *expect* the internal standard to drop out of the equation when an external standard is used. If it's a software offset system, you expect it to update the offsets against the external standard. You might even expect it to automatically re-calibrate the numbers when an external reference is connected (not a good idea ...).As with a lot of this, having a better manual would be a big plus. It's a "say what you do / do what you say" kind of thing. Without doc's there are just guesses about what might or might not be happening.Bob

author: mimi
author_rank: Newbie
timestamp: February 13, 2016, 04:41:48 pm
content: I just tested with an externall reference. My assumption proofs wrong. With external reference and frequency set to 10.0 MHz output is perfectly in sync with reference (as it should be). The counter reading is different though:10.000 4 MHz with external reference9.999 60 with internal reference (not 100% stable as with external ref.).I was not aware that I have to change the settings for the external reference to be used (thought it just overdrives internal clock). With the explicit setting to external ref it is easy for the firmware to disable "software calibration" if external ref is in effect...

author: uncle_bob
author_rank: Unknown
timestamp: February 13, 2016, 04:55:12 pm
content: Quote from: mimi on February 13, 2016, 04:41:48 pmHiHere's the gotcha with having "calibrate the settings" turned on all the time. It's the fact that they get written to eeprom as they are updated. Eeprom's have a finite life. If ..errr ... somebody ... was to run a counter so it updated say every few seconds ....the eeprom dies while the counter is still in warranty. Fortunately HP took pity on me and replaced the eeproms in all of the multi kilobuck counters in that case.Bob