Yeah, this is correct. I just brought in all my equipment as we're about to have another hurricane in our area. But I'm going to test every parameter around time, and see what comes into EKOS from the mount with each option just to confirm everything before any changes are made.

Despite using the settings I prescribed above, and having the correct time in EKOS as pulled from the mount, my meridian flip went early about 1 hour, so something is still not correct.

Of course, if I make EKOS the master time keeper, everything works as planned. It's only when I make the mount the time and location master that things go wrong. Pointing accuracy is hurt when I sync time and location to the mount, so do need to get the issue sorted out.

same issue here, I've tried DST off / on at the hand controller, it makes no difference.

Mount time: set to what the current GMT+1 is (as current location is London)
Mount DST: off
MOUNT UTC: +060

Ekos:
Mount Updates Kstars
Time sync ticked

and I get in the bottom left corner the time in UTC and not UTC+1

Hi all,
I'm not sure if this issue still exists. I've not had it myself. I have no MGPBOX or GPS and use the 'kstars updates time' setting.
If ppl still have this issue then next to Jasem's enable debug log before you connect post earlier in this thread is a good place to start, and maybe this helps for those that are not afraid to telnet to an API :
The 10micron API can be reached on port 3490 as follows :here you can give commands to the mount, like 'what is todays date' and I've added my mounts' responses so you have an idea what format expector what is your timezone offset ?or what time do you think it is now ?Maybe this helps anyone in finding any discrepancies.
-- Hans

I know this is an old thread but wondering if this was ever resolved. Previously I had my 10micron updating kstars and it all seemed to work. After updating kstars to 3.5.9 on ubuntu linux I now seem to have kstars time offset by 1 hour from correct local time and meridian flip is messing up. It seems OK if I set kstars update mount. I have also seen it suggested to not have mount and kstars trying to sync time and let GPS set mount independently of kstars. What is the currently understood best way to do this?

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.