×

INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

indi_celestron_aux

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Jasem. The alignemnt model is *crucial* for correct tracking in AltAz model. The axis velocity is calculated at each step using the model. Without the correct model, we do not know where we are pointing, and thus we do not know how fast we should be moving.It is quite different in Eq mode where you can blindly set sideral rate and just worry if the target is smack-middle of the FOV.
P.
9 months 2 weeks ago #78450
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Thanks, by I was standing on the shoulders of giants and I had help ;) And I just made the driver (implemented the AUX protocol deciphered much earlier by Andre Paquette) - it would not work at all without alignment module.

Thanks for the encouragement. There is still missing functionality, but I am glad it is starting to feel useful. And thanks for testing - this is another data point suggesting that internal alignment routines work much better than the new plugin. SVD seems to be somewhere in between. I have never tried the real mount + simulated ccd combination. Good idea.
P.
9 months 2 weeks ago #78451
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

I run a series of test with real scope+simulated ccd against current astroberry packaged verisons.
Conclusions:
  • Internal plugin still works fairly well - this is the only plugin which is useful with the CAUX driver. Do not use others at the moment (except for testing). You will only get confused.
  • SVD plugin actually seems to work but is very confusing when you have less then 3 sync points - jumps all over the place (after sync points to different place than synced ... this is confusing).
  • Nearest plugin works for pointing with similar accuracy to internal plugin but does not work for tracking. So it is useless for the AUX driver. Jasem: it seems it does not update the time of the solution, the pointing is correct and then the sky drifts. This is true for simulated and true ccd (i.e. real sky).
  •  The "manually point at the moon and sync" strategy actually can be made to work, but the steps are fairly complicated and easy to get wrong (you need to sync first, then goto the same object to engage tracking, then goto next target and sync without manually moving the scope and so on). Furthermore, you risk that the movements of the mount may cross unsafe regions. This is generally a bad idea. I would never use it in this mode with my hardware, and you should not as well.
  • I would rather suggest pointing at the horizon (level, approx) and point it to the approx north. I will implement selectable initial direction in the next version, to avoid long slews to get to southern directions. Then, just do a goto "to the moon" (or other bright object) use motion control in the driver (you can use telescope app - indi client on your phone for this) to correct the position and sync (also from the app). Alternatively, just capture, plate solve and sync from ekos. Go to next target and repeat. The third target should be quite close if your initial position was not far off and the mount is fairly level. This is the procedure I use.
  • Note that "slew to target" function in ekos does not add sync points. You need to make your mount model first (this is actually better that way, since it avoids multiple clustered sync points). If you need to correct your pointing model do the goto, solve&sync and then slew to target.
  • Park position, as is implemented now, slews the mount to the initial position it was turned on. If you did not move the scope manually (which you must not) this will be level and pointing north. If you moved manually this may point below horizon or even go to some unsafe position - that is why you should not move the scope manually, and this goes not only for parking - the normal operation may be unsafe as well in such case. Moving manually may be dangerous to your hardware.
P.
9 months 2 weeks ago #78473
The topic has been locked.
  • Posts: 36
  • Thank you received: 0

Replied by Maciek on topic indi_celestron_aux

Thank you guys for moving things forward !

Paweł - here are my points against your "manually point at the moon and sync":
  • Celestron does that in their hand controller and in SkyPortal. Think about it!
  • there is no single hint for a user saying that first sync should be at horizon level - thus when doing first sync above horizon level user risk exactly the same - mount may cross unsafe regions. There is no guarantee where user point. In my humble opinion, the risk is exactly the same or maybe your way is even more dangerous actually, because there is no information for user about horizon first sync and user experiences moved from SkyPortal, hand controller or other app encourage user to point to the moon and sync. Your method gives exactly same risk or even greater
  • when doing first alignment sync using plate solver or just syncing to the star with proper leveled mount, you got 0 error agains „some" error from trying to find Alt 0 Az 0 using your compass and spirit level :-P
Last edit: 9 months 2 weeks ago by Maciek.
9 months 2 weeks ago #78475
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

I've started re-writing the driver completely, some progress here: github.com/indilib/indi-3rdparty/commit/...5225b6305dedaeb42a73

Might take me a week or two to finish.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
9 months 2 weeks ago #78476
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Maciek: The first sync should not be on the horizon. There is no hint about the first sync at horizon because you should not sync at the horizon. Regarding the safety. The: "point at the moon and do the first sync" can be executed safely if you never move the mount manually again. Then the park position will be at the initial position of the moon (in AltAz) which is presumably safe. However, it is much more difficult to reason about the other movements of the mount. Furthermore,  at the preset stage, the execution of this procedure is confusing and non-intuitive. I will try to make it better in next versions. For now, I really advise doing it the way described below.

