Welcome, Guest
Username: Password: Remember me
20 Aug 2017
INDI development team is happy to announce the release of INDI Library v1.5.0. This new exciting release builds on the maturity of INDI Library and comes with many new supported devices and fixes for existing drivers.
Read More...
  • Page:
  • 1
  • 2

TOPIC: Still weird issue with GPS time

Still weird issue with GPS time 4 weeks 5 hours ago #20440

On a previous thread, I had issues with Ekos polling data from my USB GPS receiver. Well that issue has been fixed. This one is different. I ran some tests last night with the Pi3 running headless (no ethernet /internet) this time and found that although proper location data is retrieved for my area, the time data is not. When I boot the Pi, the system time and date is way off obviously. That time and date information should correct itself once I connect to GPSD in EKOS, both in the mount UTC field and in Kstars, correct? I can see GPSD has got a fix, and latitude/longitude are correct, UTC is set to - 5, but the UTC time field is just a calculation of the incorrect system time +5. The local time in Kstars just sets itself to the system time. Clicking "update" in the GPSD driver doesn't correct things. Very weird behavior. The only way to get time to correct itself is to connect the Pi3 to the internet. cgps shows the correct UTC time after satlock whether offline or online.

Using a tutorial I found, I attempted to see if I can set the system time from GPSD at boot, but I've run into a wall because I'm getting errors from NTP. The NTP daemon will not start and any attempt to start the NTP service exits with the message:

● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since pet 2017-03-24 13:24:13 CET; 3s ago
Docs: man:systemd-sysv-generator(8)
Process: 2092 ExecStart=/etc/init.d/ntp start (code=exited, status=5)

mar 24 13:24:13 tnmtv3 systemd[1]: Starting LSB: Start NTP daemon...
mar 24 13:24:13 tnmtv3 systemd[1]: ntp.service: Control process exited, code=exited status=5
mar 24 13:24:13 tnmtv3 systemd[1]: Failed to start LSB: Start NTP daemon.
mar 24 13:24:13 tnmtv3 systemd[1]: ntp.service: Unit entered failed state.
mar 24 13:24:13 tnmtv3 systemd[1]: ntp.service: Failed with result 'exit-cod

If I apt purge ntp and then reinstall ntp, everything will work... until I reboot. Then the error comes back. This is a relatively fresh Stellarmate install, so. I'm wondering if there is something wrong with MATE 16.04 for the Pi, or maybe a permissions issue?

What I want to know is if either issue is repeatable on other people's Pi3's running offline or is this exclusive to just me? I could care less about the NTP problem if I can just get EKOS/KSTARS to set to the GPS time signal once there is a satellite lock.

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 4 weeks 44 minutes ago #20443

Can you run this on the RPI3 and check if the timezone is correct for you?
sudo dpkg-reconfigure tzdata

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Still weird issue with GPS time 4 weeks 19 minutes ago #20446

  • Kaczorek
  • Kaczorek's Avatar
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 393
  • Karma: 4
  • Thank you received: 135
RPi does not have RTC (real time clock) so it boots at 01-01-1970 and needs to set proper time/date from some source. In a standard configuration it uses network to accomplish this goal. For many years NTP service has been used to sync operating system time to network based source. NTPD service also supports non-network sources such as GPSD service, so you can set operating system time even if you don't have Internet connection e.g. from gps device. So it is NTP service that sets your operating system time, not indi-gpsd driver. indi-gpsd driver reads operating system time and timezone to calculate offset and DST - if they are not correct you get the issues exactly you have described.

However NTP service has been replaced by timesyncd service in the recent ubuntu releases (which I believe is insane). For the sake of compatibility, timesyncd disables execution bit on ntpd service at the boot time. As the result NTP service runs fine after reinstallation and will not run after reboot. Moreover timesyncd service requires Internet connection and cannot use gps as a time/date source. To fix it you need to revert from timesyncd service to NTP service to support off-line time/date setting from gps. See example approach here
The following user(s) said Thank You: knro, SparkyHT

Please Log in or Create an account to join the conversation.

Last Edit: by Kaczorek.

Still weird issue with GPS time 3 weeks 6 days ago #20447

