Re: [time-nuts] Raspberry Pi NTP server
From: Steven Sommars [] Why bother with GPS/USB? Sometimes I use laptops. Few laptops today directly support PPS/serial. I just checked with Dell and found zero laptops with native RS232. Thanks for posting your measurements, Steven. If you can find a laptop with a direct Ethernet LAN connection you may find that's quite good if (and it's a big if) you have a stratum-1 Ethernet source available. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] HP 5316B External Reference
Thank you Paul. On 7/11/2020 6:59 PM, paul swed wrote: Wes many of the HP sig gens and counters use that method I might guess starting in the 70s. They all lock very well to the external reference and are as good as the external reference is. One gotcha. It seems some people pull the oscillators to sell on auction sites. So if its missing thats a bit of a mess to deal with. Regards Paul ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] HP 5316B External Reference
Thanks for your insights Rick. The manual specifically states: "The HP 5316B does not actually use the external input signal for a time base but locks-on to the signal with an injection-lock-multiplier. The external signal must be 1,5, or 10 MHz" My only experience with injection locking was with the Phoenix Missile IMPATT diode "amplifier" which was actually three circulator-coupled oscillator stages using one, three and sixteen diodes respectively. I don't currently own one of these counters, I'm just investigating the idea of using one for off-the-air frequency measurements where the unknown is mixed down to audio. Wes N7WS On 7/11/2020 6:46 PM, Richard (Rick) Karlquist wrote: On 7/11/2020 3:51 PM, Wes wrote: As I understand it this counter has an external reference input that isn't used directly as the time base but injection locks the internal time base. Does anyone here know how well this works. Is using a GPSDO as a reference a worthwhile accuracy improvement? Wes Stewart N7WS I worked in Frequency Counter R at the HP Santa Clara division around the time the 5316B introduced, but didn't know about this detail. AFAIK, most counters we made did NOT work this way. Whatever external reference you fed in (warts and all) was used to clock the counter. OTOH, most RF instruments (other than counters) used a PLL (not injection locking) to lock the internal oscillator to the external reference. IMHO, this architecture only made sense on sig gens and spec ans, not on counters. I will point out that the 5316B was a cost reduced version of the 5316A. I was the project manager for the 5334B, which was a cost reduced version of the 5334A. I believe there was a third model where the B version was cost reduced from the A version, but I don't remember which one. As a group, these were called the "killer B's" because they would supposedly kill off Racal Dana sales or some silly marketing nonsense to that effect. It's possible that for some obscure reason, a scheme was employed to save money that superficially resembled injection locking. I'm guessing a multifunction chip was used that had a built in oscillator with an external crystal, but no access to the connection from the oscillator output (on the chip) to the downstream circuit. Are you sure that the 5316B actually uses injection locking, rather than having the external reference simply drive the crystal pins on the IC? This would be easy to verify by feeding in an external reference that was say 100 ppm off frequency and seeing if the counter still worked OK. No injection locking scheme AFAIK would ever pull that far. If it actually is true injection locking, the problem is that whether it worked would depend on the relationship between the free running frequency and the external reference frequency, of course. IOW, it might work in some cases and not in others. Rick N6RK ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] FTS 4065A schematics?
Jim I do not have a 4065. But a 4060 and it uses a +31V supply. Its derived from the common 24V supply by a DC/DC up converter. The tantalum caps had burst and eaten many traces and parts. No real way to repair that damage though I seriously tried. When that all failed, I simply introduced a nice 31 VDC supply. System is up and operational and locks quite quickly. Just a thought that may help you. Regards Paul. On Sat, Jul 11, 2020 at 10:34 PM AC0XU (Jim) wrote: > Time Nuts- > > Another project - have an FTS 4065A cesium beam reference with what > appears to be a short in the -34V supply line. I have the 4065C Operators > Guide, which has partial schematics. However, the C version apparently has > only a +34V main supply, whereas the A version has both + and -34V. > > Does anyone have manuals or schematics for the FTS 4065A? > > Thanks! > > Jim > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] PDIP package 100 MHz decade dividers
Hi Perrier https://www.y-ic.es/datasheet/3b/74F569SC.pdf will work 73 KJ6UHN Alex On 7/11/2020 3:00 PM, Perry Sandeen via time-nuts wrote: Learned List, On previous posts I was looking for a PDIP package 100 MHz decade divider. Reading just the front of the data sheet I thought that the 74LS161 would work. Boy, was I wrong. Several members posted that 25 Mhz max was its limit. So *on the road again* (sorry Willie) I went on another search this time with the correct logic family. It turns out Arrow carries the 74HC161 for less that $1. Additionally I D/L'd the Charles Wenzel Unusual Frequency Dividers PDF and discovered a 100 MHz decade divider circuit using 1/2 of a 74HC74 in a configuration that will decade divide up to 300 MHz. I'm attaching a copy of the circuit for anyone interested. Regards, Perrier ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] HP 5316B External Reference
Wes many of the HP sig gens and counters use that method I might guess starting in the 70s. They all lock very well to the external reference and are as good as the external reference is. One gotcha. It seems some people pull the oscillators to sell on auction sites. So if its missing thats a bit of a mess to deal with. Regards Paul On Sat, Jul 11, 2020 at 8:57 PM Wes wrote: > As I understand it this counter has an external reference input that isn't > used > directly as the time base but injection locks the internal time base. > Does > anyone here know how well this works. Is using a GPSDO as a reference a > worthwhile accuracy improvement? > > Wes Stewart N7WS > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Raspberry Pi NTP server
On 7/11/20 1:30 PM, Steven Sommars wrote: Using GPIO with an RPi is a good direction, of course. That wasn't my question. Some data may help explain. Configuration = RPi4 (raspbian buster) Uputronics RPi GPS board (includes PPS) connected to GPIO pins. This is the time of day source for the RPi4. (via GPSD+chrony). Navisys USB GR701 (includes PPS and Integrated serial->USB conversion). Contains integrated Prolific Technology, Inc. PL2303 The observed PPS variation on the Uputronics PPS is a few microseconds. (ppstest was used for measurements). Using a PPS to drive NTP's computer clock disciplining, which is in turn used to measure the same PPS makes for a dubious circular measurement.It is comforting though to see that the variance is in the ~1-3 microsecond range. One must also add Trent's interrupt latency measurement (3 microseconds). With the GPIO connection the RPi time base should be within say 10 microseconds of UTC. The USB-connected Navisys fares worse. [image: image.png] By the time the PPS reaches the OS there is about 1 msec of variance with an average offset of a bit over 0.6 msec. I suspect the 1 msec USB polling is the largest latency contributor, though there are other sources as mentioned by Tim. I'd like to reduce the USB polling contribution by polling at 125 microseconds as the Linux PPS folks suggest (http://linuxpps.org/doku.php/technical_information)Would an FTDI-based USB convertor do the trick? Why bother with GPS/USB? Sometimes I use laptops. Few laptops today directly support PPS/serial. I just checked with Dell and found zero laptops with native RS232. I would not expect another kind of USB to serial converter to do better. The problem is higher up in the way that Linux handles USB devices. The USB hardware can certainly handle higher rates (and does), but the "software interrupts" as the event travels up the stack limits the timing resolution. You might want to look into one of the "real time" linux kernels or other similar implementations - they might have "turned some of the knobs" to improve the handling of device data. USB device handling in Linux (and Windows, and Mac OSX) is quite complex, if only because USB itself is quite complex in that it has to support multiple "kinds" of devices with wildly varying properties (HID, Mass Storage, Isochronous data, etc.) - Not to mention all the complexities associated with hot plugging and unplugging and "enumeration" and "power control". You might also want to delve into the handling of USB request Blocks (URBs) which is how Linux handles USB related events. https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch13.html https://www.kernel.org/doc/html/v4.12/driver-api/usb/index.html The above document describes a variety of ways to get at USB devices in non-standard ways, through the USB API. Another interesting alternative might be to modify the low level interrupt handler for your Prolific chip (or whatever you're using) - you could probably snapshot the system timer in the IRQ. But then you're faced with the challenge of propagating that time to where you need it, and hopefully in a way that doesn't break Linux. In any case, your problem is not that it's USB. Your problem is that Linux has some compromises in how it handles USB devices that essentially imposes a 1kHz quantization on it. There is a reason why USB support was late in coming to Linux compared to other devices. And there's a reason why everyone curses at serial interfaces, particularly over USB. Their character at a time behavior fits real well for read() and write() in most OSes, but the ioctl() call tends to be very, very complex. And getting high speed or deterministic behavior is always a challenge. I feel your pain. All of my serial interfaces stopped working when I went from Mavericks to Mojave... I finally got a SiLabs interface working, and one instance of a FTDI device. The Prolific PL2303, not yet. I was seriously contemplating making Ethernet to USB interfaces on an Arduino, where there's no OS involved. I have so many pieces of equipment with USB interfaces, all a bit different, all sort of using a serial port model. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] HP 5316B External Reference
On 7/11/2020 3:51 PM, Wes wrote: As I understand it this counter has an external reference input that isn't used directly as the time base but injection locks the internal time base. Does anyone here know how well this works. Is using a GPSDO as a reference a worthwhile accuracy improvement? Wes Stewart N7WS I worked in Frequency Counter R at the HP Santa Clara division around the time the 5316B introduced, but didn't know about this detail. AFAIK, most counters we made did NOT work this way. Whatever external reference you fed in (warts and all) was used to clock the counter. OTOH, most RF instruments (other than counters) used a PLL (not injection locking) to lock the internal oscillator to the external reference. IMHO, this architecture only made sense on sig gens and spec ans, not on counters. I will point out that the 5316B was a cost reduced version of the 5316A. I was the project manager for the 5334B, which was a cost reduced version of the 5334A. I believe there was a third model where the B version was cost reduced from the A version, but I don't remember which one. As a group, these were called the "killer B's" because they would supposedly kill off Racal Dana sales or some silly marketing nonsense to that effect. It's possible that for some obscure reason, a scheme was employed to save money that superficially resembled injection locking. I'm guessing a multifunction chip was used that had a built in oscillator with an external crystal, but no access to the connection from the oscillator output (on the chip) to the downstream circuit. Are you sure that the 5316B actually uses injection locking, rather than having the external reference simply drive the crystal pins on the IC? This would be easy to verify by feeding in an external reference that was say 100 ppm off frequency and seeing if the counter still worked OK. No injection locking scheme AFAIK would ever pull that far. If it actually is true injection locking, the problem is that whether it worked would depend on the relationship between the free running frequency and the external reference frequency, of course. IOW, it might work in some cases and not in others. Rick N6RK ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] HP 5316B External Reference
Hi The “typical” HP counter for many decades has phase locked an internal oscillator to the external reference. I have not seen any designs that use injection locking. Given the somewhat crazy math associated with injection locking, this is not a big surprise. By modern standards the 5316 is not all that fancy. It will give you 7 digits / second. The 5334 / 5335 series (from the 1970’s) will do 9 digits / second. The 53131 / 53132 series ( from the 1980’s) is in the 10 digits / second region. The “modern” 5323x series can add another digit to that. The more modern stuff does this and that to add another digit to the numbers above. The “value” of that added digit has been debated in several (hundred) threads ….. So: Does your GPSDO “help” a 5316? If it’s crazy far out of adjustment, then sure it does. Given it’s lower resolution it will not be “helped” as much as a more modern device. Bob > On Jul 11, 2020, at 6:51 PM, Wes wrote: > > As I understand it this counter has an external reference input that isn't > used directly as the time base but injection locks the internal time base. > Does anyone here know how well this works. Is using a GPSDO as a reference a > worthwhile accuracy improvement? > > Wes Stewart N7WS > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] FTS 4065A schematics?
Time Nuts- Another project - have an FTS 4065A cesium beam reference with what appears to be a short in the -34V supply line. I have the 4065C Operators Guide, which has partial schematics. However, the C version apparently has only a +34V main supply, whereas the A version has both + and -34V. Does anyone have manuals or schematics for the FTS 4065A? Thanks! Jim ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] HP 5316B External Reference
As I understand it this counter has an external reference input that isn't used directly as the time base but injection locks the internal time base. Does anyone here know how well this works. Is using a GPSDO as a reference a worthwhile accuracy improvement? Wes Stewart N7WS ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] PDIP package 100 MHz decade dividers
Hi HC is the *slower* version of AC. If it makes it to 50 MHz, you are doing well ….. Bob > On Jul 11, 2020, at 6:00 PM, Perry Sandeen via time-nuts > wrote: > > Learned List, > On previous posts I was looking for a PDIP package 100 MHz decade divider. > Reading just the front of the data sheet I thought that the 74LS161 would > work. Boy, was I wrong. Several members posted that 25 Mhz max was its limit. > So *on the road again* (sorry Willie) I went on another search this time with > the correct logic family. > It turns out Arrow carries the 74HC161 for less that $1. > Additionally I D/L'd the Charles Wenzel Unusual Frequency Dividers PDF and > discovered a 100 MHz decade divider circuit using 1/2 of a 74HC74 in a > configuration that will decade divide up to 300 MHz. > I'm attaching a copy of the circuit for anyone interested. > Regards, > Perrier > <100 MHz divide by 10.tif>___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] PDIP package 100 MHz decade dividers
The 74XX160/74XX162 is the decade divider that runs at maximum clock rate for the chip. Meaning no external feedback is necessary to make it work at divide by 5/10. The 74XX161/74XX163 can only divide by powers of 2 at maximum clock rate. You have to add feedback to divide by 5 and THAT is what slows it down so much. Dividing by 10 is even slower in most logic families. There is also 74XX190 series. Rick N6RK On 7/11/2020 3:00 PM, Perry Sandeen via time-nuts wrote: Learned List, On previous posts I was looking for a PDIP package 100 MHz decade divider. Reading just the front of the data sheet I thought that the 74LS161 would work. Boy, was I wrong. Several members posted that 25 Mhz max was its limit. So *on the road again* (sorry Willie) I went on another search this time with the correct logic family. It turns out Arrow carries the 74HC161 for less that $1. Additionally I D/L'd the Charles Wenzel Unusual Frequency Dividers PDF and discovered a 100 MHz decade divider circuit using 1/2 of a 74HC74 in a configuration that will decade divide up to 300 MHz. I'm attaching a copy of the circuit for anyone interested. Regards, Perrier ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Raspberry Pi NTP server
Using GPIO with an RPi is a good direction, of course. That wasn't my question. Some data may help explain. Configuration = RPi4 (raspbian buster) Uputronics RPi GPS board (includes PPS) connected to GPIO pins. This is the time of day source for the RPi4. (via GPSD+chrony). Navisys USB GR701 (includes PPS and Integrated serial->USB conversion). Contains integrated Prolific Technology, Inc. PL2303 The observed PPS variation on the Uputronics PPS is a few microseconds. (ppstest was used for measurements). Using a PPS to drive NTP's computer clock disciplining, which is in turn used to measure the same PPS makes for a dubious circular measurement.It is comforting though to see that the variance is in the ~1-3 microsecond range. One must also add Trent's interrupt latency measurement (3 microseconds). With the GPIO connection the RPi time base should be within say 10 microseconds of UTC. The USB-connected Navisys fares worse. [image: image.png] By the time the PPS reaches the OS there is about 1 msec of variance with an average offset of a bit over 0.6 msec. I suspect the 1 msec USB polling is the largest latency contributor, though there are other sources as mentioned by Tim. I'd like to reduce the USB polling contribution by polling at 125 microseconds as the Linux PPS folks suggest (http://linuxpps.org/doku.php/technical_information)Would an FTDI-based USB convertor do the trick? Why bother with GPS/USB? Sometimes I use laptops. Few laptops today directly support PPS/serial. I just checked with Dell and found zero laptops with native RS232. On Fri, Jul 10, 2020 at 2:17 PM Tim S wrote: > I believe the issue is arising from the understanding of "what" is being > interrupted. > > When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO > notice that data is available to be pulled out, for the GPIO it's > notification of a state change (and optionally, a specific state change: > high-low/low-high). > > When a USB PHY trips an interrupt it's to indicate that carrier data is > ready, or for a USB MAC that burst blocks over the link are being decoded. > There is an intermediate step between the USB carrier data being > received/decoded, and being interpreted by the driver as a specific type of > data - and the time that it is made available to the host OS. Because that > is handled in the driver, it is subject to all of the other host OS > interrupts - so timing is not deterministic for the USB driver. > > The differences here are key. > > A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will > be associated with a very precise correlation to an interrupt vs system > tick value. > > A UART time edge (watching the seconds value increment) will be subject to > the rate at which bytes are transferred out of the UART FIFO, then math is > done to detect the second transition edge. > > A USB-to-Serial converter will first encode the bytes and status pin states > into a payload compliant with USB trafic standards, transmit that data to a > USB Host (PHY/MAC) device, which triggers and interrupt for the driver > to decode the data back into meaningful data for the host, then forwards > virtual interrupt triggers to the tasks which are watching the states and > bytes. Everything on the host-side is subject to system overhead, USB > driver optimization, etc. and is thus variable. The host-side backend of > the USB transfer is where your variability is coming from IMHO. > > This is why the recommendation is to use direct (not bridged/adapted) > UART+GPIO from most RPi NTP server projects. The timing is most critical > to the 1PPS edge, so the most direct correlation possible to a tick value > in the OS is the goal. There is nothing saying that the NMEA messages must > have such low latency however - in general they merely must arrive in time > before the next 1PPS, so USB serial is fine for that traffic. > > -Tim > > On Thu, Jul 9, 2020 at 9:00 AM wrote: > > > Message: 4 > > Date: Wed, 8 Jul 2020 15:02:49 -0500 > > From: Steven Sommars > > To: Discussion of precise time and frequency measurement > > > > Subject: Re: [time-nuts] Raspberry Pi NTP server > > Message-ID: > > > atz...@mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > > PL2303, which supports USB 2.0 > > The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > > > > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > > Port > > bInterval 1 > > > > which means 1 msec polling of the PPS signal. I've been unable to poll > > more frequently, that seems to require driver changes. > > Petr, what polling rate do you see?Has anyone been able to poll USB @ > > 125 ?sec on a stock RPi? > > > > With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in > an > > unpredictable pattern.Although the
