Juan,
Here is my script that sets the date from the gps on startup:
#! /bin/sh
echo 'getting time'
#start:
cgpxlogger | head -n 20 > curtime.txt
cat curtime.txt | grep time | cut -c 29-30 > minute.txt
cat curtime.txt | grep time | cut -c 26-27 > hour.txt
cat curtime.txt | grep time | cut -c 23-24 > day.txt
cat curtime.txt | grep time | cut -c 20-21 > month.txt
cat curtime.txt | grep time | cut -c 15-18 > year.txt
date -s `echo \`cat month.txt\`\`cat day.txt\`\`cat hour.txt\`\`cat minute.txt\`\`cat year.txt\``
It is rather cludgy and relies on the output of cgpxlogger being a fixed-width string, but it works for me. Hopefully you will get some use out of it.
I actually call this script from another script in /etc/rc5.d and background it so that the rest of the boot process can continue before the gps has a lock. Since it can take a while for the gps to get a good lock, you may want to do the same. You also need to make sure this script starts up after you have started gpsd, because cgpxlogger connects to gpsd to get its information.
-Paul
-----Original Message-----
From: mike allen [mailto:allenster@...]
Sent: Thursday, October 15, 2009 10:34 PM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] GPS setting time.
2009/10/16 mike allen <allenster@...>:
> Hi Juan,
>
> 2009/10/16 Juan Osuna <jmartine@...>:
>>
>> Hi Again.
>>
>> Thank you Mike and Paul for your help.
>> I will be greatful if you can share the script that you mention related to
>> this issue.
>> Maybe you can also share the /etc/ntp.conf file. I am thinking that my
>> configuration is not well done.
>>
>> My /etc/ntp.conf:
>>
>> # This is the most basic ntp configuration file
>> # The driftfile must remain in a place specific to this
>> # machine - it records the machine specific clock error
>> driftfile /etc/ntp.drift
>> # This obtains a random server which will be close
>> # (in IP terms) to the machine. Add other servers
>> # as required, or change this.
>> #server pool.ntp.org
>>
>> server 127.127.28.0 minpoll 4 maxpoll 4
>> fudge 127.127.28.0 time1 0.185 refid GPS
>>
>> # Using local hardware clock as fallback
>> server 127.0.0.1
>> #server 127.127.28.0 minpoll 4 maxpoll 4
>> fudge 127.0.0.1 stratum 14
>>
>> # Defining a default security setting
>> restrict default nomodify nopeer
>>
>
> This ntp.conf is fine. I would uncomment the pool.ntp.org line if
> you're going to have network access.
>
>> Some questions.
>> Where can I check the NTP shared memory? in order to see if GPSD is writing
>> something.
>
> I cannot remember where the shm is off the top of my head, but there's
> a device/file you can cat to get statistics about who last read
> from/wrote to shared memory. If I remember, I'll post it.
>
try: cat /proc/sysvipc/shm and look for the pids of ntpd and gpsd respectively.
> Apart from that, if you suspect that gpsd is not writing - make sure
> that gpsd is being started up with the -n flag - this is hugely
> important. Verify using ps that gpsd is running with the following
> arguments: gpsd -p -n /dev/ttyS2
>
> The best thing to do for checking if gpsd is feeding time to ntpd and
> that ntpd is using it, is to install the ntp-bin package, and then
> run:
>
> ntpq -pn
>
> This will give you an output of the time sources that ntp is using to
> set the system time. You should see the clock source you specified in
> the ntp.conf file (GPS), and an estimate of the difference between it
> and the current system time, as well as the jitter of the time source.
>
>> Until now I can read data from GPS, and using ntpd -q can compare the
>> system time with the GPS time but I cannot set the verdex time. Is there a
>> way synchronize immediately using ntpdate or another command?
>
> The way it should work is that your system boots up and runs ntpdate
> as a 'one-shot' to set the time, then ntpd starts up and sets your
> system clock continuously based on the time sources it is receiving
> (i.e., gps, ntp servers).
>
> If you want to instantaneously set system time, you can use ntpdate,
> but you'll need a network connection. Otherwise, you might try Paul's
> script.
>
> I would recommend that you first verify that you have got gpsd and
> ntpd talking properly before trying to set the system time manually
> using gps - by this I mean that in the first instance, you should try
> and provide a network connection to your gumstix so that it can set
> its system time using an ntp server, and then verify that the nmea
> messages are indeed being used by ntp (ntpq -pn). Then you can move on
> to the issue of setting the time using only the gps.
>
>> Any advice?
>> Thank you in advance for your help.
>>
>> --
>> View this message in context: http://www.nabble.com/GPS-setting-time.-tp25900847p25918732.html
>> Sent from the Gumstix mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users
|