Hi Guys I'd loved to give it a try and supplement the star alignment function at the INDI driver and test with my RST135.
I'd just need to see what would be the command strings the mount will be accepting.
Willem, I've got a working solution now. It exactly behaves as your requested "What I would like to have is a checkbox in the driver to turn on 'star alignment on sync'. When ticked, a regular sync command from Ekos would then be interpreted in the mount as star alignment point. As soon as the mount has received at least 5 star alignment points, it automatically calculates this model. If such an option is available, the existing mount model functionality in Ekos can be used to just define five (or more) random alignment points, press 'run', and the model builds itself in the mount. Once the model is built, the check-box can be unchecked again if desired."
Stephen pointed out that there's kind of an integrated feature of INDI called "INDI Alignment Subsystem". This is not used in my solution (but is used in the 10micron driver). To be honest, I don't fully understand how this subsystem works or should work. In my understanding this computes a mount model inside of Ekos/INDI, which should be the wrong way to go for Rainbow RST mounts, since they are computing their models inside the RST hardware only based on given star alignment points.
I faced one problem though: There's a random behaviour of RST's hand controller where it crashes. After I sent over the star alignment command the display on the hand controller correctly displays the star alignment but crashes after hitting the "ESC" button on the controller. I have no idea how this is connected. The display gets blank and it needs several seconds for a reboot. The mount's processor itself does obviously not crash though, since its continuously communicating with INDI. Additionally the hand controller shows some stored alignment data after the crash/reboot.
Thanks for the advice. I've submitted a pull request so hopefully this would appear in the nightly build soon.
See the screenshot I added the alignment tab, only one checkbox that would allow the alignment data to save to the mount before every sync. Switch it on if you want to send the align command to the mount during the sync operation.
So the most convenient way to build the mount model would be using the "Mount Model Tool" and then perform a set of platesolves (with "sync" as the operation)
And then the alignment points will be saved to the mount at each sync.
I've encounter the same issue at the Hand Controller - the screen became blank after I hit the Esc button. I'm going to send a email to BJ and ask. You can try pressing the ENT (or hold it), or hit the Esc a few times, the default "boot screen" will appear again in the HC. There're no disconnection between the mount, the HC and INDI so it seemed to be just the HC display problem.
For the issuehunt bounty, thank you very much for contributing and I have made my pull request onto it.
After project finish I will donate all the amount back to INDI to support the ongoing development.
Hi Stephen, thanks for the pull request. It's basically the same as my solution though I implemented it directly into the Sync function with ternary operators (therefore less lines of code changed). Your solution works but could be condensed down into some single lines of code. Question is now: Should we merge our attempts or simply let your PR merge into indilib?
My plan was to donate any bounty to the INDI project as well – so I'm happy with that.
Thank you @Stephen and @Christopher! This is great news to have this built-in and working so fast! The solution with the extra alignment tab and the tickbox looks good to me. Will try downloading the nightly build tomorrow. Sounds like the HC blanking is perhaps somewhat annoying, but nothing to be worried about, as everything functions.
My proposal is: After Jasem reviews and eventually merges Stephen's PR, I will create another PR with some tidied up code and I will try to implement some other new commands which BJ listed in the new command set (e.g. setting slew speeds). Additionally I think there still might be a bug regarding time pulling in respect of UTC offset and DST which I try to fix.
Question: Are there some other features missing which are implemented into the ASCOM driver?
I just encountered a problem with UTC offset and DST. After the time change the UTC listed in the Rainbow Astro panel was off by one hour and the local time was off by an hour. My HA was jumping back and forth by one hour quickly, about 1 second intervals. Start time at twilight and meridian flip were wrong. I turned off the mount and resynced GPS and it was fine, I did this a couple of times and in one instance the UTC offset was wrong again, seems to be intermittent, nothing obvious in log.
Borg 107FL, Astro-Tech AT130EDT; Rainbow Astro RST-135 SkyShed Pier; QHY600PH Chroma LRGBHa; QHY5-III-462C; IR Guiding WO Uniguide 50 & ASI290mm mini; ASUS PN51 ubuntu, kstars/ekos, & firecapture; Pegasus PPBA; Stellarvue Optimus + WO Redcat, Skyguider Pro RT90C, rPi4/stellarmate
Thank you Chris, good suggestion. And thanks for pointing out having the code condensed - 100% agree. I just submit a newer version for Jasem's review, and feel free to tidy up after the PR is merged. Thank you!
And I've sent a email to BJ to mention the blank screen after Esc. Once I received his reply I'll share the updates here.
Jasem, thanks for your review on my codes.
Last edit: 2 months 1 week ago by Stephen Wong. Reason: update details