×

INDI Library v1.9.3 Released (11 Nov 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones. Some highlights:

Crazy slews with Celestron CGEM and Capture and Solve

  • Posts: 554
  • Thank you received: 138
The log-29-... file shows communication with the mount but the relevent area is buried among a lot of things that are irrelevant to this.
I've found a sync command at 20:24:23, it's close to where the mount is pointing. There's a slew which completes at 20:24:30 which sems file but there is a message saying that the target accuracy is not met.
One thing is that the last position check is before the mount has finished slewing.
[2020-12-26T20:24:30.719 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <e> "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <41B5B100,09F0BB00#> "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[SCOPE] RA-DEC ( 6:09:37,13:58:43) "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <p> "
[2020-12-26T20:24:30.857 EST DEBG ][           org.kde.kstars.indi] - Atik One : "[DEBUG] ParDeviceLibUSB::In - OK!! "
[2020-12-26T20:24:30.876 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <E#> "
[2020-12-26T20:24:30.877 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] latitude 40.9511, sop E, PierSide W "
[2020-12-26T20:24:30.877 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <L> "
[2020-12-26T20:24:30.880 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <0#> "
[2020-12-26T20:24:30.882 EST INFO ][           org.kde.kstars.indi] - Celestron GPS :  "[INFO] Slew complete, tracking... "
[2020-12-26T20:24:30.882 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] raoffset 38.1, SlewOffsetRa 35.6 arcsec "
[2020-12-26T20:24:30.885 EST INFO ][     org.kde.kstars.ekos.align] - "Slew complete. Target accuracy is not met, running solver again..."

That's all I've found, No obvious problem.
One thing, what sync tolerance are you using? It seems to be an arc minute or less. Are you expecting too much from your mount?
11 months 5 days ago #65283

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

  • Posts: 10
  • Thank you received: 1
I activated logging on all devices because my concern was that a dev would respond that "there isn't enough information," and I don't get many clear nights. Better too much information than too little.

I usually set the tolerance to 60 arcseconds, but sometimes I forget, and the default is 30 arcseconds. If there is a way to change the default, I would love to know it.

OK, so what I'm hearing is that there is no information in the log file that can be used to debug the crazy slews with Capture and Solve. As I wrote above, if I let the crazy slew finish (that is, if it looks like there is no risk of running the camera into the pier), the telescope will return to the target, usually with improved pointing.

If there is no way to see the behavior in the log file, then the best I can do is perhaps try to capture the behavior on video. I'm open to other ideas!
11 months 5 days ago #65286

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

  • Posts: 554
  • Thank you received: 138
There may be a crazy slew in the log data but it's dificult to tell with no information about where in the log data to look.
If you can give the time of a crazy slew then it might help.


The trouble isn't the quantity of the data it's the quality. There's 15,000 to 20,000 lines in the log file and finding the relevant place in that lot is going to be time consuming. Most of it is irrelevant.

Try turning the debug logging off for the cameras, most of the junk is from them.

A video won't provide any more information. I already believe you.
11 months 5 days ago #65289

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

  • Posts: 10
  • Thank you received: 1
We finally had a clear night, and I was able to capture a crazy slew in the log. Some information:

I picked some random star on KStars to align on. I did a quick focus, and somewhere between 18:05 and 18:06 I initiated an alignment with the "Slew to Target" option. I set the accuracy to 60 arcseconds. The reported offset was something like 9 arcminutes; I could see the star near the corner of the field-of-view. The telescope began to slew rapidly on the dec axis, and just after one rotation I had to start pulling cables because they were starting to wind up. I eventually turned off power to the telescope (it was still spinning) and tried to shutdown Ekos as gracefully as possible. As a result, the alignment procedure never got a second image.

I removed all of the setup lines from the log to just before the start of the alignment. I hope this is easier to read!

File Attachment:

File Name: log_17-55-27.txt
File Size:275 KB
10 months 3 weeks ago #65723
Attachments:

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

  • Posts: 554
  • Thank you received: 138
Thanks, that shows the crazy slew.

I get the impression this is a firmware issue in the HC. All the commands look fine except that after the mount has slewed through +90 in Dec the focus position is reported incorrectly.

I see it is Starsense version 1.20 but what is the exact version? There are three or four more numbers available on the HC Version display.

Chris
10 months 3 weeks ago #65798

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

  • Posts: 10
  • Thank you received: 1
Sure, from the hand controller, I find
Ver: 01.20.20244
Bld: Sep 1 2020
10 months 3 weeks ago #65799

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

  • Posts: 246
  • Thank you received: 45
When I looked briefly at the log it looked like the mount was doing a meridian flip. But there also seemed to be some weirdness in the RA values being reported by the mount as it was moving.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
10 months 3 weeks ago #65808

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

  • Posts: 554
  • Thank you received: 138
I have seen this sort of thing in the past, particularly when the mount has tracked past the meridian. If you run with no scope it's possible to let the mount run indefinitely and I've seen it get to the expected position having rotated through almost 360 degrees. Usually the alignment has been destroyed though. Also seen pier flips via the South pole instead of the North.

One thing in this case is that the declination is negative and perhaps that makes a difference. Perhaps the mount is trying to get to -8 deg by going the long way round, via +90, 180, 270/-90.

One thing that may help is an earlier HC firmware version. - or use the NexStar+ HC rather than the StarSense. The StarSense implements sync is a different way,
10 months 3 weeks ago #65812

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

  • Posts: 10
  • Thank you received: 1
Just as an experiment, I checked the Celestron Firmware Manager, and there was an update (not currently listed in the Celestron firmware history).

Ver. 1.20.20265
Bld. Sep 22 2020

I applied the update, and did a quick check this evening. Autofocus has improved, which was nice, but I still got a crazy slew. I've attached a log file, clipped to the start of the "Slew to Target."

Based on my experience so far, using Starsense with "Sync" and not "Slew to Target" works best. The NexStar+ HC works, of course, but, owing to a disability, manual alignment is very challenging for me. As I wrote earlier, using "Sync" and then slewing again with KStars works well. I just have to be careful to avoid the "Slew to Target" option.

File Attachment:

File Name: log_18-38-11.txt
File Size:42 KB
10 months 3 weeks ago #65815
Attachments:

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

  • Posts: 554
  • Thank you received: 138
The ASCOM driver doesn't use the HC sync command at all for the StarSense HCs. Instead it applies an offset in the driver to do sync independently of the HC. IIRC there is something similar in the INDI Celestron GPS driver which could be used.
I'm not in a position to do any INDI development at the moment but if someone wants to have a go... The 'm' command identifies the HC type, NexStar or StarSense. If the command fails it is a NexStar.
10 months 3 weeks ago #65832

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

  • Posts: 10
  • Thank you received: 1
OK, 8 months later, I solved the problem. 

I was preparing our Celestron mounts for solar system / eyepiece observations, and I noticed that none of the mounts were properly storing time and location. After I checked the onboard batteries and performed other failed efforts, I discovered the option to factory reset the mounts. That worked! The mounts now properly store time and location.

On a whim, I tested the "Slew to Target" method under Capture and Solve, and it worked perfectly. I mean, one-iteration perfectly. Of course, KStars has been quietly updating over the past 8 months, and so that may have contributed to the solution, but I suspect issues with the mount firmware were the real problem. 
The following user(s) said Thank You: Jasem Mutlaq
2 months 3 weeks ago #75457

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

  • Posts: 10
  • Thank you received: 1
OK, 8 months later, I solved the problem. 

I was preparing our Celestron mounts for solar system / eyepiece observations, and I noticed that none of the mounts were properly storing time and location. After I checked the onboard batteries and performed other failed efforts, I discovered the option to factory reset the mounts. That worked! The mounts now properly store time and location.

On a whim, I tested the "Slew to Target" method under Capture and Solve, and it worked perfectly. I mean, one-iteration perfectly. Of course, KStars has been quietly updating over the past 8 months, and so that may have contributed to the solution, but I suspect issues with the mount firmware were the real problem. 
2 months 3 weeks ago #75465

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

Time to create page: 1.340 seconds