This is even weirder. grin.png Maybe I should remove the version fields completely? Seems like this does not work reliably.
Maybe firmware version has another format on RST-135E. On establishing the connection to the mount in Ekos the firmware version get's written into the info log below those fields. Can you please scroll a little and tell me what it says there? For me it's at the very bottom:
Thank you, Stephen (I'm sorry for misspelling your name).
Can you please tell me as well if the serial number on your General Info tab get's spilled into the firmware field? This happened on Willem's screenshot and I cannot reproduce this behaviour here. I was able to get back the serial number and at my installation it behaves as it should (6 letters in firmware field and 6 letters in serial number field).
This does not look like that on my system – all normal here. Steven, can you check please?
Willem, I gave the mount model tool a detailed look. I was observing a single (non repeatable) crash of Ekos/KStars as well when using RST-135. Interestingly though is that a crash can be repeatably forced by either hitting "pause" during the automatic alignment routine or hitting "stop" no matter when. I tried it with simulator drivers only (no real hardware connected) and the same behaviour was observed. Can you please test this as well? It should occur by just opening the mount model tool and then hitting the stop button on the very bottom-right corner.
Ekos Debugger shows this when it happens:
Thread 1 "kstars" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xb3a01230 in __GI_abort () at abort.c:79 #2 0x00816b3a in Ekos::MountModel::resetAlignmentProcedure (this=0x343b0c8) at ./kstars/ekos/align/mountmodel.cpp:992 #3 0xb4579380 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #4 0xb4ded104 in QAbstractButton::clicked(bool) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5 #5 0xb4ded340 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
"If you want to know the info, it immediately populates as soon as you enable the pull V&T." >> Sorry, have to ask one more thing: Enabling the pulling of V&T does immediately populate the serial number in the firmware field? Or immediately populates the log files with the data?
Thanks for testing, Willem.
Regarding "automatic mount model": Am I assuming correctly you're using the "Mount Model Tool" which can be started in EKOS Align Tab by the button "Mount Model"? I tried this with CCD simulator as well and I did not observe any issues. But I will test it again tomorrow. Did EKOS crash or the hand controller?
Regarding Firmware Version: There's obviously a small bug in the data field. It seems to append the serial number of the mount which is not intended. This did not happen during my tests but to be honest, I somehow deleted my mount's serial number while reverse engineering the "hidden" serial commands... devil.png I will try to fix this issue – but most likely will be difficult since I'm not able to test it live. BTW I found some more commands but was not able to map the mount's answers to corresponding functions correctly. This is very likely not intended by Rainbow Astro as well.
Regarding pulling of V&T: I made this optional and turned off by default because I was not sure whether everyone is interested in this information and if active in sum three serial commands are being continuously sent (limited by set pull rate) additional to the mount's more important data like RA/DEC & ALT/AZ positions. Unfortunately I did not figure out how to store the setting in the driver's config file yet – this would be the most convenient solution.
Star Alignment functionality got merged into master today and should be available as nightly soon.
Additionally I implemented the following: