Re: [time-nuts] Raspberry Pi NTP server
On Freitag, 3. Juli 2020 19:44:48 CEST Hal Murray wrote: > andrew.hanc...@cyrus-consultants.co.uk said: > > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same > > module) but using a FT232RL, and connected all the pins correctly, and DCD > > so I can get PPS. > > FT232R is a USB chip. Timing over USB is "interesting". Do you know about > hanging bridges? > > Can you get a wire in to the GPIO pin the HAT used? That would be an > interesting experiment. > > There may be a parameter you can tweak, but I can't think of the name right > now. Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a Beaglebone Black instead. It is the much better platform for timekeeping experiments. Firstly, it has capture-mode timers that will give much more stable timestamps for the 1PPS kernel interface. Secondly, you can drive these timers from an external clock source. That clock source can be a GPSDO. That means, you can hook up the timer input clock to the 10MHz GPSDO output and at the same time use it for timestamping the GPSDO 1PPS pulses. Plus, this timer can be the "wall clock" for the Linux system, resulting in a zero-drift system time. Combine that with gpsd and you have a stratum-1 time source. Thirdly, the ethernet mac is on chip and it supports hardware timestamps. This means, not only NTP but also PTPv2 is possible. BR, Matthias ___ 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
From: Matthias Welwarsky [] Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a Beaglebone Black instead. It is the much better platform for timekeeping experiments. Firstly, it has capture-mode timers that will give much more stable timestamps for the 1PPS kernel interface. Secondly, you can drive these timers from an external clock source. That clock source can be a GPSDO. That means, you can hook up the timer input clock to the 10MHz GPSDO output and at the same time use it for timestamping the GPSDO 1PPS pulses. Plus, this timer can be the "wall clock" for the Linux system, resulting in a zero-drift system time. Combine that with gpsd and you have a stratum-1 time source. Thirdly, the ethernet mac is on chip and it supports hardware timestamps. This means, not only NTP but also PTPv2 is possible. BR, Matthias === ... and it has much less general support ... and it generates more RF interference ... and it costs money as the OP already has the Raspberry Pi Neither make for "precision" sources. I've yet to see a comparison between the BeagleBone and a Raspberry Pi 4. I did make a comparison earlier which showed the BBB to be better, yes, but certainly not enough for me to change given the other factors. 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] Raspberry Pi NTP server
On Samstag, 4. Juli 2020 11:30:01 CEST David J Taylor via time-nuts wrote: > From: Matthias Welwarsky > [] > Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a > Beaglebone Black instead. It is the much better platform for timekeeping > experiments. [snip] > BR, > Matthias > === > > ... and it has much less general support > ... and it generates more RF interference > ... and it costs money as the OP already has the Raspberry Pi > > Neither make for "precision" sources. I've yet to see a comparison between > the BeagleBone and a Raspberry Pi 4. I did make a comparison earlier which > showed the BBB to be better, yes, but certainly not enough for me to change > given the other factors. David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias > > Cheers, > David ___ 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/4/20 2:30 AM, David J Taylor via time-nuts wrote: ... and it has much less general support ... and it generates more RF interference ... and it costs money as the OP already has the Raspberry Pi I have both Pis and BB Blacks and Greens and Green wireless. I'm interested in the RF interference aspect - is that documented anywhere? Yeah, I'm sure both meet the respective Part 15 for WiFi transmitters (if they have a WiFi interface on board) - but I've not seen any substantive measurement data for general RFI. And given COVID telework, I can't just run down to the screen room with them and a spectrum analyzer. ___ 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
David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias === Matthias, my feeling is that if you want a precision source, neither BB not the RPi is a good solution. Maybe with all the tweak you mentioned the BB approaches precision (for some values of precision). I see the RPi as something which can provide far better NTP than simply using an Internet source, something which will be adequate for the majority of users (for some types of user!). The RPi 4 doesn't have E/net over USB hence my comment on seeing a comparison. The RF interference is to other parts of the spectrum - not specifically 1.5 GHz GPS - and has been documented. I noticed it on either 145 or 435 MHz bands when testing. [Jim] Whether anyone has bothered to do proper measurements I doubt. 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] FW: HP-5372A operation with no CRT display.
Ed: I see what appear to be good voltages from the mothor board into the A17 video driver board, that is Gnd, +12VDC, V Sync, HSync, and video (Intensity) Have a possibly good A17 board, on the bench along with a CRT, removed from instrument. Am testing voltages, waveforms, and Electrolytic Cap values for base line. It functions with just +12V drive from bench supply. I have a raster scan that varies in intensity with voltage level (0-5v) applied to video input. Have two more (not good) boards, with some known bad caps, that then can then be repaired to the baseline.Will then try A17 and CRT on the 5372A itself. Lester B Veenstra K1YCM MØYCM W8YCM 6Y6Y les...@veenstras.com 452 Stable Ln (HC84 RFD USPS Mail) Keyser WV 26726 GPS: 39.336826 N 78.982287 W (Google) GPS: 39.33682 N 78.9823741 W (GPSDO) Telephones: Home: +1-304-289-6057 US cell +1-304-790-9192 Jamaica cell: +1-876-456-8898 -Original Message- From: time-nuts [mailto:time-nuts-boun...@lists.febo.com] On Behalf Of ed breya Sent: Tuesday, June 30, 2020 4:40 PM To: time-nuts@lists.febo.com Subject: Re: [time-nuts] FW: HP-5372A operation with no CRT display. Looking back at the OP, it appears the display is at least partially working, since there is some HV to light a dim spot on screen. I don't know what this display looks like inside, but imagine it's one or two small boards mounted open-frame on the CRT mechanical assembly, and connected to the instrument by one or two cable/connector assemblies. It should be possible to remove the whole thing onto a bench, and run it out in the open for better access. The first thing to do is close inspection, looking for any obvious problems like puffy or leaky capacitors and burnt parts, loose/broken connections, and possibly fuses open. Power supply problems are the most likely culprits, so if you can figure out the internal power distribution at least somewhat, you can make some measurements. These kind of units likely run on a single bulk supply at a standard voltage like +12 (most likely since most magnetic raster CRTs use 12V heaters) or +24, and you should be able to find out from the schematics for the rest of the system. Are the signals in the interconnections labeled? If so, the power should be identified, and also try to figure out what each signal is supposed to do. You already know the sync and video, etc, but also look for anything else like an enable or standby signal. What I'm getting at here is that depending on the overall supply architecture, when the 5372A is in standby (keeping the OCXO on) it could be that a lot of stuff is actually powered, but disabled. Related to this, is there a GPIB or other command that can turn off the display and lock out the front panel when in remote-only mode? If there is some form of on/off provision, a signal failure here could shut it down even if the rest is OK. There are lots of possibilities, but it narrows it down a lot if you can proof the supplies and external controls. Ed ___ 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/4/20 7:49 AM, David J Taylor via time-nuts wrote: David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias === Matthias, my feeling is that if you want a precision source, neither BB not the RPi is a good solution. Maybe with all the tweak you mentioned the BB approaches precision (for some values of precision). I see the RPi as something which can provide far better NTP than simply using an Internet source, something which will be adequate for the majority of users (for some types of user!). The RPi 4 doesn't have E/net over USB hence my comment on seeing a comparison. The RF interference is to other parts of the spectrum - not specifically 1.5 GHz GPS - and has been documented. I noticed it on either 145 or 435 MHz bands when testing. [Jim] Whether anyone has bothered to do proper measurements I doubt. I was wondering more about non-GPS band interference.. And whether anything was hooked up to it. I've got some RTL-SDRs here, and I've connected them both to an older RPi and some BBs, and with a whip antenna about a meter away, I've not noticed a huge difference between them, in a sort of casual way. They're both noisy, but then, I don't know if it's the environment, or other stuff hooked up to them (Ethernet or USB cables, or the USB power supply). I wouldn't expect them to be hugely different from an RFI standpoint as bare boards with nothing else connected. It's stuff that's connected is more likely the source, by conduction from the board then radiation from the wires. That's why I was asking about the details. ___ 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.
