×

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

Bi-monthly release with minor bug fixes and improvements

Wrong GOTO using GPSD hour in Summer - Daylight problem

  • Posts: 13
  • Thank you received: 2
Hello,I use a PI4 with Stellarmate, an AZEQ6 mount, a QHY294M camera for imaging, a QHYFW3 filter wheel connected directly to the camera, a QHY5III178C camera for guiding, a focuser all controlled on VNC with PC DELL on Windows 10. I control the mount, the focuser, the GPSD and the QHY294M camera directly from Kstars which runs on the Stellarmate and the PI4. So I use EKOS and INDI drivers.For the guidance, I had problems with the internal guidance of EKOS. I use PHD2 which runs on the PI4 and is called by EKOS as external guider. Finally, for the PolarMaster camera that was conflicting with EKOS, I finally run the software directly from Windows 10. 

While during the winter I had no problems, the switch to daylight saving time created a problem that I can't seem to solve. In winter, my PI4 did not keep time. But the mount was using the GPSD signal to set the current time. I had chosen in Kstar that "GPSD sets the time for all devices". When the time changed to daylight saving time, the GOTO did not work anymore. We were off target every time. So I bought a Hat RCT for my PI4. It works. My PI4-SM is now on local time. So when I say "Kstar sets the time for all devices", it works. But if I ask for the time to be set by GPSD, then the GOTO falls an hour behind the target. My assumption is that GPSD does transmit that I am in UTC+2 but not that I am in daylight saving time. However, everything seems to be correct. I was able to verify my bad positioning by doing an ALIGN after the Meridian flip (see file ekos-2021-05-30T22-32-40 TXT then ekos-2021-05-31T00-32-57 TXT). Thank you for your help.Sincerely


 
Last edit: 2 years 9 months ago by Christian Voirol.
2 years 9 months ago #72108
Attachments:

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

The important bits are this:
[2021-05-30T21:26:48.222 CEST INFO ][           org.kde.kstars.indi] - GPSD :  "[INFO] GPS fix obtained. "
[2021-05-30T21:26:48.227 CEST INFO ][           org.kde.kstars.indi] - Setting location from device: "GPSD" Longitude: " 06° 16' 07\"" Latitude: " 46° 31' 57\""
[2021-05-30T21:26:48.228 CEST INFO ][           org.kde.kstars.indi] - Setting UTC time from device: "GPSD" "Sun May 30 19:27:31 2021 GMT"
[2021-05-30T21:26:48.229 CEST DEBG ][                org.kde.kstars] - Daylight Saving Time active
[2021-05-30T21:26:48.229 CEST DEBG ][                org.kde.kstars] - Next Daylight Savings Time change (Local Time):  "Sun Oct 31 00:59:59 2021 GMT"
[2021-05-30T21:26:48.229 CEST DEBG ][                org.kde.kstars] - Next Daylight Savings Time change (UTC):  "Sat Oct 30 22:59:59 2021 GMT"
[2021-05-30T21:26:48.231 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] updateLocation: long = 6.26868 lat = 46.5326 "
[2021-05-30T21:26:48.233 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] Observer location updated: Latitude 46:31:57.2 (46.5326) Longitude  6:16:07.2 (6.26868) "
[2021-05-30T21:26:48.235 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] Setting UTC Time to 2021-05-30T19:27:31, Offset 2 "
[2021-05-30T21:26:49.663 CEST INFO ][           org.kde.kstars.indi] - Setting location from device: "GPSD" Longitude: " 06° 16' 07\"" Latitude: " 46° 31' 57\""
[2021-05-30T21:26:49.664 CEST INFO ][           org.kde.kstars.indi] - GPSD :  "[INFO] GPS fix obtained. "
[2021-05-30T21:26:49.665 CEST INFO ][           org.kde.kstars.indi] - Setting location from device: "GPSD" Longitude: " 06° 16' 07\"" Latitude: " 46° 31' 57\""
[2021-05-30T21:26:49.667 CEST INFO ][           org.kde.kstars.indi] - Setting UTC time from device: "GPSD" "Sun May 30 19:27:32 2021 GMT"
[2021-05-30T21:26:49.668 CEST DEBG ][                org.kde.kstars] - Daylight Saving Time active
[2021-05-30T21:26:49.669 CEST DEBG ][                org.kde.kstars] - Next Daylight Savings Time change (Local Time):  "Sun Oct 31 00:59:59 2021 GMT"
[2021-05-30T21:26:49.669 CEST DEBG ][                org.kde.kstars] - Next Daylight Savings Time change (UTC):  "Sat Oct 30 22:59:59 2021 GMT"
[2021-05-30T21:26:49.673 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] updateLocation: long = 6.26868 lat = 46.5326 "
[2021-05-30T21:26:49.677 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] Observer location updated: Latitude 46:31:57.2 (46.5326) Longitude  6:16:07.2 (6.26868) "
[2021-05-30T21:26:49.681 CEST INFO ][           org.kde.kstars.indi] - EQMod Mount :  "[INFO] Setting UTC Time to 2021-05-30T19:27:32, Offset 2 "

