Date: Mon, 23 Jul 2018 08:46:16 -0600 From: Ian Lepore <ian@freebsd.org> To: Per olof Ljungmark <peo@nethead.se>, David Cornejo <dave@dogwood.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi3 and Adafruit GPS Hat Message-ID: <1532357176.1344.130.camel@freebsd.org> In-Reply-To: <7a14173c-cc28-6dc7-3787-a5b77a396b30@nethead.se> References: <47f49a55-66b0-1c02-4530-4701a3bd0c43@nethead.se> <20180718170157.GA40221@night.db.net> <ba31ee27-1d17-8616-96b2-b982268f0dc2@nethead.se> <CAFnjQbt395y4xyHEp52GAHW9X9bHvdCAT9q-gKA2--RvQvqTtA@mail.gmail.com> <7a14173c-cc28-6dc7-3787-a5b77a396b30@nethead.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2018-07-23 at 11:40 +0200, Per olof Ljungmark wrote: > On 07/23/18 10:46, David Cornejo wrote: > > > > this might be a little blasphemous, but for grins I tried an Oncore with > > PPS to a GPIO and running the serial through a TTL-USB serial cable and > > that seems to work ok. > > > > there's probably some good reason that this is a bad idea. > Depends on what precision you are after, but for lowest possible jitter > you need to use the uart, the difference is in magnitudes. > Technically that may be correct, but it's meaningless. On a usb 1.x adapter there may be ~500us of jitter from one measurement to the next. On a usb 2.x adapter the jitter drops to typically ~60us. Those values are pretty much in the noise for ntpd, which uses a median filter to smooth any serious jitter out of the measurements. Here are some real-world measurements. The pps source for all 3 inputs is the same gps-disciplined rubidium oscillator, so all the jitter is within the uart, usb hardware, and freebsd drivers. The usb adapters are both FTDI chips, which have a fixed latency on reporting a change on the DCD pin (pin-change status messages are only delivered once a millisecond on ftdi chips). remote refid st t when poll reach delay offset jitter ====================================================================== xPPS(0) .uart. 0 l 6 16 377 0.000 1.097 0.001 xPPS(1) .usb1. 0 l 4 16 377 0.000 -0.051 0.773 oPPS(2) .usb2. 0 l 4 16 377 0.000 -0.001 0.035 *dvb.hippie.lan .GPS. 1 u 12 64 377 1.234 1.296 2.707 +utcnist2.colora .NIST. 1 u 1 64 377 13.605 3.940 2.729 You can see in this case ntpd actually chose the usb2 pps input as the system peer. It did so because at startup the clock offset was closer than the uart, and the difference in jitter between the two wasn't significant, so the ntpd code that prevents clock-hopping chose to stick with the peer with the smaller offset. -- Ian > > > > On Sun, Jul 22, 2018 at 9:09 PM Per olof Ljungmark <peo@nethead.se > > <mailto:peo@nethead.se>> wrote: > > > > On 07/18/18 19:01, Diane Bruce wrote: > > > On Wed, Jul 18, 2018 at 05:10:16PM +0200, Per olof Ljungmark > > wrote: > > >> Being a complete newbie to arm I thought a nice project > > would be to > > >> build a NTP server with the parts in the subject line. > > >> > > >> Unfortunately I have almost no idea where to start, it seems > > FreeBSD for > > >> arm have shifted around quite a bit, almost none of the > > googled > > pages I > > >> find has relevance, and to add insult to injury, the Pi > > project > > >> apparently shifted the serial ports around for the Pi3. > > >> > > >> What I need to achieve, > > >> > > >> - Stop the kernel to use the uart for console output (I have > > ethernet > > >> and HDMI connected) > > > > > > No need. > > > > > > change your config.txt > > > > > > #dtoverlay=pi3-disable-bt > > > device_tree_address=0x4000 > > > kernel=u-boot.bin > > > enable_uart=1 > > > > > > This moves the console port to the less capable micro uart > > port > > > this will free up the good uart (the pl011 device) as > > /dev/ttyu0 > > > > > > Remove the pi3-disable-dt in config.txt > > > enable_uart=1 is needed. > > > > > >> VERY grateful if someone that knows better can give me a > > push in the > > >> right direction for up to date information. > > > .. > > > > > > This is assuming you use FreeBSD-12 (Head of tree) > > > > > > > Yes, 12.0-CURRENT #2 r336461. > > > > Unfortunately your advice did not solve the problem, when the > > hat is > > attached it sends NMEA sequences to the u-boot loader making it > > impossible to boot further, just like it is described in this > > thread: > > > > http://freebsd.1045724.x6.nabble.com/Adding-a-GPS-Module-hat-sh > > ield-on-a-Raspberry-Pi-td6236680.html > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org> > > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org > > <mailto:freebsd-arm-unsubscribe@freebsd.org>" > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1532357176.1344.130.camel>