[time-nuts] Re: function generator

Andy Talbot andy.g4jnt at gmail.com
Mon Nov 22 17:34:23 UTC 2021


The frequency setting error is the clock frequency divided by the
accumulator length, at least in a DDS
If it has a 32 bit NCO clocked at 200Mhz, the setting error will be
200MHz/2^32 = 0.046Hz.
Max possible error will be 2^-32 of te hclock.

Not sure how that AWG would be set up, but if you can choose your buffer
length, then make sure you get one that allows an exact integer division
from your clock.   If you can't choose a buffer length and are forced to
take a fixed value, then frequency generation errors are inevitable.



Andy
www.g4jnt.com



On Mon, 22 Nov 2021 at 17:14, Jeremy Elson <jelson at gmail.com> wrote:

> Andy,
>
> I was thinking in the same direction - the device can create arbitrary
> waveforms so they're almost certainly using DDS. So I assumed it was some
> sort of round-off error. I just can't quite convince myself of this because
> it seems like round-off errors would be bigger, i.e. an error of one part
> in 1E11 suggests a buffer of length 1E11 which seems unlikely.
>
> On Mon, Nov 22, 2021 at 9:06 AM Andy Talbot <andy.g4jnt at gmail.com> wrote:
>
>> Could the Rigol be using a DDS / NCO lookup approach to its frequency
>> generation?  In which case you'll be subject to rounding errors on the DDS
>> increment, whose maximum magnitude will be  dependent on the register
>> length.
>>
>> Andy
>> www.g4jnt.com
>>
>>
>>
>> On Mon, 22 Nov 2021 at 16:53, Jeremy Elson <jelson at gmail.com> wrote:
>>
>> > I did not see any such setting in the Rigol, but I'll check again. in
>> April
>> > I did write to Rigol to report the problem and had the following
>> (abridged)
>> > conversation with support:
>> >
>> > Me:
>> >
>> > "I recently tried to use your DG1022Z signal generator to generate one
>> > pulse-per-second (pulse mode, frequency 1.000000hz, width 10
>> microseconds).
>> > However, it appears there is a small frequency error of one part in
>> 1e11,
>> > i.e. the pulse per second gets later by about 6 nanoseconds every 1,000
>> > seconds." [More technical description abridged, including a link to a
>> > graph.]
>> >
>> > Rigol:
>> >
>> > "Please find the following datasheet for DG1000Z, the accuracy is
>> +/-1ppm.
>> > If your pulse is 1second with 10us width, 6ns per 1000s is in the
>> accuracy
>> > range."  [They attached an image of a page from the DG1000Z datasheet,
>> > showing a line that said "Accuracy: +/- 1ppm of the setting value"]
>> >
>> > Me:
>> >
>> > "Is this the specification even when the unit is provided with an
>> accurate
>> > external clock?"
>> >
>> > Rigol:
>> >
>> > "I would say Yes. The internal processing circuit will effect the clock
>> > signal,  harmonics and phase noise will result the frequency variance."
>> >
>> > -Jeremy
>> >
>> > On Sun, Nov 21, 2021 at 11:54 PM Poul-Henning Kamp <phk at phk.freebsd.dk>
>> > wrote:
>> >
>> > > --------
>> > > Jeremy Elson writes:
>> > >
>> > > > [...] I plugged an RbXO into the DG1022Z and simply asked the
>> > > > DG1022Z to divide it down to a 1pps signal. That is, I configured
>> it to
>> > > > create a pulse with a small duty cycle and 1hz frequency using the
>> > > external
>> > > > clock as a reference. To my surprise, it introduces a small but
>> > > > measurable error of one part in 1E11 in the dividing-down. You can
>> read
>> > > the
>> > > > full story of this in my post from earlier this year:
>> > >
>> > > When you feed such instruments an external clock, you often have to
>> > change
>> > > one or more calibration constants for the internal (OC)XO's offset to
>> > zero.
>> > >
>> > > Another problem is that if you use the square wave output of a DDS
>> based
>> > > generator, they often produce the square from the sine output of
>> > > the DDS chip with a schmitt-trigger, which causes lousy jitter.
>> > >
>> > > --
>> > > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> > > phk at FreeBSD.ORG         | TCP/IP since RFC 956
>> > > FreeBSD committer       | BSD since 4.3-tahoe
>> > > Never attribute to malice what can adequately be explained by
>> > incompetence.
>> > >
>> > _______________________________________________
>> > time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
>> send
>> > an email to time-nuts-leave at lists.febo.com
>> > To unsubscribe, go to and follow the instructions there.
>> >
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
>> send an email to time-nuts-leave at lists.febo.com
>> To unsubscribe, go to and follow the instructions there.
>>
>




More information about the Time-nuts_lists.febo.com mailing list