What's your UTC offset in the summer?
2 years 9 months ago #72117

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

  • Posts: 219
  • Thank you received: 41

Perhaps the question is the problem ;). Long time ago I discussed with the author of OnStep driver software about this issue. For him the problem is that Ekos is mixing UTC offset and summer time offset. As they set, the UTC offset is fixed for a location on Earth. Then in some locations you add an hour over this UTC offset but the UTC offset didn't change. He managed those two items (UTC offset and summer time) independently and this causes some problems (1h offset) when using OnStep with Ekos.

As I'm using plate solving always is not a problem, except for the initial goto, where the target is clearly off.

I don't know if the reported problem is related with this interpretation of summer time / UTC offset I'm only adding this piece of information that could be related.

Regards,
The following user(s) said Thank You: Christian Voirol
2 years 9 months ago #72120

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

  • Posts: 13
  • Thank you received: 2
In Switzerland, we follow the European Community and we add one hour in summer. Then, I have +1h from UTC in winter and +2h from UTC in summer. But, like rbarberac said, I didnt' find an box to tick in EKOS to distinguish "summer time" vs "winter time". Then, it works as if I'm living in a place which is +2h from UK. May be the right think to do is the systematic use of plate solving at the begining of the session, like proposed by rbarberac?
2 years 9 months ago #72136

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

Looks like the UTC offset is already compensating for this:
Setting UTC Time to 2021-05-30T19:27:32, Offset 2

It's +2 here, and this what the mount was set to. So it looks like time-wise, everything appears to be fine.
2 years 9 months ago #72142

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

  • Posts: 13
  • Thank you received: 2
It does indeed compensate for two hours, but how does it know that it is 1 hour of time difference and 1 hour of summer time and not two hours of time difference? Because there, it is as if the frame takes into account two time zones. It's strange because it also has a GPS position. It would be "easy" to calculate the current position on this basis.
This problem is clearly absent in winter. So it's really related to its understanding of daylight saving time.
2 years 9 months ago #72145

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

The end results is what matters. It's 19:00:00 UTC with +2 offset, then local time is 21:00:00 which is what matters. Unless 21:00:00 is incorrect?
2 years 9 months ago #72147

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

  • Posts: 13
  • Thank you received: 2
Dear Jasem,

It's difficult to put all informations in the windows. I created a PDF file which contains all the information.

Thank you for your help
Best regards
Christian
 

This browser does not support PDFs. Please download the PDF to view it: Download PDF

2 years 9 months ago #72157
Attachments:

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

  • Posts: 13
  • Thank you received: 2
Dear Jasem, Dear all,

June 13, 2021 was another great night for imaging. I took the opportunity to try to collect as much info as possible on my first GOTO. As a reminder, I NEVER have a problem in winter. The problem has only appeared since we switched to daylight saving time. It's hard to believe that it's a coincidence.
As it is, I can do a Plate Solver before each session and then my problem is solved. But I think that in my configuration (everything runs on the PI4 under Stellarmate - AZEQ6 with EQMod and GPSD), there is something that positions the first GOTO wrong.
Thank you for your help
Best regards
Christian

 

This browser does not support PDFs. Please download the PDF to view it: Download PDF

2 years 9 months ago #72383
Attachments:

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

  • Posts: 421
  • Thank you received: 102
The end results is what matters. It's 19:00:00 UTC with +2 offset, then local time is 21:00:00 which is what matters. Unless 21:00:00 is incorrect?

I don't believe that is correct, not for locating stars in the sky. The stars don't shift over 15 degrees when summer/daylight savings time comes into effect. :)
 
2 years 9 months ago #72387

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

  • Posts: 51
  • Thank you received: 4
I had the same problem in the UK. Solved on a non GPS mount by setting Lat, Long and DST = YES on the mount. 

Then select ‘allow mount to update KStars’  and zero offset for UTC (for me in UK, will be+1 for you) in Geographic Settings. Select “no DST offset” in KStars.

Kstars wrongly shows my LT as UTC, but the actual alignment is correct as the mount has corrected its position for DST.

When DST Ends, select DST=NO in the mount and correct alignment will be applied in KStars.

HtH

R
2 years 9 months ago #72394

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

  • Posts: 104
  • Thank you received: 21
What LC_TIME does “locale” report?
And which time zone is used by “date”?
But honestly I don’t know, if that matters…
2 years 9 months ago #72460

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

Time to create page: 0.562 seconds