Time Synchronization

[MTCAT]

Hi Rich and bmarkus,

You could be right, as I understand, the data logger program looks for and saves transient events in short bursts (200 kHz sample rate on each channel) whenever an amplitude threshold is exceeded, these transients arrive randomly so all we can do is define the stop and end times of each burst (a 2 second window around the event) as best we can (with the PPS).

But, the data logger also collects a continuous data stream, which is decimated to a 20 kHz sample rate, saved in 60 second windows, but the start/stop times of each continuous file is supposed to be aligned with the beginning and end of every minute, so perhaps this is where the real time kernel comes in ? To make sure that the start and end of each continuous file is as close as possible to the beginning/end of every minute ?

Does the 2.6.33.3 kernel I've been playing around with have a real-time "patch" ?, if that's the right word .

I do also have the source code for the logger program, but it's in C (C++ ?), which is not my "cup of tea" unfortunately.

Thanks,

David

[MTCAT]

Hi Rich,

In your opinion, do you think it would be okay to put the start-up commands for gpsd and chrony in a file located in ~/.X.d ? I thought by waiting until after X starts up, it might give the GPS a few more seconds to pick up satellites ?

Thanks,

David

[Rich]

Hi MTCAT
I don't see why not. Since commands placed their need to be backgrounded, I often place commands in a script that
I save in  /home/tc/.local/bin/.  Then I create a file in  ~/.X.d  containing an entry like this:

Code: [Select]

MyScript.sh &This places the script in the background and leaves flexibility in the script for additional functions.

[MTCAT]

Hi Rich,

Thanks, just like you showed me how to do with the clock, awesome, I'll do that if I ever can get the real time patch going, I started a new thread for that, I found a quite complicated (from my point of view) post you made some time ago about building a kernel from scratch.

Thanks,

David

[Rich]

Hi MTCAT

... it might give the GPS a few more seconds to pick up satellites ?

Is there a signal or a bit that can be tested to indicate when the GPS is ready?

[MTCAT]

Hi Rich,

Good question, I'm not sure, I'll have to look into that... would make sense that there would be a status indicator of some sort. I know the PPS isn't valid until the GPS gets a lock, at which time the NMEA strings become sorted out as well.

Just got a fresh install of TC3.8_4 done on a new pen drive, here we go !, into the real-time world !

Thanks,

David

 

[bmarkus]

Is there a signal or a bit that can be tested to indicate when the GPS is ready?

Quality indicator in GGA message probably.

[AdrianLevi]

...
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 ?).
...
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

I cannot find gpsd.tcz anywhere, Has it been removed from the repositories?
Googling I can find a reference to Tiny Core 3.x but it is quite old and the link seems to be dead.
Has anyone made a new gpsd extension for tiny core?

[Rich]

Hi AdrianLevi
Welcome to the forum.

The only version I see in the repos is version 3.1 here:
http://tinycorelinux.net/4.x/x86/tcz/gpsd.tcz.info

Code: [Select]

http://tinycorelinux.net/4.x/x86/tcz/
     81920 Oct 15  2011 gpsd-clients.tcz
     32768 Oct 15  2011 gpsd-dev.tcz
     49152 Oct 15  2011 gpsd-python.tcz
    229376 Oct 15  2011 gpsd.tcz

[gadget42]

also you should note that tcl 4.x may be archived offline at the end of this year

see for previous reference and/or example:

removal of 3.x
https://forum.tinycorelinux.net/index.php/topic,26497.0.html
removal of 1.x and 2.x
https://forum.tinycorelinux.net/index.php/topic,25955.0.html