Le mardi 20 juin 2017 15:13:16 UTC+2, Fida Hasan a écrit : > > That command gives all details: > > ntpq -c rv -c pe -c cv -c kern -c as > > > > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, > > version="ntpd 4.2.8p10@1.3728 Tue May 16 04:35:53 UTC 2017 (1)", > > processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1, > > precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS, > > reftime=dceaa6d4.0b6f4fcb Tue, Jun 13 2017 20:00:52.044, > > clock=dceaa6e1.471ffbf5 Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5, > > mintc=3, offset=-0.000094, frequency=2.094, sys_jitter=0.000060, > > clk_jitter=0.001, clk_wander=0.002 > > remote refid st t when poll reach delay offset > > jitter > > ============================================================================== > > +192.168.0.111 .GPS. 1 s 21 32 377 0.630 -0.008 > > 0.009 > > +192.168.0.112 .GPS. 1 s 5 32 377 0.449 0.058 > > 0.011 > > 192.168.0.115 192.168.0.107 2 s 24 32 377 0.640 0.006 > > 0.024 > > oGPS_NMEA(0) .GPS. 0 l 13 32 377 0.000 0.000 > > 0.000 > > associd=0 status=0000 no events, clk_unspec, > > device="NMEA GPS Clock", > > timecode="$GPRMC,180104,A,____.____,_,_____.____,_,000.0,224.0,130617,001.8,E*__", > > poll=21509, noreply=0, badformat=0, baddata=0, fudgetime2=550.000, > > stratum=0, refid=GPS, flags=13 > > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, > > pll offset: 0 > > pll frequency: 2.09364 > > maximum error: 0.0075 > > estimated error: 0 > > kernel status: pll ppsfreq ppstime ppssignal nano > > pll time constant: 5 > > precision: 1e-06 > > frequency tolerance: 500 > > pps frequency: 2.09375 > > pps stability: 0.00802612 > > pps jitter: 0.001 > > calibration interval 256 > > calibration cycles: 12684 > > jitter exceeded: 26092 > > stability exceeded: 0 > > calibration errors: 0 > > > > ind assid status conf reach auth condition last_event cnt > > =========================================================== > > 1 46417 f4fd yes yes ok candidate 15 > > 2 46418 f43d yes yes ok candidate 3 > > 3 46419 f01d yes yes ok reject 1 > > 4 46420 971a yes yes none pps.peer sys_peer 1 > > > > As you can see the result is quite good and stable > > Best, > > Jean-Michel. > > > > > Hi Jean-Michel, > Splendid work. I was just taking sometimes to complete my experiment with my > existing system (Rpi-3, GPS HAT (Uputronics)). > > You know, my result is not bad if I run the system in kernel mode. > I have used driver 20 and in the stand-alone mood, means no other servers > were associated, no internet connection at all. > In user mode I recorded the maximum offset as 6 microseconds. But in kernel > mode I run the system over three days, and the maximum offset comes 1.60 > microseconds. From the statistical recorded data, I found the average is 1.03 > microseconds. > > I am very interested in going further. I have in mind to try your suggested > system with Odroid. You have tested with OdroidC1+, where OdroidC2 is the > latest version of it. So, can you please share some points to clear my > understanding because I literally have no experiences working with this > particular SBC system. > 1. Do I need to use OdriodC1+, or OdriodC2+ would be okay?(as I found Rpi3 > and others have differences so all of their setting does not mutually works > therefore troubleshooting is difficult.) > 2. Did you use Linux/or Android as OS? > 3. I believe this Odroid is likea clone of Rpi, means, their GPIO Pin > configuration is same. So, the Rpi HAT like uputronics provides should fit > with it? > > > You are very resourceful. Thank you very much for all of your valuable > sharing. This time, I am trying to build with chrony. I have got some > references that chrony does better in regard to offsets. I was just wondering > if you have any experiences working with chrony! > > While trying with chrony I still unable to fix gpsd with it therefore no GPS > and PPS output is observed. > So, > > 1. I made the necessary configurations: > a) In the boot configuration file (/boot/conf.txt) I stop Linux putting > serial console by removing 'console=serial0,115200' > b) I load pps-gpio to kernel module (sudo sh -c "echo pps-gpio >> > /etc/modules" > c) Told to use GPIO18 as the PPS input by inputting > "dtoverlay=pps-gpio,gpiopin=18" into config.txt file. > d) I added this three additional command to the config.txt file, > "core_frequency=300" "force_turbo=1" and "enable_uart=1". > 2. I installed 'picocom' and 'pps-tools' to see whether my GPS and PPS are > from the receiver is functioning? > a) 'picocom -b 9600 -f n /dev/ttyS0' commands start to show output from > GPS module that essentially starts with $GPRMC > b) 'ppstest /dev/pps0' command also executes successfully showing, 'ok > found 1 sources (s) bla bla > -------------means, both GPS and PPS of the receiver are interfaced and > active with the system. > > From this point onward, if I set up ntp, it get fix with the drivers and > working fine. However, according to the instruction here: > http://catb.org/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd > > 3. I installed chrony and gpsd into my system. And always ensured that Chrony > is Running before gpsd. > > > allow 0/0 > > refclock SHM 1 refid GPS precision 1e-1 offset 0.9999 delay 0.2 > refclock SOCK /tmp/chrony.ttyS0.sock refid PPSS > > But I don't get any result. It is sure that chrony does not get feed from > GPSD. > > chronyc sources results are look likes: > > pi@raspberrypi:~ $ chronyc sources > 210 Number of sources = 4 > MS Name/IP address Stratum Poll Reach LastRx Last sample > =============================================================================== > #? GPS 0 4 0 10y +0ns[ +0ns] +/- > 0ns > #? PPSS 0 4 0 10y +0ns[ +0ns] +/- > 0ns > ^* time.campus.qut.edu.au 3 5 377 1 -103us[ -107us] +/- > 15ms > > > I understand that something somewhere I am missing terribly, but could not > locate. Hope you may have some good suggestion in this regard. > > Bests, > FH
Hi Hasan Good luck with ntp experimentations, this is an exiting (and complicated) story. As you already know, drivers 22 and 20 are are able to directly manage the pps signal. There are different ways to set how the pps works with ntp through flags 1 and 3. Unfortunately drivers are not strictly equals in their way to deal with the PPS API. Driver 22 will silently accept flag3 set to 1 even if it is not able to set the kernel mode while driver 20 will stop to talk to the PPS API with the same error, that's why lot of persons think that driver 20 is not working well and think also to have set the kernel mode using driver 22 even if it's not true. For both drivers (20 with flag1=1 and 22) the first mode is to use the pps api to retrieve back time stamps from the irq managed by the kernel; then the ntp pll does its job and ntp try to make corrections. With flag3=1 for both drivers (20,22) the pll is managed directly by the kernel. The best way to see how the kernel is set is by asking with 'ntpq -c kern'. The 'pll offset' value is equal to 0 because it is not anymore handle by ntp, The 'kernel status' show 5 states 'pll ppsfreq ppstime ppssignal nano', ppstime must be present. I remind you that the 'kernel mode' is only available is the right options have been set during a kernel compilation; As far as I tested this is not the case with the Raspbian distribution. Concerning my choice to switch from Raspi2-3 to an OdroidC1+; that was motivated by the fact that clients benefit from a true Ethernet link instead of passing by an USB interface. Reaching delays from client side are divided at least by 3! I chose the C1+ version for several reasons: 32 bit cores and not 64, lower price, RTC integrated. I run a basic Linux and not an Android. If you use a RpiHat card keep in mind that the 'Hat' talk to the kernel during the boot to automatically load 'some' drivers. With the 'Hat card' lot of things are done for you without the need to manually set them. I did the choice to work with a Garmin 18xLVC and because of that I had to manage voltage compatibilities between the Garmin and the GPIO interface, I had also to manage myself all software things that the 'Hat' do for you. So I can't tell you if your 'Hat GPS' is able to works as it is working on your Pi but my feeling is that it will works differently... I did also some work with Chrony. Chrony is very efficient, it's a very good ntp protocol implementation. But even if Chrony is able to talk with the PPS API it is not able to directly talk with NMEA messages and you have to pass by a shared memory mechanism and for example GPSD program. I personally don't like GPSD because it always try to do more than you want and because of that it tries to change your GPS settings or to manage the PPS signal before ntp ... Chrony is also not able to switch the Kernel in PLL mode, so I went back to ntp but I think for clients Chrony is better. Some time ago I try the Chrony package in Raspbian and it was corrupted, I did a full manual installation from sources and the most painful part was to set up all systemd scripts... But the good part is that you learn a lot. In your ntp or chrony configuration files please don't use the 'refid' option because the only create some false information on what you are really using . Best and good luck _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
