Re: [time-nuts] Raspberry Pi NTP server
> Is there any way for a USB device to synchronise with the CPU clock (perhaps > via the USB framing) so that a special-purpose device could timestamp the PPS > occurrence with respect to CPU time ? If you were designing a special purpose device, just add a counter to measure the time from the PPS until the CPU reads the info. Suppose you could control the USB timing. Each sample doesn't give you a number, only a yes/no or rather a before/after. It might work if you ask a bit after you expect the PPS and the next second ask a bit before. The question is how small can you make a "bit". -- These are my opinions. I hate spam. ___ 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] Just any counter external reference and discipline mode.
There's a lot of lore out there that, for instance, HP would put
oscillators with good long term stability in counters, but for things
like a spectrum analyzer or signal generator, you'd use an oscillator
with good close in phase noise, because absolute frequency accuracy
isn't as important, but ability to make close in measurements with high
dynamic range is.
Yes, some validity to that. Santa Clara Division's overriding
constraint was to make sure that every oscillator could find a home.
The counters were synergistic with the RF instruments in that sense.
Another issue was that they didn't want to use a lot of resources
to do production testing. Finally, as a captive supplier, SCD
was not allowed to charge extra $ for specially selected oscillators.
I would also not make any assumptions about continuity of design,
especially when it changes from an all analog to a DDS based design. A
synthesizer using analog synthesis with PLLs would smoothly sweep, while
a DDS design typically goes in discrete steps (unless specifically
designed for smooth sweeps), and may or may not be phase continuous
across steps.
There are a lot of quirks about continuity of design. In general,
the microwave divisions in Santa Rosa wanted to keep the "platform"
and architecture the same and update products by making newer
blocks that did the same function as older ones. Then there was
the permanent magnet YIG tuned oscillator (PMYTO) ("because we can"
since we make our own YTO's). This kept showing up in new products long
past its "best by" date. A fixed frequency 2nd LO using a microwave
cavity for the tank circuit initially used in 1968 was still being
designed in in the 2000's. The YTO kind of spoiled HP with its
effortless smooth phase continuous sweeps.
Around 2000, when I was working for Agilent Labs, I got assigned to
a committee to study replacements for the YTO. The problem was
that they wanted a drop in replacement, rather than a new architecture
that was not designed around the YTO. I was happy to be paid to
attend meetings, but in the end I don't think we accomplished
anything. We didn't even kill off the PMYTO of all things.
There is a lot of inertia, especially when people's jobs depend
on nothing changing.
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] Raspberry Pi NTP server
Is there any way for a USB device to synchronise with the CPU clock (perhaps via the USB framing) so that a special-purpose device could timestamp the PPS occurrence with respect to CPU time ? On Mon, Jul 13, 2020 at 9:51 PM Trent Piepho wrote: > On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra wrote: > > > > All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means > > they are polled only once in 1ms and there is no way how to change it > > (poll rate is selected at hardware level). > > Looking at the UHCI specification, for USB 1.1 HCIs, while there poll > rate is fixed at about 1 ms, it is possible to tweak it slightly via > the start of frame modify register. > > If one is measuring a PPS, then the pulses are not random. It's > possible to try to align the USB frames with the PPS and do quite a > bit better than just a 1 msec poll rate would do at random. Certainly > would be hard to fit this into the software stack. And I don't see > this ability in the EHCI spec, though I'm certainly no expert with USB > HCI drivers, so perhaps it's gone now because no one could figure out > how to use it. > > ___ > 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] EEG TS RFS Rubidium
It is taken In a message dated 7/13/2020 4:56:05 PM Eastern Standard Time, time-nuts@lists.febo.com writes: I was given a working with new capacitors EEG TS RFS. Have no use for it but if some one wants it for the cost of shipping be glad to send it . Off list please. I opened it up, impressed with the optical unit, has any one analysed it, with EEG space history is it more than what we find in Telecom units?Bert Kehren___time-nuts mailing list -- time-n...@lists.febo.comTo unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.comand 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] Just any counter external reference and discipline mode.
I have an 8640B in the lab. Bizarre instrument. David On 7/13/20 2:57 PM, Richard (Rick) Karlquist wrote: On 7/13/2020 11:34 AM, jimlux wrote: There are also "frequency locked" devices that are not "phase locked" - they essentially discipline an internal oscillator by adjusting its frequency, but not with any sort of phase locked loop. The 8640 famously worked (sort of) this way. The cavity had an extremely limited electronic tuning range, and would only stay in lock for a few minutes before drifting off. It would do this even if you left it on 24/7. The display would then flash, and you had to release the lock button, retune the frequency using the mechanical cavity know, and then push the lock button back in. Are you kidding me? Definitely in the "gee whiz", "because we can", or "too clever by half" category. At least they didn't have the chutzpah to charge $ for this as an optional "feature". The Navy, recognizing that this was not sailor proof, had the feature/bug omitted from the military version. Good for them. Rick ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.febo.com%2Fmailman%2Flistinfo%2Ftime-nuts_lists.febo.comdata=02%7C01%7Cdavid.g.mcgaw%40dartmouth.edu%7C9afb4f70d6bc4b0ad52508d8275fd4c3%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637302639872214633sdata=hktXOKkryvi2YDC3YulE4RNXZDaeHyA87SkCcHN5ekU%3Dreserved=0 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] EEG TS RFS Rubidium
I was given a working with new capacitors EEG TS RFS. Have no use for it but if some one wants it for the cost of shipping be glad to send it . Off list please. I opened it up, impressed with the optical unit, has any one analysed it, with EEG space history is it more than what we find in Telecom units? Bert Kehren ___ 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 Mon, Jul 13, 2020 at 8:54 AM Petr Titěra wrote: > > All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means > they are polled only once in 1ms and there is no way how to change it > (poll rate is selected at hardware level). Looking at the UHCI specification, for USB 1.1 HCIs, while there poll rate is fixed at about 1 ms, it is possible to tweak it slightly via the start of frame modify register. If one is measuring a PPS, then the pulses are not random. It's possible to try to align the USB frames with the PPS and do quite a bit better than just a 1 msec poll rate would do at random. Certainly would be hard to fit this into the software stack. And I don't see this ability in the EHCI spec, though I'm certainly no expert with USB HCI drivers, so perhaps it's gone now because no one could figure out how to use it. ___ 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
Petr, Is the variance plot based on PPS timestamps, or on NTP's smoothing of the timestamps? Have you measured the offset? On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra wrote: > On 12.07.2020 3:57, jimlux wrote: > > 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. > > > > I beg to differ. With correct USB convertor I achieve sub millisecond > variance (see attached screenshot fro FTDI232RL chip). I get similar > results on other computers too. > > All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means > they are polled only once in 1ms and there is no way how to change it > (poll rate is selected at hardware level). > > Petr Titera > > > 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 > >
Re: [time-nuts] Just any counter external reference and discipline mode.
On 7/13/20 11:27 AM, paul swed wrote: Taka I firmly believe the first answer to your question is cost. Was the counter an economical unit or higher quality. My 5335 counters have seriously cheap xtal clocks and an external reference makes a big difference. But the larger costly generators and counters seem to use the phase lock approach. I suspect it also filters the reference input. Regards Paul WB8TSL There's a lot of lore out there that, for instance, HP would put oscillators with good long term stability in counters, but for things like a spectrum analyzer or signal generator, you'd use an oscillator with good close in phase noise, because absolute frequency accuracy isn't as important, but ability to make close in measurements with high dynamic range is. I would also not make any assumptions about continuity of design, especially when it changes from an all analog to a DDS based design. A synthesizer using analog synthesis with PLLs would smoothly sweep, while a DDS design typically goes in discrete steps (unless specifically designed for smooth sweeps), and may or may not be phase continuous across steps. ___ 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] Just any counter external reference and discipline mode.
On 7/13/2020 11:34 AM, jimlux wrote: There are also "frequency locked" devices that are not "phase locked" - they essentially discipline an internal oscillator by adjusting its frequency, but not with any sort of phase locked loop. The 8640 famously worked (sort of) this way. The cavity had an extremely limited electronic tuning range, and would only stay in lock for a few minutes before drifting off. It would do this even if you left it on 24/7. The display would then flash, and you had to release the lock button, retune the frequency using the mechanical cavity know, and then push the lock button back in. Are you kidding me? Definitely in the "gee whiz", "because we can", or "too clever by half" category. At least they didn't have the chutzpah to charge $ for this as an optional "feature". The Navy, recognizing that this was not sailor proof, had the feature/bug omitted from the military version. Good for them. Rick ___ 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] Just any counter external reference and discipline mode.
Good question; answer is not so simple. Here goes: Signal generators and spectrum analyzers have to have a low phase noise oscillator inside to be able to generate/detect spectrally pure signals. Unlike counters, the 10811, etc has to be standard equipment, not an option. Therefore, in order to make the product "customer proof" (or "sailor proof" if the Navy is the customer), they do not allow the customer to supply has own noisy external reference. Instead, they lock the high quality internal reference to the customer's external reference ... with a VERY SLOW phase locked loop. An additional insurance policy that goes along with this is that this scheme limits how far off of 10 MHz the external reference can go. The internal workings of the product may include PLVCXO's etc that don't have much frequency agility, such as the optional 640 MHz SAW oscillator in the 8662A. Now for something completely different: Counters, OTOH, ship with an oscillator that is basically a 99 cent clock oscillator like your computer has. There are many applications where all you need is what we call "indication only" (AKA sanity check) where this cheap oscillator is fine. The other end of the spectrum was exemplified by the HP Santa Clara Division itself. We had a high performance HP Cs standard compared to Loran or later GPS that was distributed around the plant. We would plug this external reference into the counter and make 12 digit measurements. Spectral purity wasn't so critical for a counter, just to get the frequency right. Also, the counter worked perfectly well if you put in 10.001 MHz etc, it just scaled everything. There were various reasons why you might want to do this. Customers without a house standard, but with high accuracy demands had to pony up the $ for the OCXO option. IMHO, this "different strokes for different folks" made a lot of sense. Also, each division was autonomous, so there was no way to force all the divisions to do external reference one "corporate" way. That wasn't what the "HP way" was about. On 7/13/2020 9:58 AM, Taka Kamiya via time-nuts wrote: I'm sorry to interject a newbie question I changed the title to distinguish from rest of the conversation. At least for me, the general public, circuit diagram is not made available for later models. I have no way to tell for sure what is being done inside. --- (Mr.) Taka Kamiya KB4EMF / ex JF2DKG Before I got a job at HP in 1979, the manuals did have circuit diagrams. I used to read them like text books. I would often open up HP instruments to discover details not covered in the manual. I reverse engineered them, and even modified them. Another good resource was HP Journal. That is what inspired me to apply for a job there. Once there, I could talk to the actual engineer who designed the thing. Amazing! Also, at HP, I discovered why the screws always cammed out: "Pozidrive". Never heard of it before. Who knew? 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] Just any counter external reference and discipline mode.
On 7/13/20 9:58 AM, Taka Kamiya via time-nuts wrote: I'm sorry to interject a newbie question I changed the title to distinguish from rest of the conversation. I have heard this both ways about external references - whether it's used to phase lock internal source and used directly after some conditioning. Both come from people on this list I trust. Limiting discussion to HP counters from 70s to 90s, which is the truth? Were there exceptions? If so, why? (I'm not interested in injection locking) If some are phase locking, what does it phase lock? Most counters have options on internal reference (ie. HP53132A has standard, mid performance, high performance, and ultra performance) Does it phase lock the standard that's always there? Or try to phase lock optional reference? I really don't see the need for phase locking, as only critical element is rise time - so rather, signal conditioning makes sense. At least for me, the general public, circuit diagram is not made available for later models. I have no way to tell for sure what is being done inside. - There are also "frequency locked" devices that are not "phase locked" - they essentially discipline an internal oscillator by adjusting its frequency, but not with any sort of phase locked loop. The 33600 series function generators from Agilent/Keysight are in this bucket. You can feed in a 10 MHz source and they'll (after a fairly short time, a few seconds) produce a 10 MHz output that is "right on frequency", but it won't have a predictable phase relationship with the external reference. ___ 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] Just any counter external reference and discipline mode.
Taka I firmly believe the first answer to your question is cost. Was the counter an economical unit or higher quality. My 5335 counters have seriously cheap xtal clocks and an external reference makes a big difference. But the larger costly generators and counters seem to use the phase lock approach. I suspect it also filters the reference input. Regards Paul WB8TSL On Mon, Jul 13, 2020 at 2:07 PM Taka Kamiya via time-nuts < time-nuts@lists.febo.com> wrote: > I'm sorry to interject a newbie question I changed the title to > distinguish from rest of the conversation. > > I have heard this both ways about external references - whether it's used > to phase lock internal source and used directly after some conditioning. > Both come from people on this list I trust. Limiting discussion to HP > counters from 70s to 90s, which is the truth? Were there exceptions? If > so, why? (I'm not interested in injection locking) > If some are phase locking, what does it phase lock? Most counters have > options on internal reference (ie. HP53132A has standard, mid performance, > high performance, and ultra performance) Does it phase lock the standard > that's always there? Or try to phase lock optional reference? I really > don't see the need for phase locking, as only critical element is rise time > - so rather, signal conditioning makes sense. > > At least for me, the general public, circuit diagram is not made available > for later models. I have no way to tell for sure what is being done inside. > > --- > (Mr.) Taka Kamiya > KB4EMF / ex JF2DKG > > > On Monday, July 13, 2020, 12:39:53 PM EDT, jimlux < > jim...@earthlink.net> wrote: > > On 7/13/20 9:02 AM, Richard (Rick) Karlquist wrote: > > > > > > On 7/13/2020 6:26 AM, Wes wrote: > >> Hi Magnus, > >> > >> I did have the manual when I posed the original question but I had not > >> delved into the cal procedure until you mentioned it. It seems to be > >> a bit complicated for what it does. I wonder how stable this is and > >> how often might it need to be repeated. Why they didn't use the > >> external reference more directly is a puzzle. > >> > >> I appreciate your time in looking into this. > >> > >> Regards, > >> > >> Wes > >> > >> > > > > I don't know the specific engineer who designed this injection > > locking scheme, but IMHO it's a "too clever by half" sort of > > thing (and that's being charitable). Unfortunately, I encountered many > > examples of that in the 5334A, and other counters. I took out around > > a dozen of these "clever" circuits in the process of replacing the > > 5334A with the 5334B. The engineers involved were outside their > > lane as the saying goes; I actually talked to them about why they > > designed the circuit in that way. Didn't have a valid reason IMHO. > > Just having been in that environment, I would be distrustful of the 5316 > > design for anything important application like time nuts work. > > Actually, I would be distrustful of any injection locking multiplier no > > matter who designed it. Unfortunately, you can't conclude that > > a design is good simply because it came out of HP. In some ways, > > it was disillusioning to go to work for HP and see what is > > really going on. > > > > The same is true of NASA (and probably any big organization). > > In most cases, there's not some rigorous process to choose the "best" > design, often it's "the first design that works" that is selected. > > Subsequent revisions will sometimes purge "clever but non-robust" > solutions. Technology advances will also make "couldn't work 10 years > ago, but works now" changes, although there are plenty of examples which > "let's do it that way, because if we change it, we have to spend time > explaining why" > > > ___ > 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 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] Just any counter external reference and discipline mode.
I'm sorry to interject a newbie question I changed the title to distinguish from rest of the conversation. I have heard this both ways about external references - whether it's used to phase lock internal source and used directly after some conditioning. Both come from people on this list I trust. Limiting discussion to HP counters from 70s to 90s, which is the truth? Were there exceptions? If so, why? (I'm not interested in injection locking) If some are phase locking, what does it phase lock? Most counters have options on internal reference (ie. HP53132A has standard, mid performance, high performance, and ultra performance) Does it phase lock the standard that's always there? Or try to phase lock optional reference? I really don't see the need for phase locking, as only critical element is rise time - so rather, signal conditioning makes sense. At least for me, the general public, circuit diagram is not made available for later models. I have no way to tell for sure what is being done inside. --- (Mr.) Taka Kamiya KB4EMF / ex JF2DKG On Monday, July 13, 2020, 12:39:53 PM EDT, jimlux wrote: On 7/13/20 9:02 AM, Richard (Rick) Karlquist wrote: > > > On 7/13/2020 6:26 AM, Wes wrote: >> Hi Magnus, >> >> I did have the manual when I posed the original question but I had not >> delved into the cal procedure until you mentioned it. It seems to be >> a bit complicated for what it does. I wonder how stable this is and >> how often might it need to be repeated. Why they didn't use the >> external reference more directly is a puzzle. >> >> I appreciate your time in looking into this. >> >> Regards, >> >> Wes >> >> > > I don't know the specific engineer who designed this injection > locking scheme, but IMHO it's a "too clever by half" sort of > thing (and that's being charitable). Unfortunately, I encountered many > examples of that in the 5334A, and other counters. I took out around > a dozen of these "clever" circuits in the process of replacing the > 5334A with the 5334B. The engineers involved were outside their > lane as the saying goes; I actually talked to them about why they > designed the circuit in that way. Didn't have a valid reason IMHO. > Just having been in that environment, I would be distrustful of the 5316 > design for anything important application like time nuts work. > Actually, I would be distrustful of any injection locking multiplier no > matter who designed it. Unfortunately, you can't conclude that > a design is good simply because it came out of HP. In some ways, > it was disillusioning to go to work for HP and see what is > really going on. > The same is true of NASA (and probably any big organization). In most cases, there's not some rigorous process to choose the "best" design, often it's "the first design that works" that is selected. Subsequent revisions will sometimes purge "clever but non-robust" solutions. Technology advances will also make "couldn't work 10 years ago, but works now" changes, although there are plenty of examples which "let's do it that way, because if we change it, we have to spend time explaining why" ___ 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
On 7/13/2020 9:46 AM, Wes wrote: Thanks again for your insight Rick. I'll be passing on acquiring one of these. Wes N7WS I'm so glad you asked before buying. I hate having to tell something they wasted their money. Rick ___ 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 again for your insight Rick. I'll be passing on acquiring one of these. Wes N7WS On 7/13/2020 9:02 AM, Richard (Rick) Karlquist wrote: On 7/13/2020 6:26 AM, Wes wrote: Hi Magnus, I did have the manual when I posed the original question but I had not delved into the cal procedure until you mentioned it. It seems to be a bit complicated for what it does. I wonder how stable this is and how often might it need to be repeated. Why they didn't use the external reference more directly is a puzzle. I appreciate your time in looking into this. Regards, Wes I don't know the specific engineer who designed this injection locking scheme, but IMHO it's a "too clever by half" sort of thing (and that's being charitable). Unfortunately, I encountered many examples of that in the 5334A, and other counters. I took out around a dozen of these "clever" circuits in the process of replacing the 5334A with the 5334B. The engineers involved were outside their lane as the saying goes; I actually talked to them about why they designed the circuit in that way. Didn't have a valid reason IMHO. Just having been in that environment, I would be distrustful of the 5316 design for anything important application like time nuts work. Actually, I would be distrustful of any injection locking multiplier no matter who designed it. Unfortunately, you can't conclude that a design is good simply because it came out of HP. In some ways, it was disillusioning to go to work for HP and see what is really going on. 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
On 7/13/20 9:02 AM, Richard (Rick) Karlquist wrote: On 7/13/2020 6:26 AM, Wes wrote: Hi Magnus, I did have the manual when I posed the original question but I had not delved into the cal procedure until you mentioned it. It seems to be a bit complicated for what it does. I wonder how stable this is and how often might it need to be repeated. Why they didn't use the external reference more directly is a puzzle. I appreciate your time in looking into this. Regards, Wes I don't know the specific engineer who designed this injection locking scheme, but IMHO it's a "too clever by half" sort of thing (and that's being charitable). Unfortunately, I encountered many examples of that in the 5334A, and other counters. I took out around a dozen of these "clever" circuits in the process of replacing the 5334A with the 5334B. The engineers involved were outside their lane as the saying goes; I actually talked to them about why they designed the circuit in that way. Didn't have a valid reason IMHO. Just having been in that environment, I would be distrustful of the 5316 design for anything important application like time nuts work. Actually, I would be distrustful of any injection locking multiplier no matter who designed it. Unfortunately, you can't conclude that a design is good simply because it came out of HP. In some ways, it was disillusioning to go to work for HP and see what is really going on. The same is true of NASA (and probably any big organization). In most cases, there's not some rigorous process to choose the "best" design, often it's "the first design that works" that is selected. Subsequent revisions will sometimes purge "clever but non-robust" solutions. Technology advances will also make "couldn't work 10 years ago, but works now" changes, although there are plenty of examples which "let's do it that way, because if we change it, we have to spend time explaining why" ___ 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/13/2020 6:26 AM, Wes wrote: Hi Magnus, I did have the manual when I posed the original question but I had not delved into the cal procedure until you mentioned it. It seems to be a bit complicated for what it does. I wonder how stable this is and how often might it need to be repeated. Why they didn't use the external reference more directly is a puzzle. I appreciate your time in looking into this. Regards, Wes I don't know the specific engineer who designed this injection locking scheme, but IMHO it's a "too clever by half" sort of thing (and that's being charitable). Unfortunately, I encountered many examples of that in the 5334A, and other counters. I took out around a dozen of these "clever" circuits in the process of replacing the 5334A with the 5334B. The engineers involved were outside their lane as the saying goes; I actually talked to them about why they designed the circuit in that way. Didn't have a valid reason IMHO. Just having been in that environment, I would be distrustful of the 5316 design for anything important application like time nuts work. Actually, I would be distrustful of any injection locking multiplier no matter who designed it. Unfortunately, you can't conclude that a design is good simply because it came out of HP. In some ways, it was disillusioning to go to work for HP and see what is really going on. 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] Raspberry Pi NTP server
On 12.07.2020 3:57, jimlux wrote: 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. I beg to differ. With correct USB convertor I achieve sub millisecond variance (see attached screenshot fro FTDI232RL chip). I get similar results on other computers too. All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means they are polled only once in 1ms and there is no way how to change it (poll rate is selected at hardware level). Petr Titera 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. ___ time-nuts mailing list --
Re: [time-nuts] Raspberry Pi NTP server
On Sun, Jul 12, 2020 at 11:51 AM jimlux wrote: > > Is the PPS via USB CTS stamped at interrupt time? or is it stamped > higher up in the stack? > > I started tracing this out, but then decided I'm not going to be writing > Linux USB drivers any time soon, so gave it up. > > I could easily imagine that the interrupt comes in, marks a thread as > "ready to run" and the "oh CTS has changed state" is detected at a > higher level. Best way to see this is to do live tracing. Use perf to turn on event captures with IRQs, context switches, PPS events, USB events. Then in something like Trace Compass you can see the timeline of what is actually happening. The hard IRQ context first, then maybe a context switch into a kernel thread that was made runnable by an action of the irq handler. ___ 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.
