[time-nuts] 3 corner hat for phase noise
Hello, Does anyone have an EXCEL spreadsheet that calculates the individual phase noise of 3 oscillators when they are compared against each other, e.g A vs B, A vs C, B vs C. I.e the 3 corner hat technique. I do have a Timepod and I thought Timelab could do that, have haven't found how to do that. Regards Martyn ___ 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] SRS PRS10 repair
Hi, You have too many 1s in your startup string compared to the expected PRS_10\r. If the MCU clock is not 10Mhz then the integrated UART rates will be off, which should produce framing errors, but do UARTs still detect and systems report these nowadays, or just pass along garbled data? Otherwise, garbled data is most often a result of inadequate pin contact, if the connectors are not seated properly, or the pins or sockets are loose in their shells. Age and rough treatment can have that effect. Internal hardware jumpers allow these pins to be configured as analog outputs to monitor the lamp intensity and varactor voltage for complete compatibility with the FRS. Have you checked the jumpers in the manual Configuration Notes: Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data. Many system parameters (including the lamp intensity) may be monitored via the RS-232 interface. The function of this pin may be changed to an analog monitor for the lamp intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348) on the microcontroller PCB. On 2015-08-24 22:40, Brian M wrote: I tried through the weekend, double and triple checking wiring and setup. I've tried the following methods of getting serial comms working: PRS10 - Arduino Uno (with processor bypassed) - USB Host PRS10 - Level Shifter - BBB UART PRS10 - MAX232 - USB Serial adapter Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy I guess the good news is that this output appears consistent with each power cycle of the device. And I'm getting the same results through all the hookup methods I've tried. My minicom settings are for software flow control at 9600 8N1 - from what the manual states, this should be the right settings. I've tried screen as well - and get the same text. I went crazy trying several other rates and setting combinations. No luck. Maybe I've missed something obvious. I agree that getting comms going to the MCU are going to be an important step. How do people address this type of problem? Scope the serial and try to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there further steps people try after that? If nothing else I think there's some interesting stuff to learn here. I also wouldn't mind tearing out the electronics, determining if the lamp is good, and attempt to build from there. I don't know the datecode for the unit, the PCB is marked with a datecode suggesting 2003? I don't have the full case. I'm trying to assess what are reasonable next steps. How do I determine if the MCU is healthy? If the MCU is fried, how do I determine if I just need to squeeze a new MCU board in there? Thanks! I appreciate the input so far! - Brian PS - after looking again at the signal on the scope, it does seem like it is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like what I saw on the main connector. On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.c...@sfr.fr wrote: Le 22 août 2015 à 03:40, Bob Camp kb...@n1k.org a écrit : Hi On any microprocessor based gizmo, getting the micro running (again) is generally priority number one. It sets everything up and gives you the diagnostic info you need to go further. Garbled serial is better than none at all. It suggests something short of a total MCU death spiral … Bob On Aug 21, 2015, at 7:26 PM, Brian M brayn...@gmail.com wrote: Dear list - I have come into possession of a for parts prs 10. I'd like to try to repair this device. What I've noticed so far. Serial is garbled. (Even at varying baud rates). You don’t say how you are connecting to the Rb. The manual states: RS-232 data is sent to the host on pin 4, received from the host on pin 7. The baud rate is fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR or CTS controls are used; rather, the XON/XOFF protocol has been implemented. The transmit drive level is 0 and 5 V, not the +/-12 V normally associated with RS-232. These levels are compatible with most RS-232 line receivers, but does not require their use (a TTL inverter may be used instead), hence simplifies the interface when used inside an instrument at the sacrifice of degraded noise immunity over long lines. So make sure that you adhere to that. Lamp isn't lit. What’s the date code. Early versions may be reaching EOL, though 20yrs id quoted. Doesn't look great. I'd like to know if anybody else has wandered down this path. What are common failure modes? Anything match up with what I describe? Voltages to check would be helpful. The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect the crystal is fine. Thanks in advance. Happy hacking! - Brian ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[time-nuts] measuring os latency for pps
Hi, Not sure if it is interesting for you guys but I wrote a simple program for e.g. Linux (or any other system with the pps api implemented) that listens on a pps source waiting for a pulse and then toggles a gpio pin. That way you can measure the latency introduced by the the kernel when listening from userspace. Note that there's a little extra latency due to the gpio-pin handling. It is on github: https://github.com/flok99/pps2gpio Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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] SRS PRS10 repair
brayn...@gmail.com said: Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy One opportunity for confusion is an extra or missing inverter. Does the start bit have the correct polarity? I would put a scope on it and decode a few characters by hand. Or compare it to what you see when you send the same string. -- These are my opinions. 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] SRS PRS10 repair
Looking at the data expected and received on the wire, there could be an extra inversion after some bits delay until an inverted 1 is detected as a start bit: 1101 0011 00110001 0101 01010011 01010010 0101 .01_SRP - what you should see on your scope 0001 01100111 0101 01010110 00101011 0001 01110111 ygPV+yw - what you probably see on your scope You should be able to connect your output data directly into any current PC serial port as they should both work with 0-5V nowadays. On 2015-08-25 11:35, Brian M wrote: The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence. Thanks for the input on this. I'll reply back after I've had more time to hack at this. On Tuesday, August 25, 2015, Brian Inglis brian.ing...@systematicsw.ab.ca mailto:brian.ing...@systematicsw.ab.ca wrote: You have too many 1s in your startup string compared to the expected PRS_10\r. If the MCU clock is not 10Mhz then the integrated UART rates will be off, which should produce framing errors, but do UARTs still detect and systems report these nowadays, or just pass along garbled data? Otherwise, garbled data is most often a result of inadequate pin contact, if the connectors are not seated properly, or the pins or sockets are loose in their shells. Age and rough treatment can have that effect. Internal hardware jumpers allow these pins to be configured as analog outputs to monitor the lamp intensity and varactor voltage for complete compatibility with the FRS. Have you checked the jumpers in the manual Configuration Notes: Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data. Many system parameters (including the lamp intensity) may be monitored via the RS-232 interface. The function of this pin may be changed to an analog monitor for the lamp intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348) on the microcontroller PCB. On 2015-08-24 22:40, Brian M wrote: I tried through the weekend, double and triple checking wiring and setup. I've tried the following methods of getting serial comms working: PRS10 - Arduino Uno (with processor bypassed) - USB Host PRS10 - Level Shifter - BBB UART PRS10 - MAX232 - USB Serial adapter Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy I guess the good news is that this output appears consistent with each power cycle of the device. And I'm getting the same results through all the hookup methods I've tried. My minicom settings are for software flow control at 9600 8N1 - from what the manual states, this should be the right settings. I've tried screen as well - and get the same text. I went crazy trying several other rates and setting combinations. No luck. Maybe I've missed something obvious. I agree that getting comms going to the MCU are going to be an important step. How do people address this type of problem? Scope the serial and try to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there further steps people try after that? If nothing else I think there's some interesting stuff to learn here. I also wouldn't mind tearing out the electronics, determining if the lamp is good, and attempt to build from there. I don't know the datecode for the unit, the PCB is marked with a datecode suggesting 2003? I don't have the full case. I'm trying to assess what are reasonable next steps. How do I determine if the MCU is healthy? If the MCU is fried, how do I determine if I just need to squeeze a new MCU board in there? Thanks! I appreciate the input so far! - Brian PS - after looking again at the signal on the scope, it does seem like it is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like what I saw on the main connector. On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.c...@sfr.fr wrote: Le 22 août 2015 à 03:40, Bob Camp kb...@n1k.org a écrit : Hi On any microprocessor based gizmo, getting the micro running (again) is generally priority number one. It sets everything up and gives you the diagnostic info you need to go further. Garbled serial is better than none at all. It suggests something short of a total MCU death spiral … Bob On Aug 21, 2015, at 7:26 PM, Brian M brayn...@gmail.com
Re: [time-nuts] SRS PRS10 repair
Hang on a minute, polarity does not switch all of a sudden. The standard RS-232 interface chips include an inverter. The normal output from serial pins on microprocessors or PCI/USB serial chips expects that inversion. For short runs where you are designing both ends, it's common to skip the RS-232 drivers. So if you are trying to talk to something like a GPSDO board without the typical 9 pin serial connector, there is a reasonable chance you may need to add an inverter. (or maybe a real RS-232 interface chip) It's also possible to cheat on the RS-232 interface ship. A TTL/CMOS driver will work with most RS-232 receivers and a resistor with maybe a pair of diodes will protect a CMOS receiver from RS-232 levels. If you are doing that, you need an inverter in there someplace. With a microprocessor, the inverter is often available (for free) in the pad driver. -- These are my opinions. 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] measuring os latency for pps
What are you measuring? Seriously. What is it you need to know, is it? 1) The time between the raising edge of the PPS and when the OS samples the time 2) The time it takes between the PPS edge and when a user land process is notified. There are other things you can measure but if you want to see #1 above you can't use a TIC. And you can't have the user space process set s GPIO bit. The reason is that the PPS interrupt handler dramatically shortens the time removing ALL of the kernel process or latency. Look at the interrupt code. The clock is sampled there. The edge triggers the interrupt then while inside the handler the internal clock is sampled and stored and a flag is set to indicate the PPS was received. Som tie MUCH later the flag is checked and the user-land process is told the PPS has detected The delay does not matter because the clock was sampled with very low latency even if the user process was not notified right away. I think the details are platform dependent, hardware on a PC is not the same as a Raspberry Pi. So you need to look at the source. On Tue, Aug 25, 2015 at 10:53 AM, Andrew Symington andrew.c.syming...@gmail.com wrote: Hi Folkert If you have a board with a hardware timer that supports load/match/compare then you can schedule an external interrupt to be generated at a predetermined point in the hardware count. Thus, if you know the transform between your disciplined clock and the hardware counter of the timer that drives it, then you should be able to do this. I have spent some time working with the (pretty neat) timers on board a beaglebone black, and I've written some code to setup input capture and compare on up to 4 timers: https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master Cheers Andrew On Tue, Aug 25, 2015 at 8:24 AM, folkert folk...@vanheusden.com wrote: Hi, Not sure if it is interesting for you guys but I wrote a simple program for e.g. Linux (or any other system with the pps api implemented) that listens on a pps source waiting for a pulse and then toggles a gpio pin. That way you can measure the latency introduced by the the kernel when listening from userspace. Note that there's a little extra latency due to the gpio-pin handling. It is on github: https://github.com/flok99/pps2gpio Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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. ___ 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. -- 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] SRS PRS10 repair
Hi - So I took the time tonight to poke at things with the scope. Hopefully it will be of interest. First off, I probed the MCU (MC68HC11) TX line directly. And, it looks like I misstated in my last mail. The MCU itself is 5V TX idle TTL Serial. On the unit's output, it is inverted and 0V idle. Not sure why that's the case... That said, I have lashed up some simple NPN inverters which are also level-shifting to a BBB UART. And with that I've got serial comms established. I get the power-on message and response from ID ? is PRS10_3.24_SN_[] Thanks again to all for their input. Always more to learn =) - Brian On Tue, Aug 25, 2015 at 7:50 PM Hal Murray hmur...@megapathdsl.net wrote: Hang on a minute, polarity does not switch all of a sudden. The standard RS-232 interface chips include an inverter. The normal output from serial pins on microprocessors or PCI/USB serial chips expects that inversion. For short runs where you are designing both ends, it's common to skip the RS-232 drivers. So if you are trying to talk to something like a GPSDO board without the typical 9 pin serial connector, there is a reasonable chance you may need to add an inverter. (or maybe a real RS-232 interface chip) It's also possible to cheat on the RS-232 interface ship. A TTL/CMOS driver will work with most RS-232 receivers and a resistor with maybe a pair of diodes will protect a CMOS receiver from RS-232 levels. If you are doing that, you need an inverter in there someplace. With a microprocessor, the inverter is often available (for free) in the pad driver. -- These are my opinions. 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. ___ 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] SRS PRS10 repair
I tried through the weekend, double and triple checking wiring and setup. I've tried the following methods of getting serial comms working: PRS10 - Arduino Uno (with processor bypassed) - USB Host PRS10 - Level Shifter - BBB UART PRS10 - MAX232 - USB Serial adapter Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy I guess the good news is that this output appears consistent with each power cycle of the device. And I'm getting the same results through all the hookup methods I've tried. My minicom settings are for software flow control at 9600 8N1 - from what the manual states, this should be the right settings. I've tried screen as well - and get the same text. I went crazy trying several other rates and setting combinations. No luck. Maybe I've missed something obvious. I agree that getting comms going to the MCU are going to be an important step. How do people address this type of problem? Scope the serial and try to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there further steps people try after that? If nothing else I think there's some interesting stuff to learn here. I also wouldn't mind tearing out the electronics, determining if the lamp is good, and attempt to build from there. I don't know the datecode for the unit, the PCB is marked with a datecode suggesting 2003? I don't have the full case. I'm trying to assess what are reasonable next steps. How do I determine if the MCU is healthy? If the MCU is fried, how do I determine if I just need to squeeze a new MCU board in there? Thanks! I appreciate the input so far! - Brian PS - after looking again at the signal on the scope, it does seem like it is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like what I saw on the main connector. On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.c...@sfr.fr wrote: Le 22 août 2015 à 03:40, Bob Camp kb...@n1k.org a écrit : Hi On any microprocessor based gizmo, getting the micro running (again) is generally priority number one. It sets everything up and gives you the diagnostic info you need to go further. Garbled serial is better than none at all. It suggests something short of a total MCU death spiral … Bob On Aug 21, 2015, at 7:26 PM, Brian M brayn...@gmail.com wrote: Dear list - I have come into possession of a for parts prs 10. I'd like to try to repair this device. What I've noticed so far. Serial is garbled. (Even at varying baud rates). You don’t say how you are connecting to the Rb. The manual states: RS-232 data is sent to the host on pin 4, received from the host on pin 7. The baud rate is fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR or CTS controls are used; rather, the XON/XOFF protocol has been implemented. The transmit drive level is 0 and 5 V, not the +/-12 V normally associated with RS-232. These levels are compatible with most RS-232 line receivers, but does not require their use (a TTL inverter may be used instead), hence simplifies the interface when used inside an instrument at the sacrifice of degraded noise immunity over long lines. So make sure that you adhere to that. Lamp isn't lit. What’s the date code. Early versions may be reaching EOL, though 20yrs id quoted. Doesn't look great. I'd like to know if anybody else has wandered down this path. What are common failure modes? Anything match up with what I describe? Voltages to check would be helpful. The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect the crystal is fine. Thanks in advance. Happy hacking! - Brian ___ 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. Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité. Benjimin Franklin ___ 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] Vanguard Ultra precision Golden Oscillator
Real time nuts use Comet Cleanser to raise their xtal frequency and a graphite pencil to lower it. Only crystal cretins would use toothpaste ;-) All my FT-243's are more acc'rit than those new-fangled silly slezium and rubitinium oscillators and masery thingamabobs. Geeze, them youngin's these days think a few hundred nanoseconds either way matters. ___ 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] SRS PRS10 repair
The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence. Thanks for the input on this. I'll reply back after I've had more time to hack at this. - Brian On Tuesday, August 25, 2015, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: Hi, You have too many 1s in your startup string compared to the expected PRS_10\r. If the MCU clock is not 10Mhz then the integrated UART rates will be off, which should produce framing errors, but do UARTs still detect and systems report these nowadays, or just pass along garbled data? Otherwise, garbled data is most often a result of inadequate pin contact, if the connectors are not seated properly, or the pins or sockets are loose in their shells. Age and rough treatment can have that effect. Internal hardware jumpers allow these pins to be configured as analog outputs to monitor the lamp intensity and varactor voltage for complete compatibility with the FRS. Have you checked the jumpers in the manual Configuration Notes: Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data. Many system parameters (including the lamp intensity) may be monitored via the RS-232 interface. The function of this pin may be changed to an analog monitor for the lamp intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348) on the microcontroller PCB. On 2015-08-24 22:40, Brian M wrote: I tried through the weekend, double and triple checking wiring and setup. I've tried the following methods of getting serial comms working: PRS10 - Arduino Uno (with processor bypassed) - USB Host PRS10 - Level Shifter - BBB UART PRS10 - MAX232 - USB Serial adapter Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy I guess the good news is that this output appears consistent with each power cycle of the device. And I'm getting the same results through all the hookup methods I've tried. My minicom settings are for software flow control at 9600 8N1 - from what the manual states, this should be the right settings. I've tried screen as well - and get the same text. I went crazy trying several other rates and setting combinations. No luck. Maybe I've missed something obvious. I agree that getting comms going to the MCU are going to be an important step. How do people address this type of problem? Scope the serial and try to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there further steps people try after that? If nothing else I think there's some interesting stuff to learn here. I also wouldn't mind tearing out the electronics, determining if the lamp is good, and attempt to build from there. I don't know the datecode for the unit, the PCB is marked with a datecode suggesting 2003? I don't have the full case. I'm trying to assess what are reasonable next steps. How do I determine if the MCU is healthy? If the MCU is fried, how do I determine if I just need to squeeze a new MCU board in there? Thanks! I appreciate the input so far! - Brian PS - after looking again at the signal on the scope, it does seem like it is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like what I saw on the main connector. On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.c...@sfr.fr wrote: Le 22 août 2015 à 03:40, Bob Camp kb...@n1k.org a écrit : Hi On any microprocessor based gizmo, getting the micro running (again) is generally priority number one. It sets everything up and gives you the diagnostic info you need to go further. Garbled serial is better than none at all. It suggests something short of a total MCU death spiral … Bob On Aug 21, 2015, at 7:26 PM, Brian M brayn...@gmail.com wrote: Dear list - I have come into possession of a for parts prs 10. I'd like to try to repair this device. What I've noticed so far. Serial is garbled. (Even at varying baud rates). You don’t say how you are connecting to the Rb. The manual states: RS-232 data is sent to the host on pin 4, received from the host on pin 7. The baud rate is fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR or CTS controls are used; rather, the XON/XOFF protocol has been implemented. The transmit drive level is 0 and 5 V, not the +/-12 V normally associated with RS-232. These levels are compatible with most RS-232 line receivers, but does not require their use (a TTL inverter may be used instead), hence simplifies the interface when used inside an instrument at the sacrifice of degraded noise immunity over long lines. So make sure that you adhere to that. Lamp isn't lit. What’s the date code. Early versions may be reaching EOL, though 20yrs id quoted. Doesn't look great.
Re: [time-nuts] 3 corner hat for phase noise
This is from 3hat.c -- C code, but you get the idea: A[i] = sqrt( (0 + SQUARE(AB[i]) - SQUARE(BC[i]) + SQUARE(AC[i])) / 2.0 ); B[i] = sqrt( (0 + SQUARE(AB[i]) + SQUARE(BC[i]) - SQUARE(AC[i])) / 2.0 ); C[i] = sqrt( (0 - SQUARE(AB[i]) + SQUARE(BC[i]) + SQUARE(AC[i])) / 2.0 ); And watch out for negative square roots. /tvb - Original Message - From: Martyn Smith mar...@ptsyst.com To: time-nuts@febo.com Sent: Tuesday, August 25, 2015 9:36 AM Subject: [time-nuts] 3 corner hat for phase noise Hello, Does anyone have an EXCEL spreadsheet that calculates the individual phase noise of 3 oscillators when they are compared against each other, e.g A vs B, A vs C, B vs C. I.e the 3 corner hat technique. I do have a Timepod and I thought Timelab could do that, have haven't found how to do that. Regards Martyn ___ 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] 3 corner hat for phase noise
Actually, after typing all that, it occurred to me that you might have actually meant to ask about N-cornered stability measurements. They aren't supported by the current official release of TImeLab; you need to use the beta version from http://www.miles.io/timelab/beta.htm . For instructions, hit 'e' to bring up the Trace Properties dialog box and move your mouse cursor over the 'Source A/Source B' fields. These allow you to add channel labels to existing .tim files. For TimePod acquisitions, it's easier to name the sources at acquisition time. Hover over the 'Ch 0/Ch 1/Ch 2' and 'Stability' fields on the Advanced tab of the acquisition dialog to see how to do that. Contrary to what the help text says, the TimeLab manual hasn't yet been updated, so the help text is all there is, as far as documentation goes. -- john, KE5FX Miles Design LLC One nice thing about phase noise is that it's computable with complex FFTs, rather than the one-dimensional phase or frequency differences that ADEV uses... ___ 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] measuring os latency for pps
Hi Folkert If you have a board with a hardware timer that supports load/match/compare then you can schedule an external interrupt to be generated at a predetermined point in the hardware count. Thus, if you know the transform between your disciplined clock and the hardware counter of the timer that drives it, then you should be able to do this. I have spent some time working with the (pretty neat) timers on board a beaglebone black, and I've written some code to setup input capture and compare on up to 4 timers: https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master Cheers Andrew On Tue, Aug 25, 2015 at 8:24 AM, folkert folk...@vanheusden.com wrote: Hi, Not sure if it is interesting for you guys but I wrote a simple program for e.g. Linux (or any other system with the pps api implemented) that listens on a pps source waiting for a pulse and then toggles a gpio pin. That way you can measure the latency introduced by the the kernel when listening from userspace. Note that there's a little extra latency due to the gpio-pin handling. It is on github: https://github.com/flok99/pps2gpio Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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. ___ 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] SRS PRS10 repair
FYI, if you have an FTDI USB/Serial dongle you can use the FTDI FT-Prog utility to reprogram the chip to invert polarity from normal. I did that with my 'Arduino' USB/TTL cable in order to talk to an Rb osc. No need to mess around with additional inverters. You can get the utility from the support area of their website. Paul On 08/25/2015 01:35 PM, Brian M wrote: The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence. Thanks for the input on this. I'll reply back after I've had more time to hack at this. - Brian ___ 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] measuring os latency for pps
On 25/08/15 18:53, Andrew Symington wrote: Hi Folkert If you have a board with a hardware timer that supports load/match/compare then you can schedule an external interrupt to be generated at a predetermined point in the hardware count. Thus, if you know the transform between your disciplined clock and the hardware counter of the timer that drives it, then you should be able to do this. I have spent some time working with the (pretty neat) timers on board a beaglebone black, and I've written some code to setup input capture and compare on up to 4 timers: https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master Wait...You mean with your driver I essentially have a A-B-C-D TIC ? _THAT_ I have a use or three for... Since there is also code out there to drive a BBB from an external reference via TCLKIN, this gets very interesting. I might just have to compare your code against my own TIC code using the PRUSS (Although that's only a traditional A-B or A-A TIC at the moment, extending to 3 or 4 inputs would decrease the precision and accuracy...) On Tue, Aug 25, 2015 at 8:24 AM, folkert folk...@vanheusden.com wrote: Hi, Not sure if it is interesting for you guys but I wrote a simple program for e.g. Linux (or any other system with the pps api implemented) that listens on a pps source waiting for a pulse and then toggles a gpio pin. That way you can measure the latency introduced by the the kernel when listening from userspace. Note that there's a little extra latency due to the gpio-pin handling. Oh this might be very interesting, esp with something like the BBB, which has the excellent counters that Andrew discusses above. Presumably it is a five minute job to modify your code to do something other than twiddle a GPIO pin. It would be very useful to try and characterise that kernel delay. I will add it to the list of things to try, once I finish moving the time lab around! Iain ___ 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] 3 corner hat for phase noise
One nice thing about phase noise is that it's computable with complex FFTs, rather than the one-dimensional phase or frequency differences that ADEV uses. Another nice thing is that it's stationary -- meaning its probability distribution can (usually) be treated as unchanging from one measurement to the next. These two properties allow PN measurements to be performed with vector averaging over time, resulting in a single correct value at each bin. Unlike a stability measurement, the expectation with PN is that repeated measurements will always yield the same plot. So you don't need to use statistical hacks like N-corner hats to measure phase noise with a TimePod or other multichannel instrument. Pull the SMA jumpers off of the Ch0 and Ch2 jacks and feed two independent references to them. Over time, the measurement will converge to the phase noise of the source at the REF IN jack, even if it is quieter than either of the two sources at the input jacks. The TimePod/3120A firmware can't compensate for frequency offsets between Ch0 and Ch2, so the two independent sources need to be very close in frequency and they need to stay that way over the course of the measurement. A pair of good-quality rubidium or GPS clocks can be a good way to go. -- john, KE5FX Miles Design LLC -Original Message- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak Sent: Tuesday, August 25, 2015 11:11 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] 3 corner hat for phase noise This is from 3hat.c -- C code, but you get the idea: A[i] = sqrt( (0 + SQUARE(AB[i]) - SQUARE(BC[i]) + SQUARE(AC[i])) / 2.0 ); B[i] = sqrt( (0 + SQUARE(AB[i]) + SQUARE(BC[i]) - SQUARE(AC[i])) / 2.0 ); C[i] = sqrt( (0 - SQUARE(AB[i]) + SQUARE(BC[i]) + SQUARE(AC[i])) / 2.0 ); And watch out for negative square roots. /tvb - Original Message - From: Martyn Smith mar...@ptsyst.com To: time-nuts@febo.com Sent: Tuesday, August 25, 2015 9:36 AM Subject: [time-nuts] 3 corner hat for phase noise Hello, Does anyone have an EXCEL spreadsheet that calculates the individual phase noise of 3 oscillators when they are compared against each other, e.g A vs B, A vs C, B vs C. I.e the 3 corner hat technique. I do have a Timepod and I thought Timelab could do that, have haven't found how to do that. Regards Martyn ___ 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.
