rpi3 and Adafruit GPS Hat

[Ralph Smith]

Sent from my iPhone

> On Jul 23, 2018, at 11:24 AM, Ian Lepore <ian at freebsd.org> wrote:
> 
>> 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.

Not using the stock uboot, you will need to modify it. I have this working on 12-CURRENT for the Pi 2, I haven’t tried it on the Pi 3. I documented how I modified u-boot for 11-STABLE in https://docs.freebsd.org/cgi/getmsg.cgi?fetch=188164+0+archive/2018/freebsd-arm/20180204.freebsd-arm, this should apply to the current u-boot port as well. You will also meet to modify the DTB so the system doesn’t send console output to the uart as well. 

Ralph