rpi3 and Adafruit GPS Hat

[Ian Lepore]

On Mon, 2018-07-23 at 17:20 +0200, Per olof Ljungmark wrote:
> On 07/23/18 16:46, Ian Lepore wrote:
> > 
> > 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.
> > 
> Yes, I was technically correct but of course you are right too -
> however, the main problem is not the jitter but rather that I am unable
> to switch off the serial console and stop the u-boot loader from
> receiving NMEA data. The Adafruit GPS Hat is made to sit right on the Pi
> 40-pin header, as you probably know.
> 
> To quote one of the posters in the thread I linked to:
> "... I am seriously baffled by how difficult (nearly impossible) it had
> been to get rid of the serial console..."
> 
> Unfortunately I am not fluid enough to figure out where to make the
> changes, the advices I've seen so far is not applicable to 12-CURRENT in
> an easy way.
> 
> And that is also why I wrote bugreport 229976. It may be that all the
> folks involved with FreeBSD/ARM are serious developers so they do not
> see it as a problem but for me it is, being more on the
> application/administration side of things.
> 
> Thanks,
> 
> //per
> 

Unfortunately, I can't help with the rpi part of this, since it's
related to the firmware and uboot, and that part of the rpi world has
changed drastically since I was involved with it years ago. I know you
can build a custom uboot that disables serial console support
completely, but I don't know if there's a way to achieve that with the
stock uboot.

-- Ian