×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

SkySafari, GPSD, EQMod Mount, Time

  • Posts: 32
  • Thank you received: 13
I am having some issues with SkySafari and time updates. I’m not entirely sure how all of this is *supposed* to work, so I’m going to explain what I’m doing in a long post. I hope someone takes the time to read all of this and shed some light on it for me. :)

I have the gpsd daemon running on a Raspberry Pi using Astroberry. In addition to gpsd, chronyc is running to keep the system time in sync with GPS. When I am plugged into my home network, I unplug the GPS device and turn on Astroberry’s virtual GPS service to set a static location and the system gets the time from the network. This all seems to work just fine both with an actual GPS and with the virtual GPS.

On INDI, I’m running the GPSD driver, the SkySafari Driver, and the EQMod Mount driver. (I also have a guide camera, joystick, etc, but they are not relevant to this post). It is also important to note that I am not using KStars/Ekos.

The GPSD INDI driver is configured to use the system time instead of using the GPS time directly. As I understand it, this allows chronyc to smoothly handle any time blips due to any possible GPS issues.

The EQMod Mount driver is set to snoop “GPSD”. This eventually reverts to “GPS Simulator” even though GPSD is still able to update EQMod Mount. I’m unsure why this happens, but it continues to work as expected.

After the GPSD INDI driver starts and it gets a GPS lock from the gpsd service, it will update the EQMod Mount driver’s Location (EQMod Mount.GEOGRAPHIC_COORD.*) and UTC Time (EQMod Mount.TIME_UTC.UTC) parameters. If the GPSD Refresh parameter is set to 0, it updates the mount once and is essentially done. After this initialization is done, the EQMod Mount.JULIAN.JULIANDATE parameter is synchronized and continues to move forward in time. The EQMod Mount.TIME_UTC.UTC parameter stays static. It shows the moment in time of the last location and time synchronization with the mount.

Now, enter SkySafari. When the SkySafari app (in this case Android) talks to the SkySafari INDI driver, it gets the time and location. The time sent to the SkySafari app is based on the mount’s EQMod Mount.TIME_UTC.UTC parameter and not the EQMod Mount.JULIAN.JULIANDATE parameter. This means that SkySafari lags in time. The pointing accuracy for GOTO ends up being off by the amount of time difference between the actual time and the time saved in the UTC parameter. This is the problem I want to solve.

One thing I tried was to set the GPSD driver’s REFRESH parameter to be non-zero. I’m not sure what value is appropriate. I first tried a value of 1. This worked for a very short while and fixed the pointing accuracy in SkySafari. It proved to me that SkySafari is being sent the UTC date. An interval of 1 second causes a very chatty communication between drivers, however. It also quickly stops working. The logs show “[ERROR] GPSD read error” for every refresh attempt after it stops working. Setting the REFRESH parameter to a larger value will allow me to run longer before getting the read error, but it will still hit the error. Even refreshing every 60 seconds will eventually hit the GPSD read error and cause the time sync to stop working.

So, the GPSD refresh parameter is not a workable solution, at least not without fixing the read error bug in the GPSD driver. It also seems silly (to me at least) to keep updating the GPS coordinates just so we can have an accurate time. Is it wrong to assume the SkySafari driver should be using the Julian date as a time source instead of the more static UTC date?

What’s the better way to make this work? Fix the GPSD bug so it continues to refresh without read errors, or fix the SkySafari driver so it uses a non-static date? Maybe both?

What am I doing wrong? What do I not understand?
3 years 10 months ago #53452

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

  • Posts: 51
  • Thank you received: 0
I have also been experiencing problems with the gpsd driver. On Stellarmate and Astroberry, Indi often has difficulty connecting reading from the GPS. Running cgps in a terminal window shows the GPS reporting data continuously but Indi shows no data. When it does show position and time fix from the GPS, cgps shows the time updating continuously, but when the GPS refresh button is pressed, the Indi control panel time is unchanged but the Kstars time is reset to the time in the Indi control panel. I think the Indi control panel time may be updated but very rarely. Once the GPS connection stops updating, the Indi server must be stopped and restarted to reestablish the connection. For that reason, the refresh interval must always be set to 0. Does this sound similar or related to your issue?
What is chronyc and what is the Astroberry virtual GPS service?
3 years 10 months ago #53598

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

  • Posts: 32
  • Thank you received: 13
There might be multiple issues. I'm also sure my post is a bit too long. :)

I know for sure there is an issue with the GPSD driver in INDI. It will eventually start putting “[ERROR] GPSD read error” in the log for each refresh attempt. This should probably be entered as a bug regardless of what the correct way to keep time updating correctly in SkySafari.

I don't know if your issues are the same as mine. I'm not using KStars. There are multiple times in the INDI control panel. The time on the GPSD driver seems to be OK for me. The UTC Time on the EQMod Mount "Site Management" tab is only updated when it is explicitly set. A successful GPS refresh will update it, so can clients (I think). The Julian Date on the same "Site Management" tab always seems to be clicking forward. I think this is the correct time, and it can be synchronized with a UTC Time update. I might also be completely wrong on all of this. :)

