Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
Hi Tom, I am just curious... What did you mean if the GPS was warmed up? Do you mean the Jupiter GPS unit its self to be warmed up? (if so, what does the Jupiter unit have to do with the oscillator stability, besides providing that 10KHz signal?) Great info, thanks. Do you have any documentation you could send me or website documenting your project? (hopefully I am not asking for too much! :-) ) Thanks On Sun, Jan 29, 2012 at 1:36 AM, Tom Curlee tcur...@sbcglobal.net wrote: Ray: I used a similar circuit to lock my 10 GHz LO to GPS. I used a similar Jupiter GPS board receiver (not the 'T' version). My 10 GHz LO is one of the older Microwave Associates brick type of oscillators. It has an internal 106.5 crystal oscillator that is in a crude oven. The 106.5 is multiplied by 96 to get the 10.224 GHz LO frequency. It would hold frequency fairly reasonably in my lab, but outside in the summer it would drift as much as 30 kHz. I installed a varactor diode on the quartz oscillator to control the frequency. I divided the 106.5 MHz down to 10 kHz and compared it with the 10 kHz out of the Jupiter in an exclusive OR gate. I used a one op amp filter circuit that had a time constant of 5 to 10 seconds - not critical, but just needs to be slow. If the GPS was 'warmed up' (it had been on in the last few hours), the 10 GHz LO will lock to within a few Hz of the 10.224 GHz in less than a minute after power on. I have some other frequency stability issues that I need to fix, but the GPS lock portion of the circuit works great. Look on eBay for GPS antennas. I use one of the small mag mount units. You can get one for around $6.00, shipping included. Also look on www.halted.com and search for GPS antenna. They have some (that I use) for $3.95, but charge $5.00 handling for under $20 - 1 is $8.95, 2 is $12.90, etc Let me know if I can help in any way. 73, Tom WB6UZZ --- On Sat, 1/28/12, Ray Xu rayxu...@gmail.com wrote: From: Ray Xu rayxu...@gmail.com Subject: [time-nuts] Building a GPSDO trouble using Jupiter-T To: time-nuts@febo.com Date: Saturday, January 28, 2012, 10:50 PM Hi guys I'm planning to build a GPSDO to use as a frequency ref for my GHz ventures. I've done research in what other people have built - but I have no experience working with long-term precision/stability products (nor do I have the equipment to do so -- I think). I'm using the Jupiter T (the one with the 10-pin header) GPS and its 10KHz output in an analog PLL that controls a 10MHz VCXO. It would be ideal for me that if I were to multiply the 10MHz output up to 10GHz, I would get about a few Hertz or so of inaccuracy. It would also be ideal if I can have a PLL lock time of a few minutes while maintaining accuracy. However, right now as I am trying to design my project, I can't find enough information on the web regarding the VCXO's (or the PLL oscillator, in this case) short term accuracy effect on output frequency. I know that its short term accuracy depends on the response time of the PLL, which also depends on the amount of jitter from the Jupiter-T's 10KHz output... I know that the longer the time constant for the PLL, the better accuracy, but I do not want to wait, literally, hours for it to lock... Also, what is the advantage of using a OCXO instead of a VCXO in terms of short-term accuracy? If the PLL time constant is only a few seconds, then a crystal shouldn't deviate in frequency by too much within a few seconds, assuming I'm using a crystal bought from a well-known manufacturer...or could it? I am inclined towards using oscillators that do not require any significant warm up time... For those who have experience using the Jupiter T GPS: I have bought this http://www.ebay.com/itm/Navman-jupiter-T-Tu60-GPS-Kit-1pps-10khz-GPS-Module-/260790984470but I could not get it to communicate via serial. So far, I do not have an antenna available and so the antenna port is just left disconnected. When I turn it on, there is a 1pps and 10KHz signal and the TX line is at logic high. However, I cannot get it to communicate to anything else, even a dumb terminal. It does not respond to when I send a message ID to it. (Because of computer difficulties, I am using the PicKit 2's UART tool). Is my device a dud or am I doing something wrong? Many inputs is highly appreciated. Thanks -- __ 73, Ray Xu KF5LJO ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- __ 73, Ray Xu KF5LJO ___ time-nuts mailing list --
[time-nuts] FS 4x 5MHz OCXO
For sale lot of 4 OCXO 2x Oscilloquartz 8676-AT 5 MHz 12V. (Used) 2x Isotemp OCXO91-30 5 MHz (brand new) for 50.00 Euro + shipping rate extimated shipping cost for europe 45 Euro, Italy 14 Euro. If interested email me directly to: tim...@timeok.it Luciano P. S. Paramithiotti IZ5JHJ Sent to you using Uebimiau Webmail version 3.11 Developed by Dave and Todd at http://www.manvel.net and http://www.tdah.us ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] eBay FE-5680A
Hi Brad, I've had no problems so far. I bought a couple on a free postage deal (took about a month). Both worked fine, and just in process of building them into a case. Communications with the guy in China were first class. You also need to realise, that you are getting one hell of a deal with the prices quoted on EBay from China. These Rubidiums from direct from FEI or one of their reps are going to be in excess of $1000 each new. OK, you take the risk of the odd dud, and also you don't know how old they are and how long they'll run, but at the prices quoted it is well worth the risk. I hope that helps. Rob Kimberley -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Brad Stockdale Sent: 28 January 2012 22:28 To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] eBay FE-5680A All, I am getting ready to order a few FE-5680A's from eBay and I noticed that all of the sellers are from Asia. Is this typically the case or are there some US based sellers? The reason I ask is because I'm always leery of buying things that ship from Asia. I've ordered stuff twice from other sellers in Asia (Hong Kong in one case and China in another). Ive only got stuck a couple times on eBay and both times it was with my deals with ppl in Asia. So, I guess this is my question: are the Asia based sellers on eBay the normal suspects and should I be concerned that I won't get the units I order? Thanks, Brad Stockdale ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] FE-.5680A trimming resolution
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.666Hz 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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Wow, good work, a very fine reverse engineering attempt. On Sun, Jan 29, 2012 at 12:45 PM, Javier Herrero jherr...@hvsistemas.eswrote: 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.666Hz 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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
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.666Hz 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
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.666Hz 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
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 jherr...@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.666Hz 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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Hi That is indeed an odd update rate. The short term stability of the FE-5680 is in the parts in 10^-13 range once you get past 100 seconds. I would think updates of a DDS lsb or more would mess up the stability. Of course if it is temperature correction, it may still be in the noise. Bob On Jan 29, 2012, at 8:22 AM, Javier Herrero jherr...@hvsistemas.es wrote: 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.666Hz 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
On 01/29/2012 02:45 PM, Bob Camp wrote: 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. Considering that you only need about 3 bits or so, and considering that the internal step mechanism run with so low rate, achieving this should not be all that hard really. It's not like there is a flashy GUI for the PIC to keep up with. A little 8 pin PIC should pull it off with not too high effort. Cheers Magns ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Hi Yes, I think the dither would just be a minor routine running on what ever you use to discipline the rubidium. Other than a disciplined environment I don't see a lot of need for sub 7x10^-13 steps. Bob On Jan 29, 2012, at 9:12 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 01/29/2012 02:45 PM, Bob Camp wrote: 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. Considering that you only need about 3 bits or so, and considering that the internal step mechanism run with so low rate, achieving this should not be all that hard really. It's not like there is a flashy GUI for the PIC to keep up with. A little 8 pin PIC should pull it off with not too high effort. Cheers Magns ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
Hi If you lock up a simple VCXO with a basic PLL, your 10 GHz LO will flop around a couple hundred hertz on a second to second basis. To get good performance off of GPS you need long averaging times. Your oscillator needs to be pretty stable without the GPS. That is where some sort of TCXO or OCXO comes in. Bob On Jan 29, 2012, at 3:19 AM, Ray Xu rayxu...@gmail.com wrote: Hi Tom, I am just curious... What did you mean if the GPS was warmed up? Do you mean the Jupiter GPS unit its self to be warmed up? (if so, what does the Jupiter unit have to do with the oscillator stability, besides providing that 10KHz signal?) Great info, thanks. Do you have any documentation you could send me or website documenting your project? (hopefully I am not asking for too much! :-) ) Thanks On Sun, Jan 29, 2012 at 1:36 AM, Tom Curlee tcur...@sbcglobal.net wrote: Ray: I used a similar circuit to lock my 10 GHz LO to GPS. I used a similar Jupiter GPS board receiver (not the 'T' version). My 10 GHz LO is one of the older Microwave Associates brick type of oscillators. It has an internal 106.5 crystal oscillator that is in a crude oven. The 106.5 is multiplied by 96 to get the 10.224 GHz LO frequency. It would hold frequency fairly reasonably in my lab, but outside in the summer it would drift as much as 30 kHz. I installed a varactor diode on the quartz oscillator to control the frequency. I divided the 106.5 MHz down to 10 kHz and compared it with the 10 kHz out of the Jupiter in an exclusive OR gate. I used a one op amp filter circuit that had a time constant of 5 to 10 seconds - not critical, but just needs to be slow. If the GPS was 'warmed up' (it had been on in the last few hours), the 10 GHz LO will lock to within a few Hz of the 10.224 GHz in less than a minute after power on. I have some other frequency stability issues that I need to fix, but the GPS lock portion of the circuit works great. Look on eBay for GPS antennas. I use one of the small mag mount units. You can get one for around $6.00, shipping included. Also look on www.halted.com and search for GPS antenna. They have some (that I use) for $3.95, but charge $5.00 handling for under $20 - 1 is $8.95, 2 is $12.90, etc Let me know if I can help in any way. 73, Tom WB6UZZ --- On Sat, 1/28/12, Ray Xu rayxu...@gmail.com wrote: From: Ray Xu rayxu...@gmail.com Subject: [time-nuts] Building a GPSDO trouble using Jupiter-T To: time-nuts@febo.com Date: Saturday, January 28, 2012, 10:50 PM Hi guys I'm planning to build a GPSDO to use as a frequency ref for my GHz ventures. I've done research in what other people have built - but I have no experience working with long-term precision/stability products (nor do I have the equipment to do so -- I think). I'm using the Jupiter T (the one with the 10-pin header) GPS and its 10KHz output in an analog PLL that controls a 10MHz VCXO. It would be ideal for me that if I were to multiply the 10MHz output up to 10GHz, I would get about a few Hertz or so of inaccuracy. It would also be ideal if I can have a PLL lock time of a few minutes while maintaining accuracy. However, right now as I am trying to design my project, I can't find enough information on the web regarding the VCXO's (or the PLL oscillator, in this case) short term accuracy effect on output frequency. I know that its short term accuracy depends on the response time of the PLL, which also depends on the amount of jitter from the Jupiter-T's 10KHz output... I know that the longer the time constant for the PLL, the better accuracy, but I do not want to wait, literally, hours for it to lock... Also, what is the advantage of using a OCXO instead of a VCXO in terms of short-term accuracy? If the PLL time constant is only a few seconds, then a crystal shouldn't deviate in frequency by too much within a few seconds, assuming I'm using a crystal bought from a well-known manufacturer...or could it? I am inclined towards using oscillators that do not require any significant warm up time... For those who have experience using the Jupiter T GPS: I have bought this http://www.ebay.com/itm/Navman-jupiter-T-Tu60-GPS-Kit-1pps-10khz-GPS-Module-/260790984470but I could not get it to communicate via serial. So far, I do not have an antenna available and so the antenna port is just left disconnected. When I turn it on, there is a 1pps and 10KHz signal and the TX line is at logic high. However, I cannot get it to communicate to anything else, even a dumb terminal. It does not respond to when I send a message ID to it. (Because of computer difficulties, I am using the PicKit 2's UART tool). Is my device a dud or am I doing something wrong? Many inputs is highly appreciated. Thanks -- __ 73, Ray Xu KF5LJO ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
Re: [time-nuts] FE-.5680A trimming resolution
El 29/01/2012 14:45, Bob Camp escribió: 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 Since I've all the things powered on the bench table, it is easy to measure: 21ms from the start of the serial message, to the end of the last DDS programming word. I've repeated several times, the time does not seem to have submitted to latencies, it is very constant. The automatic update rate of the DDS in the unit is somewhat around 28.5 seconds (I misread an inter-word delay of 671.5us as a 671.5 seconds interval). I'm trying to get a long capture from the logic analyzer to try to plot the DDS programming variations, but then I need to post-process it since the analyzer has no SPI decoding so I'm gathering the bit streams. My next intention is to replace the OCXO in one of my Thunderbolts with a Rb and use a small microcontroller to get the voltage correction from the Thunderbolt through the serial port and convert to a 5680A offset. I probably will use a Luminary since I've some small evaluation boards around, and I only have to add a MAX3232-class interface IC for the serial ports. Now... my question is to decide which of the two Thunderbolt will be converted to Franken-Thunderbolt. I've bee monitoring both from some time, feeding them from same GPS signal, and both looks quite the same (I was trying to see if one of them has a worse OCXO than the other. One is from the past group purchase, and the other has been purchased not long ago - but both are very similar, with same firmware and the Trimble OCXO, and monitored with Lady Heather they are really very similar). Next... clean-up the Rb output with an OCXO (the one from the Trimble or a 10811A I've around). But this depends on other things I must do... with more priority :) Regards, Javier ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
At 05:45 AM 1/29/2012, Javier Herrero wrote: 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 Can you do a test at +/- fullscale offset as well? This is a very exciting discovery. Nice work! -- newell N5TNL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
I'm now gathering the unit self-updating of DDS data, that will take somewhat long... so I will try later or tomorrow. Since we have seen that the DDS values are reported back in a response to a command, it is easy to do without the need to have anything hooked to the SPI bus :) Regards, Javier El 29/01/2012 19:37, Scott Newell escribió: At 05:45 AM 1/29/2012, Javier Herrero wrote: 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 Can you do a test at +/- fullscale offset as well? This is a very exciting discovery. Nice work! ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] CSD-510
I wonder if anyone in the group might have any technical info on a Leitch CSD-510 clock system driver I believe it was made for the broadcast ind. I have tried web searches but only find sellers of the unit. Don wa9ylp ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Hi If you try to do full scale, check the range of your VCXO first. The digital test is much easier if you already know where your VCXO stops tuning. Bob On Jan 29, 2012, at 1:45 PM, Javier Herrero jherr...@hvsistemas.es wrote: I'm now gathering the unit self-updating of DDS data, that will take somewhat long... so I will try later or tomorrow. Since we have seen that the DDS values are reported back in a response to a command, it is easy to do without the need to have anything hooked to the SPI bus :) Regards, Javier El 29/01/2012 19:37, Scott Newell escribió: At 05:45 AM 1/29/2012, Javier Herrero wrote: 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 Can you do a test at +/- fullscale offset as well? This is a very exciting discovery. Nice work! ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Hi A roughly 30 second update rate makes a lot of sense. That would keep the update steps buried in the short term stability noise. Good news on the serial update timing and it's stability. Sounds like you could do several updates a second. That's plenty fast enough. Bob On Jan 29, 2012, at 1:19 PM, Javier Herrero jherr...@hvsistemas.es wrote: El 29/01/2012 14:45, Bob Camp escribió: 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 Since I've all the things powered on the bench table, it is easy to measure: 21ms from the start of the serial message, to the end of the last DDS programming word. I've repeated several times, the time does not seem to have submitted to latencies, it is very constant. The automatic update rate of the DDS in the unit is somewhat around 28.5 seconds (I misread an inter-word delay of 671.5us as a 671.5 seconds interval). I'm trying to get a long capture from the logic analyzer to try to plot the DDS programming variations, but then I need to post-process it since the analyzer has no SPI decoding so I'm gathering the bit streams. My next intention is to replace the OCXO in one of my Thunderbolts with a Rb and use a small microcontroller to get the voltage correction from the Thunderbolt through the serial port and convert to a 5680A offset. I probably will use a Luminary since I've some small evaluation boards around, and I only have to add a MAX3232-class interface IC for the serial ports. Now... my question is to decide which of the two Thunderbolt will be converted to Franken-Thunderbolt. I've bee monitoring both from some time, feeding them from same GPS signal, and both looks quite the same (I was trying to see if one of them has a worse OCXO than the other. One is from the past group purchase, and the other has been purchased not long ago - but both are very similar, with same firmware and the Trimble OCXO, and monitored with Lady Heather they are really very similar). Next... clean-up the Rb output with an OCXO (the one from the Trimble or a 10811A I've around). But this depends on other things I must do... with more priority :) Regards, Javier ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Trimble firmware updates and GPS signal structure.
Whilst downloading some information from Trimble's support pages today I discovered, only two years late:-), that in January 2010 Trimble released firmware upgrades for the Acutime Gold, Mini-T, Resolution T, Thunderbolt E, and no doubt other GPS units too. Trimble states in each case. This firmware version was published to correct the signal tracking outage every 12.5 minutes due to the change in the GPS signal structure by the DoD. No firmware update seems to be available for the original Thunderbolt, nor for other earlier units, which probably isn't too surprising but I don't recall anyway ever noticing periodic dropouts of this nature when monitoring Thunderbolts. Does anybody have any experience of this ? Regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] FE-5680A command decoding speculation
Speculation... just for fun. Seeing Javier's great recent work on the 5680 DDS operation has me thinking more about two of the mystery commands. If the unit is applying a periodic correction to the DDS frequency beyond what the user requests via RS-232 commands, as a function of (for example) temperature, and/or a power supply voltage, it would need some calibration coefficient. Those correction factors would logically be a user-settable parameter. We know there is a 12-bit 4 channel A/D chip onboard, apparently monitoring temperature (and supply voltage?) and maybe that's not just a passive monitor function, but used to generate the correction factor. Now, looking at the response to Cmd 0x57 and 0x59 on my unit, I see a long string of bytes which look like sets of 2-byte pairs, the second byte of each pair differs by roughly the same number from the previous. Each unit has a different number of these pairs, and they are followed by all 0x00 bytes. Pure speculation here, but if the unit was keeping a log of the most recent commanded voltage or temperature coefficient correction factors, and this was done at regular intervals, it might look a lot like that. Another possibility is an automatically generated correction, if there is any known drift with time (?). Yet another possibility is a look-up table, for example, to take the measured temperature to find the right DDS offset correction factor. I might expect the lookup table to be a consistent size, though. In case of interest, below is the data I'm talking about, from my three units. Remember the first 4 reply bytes is a command header, and the last byte is a checksum. FE-5680A Unit Number 62388: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 30 40 00 4B 00 58 00 63 00 6E 00 7A 00 85 00 90 00 97 00 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A Cmd 0x59 0x56 byte reply: 59 56 00 0F 30 BF 00 A2 00 80 00 2F 00 00 00 EA FF 9E FF 7C FF 4A FF 39 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 FE-5680A Unit Number 66721: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 50 41 00 43 00 47 00 4A 00 4E 00 51 00 55 00 58 00 5C 00 5F 00 63 00 66 00 6A 00 6E 00 71 00 75 00 78 00 7B 00 7F 00 82 00 85 00 89 00 8C 00 90 00 93 00 97 00 9A 00 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A5 Cmd 0x59 0x56 byte reply: 59 56 00 0F 50 CB FF BC FF C6 FF B0 FF B5 FF A9 FF 8E FF 77 FF 9B FF B0 FF 8C FF CD FF E5 FF 00 00 81 FF B0 FF C1 FF D6 FF DD FF D2 FF D9 FF B7 FF D8 FF CB FF E4 FF DB FF F9 FF E1 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B7 FE-5680A Unit Number 72476: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 68 3F 00 42 00 46 00 4A 00 4D 00 51 00 55 00 58 00 5C 00 5F 00 63 00 66 00 6A 00 6D 00 71 00 74 00 78 00 7B 00 7F 00 82 00 86 00 89 00 8D 00 90 00 94 00 97 00 9B 00 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E6 Cmd 0x59 0x56 byte reply: 59 56 00 0F 68 FF FF 01 00 E3 FF CE FF D8 FF EA FF D2 FF F0 FF FE FF 16 00 0A 00 0D 00 F6 FF 00 00 EF FF FE FF DD FF D3 FF E2 FF F5 FF F2 FF F3 FF E5 FF EE FF B3 FF C4 FF DA FF A9 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4B --- John Beale n8juf ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-5680A command decoding speculation
Hi Unlike a GPSDO, a rubidium does not have a reference to construct a table against. If they are doing temperature correction, it would run on a factory loaded table. Bob On Jan 29, 2012, at 5:35 PM, John Beale be...@bealecorner.com wrote: Speculation... just for fun. Seeing Javier's great recent work on the 5680 DDS operation has me thinking more about two of the mystery commands. If the unit is applying a periodic correction to the DDS frequency beyond what the user requests via RS-232 commands, as a function of (for example) temperature, and/or a power supply voltage, it would need some calibration coefficient. Those correction factors would logically be a user-settable parameter. We know there is a 12-bit 4 channel A/D chip onboard, apparently monitoring temperature (and supply voltage?) and maybe that's not just a passive monitor function, but used to generate the correction factor. Now, looking at the response to Cmd 0x57 and 0x59 on my unit, I see a long string of bytes which look like sets of 2-byte pairs, the second byte of each pair differs by roughly the same number from the previous. Each unit has a different number of these pairs, and they are followed by all 0x00 bytes. Pure speculation here, but if the unit was keeping a log of the most recent commanded voltage or temperature coefficient correction factors, and this was done at regular intervals, it might look a lot like that. Another possibility is an automatically generated correction, if there is any known drift with time (?). Yet another possibility is a look-up table, for example, to take the measured temperature to find the right DDS offset correction factor. I might expect the lookup table to be a consistent size, though. In case of interest, below is the data I'm talking about, from my three units. Remember the first 4 reply bytes is a command header, and the last byte is a checksum. FE-5680A Unit Number 62388: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 30 40 00 4B 00 58 00 63 00 6E 00 7A 00 85 00 90 00 97 00 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A Cmd 0x59 0x56 byte reply: 59 56 00 0F 30 BF 00 A2 00 80 00 2F 00 00 00 EA FF 9E FF 7C FF 4A FF 39 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 FE-5680A Unit Number 66721: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 50 41 00 43 00 47 00 4A 00 4E 00 51 00 55 00 58 00 5C 00 5F 00 63 00 66 00 6A 00 6E 00 71 00 75 00 78 00 7B 00 7F 00 82 00 85 00 89 00 8C 00 90 00 93 00 97 00 9A 00 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A5 Cmd 0x59 0x56 byte reply: 59 56 00 0F 50 CB FF BC FF C6 FF B0 FF B5 FF A9 FF 8E FF 77 FF 9B FF B0 FF 8C FF CD FF E5 FF 00 00 81 FF B0 FF C1 FF D6 FF DD FF D2 FF D9 FF B7 FF D8 FF CB FF E4 FF DB FF F9 FF E1 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B7 FE-5680A Unit Number 72476: -- Cmd 0x57 0x56 byte reply: 57 56 00 01 68 3F 00 42 00 46 00 4A 00 4D 00 51 00 55 00 58 00 5C 00 5F 00 63 00 66 00 6A 00 6D 00 71 00 74 00 78 00 7B 00 7F 00 82 00 86 00 89 00 8D 00 90 00 94 00 97 00 9B 00 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E6 Cmd 0x59 0x56 byte reply: 59 56 00 0F 68 FF FF 01 00 E3 FF CE FF D8 FF EA FF D2 FF F0 FF FE FF 16 00 0A 00 0D 00 F6 FF 00 00 EF FF FE FF DD FF D3 FF E2 FF F5 FF F2 FF F3 FF E5 FF EE FF B3 FF C4 FF DA FF A9 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4B --- John Beale n8juf ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
On Sat, Jan 28, 2012 at 10:50 PM, Ray Xu rayxu...@gmail.com wrote: Also, what is the advantage of using a OCXO instead of a VCXO in terms of short-term accuracy? If the PLL time constant is only a few seconds, then a crystal shouldn't deviate in frequency by too much within a few seconds, assuming I'm using a crystal bought from a well-known manufacturer...or could it? I am inclined towards using oscillators that do not require any significant warm up time... GPS is only a good reference if you average it over a long time period. (1000 to 10,000 seconds) There is more short term jitter in the GPS then in a decent crystal oscillator. So a very short time constant does you no good. Why use an OCXO? Because of the required long time constant. You need to average GPS for such a length of time (20 minutes to hours) that the ambient temperature will change during the averaging time. Of course you could take care that the temperature does not change but that is what an oven does.You can buy a pretty good OCXO for $20 or $25 How long? That depends on the required accuracy. You want 1Hz at 10GHz. That is 1E-10. Not super hard but no way will you have that 10 minutes after you apply power. If you need a portable standard look at those $40 rubidium nuts that are on eBay.It the 1E-10 level, after you calibrate it, if would stay on-frequency for days and not require much warm up. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Trimble firmware updates and GPS signal structure.
In a message dated 29/01/2012 21:54:02 GMT Standard Time, gandal...@aol.com writes: No firmware update seems to be available for the original Thunderbolt, nor for other earlier units, which probably isn't too surprising but I don't recall anyway ever noticing periodic dropouts of this nature when monitoring Thunderbolts. -- To answer, partially at least, my own question, I found a further reference to the Mini-T firmware upgrade in the document linked to here. _http://www.support.seasonde.com/Technician_Info/GPS_Firmware/GPSModule_FWup grade.pdf_ (http://www.support.seasonde.com/Technician_Info/GPS_Firmware/GPSModule_FWupgrade.pdf) What's mainly interesting about this file is that it comments that the problem only affects their new GPS boards, which contain Mini-Ts, but doesn't affect the older GPS boards and that these don't require an upgrade. They provide a photo of each board, and their older board clearly has an unboxed Thunderbolt piggy-backed onto it, so I have to assume, as far as the Thunderbolt's concerned, that this was never an issue. I'd still be interested in hearing if anybody has successfully upgraded an Acutime gold and/or Mini-T. The possibility of bricking a couple of Mini-Ts isn't something I wish to contemplate, even if they aren't anywhere near as good as the Thunderbolt, but if it turned out Trimble addressed the frequency jumps at the same time that would make it well worth the risk. regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Lucent RFTGm-II-XO and RFTGm-II-Rb pin outs and interconnect
I seem to recall seeing this (or perhaps for the 'non-II' units) in the past but can't seem to find it. Can anyone point me to the pin outs and interconnects for these units? Thanks in advance. Joe ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
On Sun, Jan 29, 2012 at 10:19 AM, Javier Herrero jherr...@hvsistemas.es wrote: El 29/01/2012 14:45, Bob Camp escribió: My next intention is to replace the OCXO in one of my Thunderbolts with a Rb and use a small microcontroller to get the voltage correction from the Thunderbolt through the serial port and convert to a 5680A offset. I probably will use a Luminary since I've some small evaluation boards around, and I only have to add a MAX3232-class interface IC for the serial ports. My plan is simpler. I'll compare the phase of the Rb and t-bolt and send rs-232 commans to the Rb to keep the difference as small as possible. This will run on an Arduino. I'm also thinking of porting over much of the Lady Heather t-bolt monitoring stuff to the Arduino. One thing you can do with a uP based controller is look at the t-bolt's saw tooth error correction and remove a few nS of error. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
Hi Chris Thanks for your helpful input. What do you mean by average? Do you mean that the GPS and PLL must be kept on for 20 minutes to hours, or did you mean that the PLL loop filter must have a time constant of 20 minutes to several hours? To me, the latter seems really unpractical for analog filters...Yet I have seen many of them built using analog filters. Especially JAmes Miller's http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm and his FAQ says that the time to wait is perhaps 15 minutes or so to be usable. The previous GPSDO that James built has its schematic; the filter he used doesn't look like they're anywhere close to a time constant of 20 minutes. I may consider the Rb standard, but I'm more inclined on using GPS since I actually get to build some stuff on my own :-) Thanks again Ray Xu On Sun, Jan 29, 2012 at 6:52 PM, Chris Albertson albertson.ch...@gmail.comwrote: On Sat, Jan 28, 2012 at 10:50 PM, Ray Xu rayxu...@gmail.com wrote: Also, what is the advantage of using a OCXO instead of a VCXO in terms of short-term accuracy? If the PLL time constant is only a few seconds, then a crystal shouldn't deviate in frequency by too much within a few seconds, assuming I'm using a crystal bought from a well-known manufacturer...or could it? I am inclined towards using oscillators that do not require any significant warm up time... GPS is only a good reference if you average it over a long time period. (1000 to 10,000 seconds) There is more short term jitter in the GPS then in a decent crystal oscillator. So a very short time constant does you no good. Why use an OCXO? Because of the required long time constant. You need to average GPS for such a length of time (20 minutes to hours) that the ambient temperature will change during the averaging time. Of course you could take care that the temperature does not change but that is what an oven does.You can buy a pretty good OCXO for $20 or $25 How long? That depends on the required accuracy. You want 1Hz at 10GHz. That is 1E-10. Not super hard but no way will you have that 10 minutes after you apply power. If you need a portable standard look at those $40 rubidium nuts that are on eBay.It the 1E-10 level, after you calibrate it, if would stay on-frequency for days and not require much warm up. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- __ 73, Ray Xu KF5LJO ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
Hi Erno Thanks for your suggestion; while it is convenient to have everything already planned out, I'm inclined on DIY'ing as much as I can :-) Ray Xu On Sun, Jan 29, 2012 at 1:01 AM, Erno Peres erniepe...@aol.com wrote: Hi Ray, please find on this link the info what you are looking for. http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm Rgds Ernie. -Original Message- From: Ray Xu rayxu...@gmail.com To: time-nuts time-nuts@febo.com Sent: Sun, Jan 29, 2012 7:51 am Subject: [time-nuts] Building a GPSDO trouble using Jupiter-T Hi guys I'm planning to build a GPSDO to use as a frequency ref for my GHz ventures. I've done research in what other people have built - but I have no xperience working with long-term precision/stability products (nor do I ave the equipment to do so -- I think). I'm using the Jupiter T (the one with the 10-pin header) GPS and its 10KHz utput in an analog PLL that controls a 10MHz VCXO. It would be ideal for e that if I were to multiply the 10MHz output up to 10GHz, I would get bout a few Hertz or so of inaccuracy. It would also be ideal if I can ave a PLL lock time of a few minutes while maintaining accuracy. However, right now as I am trying to design my project, I can't find enough nformation on the web regarding the VCXO's (or the PLL oscillator, in this ase) short term accuracy effect on output frequency. I know that its hort term accuracy depends on the response time of the PLL, which also epends on the amount of jitter from the Jupiter-T's 10KHz output... I now that the longer the time constant for the PLL, the better accuracy, ut I do not want to wait, literally, hours for it to lock... Also, what is the advantage of using a OCXO instead of a VCXO in terms of hort-term accuracy? If the PLL time constant is only a few seconds, then crystal shouldn't deviate in frequency by too much within a few seconds, ssuming I'm using a crystal bought from a well-known manufacturer...or ould it? I am inclined towards using oscillators that do not require any ignificant warm up time... For those who have experience using the Jupiter T GPS: have bought this ttp:// www.ebay.com/itm/Navman-jupiter-T-Tu60-GPS-Kit-1pps-10khz-GPS-Module-/260790984470but could not get it to communicate via serial. So far, I do not have n ntenna available and so the antenna port is just left disconnected. When turn it on, there is a 1pps and 10KHz signal and the TX line is at logic igh. However, I cannot get it to communicate to anything else, even a umb terminal. It does not respond to when I send a message ID to it. Because of computer difficulties, I am using the PicKit 2's UART tool). s my device a dud or am I doing something wrong? Many inputs is highly appreciated. Thanks -- _ 3, Ray Xu F5LJO __ ime-nuts mailing list -- time-nuts@febo.com o unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts nd follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- __ 73, Ray Xu KF5LJO ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
Don't confuse the PLL loop time constant with the time constant of the analog or digital filter. They are not the same. Bruce Ray Xu wrote: Hi Chris Thanks for your helpful input. What do you mean by average? Do you mean that the GPS and PLL must be kept on for 20 minutes to hours, or did you mean that the PLL loop filter must have a time constant of 20 minutes to several hours? To me, the latter seems really unpractical for analog filters...Yet I have seen many of them built using analog filters. Especially JAmes Miller's http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm and his FAQ says that the time to wait is perhaps 15 minutes or so to be usable. The previous GPSDO that James built has its schematic; the filter he used doesn't look like they're anywhere close to a time constant of 20 minutes. I may consider the Rb standard, but I'm more inclined on using GPS since I actually get to build some stuff on my own :-) Thanks again Ray Xu On Sun, Jan 29, 2012 at 6:52 PM, Chris Albertson albertson.ch...@gmail.comwrote: On Sat, Jan 28, 2012 at 10:50 PM, Ray Xurayxu...@gmail.com wrote: Also, what is the advantage of using a OCXO instead of a VCXO in terms of short-term accuracy? If the PLL time constant is only a few seconds, then a crystal shouldn't deviate in frequency by too much within a few seconds, assuming I'm using a crystal bought from a well-known manufacturer...or could it? I am inclined towards using oscillators that do not require any significant warm up time... GPS is only a good reference if you average it over a long time period. (1000 to 10,000 seconds) There is more short term jitter in the GPS then in a decent crystal oscillator. So a very short time constant does you no good. Why use an OCXO? Because of the required long time constant. You need to average GPS for such a length of time (20 minutes to hours) that the ambient temperature will change during the averaging time. Of course you could take care that the temperature does not change but that is what an oven does.You can buy a pretty good OCXO for $20 or $25 How long? That depends on the required accuracy. You want 1Hz at 10GHz. That is 1E-10. Not super hard but no way will you have that 10 minutes after you apply power. If you need a portable standard look at those $40 rubidium nuts that are on eBay.It the 1E-10 level, after you calibrate it, if would stay on-frequency for days and not require much warm up. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] FE-5680A decoded - another piece of the puzzle
Hello Nuts, I've been trying to get the analog EFC to work on the FE-5650A (a very close cousin of the FE-5680A). On these oscillators it is normally on pin-8 of the DB-9 (Option 12 and 30). As one of the serial lines is on this pin, I traced the jumper that is placed for the EFC option(s). However, changing the voltage on the pin does not seem to move the frequency (or at least not very much if it does). Anybody know the nominal EFC sensitivity of the 5680? On tracing things further, I have found that this input goes into the (4 channel) A/D associated with the microproccesor. Changing the voltage gives a value in message 5A that also changes a corresponding amount. The EFC bytes are bytes 5 6 of the 5A message, first byte is low second byte is high. Appears to be 12-bit value (0FFF max). The question is - how do you enable the EFC? Maybe it is a bit that has to be set in one of the other messages. (But then how does the uP communicate the EFC value to the physics package?) It (more likely) may be that I have not found the true C-field control circuitry yet and the A/D is just a monitor. I recall someone implementing C-field control on a FE-5680A with the pot disabled, but cannot find it now. If someone can point me to that post I sure would appreciate it. Thanks in advance. Regards, Skip Withrow ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
What do you mean by average? Do you mean that the GPS and PLL must be kept on for 20 minutes to hours, or did you mean that the PLL loop filter must have a time constant of 20 minutes to several hours? You have to compare the characteristics of the oscillator with the characteristics of your GPS receiver. If your local oscillator is very stable, then you want to average over long times (hours, days). If your local oscillator is a good thermometer and you have a very good GPS receiver, then you want a shorter time constant (minutes) so you can track temperature changes. Do you know about hanging bridges? If not, please read Timing for VLBI by Tom Clark and Rick Hambly. It's got some wonderful graphs. Once you understand those, this discussion will get much more interesting. http://gpstime.com/files/tow-time2009.pdf -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Building a GPSDO trouble using Jupiter-T
The sawtooth error in the PPS output and how they were able to correct it externally was interesting. I have seen that kind of problem before in DDS and other applications. I wonder what other GPS receivers provide either PPS outputs without sawtooth noise or a correction message. On Sun, 29 Jan 2012 20:40:52 -0800, Hal Murray hmur...@megapathdsl.net wrote: What do you mean by average? Do you mean that the GPS and PLL must be kept on for 20 minutes to hours, or did you mean that the PLL loop filter must have a time constant of 20 minutes to several hours? You have to compare the characteristics of the oscillator with the characteristics of your GPS receiver. If your local oscillator is very stable, then you want to average over long times (hours, days). If your local oscillator is a good thermometer and you have a very good GPS receiver, then you want a shorter time constant (minutes) so you can track temperature changes. Do you know about hanging bridges? If not, please read Timing for VLBI by Tom Clark and Rick Hambly. It's got some wonderful graphs. Once you understand those, this discussion will get much more interesting. http://gpstime.com/files/tow-time2009.pdf ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Lucent OMR Hookup Info (FE-5650A)
Hi Skip: I just got the Lucent OMR module with a FE-5650A. Do you know if there's hook-up info for the OMR? http://www.prc68.com/I/FEIFS.shtml#FE5650A Have Fun, Brooke Clarke http://www.PRC68.com http://www.end2partygovernment.com/Brooke4Congress.html Skip Withrow wrote: Hello Nuts, I've been trying to get the analog EFC to work on the FE-5650A (a very close cousin of the FE-5680A). On these oscillators it is normally on pin-8 of the DB-9 (Option 12 and 30). As one of the serial lines is on this pin, I traced the jumper that is placed for the EFC option(s). However, changing the voltage on the pin does not seem to move the frequency (or at least not very much if it does). Anybody know the nominal EFC sensitivity of the 5680? On tracing things further, I have found that this input goes into the (4 channel) A/D associated with the microproccesor. Changing the voltage gives a value in message 5A that also changes a corresponding amount. The EFC bytes are bytes 5 6 of the 5A message, first byte is low second byte is high. Appears to be 12-bit value (0FFF max). The question is - how do you enable the EFC? Maybe it is a bit that has to be set in one of the other messages. (But then how does the uP communicate the EFC value to the physics package?) It (more likely) may be that I have not found the true C-field control circuitry yet and the A/D is just a monitor. I recall someone implementing C-field control on a FE-5680A with the pot disabled, but cannot find it now. If someone can point me to that post I sure would appreciate it. Thanks in advance. Regards, Skip Withrow ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
Hello, Also I expect that the range would be somewhat limited by the unit software, since the control word is 32-bit, same as the DDS program word with, and I don't think that the little thing would enable to program the DDS from zero to 32-bit. In any case, my idea was first to only monitor the DDS word (at serial port) and serial port offset message limits, and also to test in that way the lock range of the 5680A - this can be a bit tedious since when I programmed a 10Hz offset, the unit unlocked ant took several seconds to lock again. Regards, Javier El 29/01/2012 21:41, Bob Camp escribió: Hi If you try to do full scale, check the range of your VCXO first. The digital test is much easier if you already know where your VCXO stops tuning. Bob On Jan 29, 2012, at 1:45 PM, Javier Herrerojherr...@hvsistemas.es wrote: I'm now gathering the unit self-updating of DDS data, that will take somewhat long... so I will try later or tomorrow. Since we have seen that the DDS values are reported back in a response to a command, it is easy to do without the need to have anything hooked to the SPI bus :) Regards, Javier El 29/01/2012 19:37, Scott Newell escribió: At 05:45 AM 1/29/2012, Javier Herrero wrote: 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 Can you do a test at +/- fullscale offset as well? This is a very exciting discovery. Nice work! ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Javier Herrero Chief Technology Officer EMAIL: jherr...@hvsistemas.com HV Sistemas S.L. PHONE: +34 949 336 806 Los Charcones, 17 FAX: +34 949 336 792 19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FE-.5680A trimming resolution
El 30/01/2012 03:19, Chris Albertson escribió: On Sun, Jan 29, 2012 at 10:19 AM, Javier Herrerojherr...@hvsistemas.es wrote: El 29/01/2012 14:45, Bob Camp escribió: My next intention is to replace the OCXO in one of my Thunderbolts with a Rb and use a small microcontroller to get the voltage correction from the Thunderbolt through the serial port and convert to a 5680A offset. I probably will use a Luminary since I've some small evaluation boards around, and I only have to add a MAX3232-class interface IC for the serial ports. My plan is simpler. I'll compare the phase of the Rb and t-bolt and send rs-232 commans to the Rb to keep the difference as small as possible. This will run on an Arduino. I'm also thinking of porting over much of the Lady Heather t-bolt monitoring stuff to the Arduino. My idea is to let the thunderbolt do all the things, replacing the oscillator, but letting it do all the comparisons, time constants, etc. since it also enables to set oscillator slope, time constant, and also do all the monitoring. So the uP, for now, will be simply a protocol converter, sniffing the DAC value from the Thundervolt and converting it to an offset to the FE-5680A, using a EKK-LM3S9B96 I've lying around. I've more ambitious plans involvign a more capable embedded processor... (too many plans for so limited free time to play with things :) ). Regards, Javier ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
