Folks
Help. I have a FocusLynx controller connected to an SVX30 DirectSync motor. I have measured my backlash at 480 ticks, however I cannot enter any number greater than 255 in the driver backlash field. I realise that I can use the AF overscan field, however I just want to be sure I’m not missing something more serious. Is there a reason the field maxes out at 255 steps?
Thanks
Anand
Read More...
I'm fairly certain that this is the problem. The Hand Controller reported the timezone as UTC -4 which includes the DST setting. It appears that KStars needs the timezone set to -5. I will uncheck the box to get the time from the mount and only location and this should fix it.
Read More...
I’m going on with the assumption that my understanding of the HA number is correct.
Yes we have just switched to summer time in my locale. However, I have the following configuration:
1. Losmandy Gemini 2 Level.
2. GPS device connected to the mount controller
3. NTP configured on the mount
4. When I power on the mount, I use the cold start option and query both GPS and NTP for the location and time.
5. Kstars is configured for “Mount updates Kstars” with both Time and Location set.
The Mini PC. Time matches the mount. How can I tell what time Kstars thinks it is currently? Also since the mount is updating location how do I determine that it’s using the correct UTC offset? Opening the Time dialog shows that my location in the table, the offset is correct. I also notice that if you choose a DST setting, the UTC offset must be the “winter” one for Kstars to get the time right during summer.
Help
Anand
Read More...
Folks,
Could someone please tell me what the HA time is referring to in this screenshot:
The reason I am asking is because I thought it meant "Clock time past the meridian" (assuming +ive number). However, in my screen shot that would make the transit time for my object 21:47 (local time). The problem is that the actual transit time for the object was 22:48. My mount has limit settings that will allow a flip request between 1 degree (4 mins) and 10 degrees (40 mins) past the meridian. As a result, when I told Ekos to "Flip if HA > 2 degrees", it kept failing. I eventually just unchecked the box and waited until the mount reported that it was far enough past the meridian and checked the box. This worked as expected and the mount performed the flip. Help.
Anand
Read More...
It appears that Unchecking the North/South and East/West check boxes under "Reverse" Solves this issue. Can someone please confirm that this does not adversely affect tracking or GOTO's in other parts of Ekos?
Read More...
Sounds like it's not mount related since you're using the EQMOD driver and I'm using the Gemini Driver.
Read More...
All,
I've read a few other threads on this issue and none seem to apply to me. I have been using the polar align assistant successfully for some time prior to upgrading the firmware on my Losmandy GM811 to the latest Level 6 firmware. When I try to polar align, it would slew for a few seconds and then stop with the error "Mount aborted. Reverse RA axis direction and try again."
Equipment:
- KStars 3.6.6 Stable
- Linux stellarmate 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
- RaspberryPi 4B with 8GB Ram
- Gemini Version Level 6 Build June 13
- HC Version 1.6 Build July 23
- Servo Version 3.0
It appears that the mount and Ekos think they are going in opposite directions:
[2023-08-22T20:23:48.814 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 30
[2023-08-22T20:23:48.958 EDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Moving W"
[2023-08-22T20:23:49.810 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 30.0083
[2023-08-22T20:23:50.870 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 30.4625
[2023-08-22T20:23:51.943 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 33.3583
[2023-08-22T20:23:52.977 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 36.9958
[2023-08-22T20:23:54.048 EDT DEBG ][ org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 40.4583
[2023-08-22T20:23:54.049 EDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope: Aborted.
[2023-08-22T20:23:54.049 EDT INFO ][ org.kde.kstars.ekos.align] - "Mount aborted. Reverse RA axis direction and try again."I also reset all of the settings on the Gemini to factory as part of the upgrade process, so I am not sure if there is a setting that I am missing.
Thanks in advance,
Anand
Read More...
I didn’t know there were align profiles. I’ll look at mine to see what it’s set to. Can you give a brief description of their purpose?
Read More...
I did. It would solve once or twice after refreshing. After that I would get the “solver failed” message. After that I’d get no more messages in the log, so I assumed it hung up.
Read More...
Hy,
I am using the "Plate Solve" Method for the polar alignment. I would have to completely restart because after I see the first "Solver Failed..." message, it does not appear to do anything else. I think I need to do some more testing so that I can give you a better report of the issue. I'm hoping to have some clear skies soon so that I can test it. It is entirely possible that this is user error.
Anand
Read More...
Hy,
I ran into a similar issue to this one last night when trying to us the polar align with platesolve. Can you confirm if your code change is integrated into 3.6.5? If yes, then I may have a different issue causing me to get the "Solver Failed" message. My experience was this:
1. Start Polar alignment
2. Capture all three images and plate solve successfully.
3. I would start the refresh and it would refresh twice, I would try to move the AZ knob and then get the dreaded "Solver Failed after..." message. What's worse is that there's no recovering from it without stopping and restarting the Polar Alignment process.
If your changes are already in my version, I will start a new thread for this.
Thanks,
Anand
Read More...