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
[ntp:questions] Polling interval in FreeBSD vs. Windows
Why in ...4.2.7p116 is it that I can set minpoll to 3 and poll every 8 seconds in Windows, but when I try the same thing for my referrence clock in FreeBSD, it will poll no sooner than 16 seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
Edward T. Mischanko wrote: Why in ...4.2.7p116 is it that I can set minpoll to 3 and poll every 8 seconds in Windows, but when I try the same thing for my referrence clock in FreeBSD, it will poll no sooner than 16 seconds. Because reference clocks override the poll interval limits. Why do you feel the need to go outside the recommended limits? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
That is the problem exactly! In FreeBSD I can not set anything to minpoll 3, but in Windows I can. Why? If I could poll my GPS/PPS every 8 seconds, I most likely would. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] MSF outages
David Lord wrote: I've not been able to come up with a reasonable explanation as to what is happening. Scope trace when either receiver is working is clean pulses. I can't get inside the Conrad circuit but following through my own receiver, at output of first rf stage, the scope shows on/off modulation and lack of noise in the off periods and constant level during the on period. When not working, as now, the overall level is lower and the signal doesn't look at all like an on/off modulated carrier. I'm in process of rebuilding both receivers so that I can move them outside. David Conrad MSF module started working again. date number of checks with reach=377 201101080/144 201101092/144 20110110 13/144 20110111 17/144 20110112 47/144 20110113 118/144 20110114 134/144 20110115 135/144 My own design receiver with simple diode detector also started working around same time. Neither receiver has been moved and Conrad module hasn't even been powered down although one day I blacked out my house with only pcs and radioclocks powered up, no lighting, no central heating or fridges but no sign at all of MSF signal. Now the demodulated signal looks like MSF again although it's not sufficient amplitude for driving rs232 as it was intended to use a PLL rather than diode detector. New pcb designs are almost finished and rf output should be much higher. I will be able to move the new receiver outdoors and to a different location should the interference come back. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
On Sun, Jan 16, 2011 at 22:34 UTC, Edward T. Mischanko etm1...@hotmail.com wrote: Why in ...4.2.7p116 is it that I can set minpoll to 3 and poll every 8 seconds in Windows, but when I try the same thing for my referrence clock in FreeBSD, it will poll no sooner than 16 seconds. Presumably because this was changed at some point after the version of ntpd that your FreeBSD box uses. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
I am running the same version of ntpd on both boxes. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
On 1/16/2011 6:02 PM, Edward T. Mischanko wrote: That is the problem exactly! In FreeBSD I can not set anything to minpoll 3, but in Windows I can. Why? If I could poll my GPS/PPS every 8 seconds, I most likely would. Why? Polling that fast would almost certainly diminish NPTD's ability to give you the maximum possible accuracy. I over simplify, perhaps grossly, but short poll intervals set your clock fairly quickly while longer poll intervals set your clock more accurately. NTPD will do the right thing if you allow it to do its job! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
A longer poling interval is not a bad thing. The polling interval is adjusted so as to reduce total noise. There is a sweet spot where polling faster or slower is worse. As an example, lets say you wanted to measure the thickness of a sheet of paper but your ruller only goes to 1/100 inch divisions. You get soe gross errors if yu tried to measure one sheet. But stack 1,000 sheets and you will do well. Longer polling interval works kind of the same way. I think the longer poll time is telling you something good about the internal clock in the BSD system. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
