[time-nuts] FE-.5680A trimming resolution
jherrero at hvsistemas.es
Sun Jan 29 08:22:33 EST 2012
El 29/01/2012 13:57, Magnus Danielson escribió:
> Hi Javier,
> On 01/29/2012 12:45 PM, Javier Herrero wrote:
>> 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.
I've just gathered the following message from the unit using the serial
Cmd 0x22 0x0D byte reply:  [0D]  [2F]    [EF] 
[FD] [CC]  [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 :)
More information about the time-nuts