I had my equipment set up outside the last two nights. It was definitely cold here too. But I was inside and the Raspberry Pi was outside serving up the devices to my laptop which was inside. Have you tried this kind of setup? It is much more comfortable for both you and the laptop. I was watching a movie and sitting in front of the fire and my laptop was next to me on a table running the sequences. The raspberry PI was outside in the freezing cold, but it is much cheaper than the laptop.

Yes, this is exactly what I do except I have my car since I have to drive to darker skies. Unfortunately this doesn't work so well when your camera is not supported! I hope to have my modified K5ii back soon, then I won't have this problem but still, I would like the synscan driver working as its the manufacturer's supported method.

Thanks @kecsap, I just tested out some things as you mentioned and its interesting...

Firstly I have v3.39.03 of the firmware which to my knowledge is the latest for V3 HCs. Yes, Kstars setup to update devices. I did not operate the system in any way. Just connected and then disconnected.

I entered incorrect data so that I could see whether it corrected it. It did so in most cases but changed others incorrectly:

Entered at the HC:

Date: 3/18/2018
Time: 17:41:44
Location: 73 09 W 44 27 N
Time zone: -3
Elevation: +20m
Daylight savings: yes

Then I connected to a remote stellarmate that had the HEQ5 connected via USB2Serial - when I tested before with the Mac, it exhibited pretty much the same symptoms.

Then I disconnected and checked the settings in the HC:

Date: 03/19/2018 (correct)
Time: 18:45:54 (correct)
Location: 74 09 W 45 27 N (correct)
Time zone: 00:00 (Wrong!!! should be -5, or -4 for daylight savings)
Elevaton: +20m (unchanged but does not agree with the Ekos device control pane which says 60.96m)
Daylight savings: No (Wrong!!! Should be YES with -5 for time zone or NO with -4 for time zone)

So time zone, daylight savings and elevation are issues.

Time zone+daylight savings: I think the handset does not care about these settings, the time itself what matters. I did not implement this part, but I never noticed because the driver worked without any problem with incorrect timezone settings.
Elevation: There is no way to set the elevation via serial protocol. It is most likely reset by the handset when longitude/latitude are set.

If you find these settings crucial for you, you should disable the handset update in KStars.

How can time matter but not time zone or daylight savings.

You mentioned that

Time: 18:45:54 (correct)

The handset will use these numbers and the latitude/longitude, it does not care about if the timezone is incorrectly set, if the local time is correct.

Then why would we always have to enter time zone and daylight savings time into the HC?

There must be something wrong because I found that it didn't seem to know where the meridian was. So I changed the geographic time zone in Kstars to UTC offset 0 (instead of -5 as it should be) and then the mount behaved correctly. It did a meridian flip if I tried to cross the meridian and it was pointing in the correct direction as I directed it on the Kstars map. I used low angle targets just east and just west of the meridian.

There must be a disconnect between Kstars understanding and the mount's understanding of the time parameters.

Thanks for the testing. I am almost completely sure what is the problem. I checked the documentation and the negative GMT offsets need special handling that is why I did not experience this problem here at GMT+2. The driver had these kinda huge bugs in every corner before my refactoring. This time handling is an earlier implementation and it seemed to work hence I did not touch. I will check today after work at home.

That's great! I'm looking forward to the fix.

Just a quick question - will this driver work with guiding (via mount control) or will I need to do guiding via "on-camera"?

@gbeaton: I have a bad news for you. I can't reproduce your problem, everything works as expected, I can sync negative GMT offset to my handset and the time+GMT match between KStars and the handset. I have also a V3 handset, the only difference that I have the latest firmware installed: v3.39.05 or the problem is the macOS environment. When you connect and sync the time, check the following before disconnecting from KStars:
- Is the GMT offset good in the handset inside the manual menu?
- Is the GMT offset good in INDI/Synscan/Site Management tab?

The daylight saving is never set on the handset, it is included in the GMT offset.

Guiding: Yes, synscan does not support guiding, it must go though the camera.

I'm working remotely from a Mac to a StellarMate via Wifi. This setup works fine with the EQMOD driver but not the Synscan driver. (Of course the stellarmate does not have correct time since it has no backed up clock, but thats not supposed to matter since its just running servers.) I'll try direct from the Mac again.

Ok. The problem can be on the Stellarmate. There is a certain code line in the driver which can be a problem on other architectures. I will also retest with my RaspPi setup on my balcony.