Re: [time-nuts] LTE-Lite module
In message 766d6811-f733-4ab2-8574-24e4606e4...@aol.com, Said Jackson via tim e-nuts writes: Thats exactly right Bob. By the time your ocxo jumps to catch up to the efc voltage, you have oversteered, then the process starts in reverse and the ocxo jumps in the opposite direction. This is a well known PI effect called windup. The cause is a phase offset of opposite sign of the frequency offset. The fix is simple: Start running with only the P term, and engage the I term only after 1. The input phase offset changes sign or 2a. The input phase offset levels off or 2b. Some calibrated amount of time has passed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] GPS for ntp
What does everyone think of this GPS module for ntp use? According to the specsheet, it uses a Ublox Neo-7N. http://www.ebay.com/itm/RY725AI-10Hz-UART-USB-interface-GPS-Glonass-QZSS-antenna-module-flash-memory-/181562403752 I'm thinking about using it for a Beaglebone ntp server. I know there was some discussion about Beaglebones a while back. Has anyone gotten ntpd with PPS and time stamping running on a Beaglebone yet (like on the Soekris Net4501)? [] I have one Beaglebone White that I got cheap, so I have something to get started with. Later, as I figure out things, I'll buy a few Beaglebone Blacks. Joe Gray W5JG Joe, You might also consider the Raspberry Pi as an NTP server using PPS: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html You can get the ublox 7Q in a ready-to-go no=-soldering board here: http://ava.upuaut.net/store/index.php?route=product/productpath=59_60product_id=95 I would reckon on sub-100 microsecond timing accuracy with the Raspberry Pi and kernel-mode PPS, but I've not done any comparison with the BB. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] LTE-Lite module
Poul-Henning, I mentioned yesterday about integrator windup, this problem is similar but happens even without any I term present: The problem is that the ocxo maintains its frequency even though the EFC control voltage is changing. Thus phase error is accruing making the efc larger and larger due to the P term. Then at some point the crystal 'snaps' and jumps in frequency, overshooting the desired frequency and causing the P term to start pushing in the opposite direction repeating the cycle. Very similar to integrator windup, but not quite the same. Main problem is the crystal is not following the steering input. Most TCXOs and cheap ocxos have this problem, and there is no way to do anything about it since in the worst case the crystal simply refuses to run at proper frequency and thus the frequency will be approximated by cycling below and above the target frequency. Mind you we are talking about effects on the tens of parts per trillion levels. Enough to jump 10s' of ns back and forth over many minutes. Bye, Said Sent From iPhone On Oct 20, 2014, at 23:41, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 766d6811-f733-4ab2-8574-24e4606e4...@aol.com, Said Jackson via tim e-nuts writes: Thats exactly right Bob. By the time your ocxo jumps to catch up to the efc voltage, you have oversteered, then the process starts in reverse and the ocxo jumps in the opposite direction. This is a well known PI effect called windup. The cause is a phase offset of opposite sign of the frequency offset. The fix is simple: Start running with only the P term, and engage the I term only after 1. The input phase offset changes sign or 2a. The input phase offset levels off or 2b. Some calibrated amount of time has passed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] LTE-Lite module
time-nuts@febo.com said: The problem is that the ocxo maintains its frequency even though the EFC control voltage is changing. Thus phase error is accruing making the efc larger and larger due to the P term. Then at some point the crystal 'snaps' and jumps in frequency, overshooting the desired frequency and causing the P term to start pushing in the opposite direction repeating the cycle. Does anybody understand the mechanism behind that behavior? -- 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] LTE-Lite module
In message 9bc23a13-646f-49c6-9ff9-d42fa5ec8...@aol.com, Said Jackson writes: Then at some point the crystal 'snaps' and jumps in frequency, overshooting the desired frequency and causing the P term to start pushing in the opposite direction repeating the cycle. If your hardware does not respond to the output, any PI(D) loop will go bezerk, and there's nothing you can do about it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] GPS for ntp
Running the BBB as an NTP server is a breeze and has a couple of advantages over the Pi. Specifically, on the BBB, the kernel module is pre-built and configuring the PPS driver is done at runtime using the device tree. No kernel re-compilation is required to get up and running, just plug and go on any of the available GPIO. The ethernet interface on the BBB is also a SoC peripheral so gives much better latency than the USB ethernet on the Pi. This gives a big improvement if you are using it to serve time for other NTP clients. I have one of the Reyax u-blox 8 modules and it works as described, _but_ be aware that they do not have an external antenna connector. I found the reception indoors was poor to the point of making it unuseable, so depending on your circumstances, this could be a major problem. E-bay is riddled with GPS modules and pretty much any of them will be fine for NTP use. For a more off the wall suggestion, I currently have a BBB hooked up to one of these: http://www.ebay.com/itm/Mini-U-blox-B39-PCI-5S-1-500-PCI-E-Express-Wireless-Card-GPS-Module-for-MID-Lapt-/201172829176?pt=Radio_Control_Parts_Accessorieshash=item2ed6d5c3f8 A little bit of soldering is required (see here: http://emerythacks.blogspot.co.uk/2013/01/u-blox-pci-5s-cheap-gps-module-for-your.html), but what you get is a dirt cheap u-blox 5 module powered at 3.3v directly by the BBB. It's not cutting edge, and I'm not going to suggest using one of these to discipline your frequency standard, but for simple NTP use it works a treat. No claims are any good without being backed by data, so attached are a couple of plots showing my NTP performance from the past 4 hours. 'Sheliak' is the BBB with the PCI-5S and 'Albali' is a Pi with an adafruit ultimate GPS breakout (MTK3339). It's easy to see the heating coming on at ~6:20, as both servers are out in the open and it's interesting to see how they both respond to the temperature change. The scale is in milliseconds, so 5m is showing 5us. Cheers Simon What does everyone think of this GPS module for ntp use? According to the specsheet, it uses a Ublox Neo-7N. http://www.ebay.com/itm/RY725AI-10Hz-UART-USB-interface-GPS-Glonass-QZSS-antenna-module-flash-memory-/181562403752 I'm thinking about using it for a Beaglebone ntp server. I know there was some discussion about Beaglebones a while back. Has anyone gotten ntpd with PPS and time stamping running on a Beaglebone yet (like on the Soekris Net4501)? [] I have one Beaglebone White that I got cheap, so I have something to get started with. Later, as I figure out things, I'll buy a few Beaglebone Blacks. Joe Gray W5JG Joe, You might also consider the Raspberry Pi as an NTP server using PPS: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html You can get the ublox 7Q in a ready-to-go no=-soldering board here: http://ava.upuaut.net/store/index.php?route=product/productpath=59_60product_id=95 I would reckon on sub-100 microsecond timing accuracy with the Raspberry Pi and kernel-mode PPS, but I've not done any comparison with the BB. Cheers, David ___ 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] GPS for ntp
From: Simon Marsh No claims are any good without being backed by data, so attached are a couple of plots showing my NTP performance from the past 4 hours. 'Sheliak' is the BBB with the PCI-5S and 'Albali' is a Pi with an adafruit ultimate GPS breakout (MTK3339). It's easy to see the heating coming on at ~6:20, as both servers are out in the open and it's interesting to see how they both respond to the temperature change. The scale is in milliseconds, so 5m is showing 5us. Cheers Simon .. and for comparison, plots from seven Raspberry Pi NTP servers running various GPS/PPS modules all with indoor antennas, some better located than others. Raspberry Pi #7 is user-mode PPS, not kernel-mode. I can supply loopstats if anyone want them. These are the offset values reported by NTP and sampled by MRTG at 5-minute intervals. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] FE5680A Corrupted EEPROM
It may either be flash or EEPROM, but it's all in the same chip. Skip told me he has fixed a couple of FE5650 units that had the same issues by reprogramming them without issues, so I think it is well worth a try on the 5680A. Regards, Tom On Mon, Oct 20, 2014 at 9:46 PM, Bob Camp kb...@n1k.org wrote: Hi Unless we are talking about flash rather than EEPROM, an image may not do you much good. Firmware normally gets stored in flash. That code is at least similar from unit to unit. Calibration data normally gets stored in EEPROM. On a modern Rb there are a lot of things that are “tweaked” by EEPROM settings rather than fiddling pots and jumpers. Each EEPROM is unique to a unit. The settings in one may not be very healthy for another one. Again, ignore all this if the objective is a flash re-load. Bob On Oct 20, 2014, at 6:08 PM, Tom Wimmenhove tom.wimmenh...@gmail.com wrote: Skip Withrow contacted me and explained that apparently the FE5650 has a tendency to get it's internal EEPROM corrupted when sending commands to it right after power up. This confirms my suspicion that the EEPROM of my FE5680A unit suffered the same fate. He offered me to reprogram the unit as he has an ST programmer but I would need a donor unit. He would also make the files publicly available. Is there anyone out there that would let me or Skip borrow their FE5680A unit for a short amount of time to read it out? This would be greatly appreciated! Regards, Tom ___ 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 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] GPS for ntp
On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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] GPS for ntp
From: Simon Marsh [] No claims are any good without being backed by data, so attached are a couple of plots showing my NTP performance from the past 4 hours. 'Sheliak' is the BBB with the PCI-5S and 'Albali' is a Pi with an adafruit ultimate GPS breakout (MTK3339). It's easy to see the heating coming on at ~6:20, as both servers are out in the open and it's interesting to see how they both respond to the temperature change. The scale is in milliseconds, so 5m is showing 5us. Cheers Simon === .. and for comparison, plots from seven Raspberry Pi NTP servers running various GPS/PPS modules all with indoor antennas, some better located than others. Raspberry Pi #7 is user-mode PPS, not kernel-mode. I can supply loopstats if anyone want them. These are the offset values reported by NTP and sampled by MRTG at 5-minute intervals. Now the omitted URL for the plots: http://www.satsignal.eu/mrtg/performance_ntp.php Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] GPS for ntp
Check lightningmaps.org, mentioned on this list before for lightning location via TOA using STMicro Cortex -M4 devices. Didier KO4BB On October 20, 2014 8:39:16 PM CDT, Joseph Gray jg...@zianet.com wrote: What does everyone think of this GPS module for ntp use? According to the specsheet, it uses a Ublox Neo-7N. http://www.ebay.com/itm/RY725AI-10Hz-UART-USB-interface-GPS-Glonass-QZSS-antenna-module-flash-memory-/181562403752 I'm thinking about using it for a Beaglebone ntp server. I know there was some discussion about Beaglebones a while back. Has anyone gotten ntpd with PPS and time stamping running on a Beaglebone yet (like on the Soekris Net4501)? Does anyone want to take a wild guess as to the best/worst case UTC offset I might get with such a setup? I realize that I'd have to try it to really find out, but guesses and advice from those more knowledgeable is always appreciated. What I'm really after is to eventually have several Beaglebones scattered around the area as part of a TDOA DF network. I have spare radios to dedicate to the task. Each fixed node will timestamp incoming transmissions and then relay that information to a central location. The central system will use the data to calculate the location of the transmitter. Does anyone here have any experience with this sort of thing? Would you recommend a better way of accurately timing the transmissions vs using ntp on each Beaglebone? I know that TDOA is used by the cellular companies. Is anyone aware of some user level projects or source code for this? I've Googled a bit, but haven't turned up much. There was one thesis about an Amateur doing part of this, but he didn't have much detail on the satellite nodes and didn't describe anything about the centralized processing part. I have one Beaglebone White that I got cheap, so I have something to get started with. Later, as I figure out things, I'll buy a few Beaglebone Blacks. Joe Gray W5JG ___ 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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] GPS for ntp
Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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] GPS for ntp
Perhaps the programmable realtime unit (PRU) is what you're looking for. It's used in the 5370 CPU replacement. -- Paul On Tue, Oct 21, 2014 at 8:33 AM, Neil Schroeder gign...@gmail.com wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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] GPS for ntp
It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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] GPS for ntp
I missed the lightningmaps mention the first time. That is very helpful. Joe Gray W5JG On Tue, Oct 21, 2014 at 5:22 AM, Didier Juges shali...@gmail.com wrote: Check lightningmaps.org, mentioned on this list before for lightning location via TOA using STMicro Cortex -M4 devices. Didier KO4BB On October 20, 2014 8:39:16 PM CDT, Joseph Gray jg...@zianet.com wrote: What does everyone think of this GPS module for ntp use? According to the specsheet, it uses a Ublox Neo-7N. http://www.ebay.com/itm/RY725AI-10Hz-UART-USB-interface-GPS-Glonass-QZSS-antenna-module-flash-memory-/181562403752 I'm thinking about using it for a Beaglebone ntp server. I know there was some discussion about Beaglebones a while back. Has anyone gotten ntpd with PPS and time stamping running on a Beaglebone yet (like on the Soekris Net4501)? Does anyone want to take a wild guess as to the best/worst case UTC offset I might get with such a setup? I realize that I'd have to try it to really find out, but guesses and advice from those more knowledgeable is always appreciated. What I'm really after is to eventually have several Beaglebones scattered around the area as part of a TDOA DF network. I have spare radios to dedicate to the task. Each fixed node will timestamp incoming transmissions and then relay that information to a central location. The central system will use the data to calculate the location of the transmitter. Does anyone here have any experience with this sort of thing? Would you recommend a better way of accurately timing the transmissions vs using ntp on each Beaglebone? I know that TDOA is used by the cellular companies. Is anyone aware of some user level projects or source code for this? I've Googled a bit, but haven't turned up much. There was one thesis about an Amateur doing part of this, but he didn't have much detail on the satellite nodes and didn't describe anything about the centralized processing part. I have one Beaglebone White that I got cheap, so I have something to get started with. Later, as I figure out things, I'll buy a few Beaglebone Blacks. Joe Gray W5JG ___ 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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] GPS for ntp
I wasn't sure if ntp would be the way to go or not. OTOH, wasn't PHK getting nanosecond accuracy with FreeBSD on the Net4501, or is my memory faulty? Joe Gray W5JG On Mon, Oct 20, 2014 at 11:03 PM, Chris Albertson albertson.ch...@gmail.com wrote: NTP is not nearly good enough to use for measuring speed of light delays. It works at the microsecond level at best. I think what you want is each station to have a local oscillator that runs in phase with the 1PPS signal that comes from GPS receivers. Then you measure the incoming signal relative to the phase of the local oscillator. On Mon, Oct 20, 2014 at 6:39 PM, Joseph Gray jg...@zianet.com wrote: What does everyone think of this GPS module for ntp use? According to the specsheet, it uses a Ublox Neo-7N. http://www.ebay.com/itm/RY725AI-10Hz-UART-USB-interface-GPS-Glonass-QZSS-antenna-module-flash-memory-/181562403752 I'm thinking about using it for a Beaglebone ntp server. I know there was some discussion about Beaglebones a while back. Has anyone gotten ntpd with PPS and time stamping running on a Beaglebone yet (like on the Soekris Net4501)? Does anyone want to take a wild guess as to the best/worst case UTC offset I might get with such a setup? I realize that I'd have to try it to really find out, but guesses and advice from those more knowledgeable is always appreciated. What I'm really after is to eventually have several Beaglebones scattered around the area as part of a TDOA DF network. I have spare radios to dedicate to the task. Each fixed node will timestamp incoming transmissions and then relay that information to a central location. The central system will use the data to calculate the location of the transmitter. Does anyone here have any experience with this sort of thing? Would you recommend a better way of accurately timing the transmissions vs using ntp on each Beaglebone? I know that TDOA is used by the cellular companies. Is anyone aware of some user level projects or source code for this? I've Googled a bit, but haven't turned up much. There was one thesis about an Amateur doing part of this, but he didn't have much detail on the satellite nodes and didn't describe anything about the centralized processing part. I have one Beaglebone White that I got cheap, so I have something to get started with. Later, as I figure out things, I'll buy a few Beaglebone Blacks. Joe Gray W5JG ___ 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. ___ 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] GPS for ntp
Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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] GPS for ntp
It just turns up as /dev/pps0 like any other PPS source, so you configure ntp in the same way you would for any other PPS source, or build ppsapitest to test it manually (Although be aware you -may get a Invalid argument error from ppsapitest after running it more than once. Reboot solves it, and since the BBB's don't do anything else, and I don't restart ntp too often, its not a big deal for me.) Iain On 21/10/14 14:58, Simon Marsh wrote: Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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 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] GPS for ntp
Sorry, I wasn't clear. The /dev/pps0 devices output a timestamp corresponding to when the event happened. The GPIO driver does this very simply by waiting for an interrupt event and then asking what (current) time it is. This leads to the problem that there is a non-deterministic time between the event and when the code gets to ask 'what time is it ?' With HW capture, you can get an accurate view of when the event took place but only relative to the counter in the particular timer/capture unit that is being used. You have to synchronise between the counter value and what the OS understands is 'system time' in order to create a retrospective timestamp for when the event occured. Whilst you've solved the problem with the interrupt approach, you've created a different one of needing to synchronise counters. My question is how do you convert between the timer value and system time to get the timestamp ? Cheers Simon On 21/10/2014 15:14, Iain Young wrote: It just turns up as /dev/pps0 like any other PPS source, so you configure ntp in the same way you would for any other PPS source, or build ppsapitest to test it manually (Although be aware you -may get a Invalid argument error from ppsapitest after running it more than once. Reboot solves it, and since the BBB's don't do anything else, and I don't restart ntp too often, its not a big deal for me.) Iain On 21/10/14 14:58, Simon Marsh wrote: Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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 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] GPS for ntp
Hi Simon, Ah, slightly different question :) I'm afraid I didn't write the code, so I can't really answer that question. What I can say is that it does appear to be as good as Ian (Lepore's) ntpq output shows. To be honest, I just use the code :) Iain On 21/10/14 15:39, Simon Marsh wrote: Sorry, I wasn't clear. The /dev/pps0 devices output a timestamp corresponding to when the event happened. The GPIO driver does this very simply by waiting for an interrupt event and then asking what (current) time it is. This leads to the problem that there is a non-deterministic time between the event and when the code gets to ask 'what time is it ?' With HW capture, you can get an accurate view of when the event took place but only relative to the counter in the particular timer/capture unit that is being used. You have to synchronise between the counter value and what the OS understands is 'system time' in order to create a retrospective timestamp for when the event occured. Whilst you've solved the problem with the interrupt approach, you've created a different one of needing to synchronise counters. My question is how do you convert between the timer value and system time to get the timestamp ? Cheers Simon On 21/10/2014 15:14, Iain Young wrote: It just turns up as /dev/pps0 like any other PPS source, so you configure ntp in the same way you would for any other PPS source, or build ppsapitest to test it manually (Although be aware you -may get a Invalid argument error from ppsapitest after running it more than once. Reboot solves it, and since the BBB's don't do anything else, and I don't restart ntp too often, its not a big deal for me.) Iain On 21/10/14 14:58, Simon Marsh wrote: Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ 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 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 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
[time-nuts] LTE-Lite module and the pendulum...
I've been following this thread with some interest. I have no idea what a LTE-Lite module is, but I believe the issues being discussed is essentially the same issue that I had a year or so ago when I had to make repairs to my two DATUM 9390-52054 GPS references. At that time I copied this list on the various steps from discovery of the power supply noise grief to further discovery of problems with the original factory supplied internal Vectron VCXO oscillator module. After replacing the internal switching power supply with an outboard Cisco unit, I went on to look at what I felt was instability of the 10 MHz reference. According to the front panel display, the error would wander anywhere from 0E-12 to 50 or 100E-12. For my use, this wasn't a major problem, but one that bothered my instinctive curiosity and another step in my life in searching for a way to improve things. The original oscillator module in the 9390 was a Vectron 716Y2690. This has a frequency trim adjustment on the side to bring the oscillator into tracking range for the DATUM 9390. In one of my two units the adjustment would jump, which I attributed to a defective trimming capacitor. My friend Stu, K6YAZ had previously given me two McCoy MC597X4 VCXO modules that do not have a frequency adjustment other than by way of the EFC control. Looking at the specs on these modules it looked like they might almost be electrically a drop in replacement for the original Vectron modules, although the McCoy's were about one-quarter the size. The McCoy's require 5 volts Vcc rather than 12 volts that the Vectron required. Not a problem. Testing confirmed that the EFC tuning voltage indeed went the same direction the McCoy requires. Since I don't have the sophisticated equipment that many of you have to comparatively confirm stability, I decided to modify only one of my 9390's and compare the results to the other one. The two 9390's have separate antennas mounted about 3 feet apart and in a pretty clear view of the sky. I stuffed the McCoy module in place of the Vectron but instead of connecting the EFC lead, I used a 1k pot with the top connected to 5 volts through a small resistor, the bottom to ground, and the arm to the EFC pin on the McCoy. Using the other 9390 for comparison, I was able to determine that in order to have the McCoy output 10 MHz, the EFC voltage wanted to be slightly under +4 volts, essentially the same as the original Vectron. Great, what could go wrong? I shut everything down and connected the EFC control voltage to the EFC terminal on the McCoy. As the McCoy came up to temperature I got a tracking light and the 10 MHz spigot came nicely onto 10 MHz, sat there and then wandered off frequency and after a while came back and overshot in the other direction. I figured this would be a process that would go on for a day or two and the pendulum would eventually settle in. After several days this did not happen and the 9390 gave me a tracking error. Apparently, the time constants in the loop and the sensitivity of the EFC control in the McCoy did not play well together. Pondering the situation I decided to slow down the EFC voltage change. I did this by putting a 4.7 uf capacitor across the EFC pin to the ground pin and fed the EFC voltage to the EFC pin through a 5100 Ohm resistor, essentially, in my opinion, hanging a flywheel across the EFC line to the McCoy. Since with the smaller McCoy I had additional space within the 9390 I also made a sandwich type enclosure out of foam for the smaller McCoy to help isolate it from tempreture changes. I let the unit run for about 24 hours and noted that it had settled in nicely and sat, according to its display, at 0E-12 for well over the next 24 hours. Comparing this to my stock 9390, this appeared to be correct except for some small amount of wandering - the stock unit was showing variations of 1E-12 to about 10E-12, the amount of drift they had both always shown. I watched this for about two weeks and while the modified 9390 sat at 0E-12, the stock unit continued to show the same amount of drift it always had shown. I modified my second 9390 with the other McCoy VCXO and now the two units sit within 0 to 1E10-12, and comparing the two using both a 1:1 Lissajou and separately using one to trigger a scope that's monitoring the other, I believe things are much improved. In the year plus since I've modified these two units they've sat quite steady and have survived some deliberate power interruptions just to see what would happen. I have detailed pictures if anyone is interested. I don't know if the above offers any input of value, or even how scientific it is according to deep Time-Nuts standards, but it's what I did. Burt, K6OQK From: Poul-Henning Kamp p...@phk.freebsd.dk Subject: Re: [time-nuts] LTE-Lite module In message 9bc23a13-646f-49c6-9ff9-d42fa5ec8...@aol.com, Said Jackson
Re: [time-nuts] LTE-Lite module
Hi Hal, This behavior is called hysteresis and it is related to vendors, and related to the chips used (or varactor diode) inside the tcxo/ocxo. It is so subtle that most vendors are not even aware that their oscillator is doing it. Some vendors have product lines that do it and others that don't. We have spent a lot of energy and time locating vendors and products that don't do it, but we still test for it. You can only see it when you discipline the crystal and can measure phase drift over 10's of minutes as the frequency shifts will typically be below the noise floor and masked by thermal stability of the tcxo. For example if a crystal has 50 parts per trillion hysteresis (5E-011) this means the phase will drift back and forth at up to 0.05ns per second which means the equivalent of less than 50ns every 16 minutes or so. Depending on how fast the loop goes back and forth around this 50ppb dead zone the crystal could phase drift back and forth some 10's of nanoseconds. That makes a big difference in ADEV and standard deviation. The solution: identify vendors and products that don't do it.. This is part of the art. Bye, Said Sent From iPhone On Oct 21, 2014, at 0:12, Hal Murray hmur...@megapathdsl.net wrote: time-nuts@febo.com said: The problem is that the ocxo maintains its frequency even though the EFC control voltage is changing. Thus phase error is accruing making the efc larger and larger due to the P term. Then at some point the crystal 'snaps' and jumps in frequency, overshooting the desired frequency and causing the P term to start pushing in the opposite direction repeating the cycle. Does anybody understand the mechanism behind that behavior? -- 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] GPS for ntp
With HW capture, you can get an accurate view of when the event took place but only relative to the counter in the particular timer/capture unit that is being used. True. You have to synchronise between the counter value and what the OS understands is 'system time' in order to create a retrospective timestamp for when the event occured. Also true. One solution to the problem is use two independent HW capture inputs. One for a GPS 1PPS and the other for your event. In this case the system clock does not need to be synchronized -- since it is used only to interpolate between the two events. The event timestamp is little more than adding the differential of the two most recent captures, which is a number from 0 to 1 second. For added precision, and if your system oscillator happens to be many ppb fast or slow, you simply adjust the differential by that small rate offset. There is no need to actually set the system clock (time) or need to discipline the system clock (rate). Since you're capturing a GPS/1PPS snapshot every second, the clock rate offset is effectively measured every second for free. /tvb ___ 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] LTE-Lite module and the pendulum...
Burt, Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Bye, Said Sent From iPhone On Oct 21, 2014, at 8:54, Burt I. Weiner b...@att.net wrote: I've been following this thread with some interest. I have no idea what a LTE-Lite module is, but I believe the issues being discussed is essentially the same issue that I had a year or so ago when I had to make repairs to my two DATUM 9390-52054 GPS references. At that time I copied this list on the various steps from discovery of the power supply noise grief to further discovery of problems with the original factory supplied internal Vectron VCXO oscillator module. After replacing the internal switching power supply with an outboard Cisco unit, I went on to look at what I felt was instability of the 10 MHz reference. According to the front panel display, the error would wander anywhere from 0E-12 to 50 or 100E-12. For my use, this wasn't a major problem, but one that bothered my instinctive curiosity and another step in my life in searching for a way to improve things. The original oscillator module in the 9390 was a Vectron 716Y2690. This has a frequency trim adjustment on the side to bring the oscillator into tracking range for the DATUM 9390. In one of my two units the adjustment would jump, which I attributed to a defective trimming capacitor. My friend Stu, K6YAZ had previously given me two McCoy MC597X4 VCXO modules that do not have a frequency adjustment other than by way of the EFC control. Looking at the specs on these modules it looked like they might almost be electrically a drop in replacement for the original Vectron modules, although the McCoy's were about one-quarter the size. The McCoy's require 5 volts Vcc rather than 12 volts that the Vectron required. Not a problem. Testing confirmed that the EFC tuning voltage indeed went the same direction the McCoy requires. Since I don't have the sophisticated equipment that many of you have to comparatively confirm stability, I decided to modify only one of my 9390's and compare the results to the other one. The two 9390's have separate antennas mounted about 3 feet apart and in a pretty clear view of the sky. I stuffed the McCoy module in place of the Vectron but instead of connecting the EFC lead, I used a 1k pot with the top connected to 5 volts through a small resistor, the bottom to ground, and the arm to the EFC pin on the McCoy. Using the other 9390 for comparison, I was able to determine that in order to have the McCoy output 10 MHz, the EFC voltage wanted to be slightly under +4 volts, essentially the same as the original Vectron. Great, what could go wrong? I shut everything down and connected the EFC control voltage to the EFC terminal on the McCoy. As the McCoy came up to temperature I got a tracking light and the 10 MHz spigot came nicely onto 10 MHz, sat there and then wandered off frequency and after a while came back and overshot in the other direction. I figured this would be a process that would go on for a day or two and the pendulum would eventually settle in. After several days this did not happen and the 9390 gave me a tracking error. Apparently, the time co nstants in the loop and the sensitivity of the EFC control in the McCoy did not play well together. Pondering the situation I decided to slow down the EFC voltage change. I did this by putting a 4.7 uf capacitor across the EFC pin to the ground pin and fed the EFC voltage to the EFC pin through a 5100 Ohm resistor, essentially, in my opinion, hanging a flywheel across the EFC line to the McCoy. Since with the smaller McCoy I had additional space within the 9390 I also made a sandwich type enclosure out of foam for the smaller McCoy to help isolate it from tempreture changes. I let the unit run for about 24 hours and noted that it had settled in nicely and sat, according to its display, at 0E-12 for well over the next 24 hours. Comparing this to my stock 9390, this appeared to be correct except for some small amount of wandering - the stock unit was showing variations of 1E-12 to about 10E-12, the amount of drift they had both always shown. I watched this for about two weeks an d while the modified 9390 sat at 0E-12, the stock unit continued to show the same amount of drift it always had shown. I modified my second 9390 with the other McCoy VCXO and now the two units sit within 0 to 1E10-12, and comparing the two using both a 1:1 Lissajou and separately using one to trigger a scope that's monitoring the other, I believe things are much improved. In the year plus since I've modified these two units
Re: [time-nuts] GPS for ntp
On Tue, Oct 21, 2014 at 6:58 AM, Simon Marsh How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) He is running NTP. NTP's job is it keep the system time in sync with a number of reference clocks. The 1PPS from a GPS makes a good reference clock. It does this by adjusting the RATE of the system clock to not gain or loose vs. a set of reference clocks over time. The algorithm is not simple. The weak link is that the timing is done in software and in the real world the accuracy is a few microseconds. -- 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] LTE-Lite module and the pendulum...
Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Whenever I've seen this behavior, it has always been caused by uncertainty or quantization on the part of the trimpot's wiper, rather than anything that could be blamed on the varactor. What would be a good example of a TCXO or OCXO model that exhibits EFC hysteresis? I don't immediately understand what could cause this phenomenon, and I'd like to reproduce it here to see what's happening. -- john, KE5FX Miles Design LLC ___ 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] LTE-Lite module and the pendulum...
Hi John, while I can't tell you which vendors are affected and which are not (Its like asking an angler for his secret angling spot :), I can say that most low cost TCXOs exhibit this behavior, and are thus not really suitable for GPSDOs. The ones we used on the LTE-Lite are quite good and do not exhibit this behavior. They are also 10x more expensive than the lost cost TCXOs in the exact same package that are typically used in non-critical applications. So far none of the quite reputable TCXO and OCXO vendors that I contacted about the problem can explain the behavior to me, like I said they were not even aware of the issue and had no way to test for it, and I had to prove it to them by sending our units to them so they can see the issue for themselves. Bye, Said In a message dated 10/21/2014 11:51:28 Pacific Daylight Time, j...@miles.io writes: Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Whenever I've seen this behavior, it has always been caused by uncertainty or quantization on the part of the trimpot's wiper, rather than anything that could be blamed on the varactor. What would be a good example of a TCXO or OCXO model that exhibits EFC hysteresis? I don't immediately understand what could cause this phenomenon, and I'd like to reproduce it here to see what's happening. -- john, KE5FX Miles Design LLC ___ 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] LTE-Lite module and the pendulum...
Also have this problem with capacitor-adjusted tuning. No matterhow careful you turn, stiction causes the adjustment to jump in the direction of the turn. Don John Miles Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Whenever I've seen this behavior, it has always been caused by uncertainty or quantization on the part of the trimpot's wiper, rather than anything that could be blamed on the varactor. What would be a good example of a TCXO or OCXO model that exhibits EFC hysteresis? I don't immediately understand what could cause this phenomenon, and I'd like to reproduce it here to see what's happening. -- john, KE5FX Miles Design LLC ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road Huson, MT, 59846 mail: POBox 404 Frenchtown MT 59834-0404 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.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] GPS for ntp
t...@leapsecond.com said: You have to synchronise between the counter value and what the OS understands is 'system time' in order to create a retrospective timestamp for when the event occured. Also true. One solution to the problem is use two independent HW capture inputs. One for a GPS 1PPS and the other for your event. In this case the system clock does not need to be synchronized -- since it is used only to interpolate between the two events. The event timestamp is little more than adding the differential of the two most recent captures, which is a number from 0 to 1 second. You haven't solved the problem yet. Now you have to synchronize the HW capture counters. You can probably do that with some simple but delicate initialization code. Maybe copy the value from the counter used for the system time? At the time-nut level, you have to worry about things like cache misses. (There may be more fine print at that level depending upon the details of the hardware.) You could also do it by calibrating out the difference: just feed the same pulse into both input pins. You have to do that each time you (re)start things. That's easy for a one-off project but adds another ugly step if you want to do it in production. Collecting long term data moves a hobby project a lot closer to production. -- 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] GPS for ntp
Here's some more info Joe My Blitzortung.org station 1162 reboots daily. It is located at 42 degrees latitude. GlobalTop PA6H GPS module. The antenna is a Motorola patch in the attic, looking through wooden boards and tar shingles. I have the antenna against the underside of the roof, tipped to the South. There are power lines on the South and East sides of the house. On the North side of the house is an 17 meter high tower with guy wires and HF inverted V antennas. Lots of multi-path. My H-field loops are made from old, quad-shielded Thick-LAN cable, 3 turns, 1.5 meter diameter. The controller has been running 18 hours so far today and there is a heavy cloud cover today. Here are current stats: Availability100.00% Type Mediatek/GlobalTop with 38400baud (FW: AXN_2.10_3339_11092201,5051) Antenna External Status Active, 3D-fix Satellites 11 tracked, 11 in view Date/Time 2014-10-21 19:31:46 Position 42.996052° -82.464241° 187.7m Smoothed 42.996035° -82.464253° 188.1m (smoothed over 1d, 0h) PDOP/HDOP/VDOP1.41 / 0.83 / 1.14 Sat. Signals (SNR) 5 42dB 2 41dB 29 43dB 10 29dB 13 30dB 26 41dB 25 28dB 6 32dB 12 29dB 9 18dB 15 23dB PPS Accuracy Mean: 33.7ns, Current: 23ns On 10/21/2014 09:23 AM, Joseph Gray wrote: I missed the lightningmaps mention the first time. That is very helpful. Joe Gray W5JG On Tue, Oct 21, 2014 at 5:22 AM, Didier Jugesshali...@gmail.com wrote: Check lightningmaps.org, mentioned on this list before for lightning location via TOA using STMicro Cortex -M4 devices. Didier KO4BB ___ 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] GPS for ntp
One solution to the problem is use two independent HW capture inputs. One for a GPS 1PPS and the other for your event. In this case the system clock does not need to be synchronized -- since it is used only to interpolate between the two events. The event timestamp is little more than adding the differential of the two most recent captures, which is a number from 0 to 1 second. You haven't solved the problem yet. Now you have to synchronize the HW capture counters. Hi Hal, Nope, there's no need to synchronize HW counters (against system time or UTC or something). That's the beauty of time-stamping or capture counters: they are free-running (at some internal CPU frequency) and share a common clock counter register from which the capture/snapshot is taken. You can probably do that with some simple but delicate initialization code. Maybe copy the value from the counter used for the system time? At the time-nut level, you have to worry about things like cache misses. (There may be more fine print at that level depending upon the details of the hardware.) No, again that's the beauty of H/W capture counters. You completely avoid the OS or software rat's nest called system time. Only the capture registers keep perfect system time by virtue of their continuous h/w counting, unaffected by software, locks, interrupts, cache, TLB, or microcode latency issues. You could also do it by calibrating out the difference: just feed the same pulse into both input pins. You have to do that each time you (re)start things. That's easy for a one-off project but adds another ugly step if you want to do it in production. Collecting long term data moves a hobby project a lot closer to production. The modern CPU's with capture/compare registers I've seen use a common N-bit timer register as the capture source, so there's no issue with intra-capture synchronization. What is still critical, to align with UTC for example, is inter-clock synchronization. And that's why two h/w capture counters are needed -- one for the event (LAN packet, for example) and one for the GPS/1PPS timestamp. /tvb ___ 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] GPS for ntp
On 21 Oct, 2014, at 08:58 , Simon Marsh subscripti...@burble.com wrote: How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) On the NetBSD prototype I have the clock adjustment system call interface is expanded to deal with multiple clocks, only one of which is the system clock. The HW counter becomes its own clock, which is the clock in which PPS measurements are expressed and which is adjusted into alignment with the PPS data. The system clock is adjusted into alignment with the HW counter clock using offset data from PIO polling of the clock pair. The IEEE1588 timestamp counter becomes a third clock, which gets adjusted into alignment with the system clock for use as a PTP server, or which is used to adjust the system clock when operating as a client. For the beaglebone this is probably overkill; since the clocks are all synchronous the system-peripheral clock polling essentially determines a constant offset, after which you can keep them in sync by making the same relative rate adjustments to all clocks. For the general IEEE1588 case, however, the counter being sampled at the ethernet interface is often clocked by a different crystal then the clock you would prefer to use as the system clock, and the process of steering one clock into synchronization with another needs to be more complex. I should note that none of these clock adjustments really requires a PLL or other feedback control loop, nor does NTP, since no clock hardware is actually adjusted. The crystals are all free running and are unaffected by the adjustments. What is adjusted is instead a paper clock, that is the adjustment is to the arithmetic done to convert each free running counter to a time of day, and this can be done open loop, with perfectly predictable results and with no feedback control, by just doing the adjustment arithmetic accurately and transparently. The thing the PLL does for ntpd, then, is to allow it to deal with (paper) clock adjustment interfaces which don't do the arithmetic accurately, or at least don't tell you what they actually did, so that the arithmetic done can only be determined by further measurement. This is unavoidable if you need to deal with a big variety of operating systems, I guess, but it does make the problem harder than if the adjustment interface is fixed and feedback loop eliminated, leaving just the measurement problem. Dennis Ferguson ___ 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] LTE-Lite module and the pendulum...
Said, The DATUM 9390's I have came from the Sieko pager watch project that I was involved in back in the mid to late 90's. As I recall, even when the DATUM clocks were new we'd have to adjust the oscillators periodically to keep them within lock range. The center of the DAC was around 27000 and they'd wander about 1 plus or minus. They'd sometimes wander out of lock at plus or minus about 15000 and one of us would have to make a trip to some transmitter site to re-set the clock and re-center the Vectron module. The adjustment was accessible through a hole in the back of the clock. As I recall, you could give the oscillator a half turn one way or the other without causing too much distress to the clock. This held true with my two units until the one oscillator developed the adjustment problem. Not knowing what was really inside the Vectron, I attributed the problem to a defective or cracked piston capacitor. The adjustment certainly had the feel of a piston capacitor. Since I made the modifications I described, the DAC sits within about 10 of 27450, and that's where my units are happy. By the way, I've got two 1.5 KVA UPS's in my shoppe, one for each clock. They'll run for a long time on those. Burt From: Said Jackson saidj...@aol.com Subject: Re: [time-nuts] LTE-Lite module and the pendulum... Burt, Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Bye, Said Burt I. Weiner Associates Broadcast Technical Services Glendale, California U.S.A. b...@att.net www.biwa.cc K6OQK ___ 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] Periods in GPS systems.
Hi All, I've been playing with a GPSDO a little here. In order to get a handle on the response time of the loop, I ran an FFT on the EFC DAC value over a long run. What was interesting, was that three frequencies popped up with minor peaks. They were cycles that equaled 512 seconds, 682 seconds, and 1024 seconds. Is anyone aware of any periods like this in the GPS system? These seem rather conspicuous! Dan ___ 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] LTE-Lite module and the pendulum...
Burt, those old Vectrons can be tricky. I had a 100MHz unit in my DTS-2070 and it could not be adjusted to 100MHz anymore, it had out-aged its trim capacitor. I threw it away I think, and replaced it with something more modern. My initial point was that your trim cap problem is very similar to what the loop is experiencing on oscillators that have an EFC hysteresis. There is not a single vendor in the world that I know of that specifies this EFC hysterisis, and this and the retrace of the crystal over the first couple of hours are two extremely important parameters as they can cause significant errors in GPSDOs. bye, Said In a message dated 10/21/2014 15:10:09 Pacific Daylight Time, b...@att.net writes: Said, The DATUM 9390's I have came from the Sieko pager watch project that I was involved in back in the mid to late 90's. As I recall, even when the DATUM clocks were new we'd have to adjust the oscillators periodically to keep them within lock range. The center of the DAC was around 27000 and they'd wander about 1 plus or minus. They'd sometimes wander out of lock at plus or minus about 15000 and one of us would have to make a trip to some transmitter site to re-set the clock and re-center the Vectron module. The adjustment was accessible through a hole in the back of the clock. As I recall, you could give the oscillator a half turn one way or the other without causing too much distress to the clock. This held true with my two units until the one oscillator developed the adjustment problem. Not knowing what was really inside the Vectron, I attributed the problem to a defective or cracked piston capacitor. The adjustment certainly had the feel of a piston capacitor. Since I made the modifications I described, the DAC sits within about 10 of 27450, and that's where my units are happy. By the way, I've got two 1.5 KVA UPS's in my shoppe, one for each clock. They'll run for a long time on those. Burt From: Said Jackson saidj...@aol.com Subject: Re: [time-nuts] LTE-Lite module and the pendulum... Burt, Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Bye, Said Burt I. Weiner Associates Broadcast Technical Services Glendale, California U.S.A. b...@att.net www.biwa.cc K6OQK ___ 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] Periods in GPS systems.
Hi They sound like update rates on the filter in your GPSDO. Bob On Oct 21, 2014, at 6:10 PM, d...@irtelemetrics.com wrote: Hi All, I've been playing with a GPSDO a little here. In order to get a handle on the response time of the loop, I ran an FFT on the EFC DAC value over a long run. What was interesting, was that three frequencies popped up with minor peaks. They were cycles that equaled 512 seconds, 682 seconds, and 1024 seconds. Is anyone aware of any periods like this in the GPS system? These seem rather conspicuous! Dan ___ 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] LTE-Lite module and the pendulum...
Hi Depending on how much you spend on a mechanical piston trimmer, the innards will be coaxial to some tolerance. To the extent they rotate or “swing” as one piece moves in and out of the other, the capacitance will be more linear or less linear vs rotation of the trimmer. What you want - a straight line capacitance vs screw turns. What you get - a bit of a wiggly line of capacitance vs screw turns. On one side of the wiggle, the adjustment moves a bit fast. On the other side of the wiggle, the adjustment moves a bit slow. Next up is backlash. This a common issue in many mechanical systems. It’s most apparent in trimmers where a screw drives a moving part rather than the whole moving end being threaded. As the threads wear, they get a little slop in them Turn the screw clockwise all the time and everything is linear. Stop with clockwise and go counterclockwise and the threads have to mate no the other side of the screw. You don’t have anything happening until they do. If you read up on running a mechanical milling machine, you will see a lot of talk about this in terms of precision milling. Then of course you have broken trimmers. Ceramic trimmers can have the metabolized portions “stick” to each other. When you force them to move, you tear the metal off of the ceramic. Now you have a broken trimmer that really does odd things. Piston trimmers can get crud in them (either from outside or from their own moving parts). It does not take a very big chunk of stuff to short out the trimmer (if it’s conductive) or to mess up the tuning (if it’s not). Trim pots have their issues as well. The wipers can build up a bit of resistance from sitting in one place for a while. Move the trimmer and you clean up the contact. Depending on the circuit, this may or may not have much effect on the EFC to the varicap. Since trimmers can get a bit of force exerted on them, all the usual broken solder joint and ripped off the board sort of stuff applies to them as well. Lots of fun !! Bob On Oct 21, 2014, at 2:50 PM, John Miles j...@miles.io wrote: Great insight thanks. You nailed it: out with the old oscillator and in with one that doesn't have that problem. Btw the mechanical tuning issue you mentioned is essentially the same exact problem: even the slightest turn will make the frequency jump too high or too low. It can drive you (and the loop) crazy trying to get it on-frequency. Whenever I've seen this behavior, it has always been caused by uncertainty or quantization on the part of the trimpot's wiper, rather than anything that could be blamed on the varactor. What would be a good example of a TCXO or OCXO model that exhibits EFC hysteresis? I don't immediately understand what could cause this phenomenon, and I'd like to reproduce it here to see what's happening. -- john, KE5FX Miles Design LLC ___ 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.