Chronyc is a UNIX system daemon not specific to INDI. It is a replacement for ntpd. It keeps clocks in sync. It can get it's time source from multiple places. In this case, it should get it's time from gpsd (the UNIX system daemon, not the INDI driver of the same name).

The Astroberry virtual GPS service runs outside of INDI. It can provide the UNIX gpsd a static location in situations where you do not have a GPS device, but still want to use gpsd to set the location in INDI or the Astroberry side menu (polar scope, etc). I have been stopping the service when I use an actual GPS device and starting it when I do not have a GPS device plugged in. I'm not sure if that is necessary any more, I had problems in earlier versions though.
3 years 10 months ago #53599

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

The next version of StellarMate (v1.5.3) should support this out of the box. Tested today and everything looked good.
3 years 10 months ago #53618

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

  • Posts: 32
  • Thank you received: 13
Is StellarMate doing something different from what I described? Does it include a fix for the INDI GPSD read errors? What is it doing special?
3 years 10 months ago #53619

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

  • Posts: 32
  • Thank you received: 13
I was out testing this again last night. I want to know more about how it is supposed to work. SkySafari isn't relevant to the problem. It's just a client. I had similar issues in Cartes du Ciel and CCD Ciel.

Is the "EQMod Mount.TIME_UTC.UTC" parameter supposed to increment on its own? It does not for me. It only updates if something explicitly sets the time and location. It appears to be the crux of all my issues.

I believe the StellarMate hardware comes with a real time clock. That might be the difference here. I do not have a real time clock. I am using only a GPS module plugged into a USB port for time and location synchronization. I'd happily buy an RTC module if it would fix this problem, but I'd like to know if that's required before I go down that path.

The GPSD driver has a bug for sure. It will eventually start giving "[ERROR] GPSD read error” for every refresh attempt... starts out working... eventually fails. But refreshing might not be necessary if a real time clock would fix the problem.
3 years 10 months ago #53698

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

  • Posts: 51
  • Thank you received: 0
I have both a GPS receiver and a real time clock on my Stellarmate/Astroberry. I don't know if that would solve your problem because I don't know how it is used. I would like to hear an explanation from the developers how the realtime clock and the GPS are handled. Specifically:
- Is the real time clock updated if there is time available from the GPS or the network?
- If all 3 time sources (RTC, GPS, Network) are available, which does Kstars use?
- Does Kstars do any evaluation of the quality of the time (latency) from the GPS?
- Is the RTC updated when time is set manually in Kstar or in the operating system?
- Does the system time get updated if the GPS reports time?
- Where does the system get the time if there is no network time server available?
3 years 10 months ago #53699

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

  • Posts: 32
  • Thank you received: 13
I don't want to mix up questions about Kstars with questions about INDI. They should be treated as different. INDI is the server. KStars/EKOS is one possible client that talks to INDI. Of course, if there's confusion around this, it probably all needs to be made clear somewhere. I'm struggling with that too.

I can tell you that GPS time synchronization with the system clock should happen outside of INDI via tools like gpsd and chronyc. This, in theory, should work even if you have a real time clock installed. It's the same on a regular computer where the little battery on a motherboard keeps the clock ticking even when the computer is off. When you turn it on, it still knows the time, but can still be kept up to date using network time or other sources (like GPS). What I don't know is if having (or not having) a real time clock affects how the lower level drivers get the time in INDI. My initial assumption is that it shouldn't, but based on KNRO's response, I think it might.

Edwin, do you use an EQMod Mount? If so, can you tell me if the EQMod Mount.TIME_UTC.UTC parameter (under Site Management) is automatically ticking forward in time, or if it keeps the value it is set with initially? It is clear to me that the TIME_UTC.UTC parameter is critical when syncing GOTO points.
3 years 10 months ago #53701

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

  • Posts: 32
  • Thank you received: 13
I shouldn't need to do this, but it's a workaround.

while true
do
  indi_setprop "EQMod Mount.TIME_UTC.UTC;OFFSET=$(date +%Y-%m-%dT%H:%M:%S\;%:z)"
  sleep 1
done
3 years 10 months ago #54004

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

  • Posts: 32
  • Thank you received: 13
Just an update. A real time clock module did nothing to solve this problem.

The GPSD INDI driver will start giving "[ERROR] GPSD read error” messages. I have a hunch that this might occur when a GPS refresh happens while the GPS fix is temporarily lost. Once it starts failing, the only fix is to restart the driver. Also, when the signal is temporarily lost, the mount's time stops updating.... even when set to use the system's time.

I still feel like I am doing something wrong. The "EQMod Mount.TIME_UTC.UTC" needs to have accurate time for the clients I use to work correctly (SkySafari and sometimes Cartes du Ciel). The only way to do this from INDI seems to be via GPSD. The thing is... I shouldn't need to keep updating the location. After I setup the mount, it doesn't move all night. I only need the time to be updated.
Last edit: 3 years 9 months ago by Kristopher.
3 years 9 months ago #55275

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

Time to create page: 1.159 seconds