×

INDI Library v1.9.0 Released (23 Apr 2021)

Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.

Problem setting up Rainbow Astro RST-135

  • Posts: 3
  • Thank you received: 0
I just got the Rainbow Astro RST-135, and I am trying to get it to work with Ekos on a Mac. It connects and controls fine, but I am having trouble getting it to point properly. It seems to be a location/Time issue. How should I set the Time&Location Updates in the Indi Configure preferences? KStars updates all devices,Mount Updates KStars,GPS Updates KStar? I can boot up the mount, and park it with the hand controller. It also has build in GPS, and sets the mount facing exactly straight west to the horizon. But Ekos updates the Dec/RA to something way off in the eastern sky and when I try to slew to know objects that are visible (Like Orion Nebula), it thinks they are below the horizon. I am apologize if this is something basic, but I am just beginning with Astrophotography and this is my first mount. Any help on how to troubleshoot would be greatly appreciated!
1 year 2 months ago #49944

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

IIRC, you cannot set time/date on the mount from the command set so KStars plays no role in setting this.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
1 year 2 months ago #49946

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

  • Posts: 3
  • Thank you received: 0
The Time and Location on the mount are set properly by GPS, but Ekos almost acts like it thinks I am at GMT and not California like I actually am located?
1 year 2 months ago #49947

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

  • Posts: 59
  • Thank you received: 3
I just got an RST-135 and am having similar problems. The main issue is that I’m not able to get the solver to work most of the time. It appears that is due to KStars/Ekos/INDI not thinking the mount is pointing where its actually pointing. I’m guessing its all related to the fact that the default / park position is as you said - pointing west on the horizon.

It worked initially as I would expect. I started with the mount in the parked position and the scope pointing west. I had manually pointed the mount as close to north as possible by sight. I then slewed the scope to close to Polaris. I was able to solve and run through a polar alignment. The solves were very fast. However I then attempted to slew to a target away from Polaris. It slewed to a position somewhat close, but quite a bit lower toward the horizon - enough that line of sight was blocked by trees. I manually slewed to a point where it could see the stars again, but the solve failed / timed out every time (both offline and online for astrometry.net). I tried quite a lot of different locations with no luck. I eventually slewed back toward polaris and solves started working again - just as fast as they were originally.

My guess is that most of the time, it thinks the actual scope position is >30 degrees from where it actually is which prevents the solver from working since it by default only searches within 30 degrees of the location hint its given.

I eventually manually slewed to the park position, shut everything down and started from scratch. I was able to repeat my original success around Polaris and then even manually performed a few shorter slews to solve / sync. I eventually was able to choose an object and slew to it and solve to center. However I realized I hadn’t set up PHD2 the way I wanted for guiding, so I shut down Ekos, started KStars and re-started it. After that I couldn’t solve again.
1 year 2 months ago #50080

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

  • Posts: 59
  • Thank you received: 3
I just ran another experiment and it does seem to be slewing the wrong direction - in at least one axis. I reset everything again with the scope pointing west (as close as possible anyway). I manually slewed to north and was able to plate solve again and the mount pointing seemed to show around the right location (90 deg DEC && the approximate correct latitude for my location - ~37deg). I then attempted to slew to an object that was higher in the sky than Polaris and to the northwest (effectively higher and more westward than the current location at that time). Instead however it slewed to a location to the northeast. After slewing, the coordinates shown in Ekos seemed right (AZ ~326 deg / ALT 56 deg). However the scope definitely slewed to the east instead of west. The altitude seems like it was probably about right.

Has anybody successfully used the RST-135 with Ekos? I’m wondering if this could be a firmware issue.
1 year 2 months ago #50084

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

  • Posts: 59
  • Thank you received: 3
I started looking at the Rainbow driver in INDI. The most recent commit from Jan 3 affects the command sent to the mount to set the declination. It appears to fix an issue affecting the sign of the degrees value used for declination. I could very easily see this issue caused by an incorrectly signed declination value. In my case, it should have probably rotated declination counter-clockwise (negative) and likely instead rotated it clockwise.

Is it possible the most recent official release of KStars (actually StellarMate 1.4.6 - up to date) doesn’t have that commit?
1 year 2 months ago #50085

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

  • Posts: 59
  • Thank you received: 3
In thinking about this problem more, I realized that the issue I mentioned with the sign on the declination value is not my problem. That only affects north / south direction (relative to the celestial axis / poles). In my case at least for the final test, I was pointing to an object well in the north (~60deg DEC). It does feel like it could be RA related. That would be odd though since my mount is pretty close to polar aligned (<3' away) and I had performed a successful plate solve / sync. Given that its so close to polar aligned, the one solve should have been enough to get it close to where it should be. I wonder if there are old calibration points in the scope that haven't been cleared out. I've been hitting the "Clear model" button, but perhaps that isn't working right.
1 year 2 months ago #50098

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

  • Posts: 59
  • Thank you received: 3
I think I have stumbled upon the answer. It looks like the GPS receiver is in the hand controller and I have not had it plugged in (why would I when I have StellarMate/Ekos). Based on the code in the driver and Jasem's comments above, the scope can accept the current location over USB, but cannot have the time set. That would mean that the scope doesn't know what time it is. If it uses that incorrect time in its alignment model after a couple of sync'ed coordinates, it could easily slew to the wrong location. Unfortunately its now light here. I'll have to wait until tonight to test my theory.
1 year 2 months ago #50099

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

  • Posts: 59
  • Thank you received: 3
I talked to another RST-135 owner today, and while he doesn’t use Ekos, he did say he had a similar problem when he started using the mount. You do need to connect the hand controller to get a GPS sync. He also mentioned that the mount will *not* automatically determine the local time zone from the location. The local time offset from UTC needs to be manually entered on the hand controller.

@psparkman - I’m guessing that is the issue you ran into. Make sure you enter the time zone offset in the hand controller.

I’m going to lobby with RainbowAstro to add time / UTC offset support to the command set. Support for that would eliminate the need to use the handset at all.
1 year 2 months ago #50116

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

  • Posts: 3
  • Thank you received: 0
@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?
1 year 2 months ago #50133

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

  • Posts: 59
  • Thank you received: 3
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));
1 year 2 months ago #50135

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

  • Posts: 59
  • Thank you received: 3
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.
1 year 2 months ago #50138

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

Time to create page: 1.461 seconds