Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What is the NTP recovery time from 16s step in GPS server?
156 views
Skip to first unread message
David Taylor
Oct 30, 2012, 1:49:22 PM10/30/12
to
I have discovered that on a cold start my Resolution SMT GPS receiver
outputs the time in GPS time, until it has downloaded enough information
to determine the GSP offset, when it switches to UTC. This particular
receiver has no battery backup (it's an evaluation board).
I'm feeding this into gpsd, from which NTP gets its coarse seconds.
This is no problem when I have other Internet or LAN servers telling NTP
what the time actually is - NTP isn't fooled and sticks with UTC.
However, suppose I had /only/ the GPS receiver? NTP has the GPS time
and the PPS signal for the exact second, syncs, and then a few minutes
in the time suddenly changes by 16 seconds. I would hope that then
causes NTP to step the clock onto UTC rather than GPS time. I realise
that the time for the GPS receiver to be sending UTC rather than GPS
time varies, but how long might it then take NTP to react to the 16
second change, and alter the system clock? Both the PPS and the gpsd
are being polled at fixed 16 second intervals.
I'm hoping that it wouldn't take NTP too long to fix the clock. I see
the situation as someone being out with some portable kit - how long
should they wait before assuming the time is correct?
It strikes me that a receiver with no battery - like mine - is a poor
choice for out portable! I have a similar receiver with battery backup
on order, so I hope it's better You know where: 251164946899.
--
Cheers,
David
Web: http://www.satsignal.eu
outputs the time in GPS time, until it has downloaded enough information
to determine the GSP offset, when it switches to UTC. This particular
receiver has no battery backup (it's an evaluation board).
I'm feeding this into gpsd, from which NTP gets its coarse seconds.
This is no problem when I have other Internet or LAN servers telling NTP
what the time actually is - NTP isn't fooled and sticks with UTC.
However, suppose I had /only/ the GPS receiver? NTP has the GPS time
and the PPS signal for the exact second, syncs, and then a few minutes
in the time suddenly changes by 16 seconds. I would hope that then
causes NTP to step the clock onto UTC rather than GPS time. I realise
that the time for the GPS receiver to be sending UTC rather than GPS
time varies, but how long might it then take NTP to react to the 16
second change, and alter the system clock? Both the PPS and the gpsd
are being polled at fixed 16 second intervals.
I'm hoping that it wouldn't take NTP too long to fix the clock. I see
the situation as someone being out with some portable kit - how long
should they wait before assuming the time is correct?
It strikes me that a receiver with no battery - like mine - is a poor
choice for out portable! I have a similar receiver with battery backup
on order, so I hope it's better You know where: 251164946899.
--
Cheers,
David
Web: http://www.satsignal.eu
David Woolley
Oct 30, 2012, 1:57:57 PM10/30/12
to
David Taylor wrote:
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
>
It's not a specified characteristic, as it is a GIGO case. However, I
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
>
believe it it is the order of 20 minutes, with standard parameters.
Most of this is for ntpd to convince itself that the local clock time it
has really is wrong.
Rob
Oct 30, 2012, 1:59:46 PM10/30/12
to
David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's an evaluation board).
>
> I'm feeding this into gpsd, from which NTP gets its coarse seconds.
> This is no problem when I have other Internet or LAN servers telling NTP
> what the time actually is - NTP isn't fooled and sticks with UTC.
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
When I wrote that part of gpsd, I implemented the proper checks so
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's an evaluation board).
>
> I'm feeding this into gpsd, from which NTP gets its coarse seconds.
> This is no problem when I have other Internet or LAN servers telling NTP
> what the time actually is - NTP isn't fooled and sticks with UTC.
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
that the time is only put in the SHM after the GPS receiver has
indicated that it has a valid fix on the satellites.
I would hope that the receiver has collected the GPS offset by that
time, so that it will not put the wrong time value in SHM during a
short interval.
However, it has been a couple of years and many changes have been
made to the code, I cannot tell you if it may have been broken.
Do you really see the problem you describe above, or is it only a
hypothesis of what might happen?
David Taylor
Oct 30, 2012, 3:21:46 PM10/30/12
to
clock in question is being polled every 16 seconds?
David Taylor
Oct 30, 2012, 3:28:26 PM10/30/12
to
On 30/10/2012 17:59, Rob wrote:
[]
a valid fix, but it is outting GPS time and not UTC. There must be a
flag in the Trimble TSIP which tells you this, as I've seen the same
when monitoring with the Trimble Studio software. It takes some time
for the switch-over to occur.
> I would hope that the receiver has collected the GPS offset by that
> time, so that it will not put the wrong time value in SHM during a
> short interval.
For this receiver that hope is not applicable. Perhaps gpsd should only
show UTC, or have a flag to indicate between GPS time and UTC?
> However, it has been a couple of years and many changes have been
> made to the code, I cannot tell you if it may have been broken.
>
> Do you really see the problem you describe above, or is it only a
> hypothesis of what might happen?
Oh, I really see this. I had occasion to restart my Raspberry Pi NTP
server and the gpsd source was off by 16.0 seconds for a few minutes
after booting. The GPS receiver is powered from the PC. At the moment
it has multiple Internet servers as well as the gpsd/ATOM reclocks.
[]
> When I wrote that part of gpsd, I implemented the proper checks so
> that the time is only put in the SHM after the GPS receiver has
> indicated that it has a valid fix on the satellites.
THanks for this information, Rob. In this case the GPS appears to have
> that the time is only put in the SHM after the GPS receiver has
> indicated that it has a valid fix on the satellites.
a valid fix, but it is outting GPS time and not UTC. There must be a
flag in the Trimble TSIP which tells you this, as I've seen the same
when monitoring with the Trimble Studio software. It takes some time
for the switch-over to occur.
> I would hope that the receiver has collected the GPS offset by that
> time, so that it will not put the wrong time value in SHM during a
> short interval.
show UTC, or have a flag to indicate between GPS time and UTC?
> However, it has been a couple of years and many changes have been
> made to the code, I cannot tell you if it may have been broken.
>
> Do you really see the problem you describe above, or is it only a
> hypothesis of what might happen?
server and the gpsd source was off by 16.0 seconds for a few minutes
after booting. The GPS receiver is powered from the PC. At the moment
it has multiple Internet servers as well as the gpsd/ATOM reclocks.
unruh
Oct 30, 2012, 3:39:51 PM10/30/12
to
On 2012-10-30, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's an evaluation board).
>
> I'm feeding this into gpsd, from which NTP gets its coarse seconds.
> This is no problem when I have other Internet or LAN servers telling NTP
> what the time actually is - NTP isn't fooled and sticks with UTC.
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
ntpd jumps if the time is out more than .128 sec. But it waits a while
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's an evaluation board).
>
> I'm feeding this into gpsd, from which NTP gets its coarse seconds.
> This is no problem when I have other Internet or LAN servers telling NTP
> what the time actually is - NTP isn't fooled and sticks with UTC.
>
> However, suppose I had /only/ the GPS receiver? NTP has the GPS time
> and the PPS signal for the exact second, syncs, and then a few minutes
> in the time suddenly changes by 16 seconds. I would hope that then
> causes NTP to step the clock onto UTC rather than GPS time. I realise
> that the time for the GPS receiver to be sending UTC rather than GPS
> time varies, but how long might it then take NTP to react to the 16
> second change, and alter the system clock? Both the PPS and the gpsd
> are being polled at fixed 16 second intervals.
to make sure that the time is not some weird outlier. I think it may
wait for 8 clock reads ( the clock filter buffer) so that would be 128
sec.
>
> I'm hoping that it wouldn't take NTP too long to fix the clock. I see
> the situation as someone being out with some portable kit - how long
> should they wait before assuming the time is correct?
Rob
Oct 30, 2012, 3:45:12 PM10/30/12
to
David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> On 30/10/2012 17:59, Rob wrote:
> []
>> When I wrote that part of gpsd, I implemented the proper checks so
>> that the time is only put in the SHM after the GPS receiver has
>> indicated that it has a valid fix on the satellites.
>
> THanks for this information, Rob. In this case the GPS appears to have
> a valid fix, but it is outting GPS time and not UTC. There must be a
> flag in the Trimble TSIP which tells you this, as I've seen the same
> when monitoring with the Trimble Studio software. It takes some time
> for the switch-over to occur.
Are you using NMEA mode or TSIP mode on that receiver?
> On 30/10/2012 17:59, Rob wrote:
> []
>> When I wrote that part of gpsd, I implemented the proper checks so
>> that the time is only put in the SHM after the GPS receiver has
>> indicated that it has a valid fix on the satellites.
>
> THanks for this information, Rob. In this case the GPS appears to have
> a valid fix, but it is outting GPS time and not UTC. There must be a
> flag in the Trimble TSIP which tells you this, as I've seen the same
> when monitoring with the Trimble Studio software. It takes some time
> for the switch-over to occur.
I wrote the TSIP driver and checked the original source and the
current version 3.7, and in the processing of the packet 0x41 there
is a check on the validity of the GPS-UTC offset (called leap seconds
in the comment, I believe this name is from the Trimble docs).
The time is only valid when the number of leap seconds is more than 10.
I would hope that the value is 0 as long as the real value has not yet
been determined.
Can you try to set the log level to INFO and see what is going wrong?
The code is in driver_tsip.c and logs the offset as the last number
in this log line:
gpsd_report(LOG_INF, "GPS Time %f %d %f\n", f1, s1, f2);
David Woolley
Oct 30, 2012, 4:06:38 PM10/30/12
to
that you have to add the time to get a best sample with the new time,
and, possibly, the time to reload the sample FIFO.
This is certainly the case for external sources. I think it is true for
reference clocks.
David Taylor
Oct 30, 2012, 4:37:59 PM10/30/12
to
On 30/10/2012 19:45, Rob wrote:
[]
> I wrote the TSIP driver and checked the original source and the
> current version 3.7, and in the processing of the packet 0x41 there
> is a check on the validity of the GPS-UTC offset (called leap seconds
> in the comment, I believe this name is from the Trimble docs).
>
> The time is only valid when the number of leap seconds is more than 10.
> I would hope that the value is 0 as long as the real value has not yet
> been determined.
I can see how that would make sense.
> Can you try to set the log level to INFO and see what is going wrong?
> The code is in driver_tsip.c and logs the offset as the last number
> in this log line:
>
> gpsd_report(LOG_INF, "GPS Time %f %d %f\n", f1, s1, f2);
Rob,
My Linux knowledge is very limited. I'm quite happy to try what you are
suggesting, but I would have no idea where to start. Where do I edit
the log level and where do I look for the reports? The reboot I /can/
manage!
--
Thanks,
David
Web: http://www.satsignal.eu
[]
> Are you using NMEA mode or TSIP mode on that receiver?
TSIP - as it's what it powers up in by default.
> I wrote the TSIP driver and checked the original source and the
> current version 3.7, and in the processing of the packet 0x41 there
> is a check on the validity of the GPS-UTC offset (called leap seconds
> in the comment, I believe this name is from the Trimble docs).
>
> The time is only valid when the number of leap seconds is more than 10.
> I would hope that the value is 0 as long as the real value has not yet
> been determined.
> Can you try to set the log level to INFO and see what is going wrong?
> The code is in driver_tsip.c and logs the offset as the last number
> in this log line:
>
> gpsd_report(LOG_INF, "GPS Time %f %d %f\n", f1, s1, f2);
My Linux knowledge is very limited. I'm quite happy to try what you are
suggesting, but I would have no idea where to start. Where do I edit
the log level and where do I look for the reports? The reboot I /can/
manage!
--
Thanks,
David
Web: http://www.satsignal.eu
David Taylor
Oct 30, 2012, 4:42:08 PM10/30/12
to
have to test this experimentally. I sincerely hope that ~20 minutes is
wrong!
Rob
Oct 30, 2012, 4:51:55 PM10/30/12
to
You now probably run "gpsd -n /dev/ttyS0" from some startup script.
(e.g. /etc/init.d/gpsd)
First stop the running server using: /etc/init.d/gpsd stop
Then run gpsd from a shell using: gpsd -N -D 2 -n /dev/ttyS0
-N will tell it not to go into the background, -D sets the loglevel.
Level 2 should show the LOG_INF message we are looking for, but you
can set a higher level to zoom in to the problem.
^C out of it when you have seen enough. then you can start the
background server again using /etc/init.d/gpsd start
Kennedy, Paul
Oct 30, 2012, 9:17:49 PM10/30/12
to
Dave,
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPSTime/UTC offset (amongst other things).
http://en.wikipedia.org/wiki/GPS_signals#Almanac
regards
pk
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPSTime/UTC offset (amongst other things).
http://en.wikipedia.org/wiki/GPS_signals#Almanac
regards
pk
David Woolley
Oct 31, 2012, 4:30:48 AM10/31/12
to
less than that. His concern is about how long ntpd takes once the GPS
receiver is reporting the correct time. As noted, ntpd is not specified
for this case, so makes no attempt to recover any faster than any other
broken local clock case.
The almanac you are referring to is a low resolution one to aid the
receiver in finding satellites after a cold start. Once it has found a
satellite, it should have a high resolution almanac for that satellite
in about 30 seconds. Modern receivers tend to decode multiple
satellites at once, which is how they get a fast start, so they may be
fully acquired in 30 seconds. However, if there is no memory at all, it
may take them some tome to find their first satellite, and locating
subsequent ones may be slow until the full coarse almanac is received.
Rob
Oct 31, 2012, 4:35:26 AM10/31/12
to
David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> Kennedy, Paul wrote:
>> I believe the answer to your question is 12.5 minutes.
>>
>> This is the time it takes to receive the full set of 25 almanac frames,
>> which contains the GPSTime/UTC offset (amongst other things).
>>
>> http://en.wikipedia.org/wiki/GPS_signals#Almanac
>
> I think he knows the time taken for the GPS receiver, which is a lot
> less than that. His concern is about how long ntpd takes once the GPS
> receiver is reporting the correct time. As noted, ntpd is not specified
> for this case, so makes no attempt to recover any faster than any other
> broken local clock case.
The main point is that the local clock is not supposed to be broken.
> Kennedy, Paul wrote:
>> I believe the answer to your question is 12.5 minutes.
>>
>> This is the time it takes to receive the full set of 25 almanac frames,
>> which contains the GPSTime/UTC offset (amongst other things).
>>
>> http://en.wikipedia.org/wiki/GPS_signals#Almanac
>
> I think he knows the time taken for the GPS receiver, which is a lot
> less than that. His concern is about how long ntpd takes once the GPS
> receiver is reporting the correct time. As noted, ntpd is not specified
> for this case, so makes no attempt to recover any faster than any other
> broken local clock case.
It worked OK years ago when I implemented it, and I wonder what has
changed now so that it no longer works. Maybe a change in the Trimble
firmware or a change in gpsd (although I do not see that in the git
browser).
When this has been cleared up and fixed, gpsd should not provide time
until the receiver reports the correct values.
Terje Mathisen
Oct 31, 2012, 5:09:23 AM10/31/12
to
Rob wrote:
> The main point is that the local clock is not supposed to be broken.
>
> It worked OK years ago when I implemented it, and I wonder what has
> changed now so that it no longer works. Maybe a change in the Trimble
> firmware or a change in gpsd (although I do not see that in the git
> browser).
>
> When this has been cleared up and fixed, gpsd should not provide time
> until the receiver reports the correct values.
My guess would be that the Trible has some form of almanac backup
> The main point is that the local clock is not supposed to be broken.
>
> It worked OK years ago when I implemented it, and I wonder what has
> changed now so that it no longer works. Maybe a change in the Trimble
> firmware or a change in gpsd (although I do not see that in the git
> browser).
>
> When this has been cleared up and fixed, gpsd should not provide time
> until the receiver reports the correct values.
battery, but that this has worn out over e number of years, so it no
longer works.
I do know that when I made my first Oncore, based on the TAPR board, I
decided to _not_ put in a backup battery, in order to avoid problems
when it eventually failed.
A quick&dirty hack would be to either:
a) Don't provide any timestamps until the Trimble reports all-up.
b) (Very dirty!) Remember (in a file) the TAI-UTC offset from the last
run, and start with this value until you get an update from the GPS. If
said update is different from the stored value, update the file.
With this approach you will be OK unless you get a leap second while the
GPS is without power...
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Rob
Oct 31, 2012, 5:31:53 AM10/31/12
to
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Rob wrote:
>> The main point is that the local clock is not supposed to be broken.
>>
>> It worked OK years ago when I implemented it, and I wonder what has
>> changed now so that it no longer works. Maybe a change in the Trimble
>> firmware or a change in gpsd (although I do not see that in the git
>> browser).
>>
>> When this has been cleared up and fixed, gpsd should not provide time
>> until the receiver reports the correct values.
>
> My guess would be that the Trible has some form of almanac backup
> battery, but that this has worn out over e number of years, so it no
> longer works.
I have tested this driver on a Trimble OEM board and it does not
> Rob wrote:
>> The main point is that the local clock is not supposed to be broken.
>>
>> It worked OK years ago when I implemented it, and I wonder what has
>> changed now so that it no longer works. Maybe a change in the Trimble
>> firmware or a change in gpsd (although I do not see that in the git
>> browser).
>>
>> When this has been cleared up and fixed, gpsd should not provide time
>> until the receiver reports the correct values.
>
> My guess would be that the Trible has some form of almanac backup
> battery, but that this has worn out over e number of years, so it no
> longer works.
contain any from of backup facility other than an unpopulated space
on the board where a goldcap can be installed.
I guess this is the default, at least for boards of that age.
> A quick&dirty hack would be to either:
>
> a) Don't provide any timestamps until the Trimble reports all-up.
now. Maybe a newer Trimble firmware behaves differently from what
I tested with.
AFAIK there is no "almanac completely received" flag in the TSIP
time message.
We need to wait for what David sees in the trace and see what can be
the reason for the failure.
Martin Burnicki
Oct 31, 2012, 6:52:40 AM10/31/12
to
of the navigational information sent repeatedly once every 12 minutes.
Another piece of this data is the UTC parameter set which includes
current UTC to GPS time offset, leap second information, etc.
In worst case. if a GPS receiver starts from scratch and starts to track
the first satellite, transmission of the UTC offset parameters may have
just passed, so the receiver will have to wait 12 minutes until those
parameters are sent next time.
If you are just interested in your current geographic position then you
don't have to wait 12 minutes since UTC parameters are not required for
navigation. For navigation it is sufficient to be able to track 4
satellites to determine position (x, y, z) and time offset t from the
GPS system time.
So ideally the GPS receiver would tell if its UTC data is valid, or not.
Just checking if UTC offset is > 10 as mentioned in a different post is
a possible workaround if no such status information is available.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
David Taylor
Oct 31, 2012, 11:52:18 AM10/31/12
to
On 30/10/2012 20:51, Rob wrote:
[]
I'm now more confused than ever! I tried your command to run gpsd after
the receiver had got satellite information, and I could see one line
with 16.000 which looked like the offset. I also saw a couple of error
lines:
gpsd:INFO: startup at 2012-10-31T12:12:34.000Z (1351685554)
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps0/path,
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps1/path, /dev/ttyACM0
gpsd:INFO: KPPS cannot open /dev/pps1: Permission denied
gpsd:ERROR: PPS ioctl(TIOCMIWAIT) failed: 22 Invalid argument
gpsd:INFO: /dev/ttyACM0 identified as type Trimble TSIP (0.517231 sec @
9600bps)
gpsd:INFO: IO Options 1e 02 00 08
gpsd:WARN: Received packet of type 28 cannot be parsed
However now the gpsd can't connect to the serial (USB) device whatever I
try. I do see the device /dev/ttyACM0 listed in /dev, but I don't get a
/dev/gps0. If I try and stop gpsd, I can connect to /dev/ttyACM0 with
minicom, but I don't see the data flow I see in Windows with puTTY.
This is what I see:
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:ERROR: device open failed: Input/output error - retrying read-only
gpsd:ERROR: read-only device open failed: Input/output error
gpsd:ERROR: initial GPS device /dev/ttyACM0 open failed
I tried plugging a USB keyboard into the same USB port, and that seems
to work correctly, so I'm thinking it's a software rather than a
hardware issue. I've checked the GPS receiver over USB on another PC
and it functions exactly as expected. Any hints as to what I might have
broken running:
$ gpsd -N -D 2 -n /dev/ttyACM0
or:
$ sudo gpsd -N -D 2 -n /dev/ttyACM0
I'll attach extracts the logs with apologies for the length....
_____________________________________________________
Test in working conditions:
pi@raspberrypi ~ $ sudo /etc/init.d/gpsd stop
pi@raspberrypi ~ $ gpsd -N -D 2 -n /dev/ttyACM0
gpsd:INFO: launching (Version 3.6)
gpsd:ERROR: can't create IPv6 socket
gpsd:INFO: listening on port gpsd
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyACM0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: speed 9600, 8O1
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: gpsd_activate(): activated GPS (fd 5)
gpsd:INFO: device /dev/ttyACM0 activated
gpsd:INFO: running with effective group ID 1000
gpsd:INFO: running with effective user ID 1000
gpsd:INFO: startup at 2012-10-31T12:12:34.000Z (1351685554)
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps0/path,
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps1/path, /dev/ttyACM0
gpsd:INFO: KPPS cannot open /dev/pps1: Permission denied
gpsd:ERROR: PPS ioctl(TIOCMIWAIT) failed: 22 Invalid argument
gpsd:INFO: /dev/ttyACM0 identified as type Trimble TSIP (0.517231 sec @
9600bps)
gpsd:INFO: IO Options 1e 02 00 08
gpsd:WARN: Received packet of type 28 cannot be parsed
gpsd:INFO: Satellite Tracking Status: Ch 0 PRN 3 Res 0 Acq 1 Eph 1
SNR 42.0 LMT 303171.0000 El 82.0 Az 199.0
gpsd:INFO: Satellite Tracking Status: Ch 1 PRN 6 Res 0 Acq 1 Eph 1
SNR 37.0 LMT 303171.0000 El 70.0 Az 127.0
gpsd:INFO: Satellite Tracking Status: Ch 2 PRN 19 Res 0 Acq 1 Eph 1
SNR 40.0 LMT 303171.0000 El 61.0 Az 279.0
gpsd:INFO: Satellite Tracking Status: Ch 3 PRN 22 Res 0 Acq 1 Eph 1
SNR 31.0 LMT 303171.0000 El 43.0 Az 132.0
gpsd:INFO: Satellite Tracking Status: Ch 4 PRN 18 Res 0 Acq 1 Eph 1
SNR 32.0 LMT 303171.0000 El 41.0 Az 75.0
gpsd:INFO: Satellite Tracking Status: Ch 5 PRN 16 Res 0 Acq 1 Eph 1
SNR 38.0 LMT 303171.0000 El 40.0 Az 181.0
gpsd:INFO: Satellite Tracking Status: Ch 6 PRN 7 Res 0 Acq 1 Eph 1
SNR 36.0 LMT 303171.0000 El 21.0 Az 284.0
gpsd:INFO: Satellite Tracking Status: Ch 7 PRN 8 Res 0 Acq 1 Eph 1
SNR 32.0 LMT 303171.0000 El 20.0 Az 323.0
gpsd:INFO: Satellite Tracking Status: Ch 8 PRN 21 Res 0 Acq 1 Eph 1
SNR 20.0 LMT 303171.0000 El 20.0 Az 65.0
gpsd:INFO: Satellite Tracking Status: Ch 9 PRN 30 Res 0 Acq 1 Eph 1
SNR 20.0 LMT 303171.0000 El 10.0 Az 170.0
gpsd:INFO: Satellite Tracking Status: Ch 10 PRN 11 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 16.0 Az 249.0
gpsd:INFO: Satellite Tracking Status: Ch 11 PRN 15 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 11.0 Az 34.0
gpsd:INFO: Satellite Tracking Status: Ch 12 PRN 26 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 7.0 Az 359.0
gpsd:INFO: Satellite Tracking Status: Ch 13 PRN 1 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 2.0 Az 238.0
gpsd:INFO: Machine ID 00 02 02
gpsd:INFO: Software version: 0.3 090427 2.7 080813
gpsd:INFO: GPS Time 303171.000000 1712 16.000000
gpsd:WARN: Received packet of type 2c cannot be parsed
gpsd:WARN: Received packet of type 22 cannot be parsed
gpsd:WARN: Received packet of type 28 cannot be parsed
gpsd:INFO: Fix info 01 05 1712 303171.000000
gpsd:INFO: Current Datum 0 0.000000 0.000000 0.000000 6378137.000000
0.006694
gpsd:INFO: Satellite Tracking Status: Ch 0 PRN 3 Res 0 Acq 1 Eph 1
SNR 41.0 LMT 303176.0000 El 82.0 Az 199.0
gpsd:INFO: Satellite Tracking Status: Ch 1 PRN 6 Res 0 Acq 1 Eph 1
SNR 35.0 LMT 303176.0000 El 70.0 Az 127.0
_____________________________________________________
After a reboot where gpsd can't get to ACM0:
pi@raspberrypi ~ $ gpsd -N -D 2 -n /dev/ttyACM0
gpsd:INFO: launching (Version 3.6)
gpsd:ERROR: can't create IPv6 socket
gpsd:INFO: listening on port gpsd
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyACM0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:ERROR: device open failed: Input/output error - retrying read-only
gpsd:ERROR: read-only device open failed: Input/output error
gpsd:ERROR: initial GPS device /dev/ttyACM0 open failed
gpsd:INFO: running with effective group ID 1000
gpsd:INFO: running with effective user ID 1000
gpsd:INFO: startup at 2012-10-31T13:40:22.000Z (1351690822)
^Cgpsd:WARN: received terminating signal 2.
gpsd:WARN: exiting.
pi@raspberrypi ~ $
I do home someone can help...
[]
> The log level is set by a startup option of gpsd.
>
> You now probably run "gpsd -n /dev/ttyS0" from some startup script.
> (e.g. /etc/init.d/gpsd)
>
> First stop the running server using: /etc/init.d/gpsd stop
>
> Then run gpsd from a shell using: gpsd -N -D 2 -n /dev/ttyS0
>
> -N will tell it not to go into the background, -D sets the loglevel.
> Level 2 should show the LOG_INF message we are looking for, but you
> can set a higher level to zoom in to the problem.
>
> ^C out of it when you have seen enough. then you can start the
> background server again using /etc/init.d/gpsd start
Rob,
>
> You now probably run "gpsd -n /dev/ttyS0" from some startup script.
> (e.g. /etc/init.d/gpsd)
>
> First stop the running server using: /etc/init.d/gpsd stop
>
> Then run gpsd from a shell using: gpsd -N -D 2 -n /dev/ttyS0
>
> -N will tell it not to go into the background, -D sets the loglevel.
> Level 2 should show the LOG_INF message we are looking for, but you
> can set a higher level to zoom in to the problem.
>
> ^C out of it when you have seen enough. then you can start the
> background server again using /etc/init.d/gpsd start
I'm now more confused than ever! I tried your command to run gpsd after
the receiver had got satellite information, and I could see one line
with 16.000 which looked like the offset. I also saw a couple of error
lines:
gpsd:INFO: startup at 2012-10-31T12:12:34.000Z (1351685554)
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps0/path,
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps1/path, /dev/ttyACM0
gpsd:INFO: KPPS cannot open /dev/pps1: Permission denied
gpsd:ERROR: PPS ioctl(TIOCMIWAIT) failed: 22 Invalid argument
gpsd:INFO: /dev/ttyACM0 identified as type Trimble TSIP (0.517231 sec @
9600bps)
gpsd:INFO: IO Options 1e 02 00 08
gpsd:WARN: Received packet of type 28 cannot be parsed
However now the gpsd can't connect to the serial (USB) device whatever I
try. I do see the device /dev/ttyACM0 listed in /dev, but I don't get a
/dev/gps0. If I try and stop gpsd, I can connect to /dev/ttyACM0 with
minicom, but I don't see the data flow I see in Windows with puTTY.
This is what I see:
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:ERROR: device open failed: Input/output error - retrying read-only
gpsd:ERROR: read-only device open failed: Input/output error
gpsd:ERROR: initial GPS device /dev/ttyACM0 open failed
I tried plugging a USB keyboard into the same USB port, and that seems
to work correctly, so I'm thinking it's a software rather than a
hardware issue. I've checked the GPS receiver over USB on another PC
and it functions exactly as expected. Any hints as to what I might have
broken running:
$ gpsd -N -D 2 -n /dev/ttyACM0
or:
$ sudo gpsd -N -D 2 -n /dev/ttyACM0
I'll attach extracts the logs with apologies for the length....
_____________________________________________________
Test in working conditions:
pi@raspberrypi ~ $ sudo /etc/init.d/gpsd stop
pi@raspberrypi ~ $ gpsd -N -D 2 -n /dev/ttyACM0
gpsd:INFO: launching (Version 3.6)
gpsd:ERROR: can't create IPv6 socket
gpsd:INFO: listening on port gpsd
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyACM0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: speed 9600, 8O1
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: gpsd_activate(): activated GPS (fd 5)
gpsd:INFO: device /dev/ttyACM0 activated
gpsd:INFO: running with effective group ID 1000
gpsd:INFO: running with effective user ID 1000
gpsd:INFO: startup at 2012-10-31T12:12:34.000Z (1351685554)
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps0/path,
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps1/path, /dev/ttyACM0
gpsd:INFO: KPPS cannot open /dev/pps1: Permission denied
gpsd:ERROR: PPS ioctl(TIOCMIWAIT) failed: 22 Invalid argument
gpsd:INFO: /dev/ttyACM0 identified as type Trimble TSIP (0.517231 sec @
9600bps)
gpsd:INFO: IO Options 1e 02 00 08
gpsd:WARN: Received packet of type 28 cannot be parsed
gpsd:INFO: Satellite Tracking Status: Ch 0 PRN 3 Res 0 Acq 1 Eph 1
SNR 42.0 LMT 303171.0000 El 82.0 Az 199.0
gpsd:INFO: Satellite Tracking Status: Ch 1 PRN 6 Res 0 Acq 1 Eph 1
SNR 37.0 LMT 303171.0000 El 70.0 Az 127.0
gpsd:INFO: Satellite Tracking Status: Ch 2 PRN 19 Res 0 Acq 1 Eph 1
SNR 40.0 LMT 303171.0000 El 61.0 Az 279.0
gpsd:INFO: Satellite Tracking Status: Ch 3 PRN 22 Res 0 Acq 1 Eph 1
SNR 31.0 LMT 303171.0000 El 43.0 Az 132.0
gpsd:INFO: Satellite Tracking Status: Ch 4 PRN 18 Res 0 Acq 1 Eph 1
SNR 32.0 LMT 303171.0000 El 41.0 Az 75.0
gpsd:INFO: Satellite Tracking Status: Ch 5 PRN 16 Res 0 Acq 1 Eph 1
SNR 38.0 LMT 303171.0000 El 40.0 Az 181.0
gpsd:INFO: Satellite Tracking Status: Ch 6 PRN 7 Res 0 Acq 1 Eph 1
SNR 36.0 LMT 303171.0000 El 21.0 Az 284.0
gpsd:INFO: Satellite Tracking Status: Ch 7 PRN 8 Res 0 Acq 1 Eph 1
SNR 32.0 LMT 303171.0000 El 20.0 Az 323.0
gpsd:INFO: Satellite Tracking Status: Ch 8 PRN 21 Res 0 Acq 1 Eph 1
SNR 20.0 LMT 303171.0000 El 20.0 Az 65.0
gpsd:INFO: Satellite Tracking Status: Ch 9 PRN 30 Res 0 Acq 1 Eph 1
SNR 20.0 LMT 303171.0000 El 10.0 Az 170.0
gpsd:INFO: Satellite Tracking Status: Ch 10 PRN 11 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 16.0 Az 249.0
gpsd:INFO: Satellite Tracking Status: Ch 11 PRN 15 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 11.0 Az 34.0
gpsd:INFO: Satellite Tracking Status: Ch 12 PRN 26 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 7.0 Az 359.0
gpsd:INFO: Satellite Tracking Status: Ch 13 PRN 1 Res 0 Acq 0 Eph 0
SNR 0.0 LMT 303171.0000 El 2.0 Az 238.0
gpsd:INFO: Machine ID 00 02 02
gpsd:INFO: Software version: 0.3 090427 2.7 080813
gpsd:INFO: GPS Time 303171.000000 1712 16.000000
gpsd:WARN: Received packet of type 2c cannot be parsed
gpsd:WARN: Received packet of type 22 cannot be parsed
gpsd:WARN: Received packet of type 28 cannot be parsed
gpsd:INFO: Fix info 01 05 1712 303171.000000
gpsd:INFO: Current Datum 0 0.000000 0.000000 0.000000 6378137.000000
0.006694
gpsd:INFO: Satellite Tracking Status: Ch 0 PRN 3 Res 0 Acq 1 Eph 1
SNR 41.0 LMT 303176.0000 El 82.0 Az 199.0
gpsd:INFO: Satellite Tracking Status: Ch 1 PRN 6 Res 0 Acq 1 Eph 1
SNR 35.0 LMT 303176.0000 El 70.0 Az 127.0
_____________________________________________________
After a reboot where gpsd can't get to ACM0:
pi@raspberrypi ~ $ gpsd -N -D 2 -n /dev/ttyACM0
gpsd:INFO: launching (Version 3.6)
gpsd:ERROR: can't create IPv6 socket
gpsd:INFO: listening on port gpsd
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyACM0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyACM0'
gpsd:ERROR: device open failed: Input/output error - retrying read-only
gpsd:ERROR: read-only device open failed: Input/output error
gpsd:ERROR: initial GPS device /dev/ttyACM0 open failed
gpsd:INFO: running with effective group ID 1000
gpsd:INFO: running with effective user ID 1000
gpsd:INFO: startup at 2012-10-31T13:40:22.000Z (1351690822)
^Cgpsd:WARN: received terminating signal 2.
gpsd:WARN: exiting.
pi@raspberrypi ~ $
I do home someone can help...
David Taylor
Oct 31, 2012, 12:37:57 PM10/31/12
to
A follow-up to this: it seems that my GPS is only recognised by gpsd if
it is plugged into the USB port sometime /after/ the computer has
started. This is obviously not acceptable in an operational
environment, and has to be the first problem to solve. Anyone any ideas?
I can then go back to seeing whether gpds is letting times through too
early.
it is plugged into the USB port sometime /after/ the computer has
started. This is obviously not acceptable in an operational
environment, and has to be the first problem to solve. Anyone any ideas?
I can then go back to seeing whether gpds is letting times through too
early.
Rob
Oct 31, 2012, 1:22:44 PM10/31/12
to
I see errors that are related to permission.
I would recommend to type in the session before you do anything else:
sudo sh
or: sudo bash
When it works ok you should have a shell running as root, and then
you can stop the service and start gpsd without the risk that you
start to run it as user 1000 (which appears to be happening according
to the logs), and this user probably is not allowed to use the serial
port.
There are various things you could do to allow serial port access for
the user, but it should not be required as gpsd normally starts as
root to open the port and then changes to user nobody for its server
activities.
Is /dev/ttyACM0 the name for the USB serial port? Is there a
/dev/ttyUSB0? Maybe you could try that.
Using USB ports in a service started at boot time should normally
work ok, but when it has issues on the Raspberry maybe it could
be solved by delaying the startup of gpsd a bit. But don't try to
tackle all issues at the same time.
The log output of the Time with offset 16 is OK. What does it
show when you powercycle the receiver?
I would recommend to type in the session before you do anything else:
sudo sh
or: sudo bash
When it works ok you should have a shell running as root, and then
you can stop the service and start gpsd without the risk that you
start to run it as user 1000 (which appears to be happening according
to the logs), and this user probably is not allowed to use the serial
port.
There are various things you could do to allow serial port access for
the user, but it should not be required as gpsd normally starts as
root to open the port and then changes to user nobody for its server
activities.
Is /dev/ttyACM0 the name for the USB serial port? Is there a
/dev/ttyUSB0? Maybe you could try that.
Using USB ports in a service started at boot time should normally
work ok, but when it has issues on the Raspberry maybe it could
be solved by delaying the startup of gpsd a bit. But don't try to
tackle all issues at the same time.
The log output of the Time with offset 16 is OK. What does it
show when you powercycle the receiver?
Miroslav Lichvar
Oct 31, 2012, 1:46:41 PM10/31/12
to
On Wed, Oct 31, 2012 at 05:22:44PM +0000, Rob wrote:
> Using USB ports in a service started at boot time should normally
> work ok, but when it has issues on the Raspberry maybe it could
> be solved by delaying the startup of gpsd a bit. But don't try to
> tackle all issues at the same time.
Isn't it better to start it from udev then? The gpsd sources provide a
> Using USB ports in a service started at boot time should normally
> work ok, but when it has issues on the Raspberry maybe it could
> be solved by delaying the startup of gpsd a bit. But don't try to
> tackle all issues at the same time.
hotplug script, which I think is included at least in the Debian and Fedora
gpsd packages.
--
Miroslav Lichvar
Rob
Oct 31, 2012, 2:13:08 PM10/31/12
to
David Taylor
Oct 31, 2012, 2:29:15 PM10/31/12
to
On 31/10/2012 17:22, Rob wrote:
> I see errors that are related to permission.
I had wondered about that as well...
> I see errors that are related to permission.
> I would recommend to type in the session before you do anything else:
>
> sudo sh
>
> or: sudo bash
> When it works ok you should have a shell running as root, and then
> you can stop the service and start gpsd without the risk that you
> start to run it as user 1000 (which appears to be happening according
> to the logs), and this user probably is not allowed to use the serial
> port.
>
> There are various things you could do to allow serial port access for
> the user, but it should not be required as gpsd normally starts as
> root to open the port and then changes to user nobody for its server
> activities.
>
> Is /dev/ttyACM0 the name for the USB serial port? Is there a
> /dev/ttyUSB0? Maybe you could try that.
>
> Using USB ports in a service started at boot time should normally
> work ok, but when it has issues on the Raspberry maybe it could
> be solved by delaying the startup of gpsd a bit. But don't try to
> tackle all issues at the same time.
>
> The log output of the Time with offset 16 is OK. What does it
> show when you powercycle the receiver?
Ignoring the offset for the moment, if I power up the Rasberry Pi from
cold while it sees the PPS signals (to an interrupt-driver GPIO pin) is
never sees gpsd data ( and trying cgps -s also times out with a can't
connect). I've left it for about 30 minutes but gpsd never sees data.
When I then do a warm reboot NTP sees data from gpsd right away and cgps
-s works as well.
My feeling is that I should concentrate on getting the PC to see GPS
cold from a cold boot first, and then worry about any 16-second step.
Would you not agree? If so, what magic file to I have to edit and how
to delay gpsd starting?
Actually, I'm not even sure myself, as I recall that from a cold boot,
stopping and restarting gpsd isn't enough to start the data flow, the
GPS receiver itself has to be plugged out and back in, but I'm happy to
try a delayed gpsd start.
What do you think?
Rob
Oct 31, 2012, 2:35:41 PM10/31/12
to
David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> Ignoring the offset for the moment, if I power up the Rasberry Pi from
> cold while it sees the PPS signals (to an interrupt-driver GPIO pin) is
> never sees gpsd data ( and trying cgps -s also times out with a can't
> connect). I've left it for about 30 minutes but gpsd never sees data.
> When I then do a warm reboot NTP sees data from gpsd right away and cgps
> -s works as well.
>
> My feeling is that I should concentrate on getting the PC to see GPS
> cold from a cold boot first, and then worry about any 16-second step.
> Would you not agree? If so, what magic file to I have to edit and how
> to delay gpsd starting?
>
> Actually, I'm not even sure myself, as I recall that from a cold boot,
> stopping and restarting gpsd isn't enough to start the data flow, the
> GPS receiver itself has to be plugged out and back in, but I'm happy to
> try a delayed gpsd start.
>
> What do you think?
I don't know much about the raspberry.
> Ignoring the offset for the moment, if I power up the Rasberry Pi from
> cold while it sees the PPS signals (to an interrupt-driver GPIO pin) is
> never sees gpsd data ( and trying cgps -s also times out with a can't
> connect). I've left it for about 30 minutes but gpsd never sees data.
> When I then do a warm reboot NTP sees data from gpsd right away and cgps
> -s works as well.
>
> My feeling is that I should concentrate on getting the PC to see GPS
> cold from a cold boot first, and then worry about any 16-second step.
> Would you not agree? If so, what magic file to I have to edit and how
> to delay gpsd starting?
>
> Actually, I'm not even sure myself, as I recall that from a cold boot,
> stopping and restarting gpsd isn't enough to start the data flow, the
> GPS receiver itself has to be plugged out and back in, but I'm happy to
> try a delayed gpsd start.
>
> What do you think?
I think it is sort of standard Linux, but then there really is no
standard Linux anymore due to all the silly changes that Ubuntu people
have been bringing.
What does the /etc/rc.d/gpsd file look like as it is now?
Is there a /etc/udev/rules.d/ directory with some .rules files in it?
David Taylor
Oct 31, 2012, 2:48:06 PM10/31/12
to
On 31/10/2012 18:35, Rob wrote:
[]
> I think it is sort of standard Linux, but then there really is no
> standard Linux anymore due to all the silly changes that Ubuntu people
> have been bringing.
Yes, the multiple variations was one of the reasons I didn't pursue
Linux development - I don't have the time to support so many versions.
> What does the /etc/rc.d/gpsd file look like as it is now?
It's in /etc/int.d/gpsd, and I'll put it at the end of this post.
> Is there a /etc/udev/rules.d/ directory with some .rules files in it?
Yes, there are two:
pi@raspberrypi /etc/udev/rules.d $ cat 40-scratch.rules
ATTRS{idVendor}=="0694", ATTRS{idProduct}=="0003", SUBSYSTEMS=="usb",
ACTION=="add", MODE="0666", GROUP="plugdev"
pi@raspberrypi /etc/udev/rules.d $ cat 99-input.rules
SUBSYSTEM=="input", GROUP="input", MODE="0660"
There's also a "default" file:
pi@raspberrypi ~ $ cat /etc/default/gpsd
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyACM0"
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
And here the gpsd startup file:
pi@raspberrypi ~ $ cat /etc/init.d/gpsd
#!/bin/sh
### BEGIN INIT INFO
# Provides: gpsd
# Required-Start: $remote_fs $syslog $network
# Should-Start: bluetooth dbus udev
# Required-Stop: $remote_fs $syslog $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Start-Before: ntp
# Short-Description: GPS (Global Positioning System) daemon
# Description: The gpsd service daemon is able to monitor one or
# more GPS devices connected to a host computer, making
# all data on the location and movements of the sensors
# available to be queried on TCP port 2947.
### END INIT INFO
# Author: Bernd Zeimetz <bz...@debian.org>
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="GPS (Global Positioning System) daemon"
NAME=gpsd
DAEMON=/usr/sbin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
if [ -z "$GPSD_SOCKET" ] && [ -z "$DEVICES" ]; then
GPSD_SOCKET=/var/run/gpsd.sock
fi
if [ -n "$GPSD_SOCKET" ]; then
GPSD_OPTIONS="$GPSD_OPTIONS -F $GPSD_SOCKET"
fi
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON -- \
$GPSD_OPTIONS -P $PIDFILE $DEVICES \
|| return 2
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
--pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE
--name $NAME
return 0
}
case "$1" in
start)
if [ "$START_DAEMON" = "true" ]; then
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC"
"$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
else
[ "$VERBOSE" != no ] && \
log_daemon_msg "Not starting $DESC" "$NAME" && \
log_end_msg 0
fi
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
reload|force-reload)
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
;;
restart)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
[]
> I don't know much about the raspberry.
Snap!
> I think it is sort of standard Linux, but then there really is no
> standard Linux anymore due to all the silly changes that Ubuntu people
> have been bringing.
Linux development - I don't have the time to support so many versions.
> What does the /etc/rc.d/gpsd file look like as it is now?
> Is there a /etc/udev/rules.d/ directory with some .rules files in it?
pi@raspberrypi /etc/udev/rules.d $ cat 40-scratch.rules
ATTRS{idVendor}=="0694", ATTRS{idProduct}=="0003", SUBSYSTEMS=="usb",
ACTION=="add", MODE="0666", GROUP="plugdev"
pi@raspberrypi /etc/udev/rules.d $ cat 99-input.rules
SUBSYSTEM=="input", GROUP="input", MODE="0660"
There's also a "default" file:
pi@raspberrypi ~ $ cat /etc/default/gpsd
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyACM0"
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
And here the gpsd startup file:
pi@raspberrypi ~ $ cat /etc/init.d/gpsd
#!/bin/sh
### BEGIN INIT INFO
# Provides: gpsd
# Required-Start: $remote_fs $syslog $network
# Should-Start: bluetooth dbus udev
# Required-Stop: $remote_fs $syslog $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Start-Before: ntp
# Short-Description: GPS (Global Positioning System) daemon
# Description: The gpsd service daemon is able to monitor one or
# more GPS devices connected to a host computer, making
# all data on the location and movements of the sensors
# available to be queried on TCP port 2947.
### END INIT INFO
# Author: Bernd Zeimetz <bz...@debian.org>
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="GPS (Global Positioning System) daemon"
NAME=gpsd
DAEMON=/usr/sbin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
if [ -z "$GPSD_SOCKET" ] && [ -z "$DEVICES" ]; then
GPSD_SOCKET=/var/run/gpsd.sock
fi
if [ -n "$GPSD_SOCKET" ]; then
GPSD_OPTIONS="$GPSD_OPTIONS -F $GPSD_SOCKET"
fi
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON -- \
$GPSD_OPTIONS -P $PIDFILE $DEVICES \
|| return 2
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
--pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE
--name $NAME
return 0
}
case "$1" in
start)
if [ "$START_DAEMON" = "true" ]; then
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC"
"$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
else
[ "$VERBOSE" != no ] && \
log_daemon_msg "Not starting $DESC" "$NAME" && \
log_end_msg 0
fi
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
reload|force-reload)
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
;;
restart)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
Rob
Oct 31, 2012, 3:25:20 PM10/31/12
to
I think it does not look bad and should basically work.
Maybe someone with more Raspberry experience can suggest what to
do.
As mentioned, it is possible to remove the /etc/init.d/gpsd and
start gpsd as a hotplug action, but I have no forther detail
about that. You could see if you can locate the gpsd.rules and
gpsd.hotplug files somewhere on the system or get them from the
git repository:
http://git.savannah.gnu.org/cgit/gpsd.git/tree/?id=release-3.7
Then put the .rules file in /etc/udev/rules.d and the gpsd.hotplug
in /lib/udev and see if it gets fired up when you plugin the
serial adapter.
Maybe someone with more Raspberry experience can suggest what to
do.
As mentioned, it is possible to remove the /etc/init.d/gpsd and
start gpsd as a hotplug action, but I have no forther detail
about that. You could see if you can locate the gpsd.rules and
gpsd.hotplug files somewhere on the system or get them from the
git repository:
http://git.savannah.gnu.org/cgit/gpsd.git/tree/?id=release-3.7
Then put the .rules file in /etc/udev/rules.d and the gpsd.hotplug
in /lib/udev and see if it gets fired up when you plugin the
serial adapter.
John Hasler
Oct 31, 2012, 3:37:28 PM10/31/12
to
Rob wrote:
> I don't know much about the raspberry.
> I don't know much about the raspberry.
> I think it is sort of standard Linux,
Raspbian is just Debian, recompiled for the particular ARM cpu the
Raspberry uses and with drivers for the Broadcom video added. The
recompilation permits the use of hardware floating point, which is
different in the Raspberry and the ARM cpus that Debian supports.
Debian also supports ARM cpus with no hardware floating point and that
version of Debian runs on the Raspberry but is slower.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Richard B. Gilbert
Oct 31, 2012, 3:52:42 PM10/31/12
to
let it run for a few months.
How slow is a "slow start"?. It can take NTPD up to ten hours to
synchronize within + or - 50 nanoseconds with whatever you are using as
a time source. If you must boot your computer at 8:30 every morning,
NTPD is a poor choice!
There is another "product" which will give you a "reasonable facsimile"
of the correct time in a very short time. I've never used it. I've
forgotten its name. Sorry about that. I'm sure that someone here
can recall the name I've forgotten!
Rob
Oct 31, 2012, 3:53:06 PM10/31/12
to
John Hasler <jha...@newsguy.com> wrote:
> Rob wrote:
>> I don't know much about the raspberry.
>> I think it is sort of standard Linux,
>
> Raspbian is just Debian, recompiled for the particular ARM cpu the
> Raspberry uses and with drivers for the Broadcom video added. The
> recompilation permits the use of hardware floating point, which is
> different in the Raspberry and the ARM cpus that Debian supports.
> Debian also supports ARM cpus with no hardware floating point and that
> version of Debian runs on the Raspberry but is slower.
What is more important in this case, is the mechanism it uses for
> Rob wrote:
>> I don't know much about the raspberry.
>> I think it is sort of standard Linux,
>
> Raspbian is just Debian, recompiled for the particular ARM cpu the
> Raspberry uses and with drivers for the Broadcom video added. The
> recompilation permits the use of hardware floating point, which is
> different in the Raspberry and the ARM cpus that Debian supports.
> Debian also supports ARM cpus with no hardware floating point and that
> version of Debian runs on the Raspberry but is slower.
starting daemons, for creating device nodes, etc.
From what I have read up to now, it appears it users a classical
(System-V like) init, and udev. Good.
(always keep Lennart Poettering away from your system!)
David Taylor
Oct 31, 2012, 4:19:07 PM10/31/12
to
I have another GPS on its way from the East, and that one has battery
backup, but serial (3.3V) rather than USB output. Getting serial into
RasPi is another challenge - but it's documented....
Steve Kostecke
Oct 31, 2012, 4:18:33 PM10/31/12
to
On 2012-10-31, David Taylor <david-...@blueyonder.co.uk> wrote:
> On 31/10/2012 18:35, Rob wrote:
>
>> I think it is sort of standard Linux, but then there really is no
>> standard Linux anymore due to all the silly changes that Ubuntu people
>> have been bringing.
>
> Yes, the multiple variations was one of the reasons I didn't pursue
> Linux development - I don't have the time to support so many versions.
This is a common misconception.
> On 31/10/2012 18:35, Rob wrote:
>
>> I think it is sort of standard Linux, but then there really is no
>> standard Linux anymore due to all the silly changes that Ubuntu people
>> have been bringing.
>
> Yes, the multiple variations was one of the reasons I didn't pursue
> Linux development - I don't have the time to support so many versions.
Just write the software once and leave it to the "Linux Distribution"
packagers to customize it to work on their OS.
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
unruh
Oct 31, 2012, 5:04:01 PM10/31/12
to
On 2012-10-31, Richard B. Gilbert <rgilb...@comcast.net> wrote:
> On 10/31/2012 4:30 AM, David Woolley wrote:
>> Kennedy, Paul wrote:
>>> I believe the answer to your question is 12.5 minutes.
>>>
>>> This is the time it takes to receive the full set of 25 almanac frames,
>>> which contains the GPSTime/UTC offset (amongst other things).
>>>
>>> http://en.wikipedia.org/wiki/GPS_signals#Almanac
>>
>> I think he knows the time taken for the GPS receiver, which is a lot
>> less than that. His concern is about how long ntpd takes once the GPS
>> receiver is reporting the correct time. As noted, ntpd is not specified
>> for this case, so makes no attempt to recover any faster than any other
>> broken local clock case.
>>
>> The almanac you are referring to is a low resolution one to aid the
>> receiver in finding satellites after a cold start. Once it has found a
>> satellite, it should have a high resolution almanac for that satellite
>> in about 30 seconds. Modern receivers tend to decode multiple
>> satellites at once, which is how they get a fast start, so they may be
>> fully acquired in 30 seconds. However, if there is no memory at all, it
>> may take them some tome to find their first satellite, and locating
>> subsequent ones may be slow until the full coarse almanac is received.
>
>
> NTPD is a "slow starter"! Ideally, you will only start it once and
> let it run for a few months.
>
> How slow is a "slow start"?. It can take NTPD up to ten hours to
> synchronize within + or - 50 nanoseconds with whatever you are using as
It will never get to within 50nsec. The interrupt processing is far more
> On 10/31/2012 4:30 AM, David Woolley wrote:
>> Kennedy, Paul wrote:
>>> I believe the answer to your question is 12.5 minutes.
>>>
>>> This is the time it takes to receive the full set of 25 almanac frames,
>>> which contains the GPSTime/UTC offset (amongst other things).
>>>
>>> http://en.wikipedia.org/wiki/GPS_signals#Almanac
>>
>> I think he knows the time taken for the GPS receiver, which is a lot
>> less than that. His concern is about how long ntpd takes once the GPS
>> receiver is reporting the correct time. As noted, ntpd is not specified
>> for this case, so makes no attempt to recover any faster than any other
>> broken local clock case.
>>
>> The almanac you are referring to is a low resolution one to aid the
>> receiver in finding satellites after a cold start. Once it has found a
>> satellite, it should have a high resolution almanac for that satellite
>> in about 30 seconds. Modern receivers tend to decode multiple
>> satellites at once, which is how they get a fast start, so they may be
>> fully acquired in 30 seconds. However, if there is no memory at all, it
>> may take them some tome to find their first satellite, and locating
>> subsequent ones may be slow until the full coarse almanac is received.
>
>
> NTPD is a "slow starter"! Ideally, you will only start it once and
> let it run for a few months.
>
> How slow is a "slow start"?. It can take NTPD up to ten hours to
> synchronize within + or - 50 nanoseconds with whatever you are using as
variable than that. You might get to withing a few micro seconds.
> a time source. If you must boot your computer at 8:30 every morning,
> NTPD is a poor choice!
>
> There is another "product" which will give you a "reasonable facsimile"
> of the correct time in a very short time. I've never used it. I've
> forgotten its name. Sorry about that. I'm sure that someone here
> can recall the name I've forgotten!
It also gives better accuracy.
Richard B. Gilbert
Oct 31, 2012, 5:25:24 PM10/31/12
to
unruh
Oct 31, 2012, 11:39:51 PM10/31/12
to
about a factor of three less than with ntpd.
That is over a long term-- days and weeks.
>
>
>
David Taylor
Nov 1, 2012, 2:44:47 AM11/1/12
to
[]
get to within 250 microseconds, and about an hour to be within 10
microseconds. Ultimately it is within about 3 microseconds.
>> NTPD is a "slow starter"! Ideally, you will only start it once and
>> let it run for a few months.
>>
>> How slow is a "slow start"?. It can take NTPD up to ten hours to
>> synchronize within + or - 50 nanoseconds with whatever you are using as
>
> It will never get to within 50nsec. The interrupt processing is far more
> variable than that. You might get to withing a few micro seconds.
On a recent restart from cold, the server here took about 15 minutes to
>> let it run for a few months.
>>
>> How slow is a "slow start"?. It can take NTPD up to ten hours to
>> synchronize within + or - 50 nanoseconds with whatever you are using as
>
> It will never get to within 50nsec. The interrupt processing is far more
> variable than that. You might get to withing a few micro seconds.
get to within 250 microseconds, and about an hour to be within 10
microseconds. Ultimately it is within about 3 microseconds.
David Woolley
Nov 1, 2012, 4:40:36 AM11/1/12
to
David Taylor wrote:
>
> On a recent restart from cold, the server here took about 15 minutes to
> get to within 250 microseconds, and about an hour to be within 10
> microseconds. Ultimately it is within about 3 microseconds.
3 microseconds of what? How are you measuring the difference between
>
> On a recent restart from cold, the server here took about 15 minutes to
> get to within 250 microseconds, and about an hour to be within 10
> microseconds. Ultimately it is within about 3 microseconds.
software clock time and UTC, independently of NTP?
David Lord
Nov 1, 2012, 5:27:33 AM11/1/12
to
previous versions were any worse. The rstarts are usually within
around 15-30 min to be better than 1 ms and replying to requests.
I lost 7 x pcs Jun-Sept this year after local mains substation
transformer self destructed so my system with GPS is down. That
would be within a few usec within an hour but was sensitive to
large temperature and load changes with nightly excursions to
30 usec for short periods.
The example I've seen as to getting sub usec was GPS combined with
a remote stable system clock source (from a TAPR board). I've too
much on at the moment repairing/replacing the failed systems to
setup the Ru clock I bought off ebay.
David
David Taylor
Nov 1, 2012, 8:13:10 AM11/1/12
to
David Woolley
Nov 1, 2012, 9:36:07 AM11/1/12
to
times higher than the actual error, but with a low value like that, it
could easily be orders of magnitude worse (e.g. if there were interrupt
latencies in the 100s of microseconds and up, or, for network time, if
there were asymmetric delays in the milliseconds).
At 250 microseconds, do they all have the same sign? The claim for
chrony would be that it gets to the state where the offsets are balanced
about zero, much faster.
unruh
Nov 1, 2012, 12:13:34 PM11/1/12
to
does not mean much)
unruh
Nov 1, 2012, 12:20:14 PM11/1/12
to
On 2012-11-01, David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> David Taylor wrote:
>> On 01/11/2012 08:40, David Woolley wrote:
>>> David Taylor wrote:
>>>
>>>>
>>>> On a recent restart from cold, the server here took about 15 minutes
>>>> to get to within 250 microseconds, and about an hour to be within 10
>>>> microseconds. Ultimately it is within about 3 microseconds.
>>>
>>> 3 microseconds of what? How are you measuring the difference between
>>> software clock time and UTC, independently of NTP?
>>
>> That's the offset as stated by NTP.
>
> That's not the time error. Under ideal circumstances, it is several
> times higher than the actual error, but with a low value like that, it
> could easily be orders of magnitude worse (e.g. if there were interrupt
> latencies in the 100s of microseconds and up, or, for network time, if
> there were asymmetric delays in the milliseconds).
Interrupt latencies in my measurements tended to be at the one or 2
> David Taylor wrote:
>> On 01/11/2012 08:40, David Woolley wrote:
>>> David Taylor wrote:
>>>
>>>>
>>>> On a recent restart from cold, the server here took about 15 minutes
>>>> to get to within 250 microseconds, and about an hour to be within 10
>>>> microseconds. Ultimately it is within about 3 microseconds.
>>>
>>> 3 microseconds of what? How are you measuring the difference between
>>> software clock time and UTC, independently of NTP?
>>
>> That's the offset as stated by NTP.
>
> That's not the time error. Under ideal circumstances, it is several
> times higher than the actual error, but with a low value like that, it
> could easily be orders of magnitude worse (e.g. if there were interrupt
> latencies in the 100s of microseconds and up, or, for network time, if
> there were asymmetric delays in the milliseconds).
microsecond level. (drive a pin on the parallel port up, measuring when
you did that, and then measuring the interrupt output time and looking
at the difference.) Of course they are all one way, so averaging does
not make this error smaller.
When I once tried to cascade two interrupt service routines on the same
interrupt togetter, the second was about 10usec later than the first--
indicating the interrupt service time of the first.
unruh
Nov 1, 2012, 12:25:39 PM11/1/12
to
On 2012-11-01, David Lord <sn...@lordynet.org> wrote:
> David Taylor wrote:
>> On 31/10/2012 21:04, unruh wrote:
>>> On 2012-10-31, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>> []
>>>> NTPD is a "slow starter"! Ideally, you will only start it once and
>>>> let it run for a few months.
>>>>
>>>> How slow is a "slow start"?. It can take NTPD up to ten hours to
>>>> synchronize within + or - 50 nanoseconds with whatever you are using as
>>>
>>> It will never get to within 50nsec. The interrupt processing is far more
>>> variable than that. You might get to withing a few micro seconds.
>>
>> On a recent restart from cold, the server here took about 15 minutes to
>> get to within 250 microseconds, and about an hour to be within 10
>> microseconds. Ultimately it is within about 3 microseconds.
>
> I'm on NetBSD-6 and ntpd 4.2.6p5 although I don't believe the
> previous versions were any worse. The rstarts are usually within
> around 15-30 min to be better than 1 ms and replying to requests.
> I lost 7 x pcs Jun-Sept this year after local mains substation
> transformer self destructed so my system with GPS is down. That
> would be within a few usec within an hour but was sensitive to
> large temperature and load changes with nightly excursions to
> 30 usec for short periods.
Yes, ntp is slow to respond to rate changes. That is its main problem in
> David Taylor wrote:
>> On 31/10/2012 21:04, unruh wrote:
>>> On 2012-10-31, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>> []
>>>> NTPD is a "slow starter"! Ideally, you will only start it once and
>>>> let it run for a few months.
>>>>
>>>> How slow is a "slow start"?. It can take NTPD up to ten hours to
>>>> synchronize within + or - 50 nanoseconds with whatever you are using as
>>>
>>> It will never get to within 50nsec. The interrupt processing is far more
>>> variable than that. You might get to withing a few micro seconds.
>>
>> On a recent restart from cold, the server here took about 15 minutes to
>> get to within 250 microseconds, and about an hour to be within 10
>> microseconds. Ultimately it is within about 3 microseconds.
>
> I'm on NetBSD-6 and ntpd 4.2.6p5 although I don't believe the
> previous versions were any worse. The rstarts are usually within
> around 15-30 min to be better than 1 ms and replying to requests.
> I lost 7 x pcs Jun-Sept this year after local mains substation
> transformer self destructed so my system with GPS is down. That
> would be within a few usec within an hour but was sensitive to
> large temperature and load changes with nightly excursions to
> 30 usec for short periods.
getting the ultimate accuracy (since rate changes due to temp changes
are probably the dominant source of inaccuracy on most systems). chrony
responds to such rate changes much faster, and keeps the time on track
with utc much better. It probably comes at the cost that the rate of the
system clock is not as well disciplined as on ntp, although that is
irrelevant if the rate keeps changing due to temp changes. what I mean
is that if your noise model is gaussian random noise on the packet
timing, then ntpd will settle down to a better rate correction than will
chrony. But that is not the dominant noise source on most systems.
David Woolley
Nov 1, 2012, 12:30:26 PM11/1/12
to
actual PPS time.
David Woolley
Nov 1, 2012, 12:32:14 PM11/1/12
to
unruh wrote:
>
> Interrupt latencies in my measurements tended to be at the one or 2
> microsecond level. (drive a pin on the parallel port up, measuring when
The Raspberry Pi is basically a headless PDA, using smart phone type
>
> Interrupt latencies in my measurements tended to be at the one or 2
> microsecond level. (drive a pin on the parallel port up, measuring when
processors. It is optimised for power consumption, not speed.
David Taylor
Nov 1, 2012, 1:29:28 PM11/1/12
to
On 01/11/2012 09:27, David Lord wrote:
[]
> David
Very sorry to hear about that David, a true pain! Perhaps a chance to
replace with some lower-power kit, though?
[]
> I lost 7 x pcs Jun-Sept this year after local mains substation
> transformer self destructed so my system with GPS is down.
[]
> transformer self destructed so my system with GPS is down.
> David
Very sorry to hear about that David, a true pain! Perhaps a chance to
replace with some lower-power kit, though?
David Taylor
Nov 1, 2012, 1:41:03 PM11/1/12
to
On 01/11/2012 13:36, David Woolley wrote:
> David Taylor wrote:
[]
> David Taylor wrote:
>> That's the offset as stated by NTP.
>
> That's not the time error. Under ideal circumstances, it is several
> times higher than the actual error, but with a low value like that, it
> could easily be orders of magnitude worse (e.g. if there were interrupt
> latencies in the 100s of microseconds and up, or, for network time, if
> there were asymmetric delays in the milliseconds).
>
> At 250 microseconds, do they all have the same sign? The claim for
> chrony would be that it gets to the state where the offsets are balanced
> about zero, much faster.
Well, it's the best data I have available to plot, and seems to indicate
>
> That's not the time error. Under ideal circumstances, it is several
> times higher than the actual error, but with a low value like that, it
> could easily be orders of magnitude worse (e.g. if there were interrupt
> latencies in the 100s of microseconds and up, or, for network time, if
> there were asymmetric delays in the milliseconds).
>
> At 250 microseconds, do they all have the same sign? The claim for
> chrony would be that it gets to the state where the offsets are balanced
> about zero, much faster.
well how changes in configuration of hardware and software affect
timekeeping. The device shows NTP offsets in the order of 10
microseconds from other PPS-driven network sources.
I believe the interrupt latency on that 700 MHz processor is around
30-50 microseconds with the Raspberry Pi hardware. For what I need it's
more than adequate - an absolute error of less than a millisecond would
not be noticed by the applications I run. Using different software
isn't going to affect the interrupt latency unless it had some way of
measuring that with external hardware.
unruh
Nov 1, 2012, 2:23:34 PM11/1/12
to
interrupt processing then I agree.
David Lord
Nov 1, 2012, 4:57:23 PM11/1/12
to
David Taylor wrote:
> On 01/11/2012 09:27, David Lord wrote:
> []
>> I lost 7 x pcs Jun-Sept this year after local mains substation
>> transformer self destructed so my system with GPS is down.
> []
>> David
>
> Very sorry to hear about that David, a true pain! Perhaps a chance to
> replace with some lower-power kit, though?
Four of those were/are < 50W each and a low power Soekris equivalent
> On 01/11/2012 09:27, David Lord wrote:
> []
>> I lost 7 x pcs Jun-Sept this year after local mains substation
>> transformer self destructed so my system with GPS is down.
> []
>> David
>
> Very sorry to hear about that David, a true pain! Perhaps a chance to
> replace with some lower-power kit, though?
is too expensive for me if the existing motherboards and ram are
still working. I need two or three ethernet and am unable to find
equivalent boards for less than arm + leg prices. How many watts do
I need to save for spending an extra 200 quid per board?
I now have a couple of new Atom boards but overlooked the lack of
eide interfaces :-(
I've never tried PXE-boot but that'ts option one. After first one the
remainder will be very easy.
I'm also investing in a DIY surge protector per system as the three
UPS I had were no protection and failed.
David
Kennedy, Paul
Nov 1, 2012, 8:01:43 PM11/1/12
to
That is one description. Another would be it is a fully functional
linux computer with LAN, HDMI, SVideo, Audio, USB, Serial, and a GPIO
bus with the footprint of a credit card, no moving parts which draws
only 2-3 watts for US$35.
My pi units run various processes such as NTP, web hosting and data IO
at a fraction of the cost of conventional hardware. Step changes in
computing technology are pretty rare. Having developed on them a couple
of months, I put the pi into that category.
Oh yes, and the silence of the pi's is worth the US$35 alone.
It really depends if you prefer your glass to be half full or half empty
;-)
regards
pk
_______________________________________________
questions mailing list
ques...@lists.ntp.org
http://lists.ntp.org/listinfo/questions
linux computer with LAN, HDMI, SVideo, Audio, USB, Serial, and a GPIO
bus with the footprint of a credit card, no moving parts which draws
only 2-3 watts for US$35.
My pi units run various processes such as NTP, web hosting and data IO
at a fraction of the cost of conventional hardware. Step changes in
computing technology are pretty rare. Having developed on them a couple
of months, I put the pi into that category.
Oh yes, and the silence of the pi's is worth the US$35 alone.
It really depends if you prefer your glass to be half full or half empty
;-)
regards
pk
questions mailing list
ques...@lists.ntp.org
http://lists.ntp.org/listinfo/questions
unruh
Nov 2, 2012, 2:37:11 AM11/2/12
to
On 2012-11-02, Kennedy, Paul <P.Ke...@fugro.com.au> wrote:
> That is one description. Another would be it is a fully functional
> linux computer with LAN, HDMI, SVideo, Audio, USB, Serial, and a GPIO
> bus with the footprint of a credit card, no moving parts which draws
> only 2-3 watts for US$35.
Yes, it is pretty amazing.
> That is one description. Another would be it is a fully functional
> linux computer with LAN, HDMI, SVideo, Audio, USB, Serial, and a GPIO
> bus with the footprint of a credit card, no moving parts which draws
> only 2-3 watts for US$35.
Charles Elliott
Nov 5, 2012, 7:57:39 AM11/5/12
to
I went thru 5-6 Corsair power supplies (PSUs) of monotonically increasing
wattage, all of which Corsair replaced at the cost of one-way shipping. I
could not figure out what was causing it, until finally an outage occurred
that fried the motherboard during the day when I happened to be home and
working. The lights dimmed and when the power came back up, the motherboard
was gone.
In Pennsylvania, USA, we have "consumer choice": We can buy electricity from
any utility willing to sell it and having a permit to operate in
Pennsylvania. So currently I buy from a utility in Texas, perhaps from some
coal-eating, CO2 belching monstrosity, and it is just wheeled across the
country. In any case, when they switched in the wires to connect to a
foreign power source there was apparently some sort of new transient created
in the transmission lines that fried everything electronic in its path,
including my motherboard, and I hypothesize, the PSUs.
I have an "APC Back-UPS XS 1300G" that has a warranty for equipment electric
failure. APC replaced the UPS, but denied the claim for the motherboard.
However, on appeal I was able to prove with actual data and logic that the
electrical transient that occurred must have caused the motherboard failure.
So, APC sent a check for $400, which was the replacement cost, not the
purchase price. The process was not fast -- it took months -- but APC
finally lived up to its guarantee.
Now I have an expensive surge protector at the wall socket, the APC UPS
plugged in to that, and the PC plugged into the UPS. Despite several
significant, observable electrical transients, I have had no computer
problems since installing the new surge protector.
There is meant to be a lesson (other than verbosity pays) here somewhere.
Charles Elliott
> -----Original Message-----
> From: questions-bounces+elliott.ch=veriz...@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=veriz...@lists.ntp.org] On
> Behalf Of David Taylor
> Sent: Thursday, November 01, 2012 1:29 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] What is the NTP recovery time from 16s
> step in GPSserver?
>
wattage, all of which Corsair replaced at the cost of one-way shipping. I
could not figure out what was causing it, until finally an outage occurred
that fried the motherboard during the day when I happened to be home and
working. The lights dimmed and when the power came back up, the motherboard
was gone.
In Pennsylvania, USA, we have "consumer choice": We can buy electricity from
any utility willing to sell it and having a permit to operate in
Pennsylvania. So currently I buy from a utility in Texas, perhaps from some
coal-eating, CO2 belching monstrosity, and it is just wheeled across the
country. In any case, when they switched in the wires to connect to a
foreign power source there was apparently some sort of new transient created
in the transmission lines that fried everything electronic in its path,
including my motherboard, and I hypothesize, the PSUs.
I have an "APC Back-UPS XS 1300G" that has a warranty for equipment electric
failure. APC replaced the UPS, but denied the claim for the motherboard.
However, on appeal I was able to prove with actual data and logic that the
electrical transient that occurred must have caused the motherboard failure.
So, APC sent a check for $400, which was the replacement cost, not the
purchase price. The process was not fast -- it took months -- but APC
finally lived up to its guarantee.
Now I have an expensive surge protector at the wall socket, the APC UPS
plugged in to that, and the PC plugged into the UPS. Despite several
significant, observable electrical transients, I have had no computer
problems since installing the new surge protector.
There is meant to be a lesson (other than verbosity pays) here somewhere.
Charles Elliott
> -----Original Message-----
> From: questions-bounces+elliott.ch=veriz...@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=veriz...@lists.ntp.org] On
> Behalf Of David Taylor
> Sent: Thursday, November 01, 2012 1:29 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] What is the NTP recovery time from 16s
> step in GPSserver?
>
0 new messages