Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-04 Thread Chris Albertson
One possibility is that the CPU is getting turned off when idle to save power. If that includes the stuff normally used for timekeeping, things could get screwed up when it gets turned back on. It has to reset the time, probably getting it from the RTC. I don't think this is the case.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-04 Thread folkert
Oh for convenience. I need to patch ntpd to use linux pps (afaik) and on other systems I successfully run gpsd with ntpd (read: low jitter). Using gpsd with ntpd reduces the jitter versus just using ntpd by itself? No I meant that running that combination is successfully because I see low

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread folkert
Hi, I decided to buy a Nanos G20. Not too expensive, real serial port, debian linux pre-installed. I don't want to sound harsh as the people from Nanos probably did their best to produce a good product, but for timekeeping it is totally crap and also useless. Well, unless I did something wrong. I

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread Hal Murray
folk...@vanheusden.com said: remote refid st t when poll reach delay offset jitter == x127.127.28.0.NMEA. 0 l3 16 3770.000 -994.05 7.857 x127.127.28.1.PPS.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread David J Taylor
Hi, I decided to buy a Nanos G20. Not too expensive, real serial port, debian linux pre-installed. I don't want to sound harsh as the people from Nanos probably did their best to produce a good product, but for timekeeping it is totally crap and also useless. Well, unless I did something wrong.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread folkert
folk...@vanheusden.com said: remote refid st t when poll reach delay offset jitter == x127.127.28.0.NMEA. 0 l3 16 3770.000 -994.05 7.857 x127.127.28.1.PPS.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread folkert
Thanks for your graphs, but what are the Y-axis units! http://keetweej.vanheusden.com/~folkert/nanosg20.png is in ms and not the delay, the offset instead. Inn your billboard above, the PPS looks to be on the wrong edge - perhaps the pulse is 250 ms wide and you are syncing to the trailing

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread Chris Albertson
The computer itself and the NTP installation are OK because we can see it syncing to other NTP servers. Likely you have a problem in the way the GPS using is connected. Some common errors is an inverted PPS, just flip it ad see if you gets better, it is really hard to see a 1Hz signal on a scope.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread Doug Calvert
On Wed, Jul 3, 2013 at 4:14 PM, folkert folk...@vanheusden.com wrote: Oh for convenience. I need to patch ntpd to use linux pps (afaik) and on other systems I successfully run gpsd with ntpd (read: low jitter). Using gpsd with ntpd reduces the jitter versus just using ntpd by itself?

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread Hal Murray
It is a garmin 18x lvc. That's pretty vanilla. It really should work. I won't be surprised if the NMEA is off by hundreds of ms and/or has 100 ms of wander, but the PPS should work. Would you please try ntpd's NMEA driver, preferably from the latest ntp-dev

Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

2013-07-03 Thread Mark C. Stephens
To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20 It is a garmin 18x lvc. That's pretty vanilla. It really should work. I won't be surprised if the NMEA is off by hundreds of ms and/or has 100 ms