It looks like my problems aren't gone yet either, though things are a bit better with the time set correctly. I'm located in California as well, so I would expect our experiences to be similar (assuming we're trying the same things). Hopefully we can get this figured out. I'd love it if anybody who has the RST-135 working would respond. At this point I don't know if its a process / user issue, a hardware issue, mount firmware, INDI driver or Ekos issue. I'm hoping we're just doing something wrong and there's an easy change to our procedures to get things working. I'm really excited to get this new mount working as I also have a new camera (ASI533MC Pro) on a recently acquired WO RedCat 51.
Here's what I've done so far tonight. I was able to set the date / time / UTC offset with the handset and confirm that it had the correct longitude / latitude. I started with the scope in the home position (saddle pointing up, scope pointing west). It appears that when the mount powers on, it assumes this position. I also had the mount roughly pointed at the north celestial pole. After starting Ekos, I initiated a goto Polaris and it actually went to roughly the right location (not sure about RA, but DEC was pointing the scope north). I manually slewed RA to move the scope to the top (to the typical park position for other mounts). From there, I was able to solve and successfully went through the guided polar alignment process. I got it from 2.5deg down to ~2' and called it good. From there I issued a goto Alnitak. It slewed to roughly the correct coordinates and a solve showed that it was only ~1 degres off (almost all in DEC - RA was only off by ~1min). The solve / slew to target option sync'ed that location and issued a new slew to the same target coordinates. The mount appeared to do a meridian flip for the slew. At the time, the mount thought DEC was ~ -1 degree when it was actually -2+ degrees, so if DEC going from negative to positive required a flip, that makes sense. However upon reaching the intended target location, the next solve showed DEC off by 29 degrees. In looking at the logs, the mount reported that it was at the location that it was directed too, but the solver put DEC much further out (and it was clear in looking at it that it had slewed DEC too far). Here's some relevant lines from the log:
[2020-02-25T19:27:50.883 PST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "05h 41m 45s" ( 5.69598 ) DE: "-01° 56' 09\"" ( -1.93589 )
...
[2020-02-25T19:27:50.946 PST INFO ][ org.kde.kstars.indi] - Rainbow RST-135 : "[INFO] Slewing to RA: 5:41:45.5 - DE: -1:56:09.2 "
...
[2020-02-25T19:28:07.215 PST INFO ][ org.kde.kstars.indi] - Rainbow RST-135 : "[INFO] Slew is complete. Tracking... "
...
[2020-02-25T19:28:07.282 PST DEBG ][ org.kde.kstars.ekos.align] - ## RA "05:41:46" DE "-01:56:09" state: Ok slewStarted? true
[2020-02-25T19:28:07.282 PST DEBG ][ org.kde.kstars.ekos.align] - ## IPS_OK --> Auto Update Position...
...
[2020-02-25T19:28:23.451 PST INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (05h 42m 54s) DEC (-02° 59' 20\") Telescope Coordinates: RA (05h 41m 45s) DEC (-01° 56' 08\")"
[2020-02-25T19:28:23.455 PST INFO ][ org.kde.kstars.ekos.align] - "Target is within 01° 05' 32\" degrees of solution coordinates."
...
[2020-02-25T19:28:23.473 PST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "05h 42m 54s" ( 5.71523 ) DE: "-02° 59' 20\"" ( -2.98915 )
[2020-02-25T19:28:23.474 PST INFO ][ org.kde.kstars.ekos.align] - "Syncing to RA (05h 42m 54s) DEC (-02° 59' 20\")"
...
[2020-02-25T19:28:23.558 PST INFO ][ org.kde.kstars.indi] - Rainbow RST-135 : "[INFO] Synced to RA 5:42:54.8 DE -2:59:20.9 "
...
2020-02-25T19:28:23.567 PST INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (05h 41m 45s) DEC (-01° 56' 08\")."
...
[2020-02-25T19:28:23.667 PST INFO ][ org.kde.kstars.indi] - Rainbow RST-135 : "[INFO] Slewing to RA: 5:41:45.5 - DE: -1:56:08.8 "
...
And... I'm going to stop there because I think I just spotted the bug in the driver that caused this. There is a double negative sign in the sync command when DEC is negative (the same that was fixed in the set DEC command):
[2020-02-25T19:28:23.557 PST DEBG ][ org.kde.kstars.indi] - Rainbow RST-135 : "[DEBUG] CMD <:Ck085.728--2.989#> "
[2020-02-25T19:28:23.558 PST INFO ][ org.kde.kstars.indi] - Rainbow RST-135 : "[INFO] Synced to RA 5:42:54.8 DE -2:59:20.9 "
Then command was ":Ck085.728--2.989#". The format is supposed to be ":CkDDD.DDD+DD.DDD#". So not only is there a double negative sign, I think there are supposed to be two digits before the decimal for the DEC value. I think it should look like: ":Ck085.728-02.989#".
The code from the driver that formats that is:
snprintf(cmd, DRIVER_LEN, ":Ck%07.3f%c%06.3f#", ra * 15.0, dec >= 0 ? '+' : '-', dec);
I think if the final dec parameter becomes std::abs(dec), it will get rid of the extra negative sign and include a leading 0.
snprintf(cmd, DRIVER_LEN, ":Ck%07.3f%c%06.3f#", ra * 15.0, dec >= 0 ? '+' : '-', std::abs(dec));