×

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

Bi-monthly release with minor bug fixes and improvements

Re:We need your feedback about mount <--> kstars/indi time sync. Do you also face this issue?

  • Posts: 55
  • Thank you received: 8
Hello all,
sorry for the clickbait title, but I wanted to attract your attention on an issue[1] Jasem and I are debugging (well, mostly Jasem, I'm just supporting), and we need to understand how many people are facing this issue and with which mount.
Theoretically, this issue should affect only people living in countries where DST is being used.
How to check if you are affected by this issue:

Kstars - Settings - Configure Kstars - INDI - Time & Location Updates -> (check) Mount Updates Kstars -> (check) time, (check) location

Connect your mount, start EKOS, and check the time in Kstars. Is it correct? Or is it off by, for example, 1 hour?

If the time is not correct, please report:
- what mount you're using
- if you're using DST
- by how much the time is off

You can my full report on the github issue, in case you should need more info

Thanks a lot!!

[1] github.com/indilib/indi/issues/1448
Last edit: 2 years 10 months ago by Paolo.
2 years 10 months ago #71204

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

  • Posts: 910
  • Thank you received: 86
No issues with HEQ5, AZ-GTi and RST-135.
-- Max S
ZWO AM5. RST-135. AZ-GTI. HEQ5. iOptron SkyTracker.
TPO RC6. FRA400. Rokinon 135 and other lenses.
ZWO ASI2600MC. D5500 modified with UVIR clip-in filter.
ZWO ASI120MM Mini x 2. ZWO 30F4 guider. Orion 50mm guider.
ZWO EAF x 2.
The following user(s) said Thank You: Paolo
2 years 10 months ago #71211

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

  • Posts: 2247
  • Thank you received: 223
I would not use a "click bait" subject as this does not help members using the search tool.
2 years 10 months ago #71223

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

  • Posts: 1
  • Thank you received: 0
CEM60, Stellarmate on rPi4, updated nightly.  
I DO live in a DST country and this problem has plagued my meridian flips from day one.  The mount disagrees with Kstars when the flip tries to run.  

I DO get the wrong time in Kstars when I have DST set to Y in the HC, and have mount update time and location.

My workaround for this was to remove the HC from the mount, then everything works fine for the flip.

No issues with my EQM-35 Pro using the same system.
2 years 10 months ago #71224

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

  • Posts: 55
  • Thank you received: 8
True! I've modified the title (honestly, I don't really know what to write there, so any idea to improve it even further is very welcome)
2 years 10 months ago #71225

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

I've modified title since this is an iOptron issue only.
2 years 10 months ago #71227

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

  • Posts: 220
  • Thank you received: 27
Hi,

if this is about time syncing for iOptron mounts there is definitelly is a problem. (Has been discussed in earlier topics)
I sync time from Kstars to the mount (cem60), and the only way to make it work correct is NOT to use DST in the mount, but set the time offset to include the DST.

The driver does not take into account the DST setting if set in the mount.

Probably caused by this
IOptron RS232 manualNote that in the shown response the DST flag is not shown but it is explained as the 4th digit (between offset and date)

the diver does not handle that:
2 years 10 months ago #71230

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

  • Posts: 220
  • Thank you received: 27
Hi,

if this is about time syncing for iOptron mounts there is definitelly is a problem. (Has been discussed in earlier topics)
I sync time from Kstars to the mount (cem60), and the only way to make it work correct is NOT to use DST in the mount, but set the time offset to include the DST.

The driver does not take into account the DST setting if set in the mount.

Probably caused by this
IOptron RS232 manual
Command: “:GLT#”
Response: “sMMMYYMMDDHHMMSS#”
This command gets time related information. The response includes a sign and 16 digits.
The sign and first 3 digits indicate the minute offset from UTC (time zone). Note: The Daylight-
Saving Time will not be take account into this value.
The 4th digit indicate the Daylight-Saving Time, 0 means Daylight Saving Time has not been
observed, 1 means Daylight Saving Time has been observed.
The 5th to 10th digits indicate for current local date.
The 11th to 16th digits indicate for current local time in 24 hours format

Note that in the shown response the DST flag is not shown but it is explained as the 4th digit (between offset and date)

the diver does not handle that:Decoding dst is missing at res+4 (and probably handling as well)

if (sendCommand(":GLT#", res))
    {
        *utc_hours = DecodeString(res, 4, 60.0);
        *yy = DecodeString(res + 5, 2) + 2000;
        *mm = DecodeString(res + 7, 2);
        *dd = DecodeString(res + 9, 2);
        *hh = DecodeString(res + 11, 2)
       *minute = DecodeString(res + 13, 2);
        *ss = DecodeString(res + 15, 2);

Didn't check setting time , but probably same thing.

Rgrds,

Paul
The following user(s) said Thank You: Paolo
Last edit: 2 years 10 months ago by PDB.
2 years 10 months ago #71231

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

  • Posts: 44
  • Thank you received: 5
I have this issue with a GEM45 (latest firmware) and ioptronv3 driver.

I’m GMT+1 with DST, and kstars is updated from the mount 1 hour earlier, i.e. as if DST is off. However, I have to stress that the issue is only related to the time displayed by ekos as Local Time. Sidereal time is correct, so no issue with slewing to target.
Also note that the driver log reports “DST is on”, so the response from the mount is properly parsed.
The following user(s) said Thank You: Paolo
Last edit: 2 years 10 months ago by simont.
2 years 10 months ago #71241

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

  • Posts: 55
  • Thank you received: 8

Nice catch! You may have found where the bug is  Thanks a lot PDB!!

EDIT: unfortunately, that doesn't seem to be our bug. CEM70 and others are using v3 driver, which now uses GUT instead of GLT, and the driver is correctly parsing the info: github.com/indilib/indi/blob/a6ffc654e24...driver.cpp#L709-L732
Last edit: 2 years 10 months ago by Paolo.
2 years 10 months ago #71243

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

  • Posts: 239
  • Thank you received: 38
Problem also occurs in the CEM120 as well.

I just reset my observation site info in settings and it gets back in sync.
The following user(s) said Thank You: Paolo
2 years 10 months ago #71244

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

  • Posts: 55
  • Thank you received: 8
Thanks! Good to know that sideral time is correct :)
What's not working correctly due to this bug is autopark (could be workarounded by setting wrong time there). Dunno about meridian flip, this should be checked too (can't do it these days due to rain)
2 years 10 months ago #71245

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

Time to create page: 1.177 seconds