[time-nuts] FE-.5680A trimming resolution

Bob Camp lists at rtty.us
Sun Jan 29 13:45:02 UTC 2012


Hi

Very interesting. 

It sounds like dithering would be needed to get down to parts in 10^-14. If we do that from an external device (PC / PIC / FPGA / whatever) it would be useful to know the delay between the serial command and the DDS update. The more variable the delay, the less accurate the dither. 

Bob



On Jan 29, 2012, at 6:45 AM, Javier Herrero <jherrero at hvsistemas.es> wrote:

> Hello,
> 
> As it has been discussed in the past days, the architecture of the newer FE-5680A that has been recently purchased by a lot of us does not led to a trimming resolution through the serial port of 1.7854e-7Hz, but rather leds to think that the trimming resolution is in fact 6.80789e-6Hz (relative frequency resolution 6.807e-13).
> 
> I've hang a logic analyzer to the DDS SPI bus, and an SPI message appears inmediately after updating the offset through the serial port. I've found that the DDS is programmed in two frequencies, separated 1400Hz near exactly, for each serial port offset setting, and that one bit increment in the serial port offset setting is translated to a one-bit increment for both DDS frequencies. The DDS frequencies are alternated at 416.6666666Hz rate through FSELECT pin, at an invariable 50% duty cycle, presumably to perform synchronous detection in the same way as explained in the FRS-C manual.
> 
> For example, the following data has been gathered:
> 
> Serial offset 00 00 00 00
> DDS A word: 44 02 62 F6 = 1141007094 = 5 313 228.32219 Hz
> DDS B word: 43 FD CC 8E = 1140706446 = 5 311 828.32085 Hz
> 
> Serial offset 00 00 00 01
> DDS A word: 44 02 62 F7 = 1141007095 = 5 313 228.32685 Hz
> DDS B word: 43 FD CC 8F = 1140706447 = 5 311 828.32550 Hz
> 
> Serial offset 00 00 00 02
> DDS A word: 44 02 62 F8 = 1141007096 = 5 313 228.33151 Hz
> DDS B word: 43 FD CC A0 = 1140706448 = 5 311 828.33016 Hz
> 
> I've seen that these values seems to vary slightly from time to time in the less significative digits, I've been then change in the order of 2-3 units from one data take to a different one minutes later. I've checked that the unit updates each several seconds the DDS control words, and I've seen changes in the lower significant bits at minutes intervals, although most of the times, same previous words are sent. I suspect this is some form of unit self-compensation, perhaps to temperature changes.
> 
> Last, I've sent an offset of 1468879 units, that shoudl correspond to a 10Hz frequency change assuming a trimming resolution of 6.90789e-6Hz, and after a temporary unit unlock, it has locked exactly at 10 000 010.000 Hz. So I can conclude that these units are not fully compliant with the manual we are handling, and that the trimming resolution is 6.80789e-6Hz and not the stated 1.7854e-7Hz.
> 
> Best regards,
> 
> Javier, EA1CRB
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list