The connections worked the other night.

Not sure if I ran into a related problem though.

Kstars is reporting a 1 hour time difference compared to the CGEM, and the RPI3 command line.

Specifically:

- CGEM is configured with Long/Lat, current 24h, zone, and DST for the current time
- RPI3 is booted and used to get time and location from device
- Command line - date - reports correct time
- viewing time on Kstars is one hour in future.

It is not clear if this is due to the TCP/IP connection to port. I doubt it though.

iOS/Mac devices though do not update Nexstar when connect. This problem was found earlier and fixed.

Actually, thinking about it, I just did a quick test:

1. rebooted RPI3
2. Not connected to mount
3. connected to RPI3
4. update date: sudo ntpdate -v time.nrc.ca
5. date - displays current time
6. Kstars - displays time one hour in future

Ideas?

Maybe edit your geo location and change DST offset in KStars?

That I think is it. The Geographic... settings for DST rules do not have one that matches what happened in Canada this year. In Canada we changed DST on March 18/19.

I will jig the settings to get it to match, as I cannot find one that does, by temporarily changing time zone.

Thank you.

KStars uses still a custom TZ file for time-zone and not the system stuff. This is what we have now:

#"US": DST starts on the first Sunday of April, reverts on the
# last Sunday of October (2:00 am). Canada uses this
# rule as well.
US Mar 2Sun 02:00 Nov 1Sun 02:00

EDIT: The KStars rules are outdated. Maybe they should be dropped. If you choose NO DST rule correction, KStars date/time are correct and match the system's?

You have the rules right:

2 a.m. on the Second Sunday in March to
2 a.m. on the First Sunday of November.

I thought I read in the DST rule first sun in April for US.

Of course I also have a typo in the above as it was Mar 11/12 that time changed.

I will check again.

Please know DST Rule link does say for US: 1st Sun Apr, Last Sun Oct. However, the rule you have above is correct.

I have reset the settings to my location, US DST rule, and proper timezone offset now and the time is correct in KStars. I can only assume I messed it up somehow in a reboot, or something.

Thank you for the suggestion to check this in Kstars.

I hope to image this weekend, and will report back as soon as I get to. Things seem to be going well though.

Last items for me are to confirm CGEM, Kstars, RPI3 all in sync with time, RA/DEC, and switching between INDI and SkySafari (when not imaging as imaging is INDI only). Then plate solving - which did work better and saved me last weekend.

Cheers!

Well, I am hoping for some help determining the best Ekos/INDI settings, or steps to correct to ththe CGEM. The imaging session got cut short tonight, as there was little time to debug the time setting issue I have been encountering verse helping my daughter have fun.

The connect to the CGEM over tcp/ip seems to work, as does the connection to Skysafri. skysafari slew to Jupiter nad M13 beautifully.

The problem is that something is change the time on the CGEM TO 2018.

Below is my procedure. Tonight out at a dark site meant no internet to use a time server on RPI3.

1. Power up cameras, RPI3, CGEM, and dew heaters with everything connected.
2. Setup CGEM - long/lat, time and date
3. Align mount using auto two star
4. Mac connects to cameras for the alignment (have not figured out how/if I can use Ekos for the Alignmwnt yet )
5. Once all aligned, launch Eros/kstars
6. Disconnect INDI mount and connect skysafari
7. Connect mount in skysafari wilpthout changing date and time.
8. Slew to M66, disconnect, reconnect INDI mount
9. Notice time was set to July 2018...

Maybe I did not have too, but after checking CGEM and seeing it too was 2018, I powered off mount and tried again, only have it happen again.

I would like to have the RPI3 use the long/lat enter on CGEM as well as date and time.

Skysafari is set to not change these setting.

What is the right was to do this?

What version of the NexStar+ Hand Control are you using? This is information is available in the options menu on the Hand Control. If you have never updated it, and have the version that shipped with the CGEM, this is likely part of the problem as that software is ancient.

So you powered on the mount, and via the hand control (with nothing else connected) the time was still set to July 2018?

What did the INDI Control Panel show? Do you have logs from the KStars client?

Why don't you disable Time & Location updates from KStars completely? It's in INDI options.

I will look for the disable setting.

Question: if the CGEM is aligned and the goto is working from the hand controlller, do I understand correctly that if the RPI3 changed the time and long/lat on the CGEM, all that needs to be done it to change it back? No realignment is needed. No power off and back on.

If true then, what are your thoughts if I was to do the following:

1. Use a web page on the RPI3 and setting RPI3 as an access point
2. Web page gets time from phone, and displays the RPI3 time
3. Button on webpage syncs RPI3 to phone
4. Indi then sets the RPI3 time on CGEM

I may try this today and I am sure I can get it to work. However, if it ruins the alignment on CGEM then it is not worth doing.

I see benefits here if possible, as then phone, SkySafari, Kstars, RPI3 and CGEM are all in sync.

Perhaps I am over complicating too, and i shiuld just let CGEM push time to RPI3 and let Kstars use that.

However, if possible to do with time, it would be awesome to do this with long/lat too. The idea being put long/lay values on web page, or in Kstars/indi and have it pushed to CGEM. This again assumes that the alignment remains true and would not need to be redone.

Thank you for the thoughts.

Thank you rockstarbill The CGEM was fine and is the part that is setup first.

I will check handcontroller version today.

When CGEM is powered on everything is connected. Should the setup to RPI3 only be connected after?

Indi is not connected until after CGEM is aligned and up and running.

Sorry, was not able to check the Indi values for date and time, and the debug was turned off.