Re: [ntp:questions] Start of new GPS 1024 week epoch
On 14/08/2013 21:20, Rob wrote: [] The raspberry pi already does that. It regularly (and on shutdown) saves the date/time in a file and loads that on boot. No need to handle this in ntpd. it is done in the /etc/init.d scripts. Thanks, Rib, I didn't know that. Do you happen to know which file, as a matter of interest? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 14/08/2013 22:07, Harlan Stenn wrote: David Malone writes: Indeed - you need to have a timestamp within about ten years of correct before you start up, otherwise the problem will be worse. Ntp has the same problem in figuring out the ntp epoch, though we've yet to see an ntp timestamp wrap around. ntp-dev has a fix for this problem - while the original solution was make sure the clock is correct to within ~65 years' time the new code uses a date of compile value, and needs the system time to be either 10 years' before that date or up to 128 years' after that date. See http://bugs.ntp.org/show_bug.cgi?id=1995 for more information (thanks, Juergen!). H If you make that 9.5 years rather than 10 it might then cover the 500-week period mentioned by Magnus. Judging by some reports here, people may be using NTP more than 10 years old. Does this fix cause a problem in that case? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 14/08/2013 17:44, Rob wrote: [] How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. [] Some receivers have battery backup, in fact all but one of the receiver types I use have this. I have an awful feeling that you are right about the potential for failure - it might take 19 years to find out, though! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 17:44, Rob wrote: [] How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. [] Some receivers have battery backup, in fact all but one of the receiver types I use have this. Ok but what happens when the battery is replaced? I have an awful feeling that you are right about the potential for failure - it might take 19 years to find out, though! Well, the first rollover was in 1999 and the next one will be in 2018. Warnings went out about the problem in 1993, and manufacturers started to implement fixes for it. It can be expected that the first problems arising from those fixes will appear 19 years later, i.e. in 2012. Manufacturers that were implementing their fix after one year have their problem now. Manufacturers that waited 2 years have it next year. We might have problems all the way up to 2018. Of course those manufacturers that updated their fix every time they released new software, automatically or not, (like what is apparently done in ntpd) can get by whenever the life of their products is less than 19 years after the last software update. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 21:20, Rob wrote: [] The raspberry pi already does that. It regularly (and on shutdown) saves the date/time in a file and loads that on boot. No need to handle this in ntpd. it is done in the /etc/init.d scripts. Thanks, Rib, I didn't know that. Do you happen to know which file, as a matter of interest? The file is /etc/fake-hwclock.data It is set by the command fake-hwclock save which is in /etc/cron.hourly/fake-hwclock and in /etc/init.d/fake-hwclock which is called in the startup and shutdown sequence. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 15/08/2013 08:27, Rob wrote: The file is /etc/fake-hwclock.data It is set by the command fake-hwclock save which is in /etc/cron.hourly/fake-hwclock and in /etc/init.d/fake-hwclock which is called in the startup and shutdown sequence. Thanks, Rob, and my apologies for a finger slip misspelling your name! I do have that file, and it has the date and (I think UTC) time as its text contents. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 15/08/2013 08:34, Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 17:44, Rob wrote: [] How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. [] Some receivers have battery backup, in fact all but one of the receiver types I use have this. Ok but what happens when the battery is replaced? [] Hope and pray? Wish for a large capacitor or flash-rom? I had thought that either ephemeris or almanac data might contain the real UTC time, but apparently it does not. Obviously a system designed too far in advance of the Year2000 fuss and bother! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Acutime Gold
I am trying to get this right, remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l4 16 3770.000 -0.003 0.005 *GPS_PALISADE(0) .GPS.0 l4 16 3770.0000.014 0.002 For the above wouldn't I need to advance PPS by time1 0.003? And retard the palisade by time1 -0.014? Assuming these are the average values. Because I tried those values and the PPS got marked bad ticker and the palisade was unreachable! Mark me as confused please.. -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of E-Mail Sent to this address will be added to the BlackLists Sent: Thursday, 15 August 2013 12:21 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Acutime Gold Mark C. Stephens wrote: remote refid st t when poll reach delay offset jitter === oPPS(0) .PPS. 0 l- 16 377 0.000 -0.001 0.004 *GPS_PALISADE(0) .GPS. 0 l 16 16 377 0.000 0.018 0.008 I was thinking about that, but how do I correlate 0.017 to time1 ? BlackList Wrote: Why can't you fix the offset with time 1 in for Driver 29? fudge 127.127.29.0 time1 0.017 -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-15, unruh un...@invalid.ca wrote: On 2013-08-14, Steve Kostecke koste...@ntp.org wrote: The time server specified in each of those lines is the one which is currently selected as the sys_peer. But as I understand it, it is simply one of the systems which is not a false ticker, and has not real significance other than that. Ie, its time is not treated any differently than any of the other systems regarded as true chimers by the selection algorithm. Or do I misunderstand something? The sys_peer is chosen after the select[ion] alrorithm scans the associations for selectable candiates _and_ after the cluster (combine?) algorithm casts out the outliers. In the last paragraph at http://www.eecis.udel.edu/~mills/ntp/html/warp.html we see: The algorithms described on the Mitigation Rules and the prefer Keyword page combine the survivor offsets, designate one of them as the system peer and produces the final offset used by the algorithm described on the Clock Discipline Algorithm page to adjust the system clock time and frequency. Section 6 of the Mitigation Rules page (http://www.eecis.udel.edu/~mills/ntp/html/prefer.html) clarifies how the process works: As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The survivor list is then sorted by increasing root distance and the first entry temporarily designated the system peer. At this point the following contributors to the system clock discipline may be available: * (potential) system peer, if there are survivors; * orphan parent, if present; * local driver, if present; * modem driver, if present; * prefer peer, if present; * PPS driver, if present. The mitigation algorithm proceeds in three steps in turn. 1. If there are no survivors, the modem driver becomes the only survivor if there is one. If not, the local driver becomes the only survivor if there is one. If not, the orphan parent becomes the only survivor if there is one. If the number of survivors at this point is less than the minsane option of the tos command, the algorithm is terminated and the system variables remain unchanged. Note that minsane is by default 1, but can be set at any value including 0. 2. If the prefer peer is among the survivors, it becomes the system peer and its offset and jitter are inherited by the corresponding system variables. Otherwise, the combine algorithm computes these variables from the survivor population. 3. If there is a PPS driver and the system clock offset at this point is less than 0.4 s, and if there is a prefer peer among the survivors or if the PPS peer is designated as a prefer peer, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables, thus overriding any variables already computed. Note that a PPS driver is present only if PPS signals are actually being received and enabled by the associated driver. If none of the above is the case, the data are disregarded and the system variables remain as they are. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-15, Steve Kostecke koste...@ntp.org wrote: On 2013-08-15, unruh un...@invalid.ca wrote: On 2013-08-14, Steve Kostecke koste...@ntp.org wrote: The time server specified in each of those lines is the one which is currently selected as the sys_peer. But as I understand it, it is simply one of the systems which is not a false ticker, and has not real significance other than that. Ie, its time is not treated any differently than any of the other systems regarded as true chimers by the selection algorithm. Or do I misunderstand something? The sys_peer is chosen after the select[ion] alrorithm scans the associations for selectable candiates _and_ after the cluster (combine?) algorithm casts out the outliers. In the last paragraph at http://www.eecis.udel.edu/~mills/ntp/html/warp.html we see: The algorithms described on the Mitigation Rules and the prefer Keyword page combine the survivor offsets, designate one of them as the system peer and produces the final offset used by the algorithm described on the Clock Discipline Algorithm page to adjust the system clock time and frequency. Section 6 of the Mitigation Rules page (http://www.eecis.udel.edu/~mills/ntp/html/prefer.html) clarifies how the process works: As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The survivor list is then sorted by increasing root distance and the first entry temporarily designated the system peer. At this point the following contributors to the system clock discipline may be available: * (potential) system peer, if there are survivors; * orphan parent, if present; * local driver, if present; * modem driver, if present; * prefer peer, if present; * PPS driver, if present. The mitigation algorithm proceeds in three steps in turn. 1. If there are no survivors, the modem driver becomes the only survivor if there is one. If not, the local driver becomes the only survivor if there is one. If not, the orphan parent becomes the only survivor if there is one. If the number of survivors at this point is less than the minsane option of the tos command, the algorithm is terminated and the system variables remain unchanged. Note that minsane is by default 1, but can be set at any value including 0. ] This is ambiguous. If no survivors- local/orphan. If suvivorsminsane (which is almost always true if no survivors)- unchanged. If I set minsane to 100 and have only 5 peers, what happens? Is local/orphan used or is nothing changed. 2. If the prefer peer is among the survivors, it becomes the system peer In the above, there are survivors, but fewer than minsane. Does this apply? or does this apply only if survivorsminsane? and its offset and jitter are inherited by the corresponding system variables. Otherwise, the combine algorithm computes these variables from the survivor population. Otherwise the combine algorithm computes these variables from the survivor population does not say how it does so. Is it the ntp offset of the system peer? or is it the offset from some (weughted?) average of the survivors? Since some of the survivor's data could be 3 hours old (poll of 10 with the 1/8 selection) and others 1 sec old. Does this enter the weighting? s 3. If there is a PPS driver and the system clock offset at this point is less than 0.4 s, and if there is a prefer peer among the survivors or if the PPS peer is designated as a prefer peer, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables, thus overriding any variables already computed. Note that a PPS driver is present only if PPS signals are actually being received and enabled by the associated driver. If none of the above is the case, the data are disregarded and the system variables remain as they are. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 08/15/2013 07:55 AM, David Taylor wrote: On 14/08/2013 22:07, Harlan Stenn wrote: David Malone writes: Indeed - you need to have a timestamp within about ten years of correct before you start up, otherwise the problem will be worse. Ntp has the same problem in figuring out the ntp epoch, though we've yet to see an ntp timestamp wrap around. ntp-dev has a fix for this problem - while the original solution was make sure the clock is correct to within ~65 years' time the new code uses a date of compile value, and needs the system time to be either 10 years' before that date or up to 128 years' after that date. See http://bugs.ntp.org/show_bug.cgi?id=1995 for more information (thanks, Juergen!). H If you make that 9.5 years rather than 10 it might then cover the 500-week period mentioned by Magnus. I do not mention a 500 week period. I mention a 1024 week period with various phases, 500, 512 and obviously 729 (wrapped this Sunday as we went into week 1753). Judging by some reports here, people may be using NTP more than 10 years old. Does this fix cause a problem in that case? Not really. This problem is common mode to recent and 10 year old NTPs. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 08/15/2013 10:22 AM, David Taylor wrote: On 15/08/2013 08:34, Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 17:44, Rob wrote: [] How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. [] Some receivers have battery backup, in fact all but one of the receiver types I use have this. Ok but what happens when the battery is replaced? [] Hope and pray? Wish for a large capacitor or flash-rom? I had thought that either ephemeris or almanac data might contain the real UTC time, but apparently it does not. Obviously a system designed too far in advance of the Year2000 fuss and bother! They completely avoid it by not numbering it that way. They have their own numbering scheme that fit's the system, and the conversion over to UTC is an added feature. It's all in ICD-GPS-200 for the current set of details, and in the ION red book series for the early stages. GPS and GPS problems is best understood if you realize that everything is counted in the GPS clock machinery with it's own set of gears. Conversion isn't that hard and it is done every second in the GPS receiver. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Acutime Gold
Mark C. Stephens wrote: remote refid st t when poll reach delay offset jitter oPPS(0) .PPS. 0 l4 16 377 0.000 -0.003 0.005 *GPS_PALISADE(0) .GPS. 0 l4 16 377 0.0000.014 0.002 For the above wouldn't I need to advance PPS by time1 0.003? I don't think so. And retard the palisade by time1 -0.014? Assuming these are the average values. Because I tried those values and the PPS got marked bad ticker and the palisade was unreachable! AFAIK, the way most people do it, is to have several refclocks / servers, and change to noselect, the one you want to check the serial end of line offset; let it run for a day or two, and take the average. According to the driver doc, a serial end of line time1 offset of around 20ms is common. You might also need to increase the mindist. You might also want to prefer the PPS. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 2013-08-15, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 08/15/2013 10:22 AM, David Taylor wrote: On 15/08/2013 08:34, Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 17:44, Rob wrote: [] How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. [] Some receivers have battery backup, in fact all but one of the receiver types I use have this. Ok but what happens when the battery is replaced? [] Hope and pray? Wish for a large capacitor or flash-rom? I had thought that either ephemeris or almanac data might contain the real UTC time, but apparently it does not. Obviously a system designed too far in advance of the Year2000 fuss and bother! They completely avoid it by not numbering it that way. They have their own numbering scheme that fit's the system, and the conversion over to UTC is an added feature. It's all in ICD-GPS-200 for the current set of details, and in the ION red book series for the early stages. GPS and GPS problems is best understood if you realize that everything is counted in the GPS clock machinery with it's own set of gears. Conversion isn't that hard and it is done every second in the GPS receiver. That is fine, but I think that the question is what are those internal geers and do those internal geers have a rollover time? Ie, for how long a time period is there a unique mapping from the internals of GPS and the time (UTC or whatever). Obviously the oscillations of the H atoms in the H laser clocks have a rollover of picoseconds. Somewhere in those sattelites is some counter with a lot longer period before it rolls over. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 14/08/13 16:03, Nils Brubaker wrote: all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. I believe the error statistics and stratum, sent downstream, come from the system peer. The actual time is a weighted average of good servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-15, unruh un...@invalid.ca wrote:
On 2013-08-15, Steve Kostecke koste...@ntp.org wrote:
[---=| Quote block shrinked by t-prot: 42 lines snipped |=---]
The mitigation algorithm proceeds in three steps in turn.
1. If there are no survivors, the modem driver becomes the only
survivor if there is one. If not, the local driver becomes the only
survivor if there is one. If not, the orphan parent becomes the only
survivor if there is one. If the number of survivors at this point
is less than the minsane option of the tos command, the algorithm
is terminated and the system variables remain unchanged. Note that
minsane is by default 1, but can be set at any value including 0.
] This is ambiguous.
Seems pretty straightforward to me ...
if (survivors == NULL) {
if exists(modem) {
survivors = modem
} elseif exists(undisciplined_local_clock) {
survivors = undisciplined_local_clock
} elseif exists(orphan_parent) {
survivors = orphan_parent
}
}
abort if (count(survivors) minsane)
If no survivors- local/orphan. If suvivorsminsane
(which is almost always true if no survivors)- unchanged.
If I set minsane to 100 and have only 5 peers, what happens? Is
local/orphan used or is nothing changed.
You can break almost anything if you grossly misconfigure it.
--
Steve Kostecke koste...@ntp.org
NTP Public Services Project - http://support.ntp.org/
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Acutime Gold
If I have palisade prefer PPS comes up fine within a minute or so. When I tried making pps prefer it got an x beside the PPS. I waited for an hour or 2 but it was still marked bad. Not sure what's going on there.. this is the relevant part of the config: # PPS server 127.127.22.0 minpoll 4 maxpoll 4 # prefer # noselect fudge 127.127.22.0 flag2 0 flag3 1 flag4 0 # time1 0.16 # palisade on ttyS0 server 127.127.29.0 minpoll 4 maxpoll 4 prefer fudge 127.127.29.0 flag2 0 # time1 0.15 As you can see I have tried different time1 for both clocks. I am not familiar with the mindist option. Will go check it out. I'll wait until the jitter settles down and post the offset. -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of E-Mail Sent to this address will be added to the BlackLists Sent: Friday, 16 August 2013 6:59 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Acutime Gold Mark C. Stephens wrote: remote refid st t when poll reach delay offset jitter oPPS(0) .PPS. 0 l4 16 377 0.000 -0.003 0.005 *GPS_PALISADE(0) .GPS. 0 l4 16 377 0.0000.014 0.002 For the above wouldn't I need to advance PPS by time1 0.003? I don't think so. And retard the palisade by time1 -0.014? Assuming these are the average values. Because I tried those values and the PPS got marked bad ticker and the palisade was unreachable! AFAIK, the way most people do it, is to have several refclocks / servers, and change to noselect, the one you want to check the serial end of line offset; let it run for a day or two, and take the average. According to the driver doc, a serial end of line time1 offset of around 20ms is common. You might also need to increase the mindist. You might also want to prefer the PPS. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 15/08/2013 20:18, Magnus Danielson wrote: [] I do not mention a 500 week period. I mention a 1024 week period with various phases, 500, 512 and obviously 729 (wrapped this Sunday as we went into week 1753). OK, swap period with phase. Judging by some reports here, people may be using NTP more than 10 years old. Does this fix cause a problem in that case? Not really. This problem is common mode to recent and 10 year old NTPs. Cheers, Magnus I was thinking that is the windows was only 10 years from compile date, using an older NTP might be an issue, although it would need to be 10 years from the first NTP from the fix date, and that hasn't yet been release (AIUI) as it's still in the development branch. Good to know that the problem is n#being addressed. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Acutime Gold
Mark C. Stephens wrote: If I have palisade prefer PPS comes up fine within a minute or so. When I tried making pps prefer it got an x beside the PPS. I waited for an hour or 2 but it was still marked bad. Not sure what's going on there.. this is the relevant part of the config: # PPS server 127.127.22.0 minpoll 4 maxpoll 4 # prefer # noselect fudge 127.127.22.0 flag2 0 flag3 1 flag4 0 # time1 0.16 # palisade on ttyS0 server 127.127.29.0 minpoll 4 maxpoll 4 prefer fudge 127.127.29.0 flag2 0 # time1 0.15 fudge 127.127.29.0 time1 0.015 # milli-seconds, not micro-seconds As you can see I have tried different time1 for both clocks. I am not familiar with the mindist option. tos mindist 0.020 -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 15/08/2013 21:33, Magnus Danielson wrote: [] They completely avoid it by not numbering it that way. They have their own numbering scheme that fit's the system, and the conversion over to UTC is an added feature. It's all in ICD-GPS-200 for the current set of details, and in the ION red book series for the early stages. GPS and GPS problems is best understood if you realize that everything is counted in the GPS clock machinery with it's own set of gears. Conversion isn't that hard and it is done every second in the GPS receiver. Cheers, Magnus Thanks, Magnus. I've not heard of ICD-GPS-2000 or ION red book before. Perhaps one day I will look them up. GPS continues to impress me - I counted and on holiday recently we took (at least) 7 GPS receivers - his and hers smart-phones, 2 iPads, Garmin GPS 60 CSx, Ventus 750, and one built into my Sony HX200V camera! The Garmin spent much of its time with a puck antenna stuck on the cabin porthole plotting our course. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
