The way I manage this is by setting the Linux box time upfront (I'm using RTC) and making sure it is updated, then I run KStars and it is set up to allow KStars to control the time and location of everything else (e.g. the mount)

Hi all,

new to this forum

I can find several posts with 'one-hour-off' issues, and I have the same issue with my Meade ETX90.

I get around this by changing the INDI settings in KStars (to not touch date/time in the mount), but I have spent way too many hours finding this issue.

Think I have narrowed it down a bit below, by testing the UTC calculation when DST is active, and when it is inactive.

The test show that DST active, gives a one hour off calculation, whereas DST inactive, gives a correct calculation.

The calculation is performed in lx200telescope.cpp

I'm not a c++ programmer, so I'm not able to create a patch.


The test is:


Location: Denmark
Timezone: GMT+1
Timeformat: 24
Local time - yyyy-mm-ddThh:mm:ss: 2023-04-06T10:01:38
DST is active
UTC is - yyyy-mm-ddThh:mm:ss: 2023-04-06T08:01:38
INDI settings in KStars: Mount Updates KStars. Time and Location checkboxes are checked.


:GG# is: Get UTC offset time
:GL# is: Get Local Time in 24 hour format
:GC# is: Get current date

KStars log show:
[2023-04-06T10:01:40.502 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GG#> "
[2023-04-06T10:01:40.502 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <-02> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [-2] "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GL#> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <10:01:38> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [10.0272] "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] <getCalendarDate> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GC#> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <04/06/23> "
[2023-04-06T10:01:40.504 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Time: 2023-04-06T09:01:38 "
[2023-04-06T10:01:40.504 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Offset: 2.00 "


i.e. the calculation of UTC from local time, is one hour off, it should read: 2023-04-06T08:01:38

Right after this has been calculated, KStars updates the local time to 11:01:38, where local time is actually 10:01:38.


Doing the same test when DST is not active, correctly gives:
Location: Denmark
Timezone: GMT+1
Timeformat: 24
Local time - yyyy-mm-ddThh:mm:ss: 2023-02-06T10:01:17
DST is inactive
UTC is - yyyy-mm-ddThh:mm:ss: 2023-02-06T09:01:17
INDI settings in KStars: Mount Updates KStars. Time and Location checkboxes are checked.

KStars log show:
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GG#> "
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <-01> "
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [-1] "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GL#> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <10:01:17> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [10.0214] "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] <getCalendarDate> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GC#> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <02/06/23> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Time: 2023-02-06T09:01:17 "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Offset: 1.00 "



The calculation takes place in:
github.com/indilib/indi/blob/602be288b3a...e/lx200telescope.cpp

in the function: bool LX200Telescope::sendScopeTime()

and I assume it is the snippet:

ltm.tm_isdst = 0;
// Get local time epoch in UNIX seconds
time_epoch = mktime(&ltm);

that always sets DST to inactive (ltm.tm_isdst = 0).

Regards,
MBantz

Hi all,

new to this forum!

I can find several posts with 'one-hour-off' issues, and I have the same issue with my Meade ETX90.

I get around this by changing the INDI settings in KStars (to not touch date/time in the mount), but I have spent way too many hours finding this issue.

Think I have narrowed it down a bit below, by testing the UTC calculation when DST is active, and when it is inactive.

The test show that DST active, gives a one hour off calculation, whereas DST inactive, gives a correct calculation.

The calculation is performed in lx200telescope.cpp

I'm not a c++ programmer, so I'm not able to create a patch.


The test is:


Location: Denmark
Timezone: GMT+1
Timeformat: 24
Local time - yyyy-mm-ddThh:mm:ss: 2023-04-06T10:01:38
DST is active
UTC is - yyyy-mm-ddThh:mm:ss: 2023-04-06T08:01:38
INDI settings in KStars: Mount Updates KStars. Time and Location checkboxes are checked.


:GG# is: Get UTC offset time
:GL# is: Get Local Time in 24 hour format
:GC# is: Get current date

KStars log show:
[2023-04-06T10:01:40.502 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GG#> "
[2023-04-06T10:01:40.502 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <-02> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [-2] "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GL#> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <10:01:38> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [10.0272] "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] <getCalendarDate> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GC#> "
[2023-04-06T10:01:40.503 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <04/06/23> "
[2023-04-06T10:01:40.504 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Time: 2023-04-06T09:01:38 "
[2023-04-06T10:01:40.504 CEST DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Offset: 2.00 "


i.e. the calculation of UTC from local time, is one hour off, it should read: 2023-04-06T08:01:38

Right after this has been calculated, KStars updates the local time to 11:01:38, where local time is actually 10:01:38.


Doing the same test when DST is not active, correctly gives:
Location: Denmark
Timezone: GMT+1
Timeformat: 24
Local time - yyyy-mm-ddThh:mm:ss: 2023-02-06T10:01:17
DST is inactive
UTC is - yyyy-mm-ddThh:mm:ss: 2023-02-06T09:01:17
INDI settings in KStars: Mount Updates KStars. Time and Location checkboxes are checked.

KStars log show:
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GG#> "
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <-01> "
[2023-02-06T10:01:18.677 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [-1] "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GL#> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <10:01:17> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] VAL [10.0214] "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] <getCalendarDate> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] CMD <:GC#> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[SCOPE] RES <02/06/23> "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Time: 2023-02-06T09:01:17 "
[2023-02-06T10:01:18.678 CET DEBG ][ org.kde.kstars.indi] - ETX90 : "[DEBUG] Mount controller UTC Offset: 1.00 "



The calculation takes place in:
github.com/indilib/indi/blob/602be288b3a...e/lx200telescope.cpp

in the function: bool LX200Telescope::sendScopeTime()

and I assume it is the snippet:

ltm.tm_isdst = 0;
// Get local time epoch in UNIX seconds
time_epoch = mktime(&ltm);

that always sets DST to inactive (ltm.tm_isdst = 0).

Regards,
MBantz

Thank you for the analysis... how would we know from the mount data alone whether daylight is active? It's already factored in the UTC offset.

Hi Jasem,

thanks for the reply

If I understand your question correctly, the DST setting can be obtained from the mount with the command (the 2010 serial meade protocol):
:GH# Get Daylight Savings Time Setting [Autostar II only]
Returns:
1# if daylight savings is enabled.
0# if daylight savings time is disabled.

After reading up on the mktime c++ function, it seems that tm_isdst can be set to -1 when dst is undefined, 0 when dst is inactive and 1 when dst is active,

Best Regards,
Martin

Thank you Martin, this command was never added in before. I pushed a possible fix for this, can you please run the latest INDI from GIT and test if it works for you?

Jasem -- is this a new problem?

The reason I ask is that I've been chasing the FITS Header problem as to why many items are missing the FITS header when running through SM, yet these same items do appear in the FITS header when I do all the control via my host computer.

I recently was pointing at Venus, in the west low on the horizon, and the dome wanted to point way off at like 200 deg. So I pointed the dome manually, then this morning went to do some sim work to see if I could find the problem. Pointed sim scope low to the west, and sim dome again was way off. Finally VNCed into SM and noticed the clock was approx (not exactly) 3 hours off. Once I adjusted the clock, dome pointing solved.

I've been running SM for I think close to 2 years and I don't recall having to check on its clock. So when the person who started the thread asking why the Ekos time is different from the mount, I'm wondering if other telescope parameters (e.g., location) are also not being sent to Ekos as they were previously.

Bob

Not new issue and I think this might be specific to users relying on mount supplying the system time/location. I think it's a better idea to have the unit itself tell the rest of the peripheral the time/location and not vice versa. However, some users want to rely on the mount internal clock. So this issue only affects such use case.

Agree with SM being the master time distributor to the other equipment.

Hi Jasem,

first attempt with this version gives same result,

will troubleshoot, as this is my first compile on astroberry

I post back when I have more info,

Cheers,
Martin

Hi again,

the logs show that the GH command is sent, but I get no response in the RES tag:
...
SCOPE 8.496287 sec : CMD <:GG#>
SCOPE 8.511057 sec : RES <-02>
SCOPE 8.511228 sec : VAL [-2]
SCOPE 8.511298 sec : CMD <:GL#>
SCOPE 8.532468 sec : RES <17:43:19>
SCOPE 8.532602 sec : VAL [17.7219]
SCOPE 8.532703 sec : <getCalendarDate>
SCOPE 8.532739 sec : CMD <:GC#>
SCOPE 8.552438 sec : RES <04/10/23>
SCOPE 8.552566 sec : CMD <:GH#>
DEBUG 13.566517 sec : Mount controller UTC Time: 2023-04-10T16:43:19
DEBUG 13.570088 sec : Mount controller UTC Offset: 2.00
SCOPE 13.570227 sec : CMD <:GVD#>
SCOPE 13.596546 sec : RES <Apr 03 2007>

I have some python code, that get a value from :GH# - in this code as a bool that is true - so the GH is supported in my mount,

Best Regards,
Martin

In Meade-TelescopeProtocol_2010-10.pdf we find

That doc claims :GH# is an Autostar II only extension.

The :GH# does NOT exist in the 10Micron command-protocol-v2.14.11.pdf
The :GH# also does NOT exist in Meade-2002-LX200CommandSet.pdf

So we cannot enable :GH# for all Meade protocol versions and derivatives.