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

Javier Herrero jherrero at hvsistemas.es
Sun Jan 29 13:22:33 UTC 2012


El 29/01/2012 13:57, Magnus Danielson escribió:
> Hi Javier,
>
> On 01/29/2012 12:45 PM, Javier Herrero 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.
>
> Good work Javier!
>
> It also makes perfect sense from the hardware architecture of these 
> newer 5680A. It's nothing wrong with it, it's just different.
>
> Somebody put this up on the wiki.
>
> I will receive new 5680A when I pickup the packet on Monday, I only 
> have an older variant with serial port and DDS output.
>
> Cheers,
> Magnus
>
I've just gathered the following message from the unit using the serial 
tool:

Cmd 0x22 0x0D byte reply: [22] [0D] [00] [2F] [44] [02] [62] [EF] [43] 
[FD] [CC] [87] [3E]
Cmd 0x22 ASCII (.): D.b.C...
Cmd 0x22 ASCII ( ): D b C

It seems that these are the current DDS values. Since now they are a 
slightly different of what I've logged before, I suppose that they are 
updated and are not some stored start-up values. So another 
reverse-engineered commad :)

I'm currently logging with the logic analyzer the SPI activity to the 
DDS, it seems to be updated at a somewhat outrangeous interval of 671.5 
seconds or something like that. It will take several hours to fill the 
analyzer memory :)

Regards,

Javier, EA1CRB




More information about the time-nuts mailing list