Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d807ec8$0$2501$db0fe...@news.zen.co.uk... David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ilprm0$3kv$1...@news.eternal-september.org... No reason not to downgrade, Q, if you don't need the fixes and features in the current firmware. I understand that some folk are running on firmware 3.20, Yes, I do have copies, but you can also download here: http://www.gawisp.com/perry/oem_sensor/ Hi David, A reply from Garmin! Also I tried the downgrade - its in and working, though I'm not seeing much if any difference in the numbers yet - I should be able to post some data later in the week once its calmed down. Thank you for contacting Garmin Europe. Thank you for your email this is something that we have put to our engineering teams in the US and they are looking into the cause. This should hopefully be something which can be fixed in a future update but at this time I don't have a date for release of the next update. Kind regards, Name Removed Marine Technical Support - Garmin Europe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d887390$0$2524$da0fe...@news.zen.co.uk... [] Hi David, A reply from Garmin! Also I tried the downgrade - its in and working, though I'm not seeing much if any difference in the numbers yet - I should be able to post some data later in the week once its calmed down. Well, that's good, it means one more report into Garmin, and increases the likelihood of a fix. From my tests on a Sure GPS board, it many be important to get NTP to look for the first sentence sent, although I guess you must already be down to a single NMEA sentence by now. It may be worth trying 115,200 baud as well. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ima1lb$o0v$1...@news.eternal-september.org... From my tests on a Sure GPS board, it many be important to get NTP to look for the first sentence sent, although I guess you must already be down to a single NMEA sentence by now. It may be worth trying 115,200 baud as well. If you have no objections it may be easier to take this 'off-list' and email you direct - it will save all the poor folk on here having to listen to my insane testing - once everything is working and playing nice I can post back. Let me know if this is OK and I'll drop you an email later this evening. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:imandk$5ic$2...@news.eternal-september.org... I would prefer on-list, as others may be able to provide help and useful input. I'm not sure I can add more than is already on my Web pages. Yep - that's totally fine. I need to have a clean up on this machine now, and I think I'm going to stick 2.6.37 kernel on it with native PPS support and see what happens. This may take a while! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d88df4c$0$2514$db0fe...@news.zen.co.uk... [] If you have no objections it may be easier to take this 'off-list' and email you direct - it will save all the poor folk on here having to listen to my insane testing - once everything is working and playing nice I can post back. Let me know if this is OK and I'll drop you an email later this evening. I would prefer on-list, as others may be able to provide help and useful input. I'm not sure I can add more than is already on my Web pages. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d88e97c$0$12167$fa0fc...@news.zen.co.uk... I need to have a clean up on this machine now, and I think I'm going to stick 2.6.37 kernel on it with native PPS support and see what happens. Scrap that - it wouldn't boot and hung on udev and I don't have time to rebuild kernels at the moment. There is also no LinuxPPS for 2.6.18 kernels - there's a 17 and a 19. PPSKit-lite is the same situation. Looks like I won't be able to take this forward now for quite a long time. (That box is due for replacement but its going to be 6 months maybe depending what my day job work load is like.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d7fd7ae$0$2503$db0fe...@news.zen.co.uk... David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ilc6um$4s8$1...@news.eternal-september.org... To me it should be common courtesy to reply as soon as possible, even if it's just an acknowledgement. You might learn more from a phone call Still no reply - but I've not had time to call them up yet and start making a noise. Do you have a copy of the old firmware - and is there any reason not to downgrade? No reason not to downgrade, Q, if you don't need the fixes and features in the current firmware. I understand that some folk are running on firmware 3.20, Yes, I do have copies, but you can also download here: http://www.gawisp.com/perry/oem_sensor/ Specifically: http://www.gawisp.com/perry/oem_sensor/GPS18xPC_LVC_320.exe Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ilprm0$3kv$1...@news.eternal-september.org... No reason not to downgrade, Q, if you don't need the fixes and features in the current firmware. I understand that some folk are running on firmware 3.20, Yes, I do have copies, but you can also download here: http://www.gawisp.com/perry/oem_sensor/ Specifically: http://www.gawisp.com/perry/oem_sensor/GPS18xPC_LVC_320.exe Thanks David - I might give that a try at some point in the week and see how it runs. At the moment the unit is only used for time keeping so some of the new stuff makes no difference. - I'll see how it goes and report back by the weekend hopefully. Cheers for your help ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ilc6um$4s8$1...@news.eternal-september.org... To me it should be common courtesy to reply as soon as possible, even if it's just an acknowledgement. You might learn more from a phone call Still no reply - but I've not had time to call them up yet and start making a noise. Do you have a copy of the old firmware - and is there any reason not to downgrade? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:il7bhl$vgg$1...@news.eternal-september.org... I hope that Garmin at least acknowledge your request - let's hope the delay means that it being passed on. Nothing yet - not even a robot responder telling my the form had been logged... I'm tempted to try and call them tomorrow, but I don't know how that might go. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Q ..@.. wrote in message news:4d79277a$0$2538$da0fe...@news.zen.co.uk... David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:il7bhl$vgg$1...@news.eternal-september.org... I hope that Garmin at least acknowledge your request - let's hope the delay means that it being passed on. Nothing yet - not even a robot responder telling my the form had been logged... I'm tempted to try and call them tomorrow, but I don't know how that might go. To me it should be common courtesy to reply as soon as possible, even if it's just an acknowledgement. You might learn more from a phone call Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Hi David, I sent off the query/problem to them a few days ago via the online form - alas no reply as yet though. I've had problems my end anyway the box this is attached to decided to die and I had to replace the CPU which did all sorts of odd things with the clock and required a change of timer source to stop the thing running mad. It's taken a couple of weeks for it to sort its self out and the jitter/offset to come back down to what they where. Anyway if I hear anything back I'll post here. I hope that Garmin at least acknowledge your request - let's hope the delay means that it being passed on. Sorry to hear about the box problems - I replaced my Pentium 133 system with a fanless Intel Atom system when that happened. The 18x is now being used just as a PPS reference on my Windows-7 SP1 system (and I think SP1 has stopped the glitches I used to see, so better timekeeping), with the NMEA part set to noselect: # PPS serial port driver - uses serialpps.sys server 127.127.22.1 minpoll 4 # PPS using serialpps.sys # NMEA serial port driver server 127.127.20.1 minpoll 4 mode 33 noselect # 19200bps, NMEA serial port Checking further, before SP1 averaged jitter was 22 - 80 microseconds, and after SP1 18 - 28 microseconds, so Windows-7 SP1 has helped the timekeeping. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ijk0a0$ssp$1...@news.eternal-september.org... Ok I'll go back over your past posts re the problem and report it myself to Garmin UK and see what they say - once I get something back I'll let you know. I have 3.60 running anyway with no new problems (that I can see) Thanks, Q, I can't see it doing any harm. Cheers, David Hi David, I sent off the query/problem to them a few days ago via the online form - alas no reply as yet though. I've had problems my end anyway the box this is attached to decided to die and I had to replace the CPU which did all sorts of odd things with the clock and required a change of timer source to stop the thing running mad. It's taken a couple of weeks for it to sort its self out and the jitter/offset to come back down to what they where. Anyway if I hear anything back I'll post here. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
http://www.sureelectronics.net/goods.php?id=99 Thanks for the link! Even though I already have a big bunch of GPSs, I've placed an order for one of those kits. :-) I really liked the multiple interfaces, the ms precision for the NMEA timestamp and the total price which is below the minimum import duty floor here in Norway. :-) Terje I'm really looking forward to your expert comments on this board! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ijhb50$ifm$1...@news.eternal-september.org... V3.60 was out at the start of Jan I think - but there is nothing in the notes to say this issue is resolved. Do we need to chase this with Garmin UK? Yes, we do. I've heard nothing back, so I'll chase them now. I'm supposed to be on the Garmin RSS feed for updates, but I didn't see 3.60 announced. I've now downloaded a copy but, as you say, it doesn't claim to address the issue. I'm still waiting for my Sure Electronics equivalent to arrive from China: Ok I'll go back over your past posts re the problem and report it myself to Garmin UK and see what they say - once I get something back I'll let you know. I have 3.60 running anyway with no new problems (that I can see) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor wrote: I'm supposed to be on the Garmin RSS feed for updates, but I didn't see 3.60 announced. I've now downloaded a copy but, as you say, it doesn't claim to address the issue. I'm still waiting for my Sure Electronics equivalent to arrive from China: http://www.sureelectronics.net/goods.php?id=99 Thanks for the link! Even though I already have a big bunch of GPSs, I've placed an order for one of those kits. :-) I really liked the multiple interfaces, the ms precision for the NMEA timestamp and the total price which is below the minimum import duty floor here in Norway. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Ok I'll go back over your past posts re the problem and report it myself to Garmin UK and see what they say - once I get something back I'll let you know. I have 3.60 running anyway with no new problems (that I can see) Thanks, Q, I can't see it doing any harm. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:igu5i1$hn9$1...@news.eternal-september.org... unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij3r1n.a4g.un...@wormhole.physics.ubc.ca... [] Your referent is somewhat unclear. If you are saying that your unit is out of spec, then return it. When operated with earlier firmware, the unit is in spec, but may be out of spec with the V3.50 firmware. Rather than return the unit, I am hoping to work with Garmin to produce a better firmware for all users. V3.60 was out at the start of Jan I think - but there is nothing in the notes to say this issue is resolved. Do we need to chase this with Garmin UK? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Jan Ceuleers wrote: On 16/01/11 09:11, Chris Albertson wrote: No, if it is not _processed right at the UTC second it is pointless. The Motorola GPS allows you to adjust the timing of the pulse to account for delay in the antenna feed line and serial line. I was also thinking about avoiding interrupt collisions. In an ideal world, if the PPS interrupt occurs exactly at the UTC second it is going to coincide with the system's timer interrupt, is it not? That's even if the system has only one PPS source. So if the GPS receiver is capable of shifting its PPS signal in time, why not shift it to a quiet part of the second in interrupt terms, and then fudge that away in ntpd? This is exactly why and how the Oncore works the way it does. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
The only way to know is to compare to another reference assumed to be correct. Pool NTP servers would be accurate enough for that. The GPSes (Motorola Oncore) I use have a related problem in that they allow the pulse to be adjust so that it happens before the UTC second or any time during the second. So I actually have a choice. But how to set it and know it is right? ??? That would make the pps totally useless. If it does not occur on the UTC second, it is pointless. No, if it is not _processed right at the UTC second it is pointless. The Motorola GPS allows you to adjust the timing of the pulse to account for delay in the antenna feed line and serial line. A GPS might have 50 feet of antenna cable and that would cause about a 50 ns delay in the signal. And then in my case the PPS, after it leaves the GPS goes through one 74F04 gate (5 ns delay) followed my a MAX232 which has a bit more delay.The Motorola UT+ and newer, have pulse accuracy that is far better than the cable speed of light delay so if the unit did not have the adjustment the cable would be the major source of error. So even if the GPS is perfect if the pulse has to go down a cable the pulse comming out the end of the cable will be late. Altogether it makes sense to advance the pulse about 80 nS. What you'd do is adjust the timing until it was a best match to the other reference clocks you have or lacking that to a set of pool NTP servers Since you are using the pool as your time source, just use them. This device adds nothing in that case. I am assuming, as with the GPS18. that the unit emits a PPS pulse exactly on the seconds transition of UTC time. How do you know the GPS18 has the pulse right on the second? Certainly there is some delay however small. I bet that if you had a second source of UTC seconds it would not match, they never do Only a person who owns one clock thinks he knows what time it is, anyone who owns two or more is never really sure. You'd think setting the UTC PPS phase to match the pool servers would make your local reference clock only as good as a pool server but that would be true if you sync'd on only one pulse. If you averaged many thousands of pulses you get much better. The local GPS even if it has a small offset to UTC will have much lass jitter than the pool server -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 16/01/11 09:11, Chris Albertson wrote: No, if it is not _processed right at the UTC second it is pointless. The Motorola GPS allows you to adjust the timing of the pulse to account for delay in the antenna feed line and serial line. I was also thinking about avoiding interrupt collisions. In an ideal world, if the PPS interrupt occurs exactly at the UTC second it is going to coincide with the system's timer interrupt, is it not? That's even if the system has only one PPS source. So if the GPS receiver is capable of shifting its PPS signal in time, why not shift it to a quiet part of the second in interrupt terms, and then fudge that away in ntpd? Cheers, Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Jan Ceuleers janspam.ceule...@skynet.be wrote: On 16/01/11 09:11, Chris Albertson wrote: No, if it is not _processed right at the UTC second it is pointless. The Motorola GPS allows you to adjust the timing of the pulse to account for delay in the antenna feed line and serial line. I was also thinking about avoiding interrupt collisions. In an ideal world, if the PPS interrupt occurs exactly at the UTC second it is going to coincide with the system's timer interrupt, is it not? That's even if the system has only one PPS source. You assume that system's timer interrupt is somehow being synchronized with the UTC second. I don't think that is what is really happening. The interrupt remains free-running (can occur at any moment, and will usually occur several times a second) and what is varied is the keeping of a local time variable in relation to this interrupt. The system remembers at what time the interrupt occurs and sets the system time to that (incremented) value whenever the interrupt comes in. When a program would read the system time at the moment of the interrupt, it would not read xxx. seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 16/01/11 11:25, Rob wrote: Jan Ceuleersjanspam.ceule...@skynet.be wrote: I was also thinking about avoiding interrupt collisions. In an ideal world, if the PPS interrupt occurs exactly at the UTC second it is going to coincide with the system's timer interrupt, is it not? That's even if the system has only one PPS source. You assume that system's timer interrupt is somehow being synchronized with the UTC second. You're right. What then about the case of multiple PPS sources? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij2ign.o9d.un...@wormhole.physics.ubc.ca... [] Is the start of the nmea sentect coming more than one second after the PPS signal? Or is it just ending at the one second mark? The start of the NMEA sentence can be /after/ the leading edge of the next PPS signal, i.e. more than one second delayed. This from watching the 'scope rather than from an automated measurement. As reported by peerstats in NTP, the end of the single NMEA sentence is close to the leading edge of the next PPS signal. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote: On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. It may not have enough information. When the program only gets PPS pulses and NMEA sentences, it has no way of telling which NMEA time corresponds to which PPS pulse. Any system that determines the offset between the arrival of the NMEA sentences and the time that is indicated in them requires an external source of correct time to do the calibration, be it either once at setup time or continuously during use. With only the GPS device connected and no other time receivers or network time servers connected, this is not possible. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij14hc.qns.un...@wormhole.physics.ubc.ca... [] This is a problem in the coding of the program (gpsd?) that you are using to get the data. The computer clock is a good device for measuring the time between the PPS. The timestamp on the PPS and the timestamp on the beginning and end of the nmea transmission are more than sufficient infomation to link the nmea time to the PPS. While I agee that the GPS should not be taking more an a second to get the time to you, the program should also be robust enough to take that into account. This is on a system with no gpsd. This is from the device itself, with measurements confirmed with a 'scope, and confirmed by others. Your referent is somewhat unclear. If you are saying that your unit is out of spec, then return it. If you are saying something else, I do not know what it is. IF the unit operates to spec, then there is enough information to link the nmea sentence to its pulse. If it is operating out of spec, then there is no reason to even believe that the PPS is actually occuring on the turn of the second UTC. A broken device is, I agree, not very useful for timekeeping. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-15, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij1g6n.mnc.un...@wormhole.physics.ubc.ca... [] ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. No program is actually needed - just an oscilloscope looking at the PPS and serial outputs. In this particular case, there is no separate program as such, just ntpd with the type 20 refclock looking at the serial signal, and a type 22 refclock looking at the PPS signal through a modified device drive. So you are separating the PPS from the nmea, and wondering how to get them together again? The best way is for the same program to look at the PPS and the nmea so it can associate them. Your process is to deliberately separate them and then wondering why it is hard to associate them again. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij3r1n.a4g.un...@wormhole.physics.ubc.ca... [] Your referent is somewhat unclear. If you are saying that your unit is out of spec, then return it. When operated with earlier firmware, the unit is in spec, but may be out of spec with the V3.50 firmware. Rather than return the unit, I am hoping to work with Garmin to produce a better firmware for all users. If you are saying something else, I do not know what it is. IF the unit operates to spec, then there is enough information to link the nmea sentence to its pulse. If it is operating out of spec, then there is no reason to even believe that the PPS is actually occuring on the turn of the second UTC. A broken device is, I agree, not very useful for timekeeping. When the NMEA data arrives immediately after the PPS signal (within a few milliseconds rather than the expected few hundred milliseconds), and when that minimum expected delay is not specified, there is an ambiguity as to which PPS pulse the NMEA refers. The aim of my post was to suggest a work-round to that problem for users of the reference NTP implementation. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij3r8s.a4g.un...@wormhole.physics.ubc.ca... [] So you are separating the PPS from the nmea, and wondering how to get them together again? The best way is for the same program to look at the PPS and the nmea so it can associate them. Your process is to deliberately separate them and then wondering why it is hard to associate them again. No. I am trying to resolve a problem where the reference NTP software produced occasional large jumps in my original configuration, and reporting how I updated the configuration to a successful resolution. I am not separating anything at all - the signals which come from the GPS device are already separate, and it is the reference NTP which associates them. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x The basic steps were: - make the GPX18x LVC noselect so that NTP would not use it - enable the peerstats to measure where NTP thought the 18x end of message occurred - analyse the peerstats file to determine the apparent offset (which was -1.000 seconds, as it happened) - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf - restart NTP I hope that helps someone. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On Fri, Jan 14, 2011 at 08:40:25AM -, David J Taylor wrote: Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf Thanks for the information. I was curious about the new position averaging mode, but I'll wait until this is resolved. 1.0s offset is horrible, that will certainly break gpsd or any application that pairs pulses with following NMEA timestamps. Have you tried increasing baud rate to 38400 and disabling all unneeded NMEA sentences? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x The basic steps were: - make the GPX18x LVC noselect so that NTP would not use it - enable the peerstats to measure where NTP thought the 18x end of message occurred - analyse the peerstats file to determine the apparent offset (which was -1.000 seconds, as it happened) - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf - restart NTP I hope that helps someone. This is a problem in the coding of the program (gpsd?) that you are using to get the data. The computer clock is a good device for measuring the time between the PPS. The timestamp on the PPS and the timestamp on the beginning and end of the nmea transmission are more than sufficient infomation to link the nmea time to the PPS. While I agee that the GPS should not be taking more an a second to get the time to you, the program should also be robust enough to take that into account. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Thanks for the information. I was curious about the new position averaging mode, but I'll wait until this is resolved. 1.0s offset is horrible, that will certainly break gpsd or any application that pairs pulses with following NMEA timestamps. Have you tried increasing baud rate to 38400 and disabling all unneeded NMEA sentences? -- Miroslav Lichvar Miroslav, From reports elsewhere, it seems that the position averaging mode adds about 8ms to the delay. You can enable and disable the mode with the Garmin configuration software. NTP seems to work correctly with the - agreed horrible - 1.0s offset. That is with 19200 baud and just the single GPRMC sentence. (I think that's the one). So changing to 38400 baud wouldn't get me a lot (about 17ms earlier). Cheers, David Well 17ms would get you under the 1.0 sec cutoff. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij14l6.qns.un...@wormhole.physics.ubc.ca... [] Well 17ms would get you under the 1.0 sec cutoff. It seems that with ntpd there is no 1.0 sec cut-off - fortunately. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij14hc.qns.un...@wormhole.physics.ubc.ca... [] This is a problem in the coding of the program (gpsd?) that you are using to get the data. The computer clock is a good device for measuring the time between the PPS. The timestamp on the PPS and the timestamp on the beginning and end of the nmea transmission are more than sufficient infomation to link the nmea time to the PPS. While I agee that the GPS should not be taking more an a second to get the time to you, the program should also be robust enough to take that into account. This is on a system with no gpsd. This is from the device itself, with measurements confirmed with a 'scope, and confirmed by others. ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On Fri, Jan 14, 2011 at 1:30 PM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. The only way to know is to compare to another reference assumed to be correct. Pool NTP servers would be accurate enough for that.The GPSes (Motorola Oncore) I use have a related problem in that they allow the pulse to be adjust so that it happens before the UTC second or any time during the second. So I actually have a choice. But how to set it and know it is right? What you'd do is adjust the timing until it was a best match to the other reference clocks you have or lacking that to a set of pool NTP servers I think what this proves is that setting up a Stratum One NTP server requires that you have access to multiple clocks in your lab. eBay makes this very inexpensive now. Many people have three or more clocks and test equipmnt so that they can be compared. Lacking this, it is just a gues if your server has corect time Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Jan 14, 2011 at 1:30 PM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. The only way to know is to compare to another reference assumed to be correct. Pool NTP servers would be accurate enough for that.The GPSes (Motorola Oncore) I use have a related problem in that they allow the pulse to be adjust so that it happens before the UTC second or any time during the second. So I actually have a choice. But how to set it and know it is right? ??? That would make the pps totally useless. If it does not occur on the UTC second, it is pointless. What you'd do is adjust the timing until it was a best match to the other reference clocks you have or lacking that to a set of pool NTP servers Since you are using the pool as your time source, just use them. This device adds nothing in that case. I am assuming, as with the GPS18. that the unit emits a PPS pulse exactly on the seconds transition of UTC time. Then the nmea sentences come after that telling you which second it was that that pulse gave the exact time to. The shmslp driver does something similar. It uses some other source to get the seconds right and then hands over to the PPS to get the nanoseconds right. But it uses only the PPS pulse, not the serial nmea data. It thus requires you to have another source of time. However with something like the GPS18 it delivers both the nanoseconds via that PPS AND the seconds via the nmea sentence. Of course that only works if you know which second that PPS pulse refers to. The specs of the GPS18 say that it is the previous pulse that that nmea timestamp refers to . But if it takes 2 sec say to deliver the nmea sentence, then the previous pps pulse is the wrong one. So the sentence MUST start less than 1 sec after the pulse. If it does not, it is broken and is not working according to spec. I have never had trouble with teh GPS18, but they are refering to the GPS 18x, the newer version. I think what this proves is that setting up a Stratum One NTP server requires that you have access to multiple clocks in your lab. eBay makes this very inexpensive now. Many people have three or more clocks and test equipmnt so that they can be compared. Lacking this, it is just a gues if your server has corect time Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
In article AANLkTi=E0_9LzCDg9esXx7yZp_NJGmSU+cuS=FY9=8...@mail.gmail.com, Chris Albertson albertson.ch...@gmail.com writes: Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. If you run the to-be-calibrated server in noselect mode, it won't pollute your local clock. If you turn on peerstats, you can get lots of data about how far off that clock is. That assumes your local clock is correct. If you believe that the PPS is correct, you only have to get the NMEA text close-enough. You can easily get there using typical network connections. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij219b.cr7.un...@wormhole.physics.ubc.ca... [] The shmslp driver does something similar. It uses some other source to get the seconds right and then hands over to the PPS to get the nanoseconds right. But it uses only the PPS pulse, not the serial nmea data. It thus requires you to have another source of time. However with something like the GPS18 it delivers both the nanoseconds via that PPS AND the seconds via the nmea sentence. Of course that only works if you know which second that PPS pulse refers to. The specs of the GPS18 say that it is the previous pulse that that nmea timestamp refers to . But if it takes 2 sec say to deliver the nmea sentence, then the previous pps pulse is the wrong one. So the sentence MUST start less than 1 sec after the pulse. If it does not, it is broken and is not working according to spec. I have never had trouble with teh GPS18, but they are refering to the GPS 18x, the newer version. Yes, it's the GPS 18x LVC - the newer version - and even then the problem only happens with newer versions of its firmware. This has been reported to Garmin. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij1g6n.mnc.un...@wormhole.physics.ubc.ca... [] ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. No program is actually needed - just an oscilloscope looking at the PPS and serial outputs. In this particular case, there is no separate program as such, just ntpd with the type 20 refclock looking at the serial signal, and a type 22 refclock looking at the PPS signal through a modified device drive. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-15, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij1g6n.mnc.un...@wormhole.physics.ubc.ca... [] ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. No program is actually needed - just an oscilloscope looking at the PPS and serial outputs. In this particular case, there is no separate program as such, just ntpd with the type 20 refclock looking at the serial signal, and a type 22 refclock looking at the PPS signal through a modified device drive. Is the start of the nmea sentect coming more than one second after the PPS signal? Or is it just ending at the one second mark? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
