@esb I do have the proper time zone offset under Time and Date. I have always had the hand controller connected and GPS working. Also, I always go to the GPS setting and hold down the enter key until it beeps and puts the A in the upper right corner indicating that it has acquired and stored the GPS time and coordinates. I have also confirmed that my Lat/Long for my Home setting is correct in case Ekos grabs that. I then set the handset to use the GPS location. I have KStars/Indi preference set to get the time and location from the mount. I have the same almost random issues every time I connect. It shows the RST-135 pointing at some other location then the due west horizon where the mount is parked. I think that we are having similar problems, and maybe we can work together to figure it out.

As for the version of the Indi driver? Looking at the file dates, there is an Indi update to the RST-135 driver in version 1.8.3 Released showing a date of Jan 2, 2020. But the KStars download file is dated in December. So maybe the latest download of KStars still doesn't have the update. How can we update the Indi drivers in KStars?

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:

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.

I ran into another problem as well. After resetting everything I was able to sync across the sky in short hops eventually getting to my target (which had passed the meridian by that point). However when I went to try to guide, it failed calibration.

[2020-02-25T20:02:21.109 PST INFO ][ org.kde.kstars.ekos.guide] - "Guide DEC: Scope cannot reach the start point after 21 iterations.\nPossible mount or backlash problems..."

However I think I've spotted the cause of that as well. Fortunately this evening I received a copy of the command set for the RST-135. For the manual RA/DEC move commands used for pulse guiding, a separate stop command is required ("Must send :Q# for stop"). However it doesn't look like the driver issues the stop command when the guide timer expires. I think fixing this problem is as simple as adding a call to issue the stop command in the guideTimeout() function. I'm guessing guiding through the guide port/cable works fine. Its just guiding through the driver/USB connection that has an issue.

Now to figure out how to actually build and test the changes I've identified here.

Hello Eric,

Thanks for investigating the issue and finding the bug. I fixed the Sync issue as you proposed, but I'm not sure about guiding. If Q# is required, this would stop guiding in BOTH axis, wouldn't it? So you can't have two pulses at the same time? say 3000 ms for RA, and 1000 ms for DE running at the same time? If the DE expires after 1000 ms, then issuing Q# would stop the RA pulse, wouldn't it?

Did this guiding issue ever get resolved? I have the RST-135 running for the very first time tonight, and guiding always fails. It begins calibrating RA, the mount moves back and forth, then goes to DC and it moves one direction and keeps going, never stopping. Eventually the guide star is lost, and guiding fails. This is the case for both PHD2 and Ekos guiding. I've tried StellarMate 1.5.4 with EKOS 3.5.0, and on my Mac remotely connected to the stellar mate running EKOS 3.4.3.

I'm able to boot the mount, home, and activate GPS. Then issue goto command from EKOS. Solve and sync, then goto gets accurate. Then I try guiding after this point and it fails.

Hi Andrew,
I have an RST-135 and I'm having the exact same problem you're seeing even with the latest release of Stellarmate. Running the mount with Windows / ASCOM the mount works without a hitch. I've also heard it works fine with the ZWO ASIair Pro and I'll be testing that shortly. At this time I can't recommend Stellarmate and the Rainbow mounts as a working combination. Hopefully, it'll get fixed soon.

Bill Clugston

Thank you for your feedback Bill.

Has the command set been updated? Anyone has access to the latest command set?

Alright, I took a look at the last command set I received from Rainbow back in June and they indeed added separate commands to stop motion axis separately. I just added this now to the driver so hopefully this fixes the guiding issue. Furthermore, I added functionality to send the mount location and time back to Ekos (in case you want to use the mount as the time/location source), and finally, I added RST-300 to the list of drivers. Please test with the next nightly builds.

If you're using StellarMate, then you can either switch to Beta channel (from App), or you can login to VNC to StellarMate, and open console and type in this command:

This should install the latest INDI code directly from Github.

Thanks Jasem, I’ll try the StellarMate update next clear night.

Thanks Jasem,
I'll update the software and hope for a clear night sometime during December. Not always an easy thing to find in the Seattle area during the winter months

Bill

Jasem, you rock! That last fix solved the guiding problem. I managed to get everything fired up and tested about a half-hour before a cold front rolled in and clouded everything out. The RST-135 slewed to Mirfak and plate-solved no problem. I then cleared the old calibration info out of Ekos and told Ekos to pick a star and start guiding. And that is exactly what it did!

Stopped guiding and slewed to M43, plate solved, and then clicked on guide again. Ekos worked flawlessly and was guiding and taking 30-second subs until the clouds rolled in and blocked the sky. Looking at the long-term weather forecast it'll be at least 2 weeks before I can test again. Maybe Andrew will get a shot at testing.

Bill

Jasem, I can confirm, it's all working well now! Thanks! Happily guiding away.