Can't get serial (uart) GPS time source to work...

Knight

I forgot to mention that under System > Advanced > Serial Communications > Serial Terminal is not checked so I believe that means that the serial port is not used for the serial console, right?

Thank you!

Nick

JKnott

@knight said in Can't get serial (uart) GPS time source to work...:

serial DB9 cable

Argghhh!!! That's a DE-9, not DB-9!

D - connector type
E - shell size
9 - number of pins

There is no such thing as a "DB-9".

BTW, in one job I had years ago, I used to buy connectors by the hundreds or thousands. If I ordered DB-9s my order would have been rejected. DB-9 is a demonstration of ignorance. Check the industrial supplier (Cannon, Amphenol, etc.) catalogs for more info.

Knight

One more thing...

I connected it to another PC and ran some tools provided by ublox...

It identifies itself as LEA-5T/ublox 5...

Thank you!

Nick

stephenw10

If shows data but is flagged false ticker it's probably just too far offset from other time sources. You probably need to adjust 'Fudge Time 2' in that case.

Steve

Knight

Hi @stephenw10 !

How do I determine that fudge value?

By the way, I tried yet another serial cable today and it temporarily worked but failed again after a reboot...

The device was called .GPS., should it have changed to .PPS. if the PPS (pin 8, CTS on this device) was detected?

Any idea why it works once in a while while connected to the serial port (and always work in USB)?

I thought it could be a conflict with something like the serial console but it seems to be off.

I wish I could add another serial port to be totally sure there is no conflict but there is no slot left and I would have to temporarily remove a NIC which would mess up my NIC assignments...

I also noticed I have this in my logs

Jul 12 12:22:32 ntpd 77100 GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
Jul 12 12:22:32 ntpd 77100 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Jul 12 12:22:32 ntpd 77100 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

Any idea which clock this is referring to?

Thank you and have a nice day!

Nick

stephenw10

I currently have it set at 0.50 for a USB connected GPS but it is very variable. That is +500ms which brings it into line with the external ntp servers it can see:

[21.05-RELEASE][admin@fw1.stevew.lan]/root: ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l    8   16  377    0.000   -1.908   1.241
 0.pfsense.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.001
+time.cloudflare 10.21.8.19       3 u   20   64  377    5.601   +9.997   0.563
+ntp0.rrze.uni-e .GPS.            1 u   57   64  367   22.510  +12.468   0.662
-ns2.posiona.net 192.36.143.150   2 u   35   64  377   51.940  +12.865   1.415

It could use another 10ms right now but there is too much variation to get that accurate. It's close enough for ntpd to accept it.

Steve

Knight

Hi @stephenw10

I was able to get the device to work but not with 1PPS.

I set the appropriate system tunatble to tell it that 1PPS was on CTS as this is where this device is supposed to send it and it did not work.

I am now trying with another serial card but it looks like finding a supported serial card for FreeBSD is very difficult (see my other thread on the subject).

My device still gets detected as false ticker. As PPS does not work I tried playing with "fudge time 2" and set it to 0.500 and it still got detected as false ticker..

I bought a little module meant to be used for a Raspberry PI which works with USB too and I get the same false ticker issue. It can work with serial too but unfortunately TTL levels and I do not have an adapter for this right now...

Thank you and have a nice day!

Nick

stephenw10

You would need an appropriate fudge time for your hardware, 0.5 is just what worked for me.

You need to play with values until you get an offset that is close to the shown remote servers.

PPS only works over serial as you said. Where did you set 'hw.uart.pps_mode' and does the port actually show as set to that after booting?

Steve

Knight

@stephenw10 said in Can't get serial (uart) GPS time source to work...:

You would need an appropriate fudge time for your hardware, 0.5 is just what worked for me.
You need to play with values until you get an offset that is close to the shown remote servers.

Funnily it seems to work best when I set it to 0 with the Raspberry PI module but I can only use it with USB right now at it wants serial at TTL levels and I do not currently have an adapter... It seems to be most of the time active peer and not false ticker.. Those fudge time, what is the unit of them, seconds?

PPS only works over serial as you said. Where did you set 'hw.uart.pps_mode' and does the port actually show as set to that after booting?

System tunables... Maybe I misunderstood but I thought it had to be setted there....

As to confirming, where am I supposed to look?

I see in the logs that it complains about not getting 1PPS but it does not show anywhere where it looks for it... My device puts it on CTS not DCD so I set hw.uart.pps_mode to 0x01... I did not yet switch back to the original NTP device (LEA-5T) connected to the serial port...

(Well actually it is connected to the serial port but to a non-supported by FreeBSD serial card... )

Thank you and have a nice day!

Nick

Knight

stephenw10

Yes, the fudge time is set in seconds but the offset is shown in milliseconds!

That tunable needs to be set as a loader value I believe, so in /boot/loader.conf.local.

You can set the specific port as sysclt (system tunable) though using dev.uart.X.pps_mode.

See: https://www.freebsd.org/cgi/man.cgi?query=uart#Pulse_Per_Second_(PPS)_Timing_Interface

Steve

Knight

@stephenw10 said in Can't get serial (uart) GPS time source to work...:
Hi Stephen!

Yes, the fudge time is set in seconds but the offset is shown in milliseconds!

Ok, thank you!

That tunable needs to be set as a loader value I believe, so in /boot/loader.conf.local.
You can set the specific port as sysclt (system tunable) though using dev.uart.X.pps_mode.

Yikes, I did not notice that the global one could not be set in the system tunables...

It work, well mostly, now..

The "mostly" because I have now this error in the logs, sometimes minutes apart, sometimes almost hours...

I am not sure what it means, what is the cause and if there is anything I could do about it...

By the way, I wonder if it would be doable to have the PPS setting (on CTS, on DCD or nowhere) configurable from the NTP settings page.

Thank you very much Stephen and have a nice day!

Nick

stephenw10

Hmm, not sure why it would be showing that unless it's losing sync maybe?

I expect it to appear as a GPS source though unless you have it configured as PPS only?

Unfortunately my own serial connected GPS seems to have failed so I have nothing to compare it with directly. No time to investigate it.

Steve

Knight

Hi Stephen!

Hmm, not sure why it would be showing that unless it's losing sync maybe?

I guess it is something like that...

I will check if I can find somewhere where I can ask what that message means exactly and what can be done about it...

I do have another device which is originally meant for a raspberry PI but can be used serially if I have the right adapter (it has TTL signaling) which I don't right now... I am quite curious to see if the problem will be present with it once I have the proper adapter.

I expect it to appear as a GPS source though unless you have it configured as PPS only?

No, it configured as a serial GPS, I am not using the PPS configuration. Once I used the port specific system tunable it went from not supporting PPS to supporting it without doing anything else...

It would be nice if the value of that system tunable would be modifiable from the serial GPS settings because that's the only way to get PPS working for a serial GPS I think..

I used the port specific system tunable because I think system tunables get backed up in pfSense backup while modifying loader.conf.local would not have been backed up, am I right?

Unfortunately my own serial connected GPS seems to have failed so I have nothing to compare it with directly. No time to investigate it.

No problem, thank you very much for your help, with your help things went from totally not working to mostly working..

If I find a solution to my latest problem I will let you know..

Thank you!

Nick