Tiny Core Extensions > TCE Talk

Time Synchronization

(1/5) > >>

MTCAT:
Hi everyone,

With and incredible amount of help (and patience) from Rich, the driver we built for the 24DSI is working 100 percent.

Next step is taking care of time synchronization with a U-Blox EVK-M8T pumping out NMEA sentences for ntp, but also with PPS signal detected and made use of by gpsd (I think), to further "discipline" ntp. The way I understand it is, the NMEA sentences gets ntp close (ms), and then the PPS really ratchets down the time-sync to us level.

Looking at some old posts, in order to see my GPS device (U-Blox EVK-M8T), I found I needed to install usb-serial-2.6.33.3-tinycore.tcz, after install, I saw a device "ttyACM0"  (was expecting "ttyUSB0").

But, that worked, typing cat/dev/ttyACM0 pumps out all the NMEA sentences from the U-Blox, so neat.

Then I installed gpsd.tcz (ver 2.96) and also ntp (but apparently chrony will work too, and is easier to set-up than ntp ?).

Finally my questions;

1) The version of gpsd I downloaded from TC repository is 2.96, this website recommends using versions newer than 3.22, see "Introduction", point 2

https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html

Would it be possible to get a newer version of gpsd for my TC 3.8_4 ?, although I don't know yet if my current 2.96 gpsd really is a problem, I did type "gpsd -D 5 -N -n /dev/ttyACM0" and it was working, output a bunch of stuff to screen....

2) The same link above indicates that "kernel" pps (KPPS) is about 5 times more accurate (1 us vs 5 us)  than "regular" PPS (see "PPS Quality Issues"), does Tiny-core have any PPS "kernel" support, or, a "pps-tools" package ? I didn't see one in the repository.

3) I have no experience really with ntp, or chrony, I would be interested to hear what you all think would be easiest to setup, and if you think which one (chrony or ntp) is "better", accurate, stable.

Thanks,

David

MTCAT:
Hi everyone,

Some small progress, from what I've been able to read up on, I have two options;

1) Kernel PPS, more accurate, but I think I would need to "patch" my kernel, right now "CONFIG_PPS" is not set in 2.6.33.3, I think I would need to turn that on with "make menuconfig" (?) and then patch the kernel ?, and then attach the PPS signal to ttyACM0 with "ldattach" command (I think we have this in TC3_8_4), but on  top of that, I would also need to install Linuxpps (pps-tools), make another extension I guess.

https://github.com/redlab-i/pps-tools

2) Using gpsd (less accurate) to feed the PPS to ntpd, I installed both gpsd and ntpd already but I haven't got it working 100 percent yet, I'm not sure if gpsd is even picking up the PPS signal on the serial port at all (ttyS0), gpsd also produces some errors on startup related to IPv4 and IPv6 sockets or something. This assumes that the ver 2.96 gpsd is okay, if having to "upgrade" to versions newer than 3.22, I'll have to build a new extension anyway ? Or, maybe a newer gpsd package exists for newer version of TC that might also work in TC3_8.4 ?

I would prefer (1) but I'm not sure if anyone has tried this already and may have words of wisdom regarding it ? Or, if reverting to (2), how I can get gpsd to pick up the PPS signal on the serial port, and/or just simply check for proper operation of gpsd.

Thanks,

David

Rich:
Hi MTCAT
I haven't dealt with  gpsd  or  ntpd  so I have nothing to offer there.

I do have some questions though.
Why do you think you need that level of accuracy?
What happens if you're off by 1uS? 1mS? 1Sec?

The kernel is configured to task switch at about 300 Hz or every 3.33 milliseconds. Since it's non-preemptive, that's about
the fastest response time you could expect if nothing else is running.

If you want 1 uS accuracy, that's better suited for dedicated hardware than a kernel. And it sounds like your hardware is
capable sampling at precise intervals and feeding that data to a buffer you can access as required.

MTCAT:
Hi Rich,

I'm hoping to have multiple independent recorders out at the same time, so, each logger needs ntp (or chrony) to adjust the system time on each logger at least well enough that a transient on one logger will be seen to occur at a similar time as on another logger (within several ms say ?). But then, we're also using the 24DSI12 to collect the PPS signal on each logger to allow an even finer time offset analysis.

But, I don't need absolute timing accuracy (I don't think), just good relative accuracy/synchronization between all the loggers themselves.

The problem is with the high frequency data, the measurement bandwidth is up to 40 kHz, so a time sync error of even 500 usec equals a phase error of > 20 degrees at 40 kHz (if I recall correctly), which is large for "good" data. I think even with 500 usec, we might have a respectable quality phase offset of < 5 degrees at 10 kHz.

So I think it's all about trying to get the high frequency phase between two events, recorded on two separate loggers, as accurate as possible, and to as high a frequency of possible.

Thanks,

David

MTCAT:
Hi Rich,

By the way, I was able to get chrony to do something, kind a sort of, it synchronized to the "pool" servers, but gpsd is not detecting my PPS signal, in fact, gpsd seems to be looking for the PPS on ttyACM0 (the USB port).

So I'm not sure how to fix that, I've also been playing around with chrony config files, using both "SOCK" and "SHM" definitions for the GPS NMEA string (ttyACM0) and the PPS (ttyS0)...

I hope I don't have to re-compile the entire kernel to enable "CONFIG_PPS" and "CONFIG_PPS_CLIENT_LDISC", right now, in 2.6.33.3 these are not enabled !

Thanks,

David

Navigation

[0] Message Index

[#] Next page