I checked the polling as default and it sets GPS and PPS on 4.
As for the 5Hz LVC, I’m going to re-solder the plugs as it won’t give me data.
Or it’s broken. Tested everything but nothing.
However, I’m testing the U-blox against the Garmin 1Hz LVC the U-blox is at about 5200ns Dev, but the Garmin is at 2789ns. Same location, no clear sky and indoor.
So I believe the Garmin simply has a better antenna.
Tracking shows root disp about 20000 Garmin and 33000 for the U-blox, it wobbles a bit.
So yes, the quality of the GPS matters, not the number of satellites it can see.
The U-blox sees 35 but uses only 10. Garmin 12 over 10.
TDOP 1.05 U-blox / Garmin 0.99
ALT error on U-blox about 4m / Garmin 101m
3D error U-blox 36.7m / 98m
So I believe the Garmin is better, maybe a better internal oscillator and better antenna.
It’s location precision is worse, but we don’t use that.
It also shows on my server page…wow, that is remarkable:
You do know that internet routers and connections themselves have 1msec delay?
Some faster, some slower.
See here, I’m the :50 guy…
Then look at Frequency calculated to real NTP-time, Chrony will counter the offset when it can.
I see there that’s doing pretty well compared to some others. My clock error often being lower then e.g. ESA timeserver
Also beware monitors are within a resolution too to be accepted. But their job is ONLY to check if a server is online and if it ticks within limites to count as a solid ticker.
The monitors are NOT atomic-clocks. You can not assume they are, as such you can not use their data to check accuracy. I do not know what is valid, but it could be 5ms or better.
PPS does not know time by itself. It requires other sources for time data or the NMEA messages. All PPS does is sync the time data. The NMEA message from the Garmin are offset from the PPS pulse. Your PPS could be offset from true time tic due to many factors (DCD/CTS/GPIO latency, electrical delays, cable capacitance affecting the slope of the PPS signal, etc.). You might have to tweak the PPS offset to accommodate.
Garmin does output Binary by default when run via GPSD, not NMEA.
Because it’s RS232 is time-stamped by the kernel (as far as I know), this means that the kernel stamped it as soon as the IRQ of RS-232 was given.
Normally this is a few ns. All other stuff doesn’t matter, as Chrony can work out the delay.
The other time is the GPS time, that is 1ms off, doesn’t matter as it’s locked to PPS.
So Chrony knows the exact time.
Why are you trying to explain something I already know?
As far as I know, the Kernel timestamps DCD-pulse, all delay’s after that do not matter.
As you can see in Chrony telling the offset being 0ns.
All this is local. Got nothing to do with what you show me. I do not need to tweak PPS.
The cable is 5m, as lightspeed it’s impossible to adjust. The timestamp is the fastes it can do on an PPS-pulse.
Are you a real person? As everybody in here knows you need to lock GPS+PPS in Chrony. Has been discussed many times.
Hey guys chill out.
We are all time-nuts and working towards the same goal
Some started this journey a long time ago, others not so long ago.
And then there’s different personalities and communication strategies, lol.
Sry. I did not know you are the man who knows all, beats all, and rest of us all need to bow down and worship the [redacted] ground you walk on. It’s condensing people like yourself you make any community forum participation intolerable. I’ll proceed to put everything in a pile and set it on fire. I’m out.
Sadly this forum is full of threads where this individual just restates incorrect information repeatedly and condescendingly until those who know better give up, and the most anyone gets is a later non-apology that blames the behaviour on neurodiversity. It is easier on the psyche to just give up sooner and save the mental energy for people who are actually open to communication. Please don’t give up, just re-priorirtise!