I was obviously not clear enough previously, thus the steps:
  1. level the telescope and point it to the norh (both approximately, the acuracy is not that important)
  2. tighten the clutches and do not touch them again ;)
  3. switch on the scope
  4. execute the goto to some bright object (without nay syncing)
  5. center the object using movement control buttons in the driver
  6. sync the position (or capture, plate solve and sync)
  7. repeat from the step 4 for next calibration object (you need 2, better 3)
I hope it is clearer now.
P.
9 months 2 weeks ago #78477
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Maciek: The first sync should not be on the horizon. There is no hint about the first sync at horizon because you should not sync at the horizon. Regarding the safety. The: "point at the moon and do the first sync" can be executed safely if you never move the mount manually again. Then the park position will be at the initial position of the moon (in AltAz) which is presumably safe. However, it is much more difficult to reason about the other movements of the mount. Furthermore,  at the preset stage, the execution of this procedure is confusing and non-intuitive. I will try to make it better in next versions. For now, I really advise doing it the way described below.

I was obviously not clear enough previously, thus the steps:
  1. level the telescope and point it to the norh (both approximately, the acuracy is not that important)
  2. tighten the clutches and do not touch them again ;)
  3. switch on the scope
  4. execute the goto to some bright object (without any syncing)
  5. center the object using movement control buttons in the driver
  6. sync the position (or capture, plate solve and sync)
  7. repeat from the step 4 for next calibration object (you need 2, better 3)
I hope it is clearer now.
P.
9 months 2 weeks ago #78478
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

I certainly appreciate your input help but Is it this bad?
My C++ is a bit rusty, but maybe "complete" rewrite is not required....
But I understand - I have so little time to work on this that you probably got inpatient.
Sorry, can't help it.
I see that it is a major rewrite. Just try to preserve the functionality, please.
I have noticed that you removed some angle wrap-around lines. Note that the mount is working with 24bit signed integers, and you need to observe this fact properly.
If you need any input from me, just ask - I will do my best.
P.
9 months 2 weeks ago #78483
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Absolutely, I will test it thoroughly on my setup here (Celestron Evolution) and I will submit it as PR, so it needs your approval before it can be merged! I'm also going to ask Rick to test it on the CGX to ensure that it works equally well on equatorial setups.

There are good reasons for re-write:
1. Migrate to new INDI properties.
2. Add missing features (Track Modes, Track Rates)
3. Add more useful information (raw encoders)
4. AuxProto was overhauled.
5. Simplify the driver.
6. Custom parking position? Not sure about this yet.

I have a couple of questions:
1. Are you certain the 24bit values are SIGNED? It appears I'm getting conflicting reports about them being unsigned as well.
2. getNorthAZ is used for what exactly? Is it supposed to be 0 for north hemisphere and 180 for south?
3. What is "approach" command used for exactly?
4. What's the parking/cord wrap toggled used for?
5. Any good summary for cord wrap handling? Still not sure about this.
6. MC_SET_NEG_GUIDERATE units appear to be "0.25 arc sec per second".. at least from ASCOM documentation. It appears you tested this experimentally?
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
9 months 2 weeks ago #78484
The topic has been locked.
  • Posts: 210
  • Thank you received: 118

Replied by Rick Bassham on topic indi_celestron_aux

Hey Jasem, unfortunately, I sold my CGX when I upgraded to a CEM120, so I won't be able to test for you. Feel free to take any code from my indi_celestron_cgx driver as well. The reason it hasn't been updated is the same. I sold the mount.
Gayle H Riggsbee Observatory - Charlotte Amateur Astronomers Club
CEM120 - TMB 100/800 - AT72EDII w/Homemade Moonlite Compatible Arduino Focuser - AT8RC w/Moonlite CSL 2.5" w/Moonlite Stepper v3
ZWO ASI2600MC-Pro - ZWO ASI2600MM-Pro - ZWO ASI174MM-Mini - ZWO OAG - ZWO EFW
AT2FF - CCDT67 - RIRED-M63
9 months 2 weeks ago #78488
The topic has been locked.
  • Posts: 36
  • Thank you received: 0

Replied by Maciek on topic indi_celestron_aux

Paweł, sorry for my mental shortcut, I understand that first sync point is somewhere up in the sky. But horizon level (Alt 0 Az 0) is some kind of hidden sync point because it determine alt 0 az 0 that way. Error in this point will affect accuracy of whole model.
Just try at your step no.1 point manually to Alt 10 Az 10 (error) and test model accuracy. You will notice how bad it becomes.
9 months 2 weeks ago #78490
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

I guess we need another remote session when moon will be up ;)
Then I will either prove myself wrong or proof to you that it actually works ;)
I just tested exactly this scenario: Manually point to the moon sync and follow with next two points. It seemed to work with simulated ccd. The real sky is another matter, though.
Let us wait for good weather and the moon/jupiter/venus ;)
P.
The following user(s) said Thank You: Maciek
9 months 2 weeks ago #78494
The topic has been locked.
Time to create page: 1.163 seconds