Kaczorek wrote: RPi does not have RTC (real time clock) so it boots at 01-01-1970 and needs to set proper time/date from some source. In a standard configuration it uses network to accomplish this goal. For many years NTP service has been used to sync operating system time to network based source. NTPD service also supports non-network sources such as GPSD service, so you can set operating system time even if you don't have Internet connection e.g. from gps device. So it is NTP service that sets your operating system time, not indi-gpsd driver. indi-gpsd driver reads operating system time and timezone to calculate offset and DST - if they are not correct you get the issues exactly you have described.

However NTP service has been replaced by timesyncd service in the recent ubuntu releases (which I believe is insane). For the sake of compatibility, timesyncd disables execution bit on ntpd service at the boot time. As the result NTP service runs fine after reinstallation and will not run after reboot. Moreover timesyncd service requires Internet connection and cannot use gps as a time/date source. To fix it you need to revert from timesyncd service to NTP service to support off-line time/date setting from gps. See example approach here


Ohhhh, well then this pieces it together for me. I guess I'll be purging timesyncd and reinstalling NTP! Without your sage knowledge I would've never known. I will try to see if I can get proper time to set after satellite lock. I have modified my ntp.conf file to use GPSD as a means to set the local time via NTP, once I get NTP running hopefully this works

Thanks!

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 3 weeks 6 days ago #20448

Umm, it appears that timesyncd is NOT a part of MATE 16.04 Pi. rm /etc/systemd/system/systemd-timesyncd.service yields:

cannot remove '/etc/systemd/system/systemd-timesyncd.service' : No such file or directory

So now I'm still baffled what is killing NTP. This may all be for naught, I read something about NTP not being able to grab time from GPSD at boot because it takes too long to sync. Sigh. Not sure a Pi is ideal for a mobile setup. It's too much of a hassle having to reset time and location every time I power up. Back to the drawing board.

Also knro, I tried sudo dpkg-reconfigure tzdata and was in the right timezone.

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 3 weeks 6 days ago #20457

Hi SparkyHT,

I did some tests on Ubuntu on my laptop and came to this solution.. or maybe a oneliner solution..

sudo date +%Y-%m-%dT%H:%M:%S -s $(cut -d "=" -f 2 <<< $(indi_getprop GPSD.TIME_UTC.UTC))

While playing around with my GPS I found that the time is correct even before it gets a fix, not sure if all GPS works the same and I haven't tested this on my RPi but maybe you could do the testing :)

Br
/Markku

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 3 weeks 4 days ago #20486

I still don't have a fix for this. I removed timesyncd service and reinstalled NTP and I'm still getting the failed to start errors. It appears I'm screwed trying to use my RPI3 out in the field because it'll never have the right time. Making this work shouldn't have to be so difficult. I thought switching from Win10 to INDI meant freedom, flexibility, and reliability, it has been anything but. I have yet to get a successful clear night out with it. Driver issues from the start, and now foiled by trying to set something as basic and essential as a clock. I guess I didn't realize I had to be a Linux master to make INDI work for me.

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 3 weeks 4 days ago #20490

No need to use GPSD if it is not working for you, you can use your phone as the GPS source

EDIT: I will also update StellarMate OS image to utilize NTP/GPSD and make a new image available soon.

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Last Edit: by knro.

Still weird issue with GPS time 3 weeks 4 days ago #20505

Ok so I did a little bit more research and turns out using GPS for NTP is useless unless your GPS unit provides precise timing via PPS. The majority of GPS dongles don't support this. Check if your is supported here: www.catb.org/gpsd/hardware.html

I configured NTP to use GPS on StellarMate, and when I ran ntpq -p, I got this:

stellarmate@stellarmate:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.001
SHM(0) .GPS. 0 l - 16 0 0.000 0.000 0.000
SHM(1) .PPS. 0 l - 16 0 0.000 0.000 0.000
+sv1.localdomain 133.243.238.163 2 u 28 64 17 194.561 1.265 10.837
*time.iqnet.com 62.201.214.162 2 u 26 64 17 176.547 10.442 14.519
+x.ns.gin.ntt.ne 249.224.99.213 2 u 29 64 7 157.242 8.576 3.270
hachi.paina.net 131.113.192.40 2 u 86 64 2 241.538 21.487 2.448
-mail.lumajangka 203.160.128.132 3 u 25 64 7 330.810 5.412 3.812
-202.143.124.3 ( 194.190.168.1 2 u 19 64 7 231.419 1.184 1.969
-one.itnet.am 93.123.39.67 2 u 26 64 7 171.718 10.273 1.899


It's using online NTP servers even though I attached a GPS and it can "read" from it, but because it doesn't have PPS, it's useless. So I'd say just use GPS NMEA driver for time synchronization. The ones that provide PPA can be pretty expensive and not really worth it unless you're need nanosecond timings.

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Still weird issue with GPS time 3 weeks 4 days ago #20526

knro wrote: Ok so I did a little bit more research and turns out using GPS for NTP is useless unless your GPS unit provides precise timing via PPS. The majority of GPS dongles don't support this. Check if your is supported here: www.catb.org/gpsd/hardware.html

I configured NTP to use GPS on StellarMate, and when I ran ntpq -p, I got this:

stellarmate@stellarmate:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.001
SHM(0) .GPS. 0 l - 16 0 0.000 0.000 0.000
SHM(1) .PPS. 0 l - 16 0 0.000 0.000 0.000
+sv1.localdomain 133.243.238.163 2 u 28 64 17 194.561 1.265 10.837
*time.iqnet.com 62.201.214.162 2 u 26 64 17 176.547 10.442 14.519
+x.ns.gin.ntt.ne 249.224.99.213 2 u 29 64 7 157.242 8.576 3.270
hachi.paina.net 131.113.192.40 2 u 86 64 2 241.538 21.487 2.448
-mail.lumajangka 203.160.128.132 3 u 25 64 7 330.810 5.412 3.812
-202.143.124.3 ( 194.190.168.1 2 u 19 64 7 231.419 1.184 1.969
-one.itnet.am 93.123.39.67 2 u 26 64 7 171.718 10.273 1.899


It's using online NTP servers even though I attached a GPS and it can "read" from it, but because it doesn't have PPS, it's useless. So I'd say just use GPS NMEA driver for time synchronization. The ones that provide PPA can be pretty expensive and not really worth it unless you're need nanosecond timings.



Here's something interesting, on my Stellarmate, I can't even go into ntpq or any other ntp related register. I always get "Connection Refused". I freshly installed the image once again and tried getting into NTP, but still get the error code=5 message. Like I said before, I tried purging timesyncd and reinstalling NTP. It just doesn't want to run on the Pi. This version of MATE is just crippled and I don't have the knowledge to make it do what I want to do.

And judging by the GPS:Smartphone thread, it doesn't look like THAT is working well either. You simply CANNOT have the Pi3 online when testing GPSD or NMEA, the results are false readings. Disconnect power to the Pi3, unplug the network cable, wait for the residual memory to clear, then apply power. The time will reset to whatever and WILL NOT COME BACK unless it is given an internet connection, PERIOD. This is not SYSTEM TIME, this is the time setting on the MOUNT location tab and KSTARS. That is my experience.

Please Log in or Create an account to join the conversation.

Still weird issue with GPS time 3 weeks 3 days ago #20536

So I spent a few hours on this and finally go it working reliably. You'll receive a link to an updated StellarMateOS image by the end of the day. Do not edit any files, just use the StellarMate Serial Port Assistant tool to add the GPS and then restart your StellarMate afterwards and you should be set.

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Still weird issue with GPS time 3 weeks 2 days ago #20555

  • Kaczorek
  • Kaczorek's Avatar
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 393
  • Karma: 4
  • Thank you received: 135

knro wrote: Ok so I did a little bit more research and turns out using GPS for NTP is useless unless your GPS unit provides precise timing via PPS.

Why would you say this? The only difference is that without PPS you will not get precision higher than 1s, while with PPS your time precision is around 1us. All the rest would work just fine.

@SparkyHT I read your thread on CHRONY... well done!
The following user(s) said Thank You: SparkyHT

Please Log in or Create an account to join the conversation.

Last Edit: by Kaczorek.
  • Page:
  • 1
  • 2
Time to create page: 0.272 seconds

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica