frequency tolerance: 500

[Udo van den Heuvel]

On 31-03-19 14:43, Achim Gratz via devel wrote:
>> Same as it ever was:
> 
> How are we supposed to know that if you don't say it?

Because I was happy and documented stuff on linuxpps.org.
Because no backups were made there the documentation went missing.

>> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe.
> 
> So is this a USB serial or is it an LVC model and you use a "true"
> RS232C port?

Pover is from USB. The rest is over RS232.
Yes, we use an LVC model.

>  How do you create the necessary PPS device?  

udev.

If you use a
> serial device, have you set it to low_latency?

rc.local

>  I haven't seen one of
> these in person, but I believe the serial port for Ryzen systems is part
> of the SuperIO, not the chipset itself.

We have an RS232 PCIe card.

>> When I switch the GPSses (I have two) the GPS works fine in the other
>> box. So something on this box is hosed and I ruled out wiring, I guess.
>> I reset the GPS configuration, I changed PPS pulse length, etc.
> 
> What's that second system you talk about that seems to work?

The firewall.
ASRock QC5000M-ITX/PH with same gps connected very similarly.
Just not on an RS232 card but one of the serial ports of the ITX.

> versions is responsible).  I suspect you've been relying on some
> defaults which have changed, but that's just a guess.

Sounds reasonable given that the situation is currently normalising
after switchign the clocksource to hpet. (from tsc)

>> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.00000006 time2 0.260 baud 4800
> 
> If you left the default message configuration on, then 4800 baud is way
> too slow.  

4800 works very well when you set it up like this:
$PGRMO,,2*75
$PGRMO,GPRMC,1*3D
$PGRMO,GPGGA,1*20
$PGRMC,A,42.9,100,,,,,,A,3,1,2,9,30*61

Kind regards,
Udo