×

INDI Library v1.9.7 Released (29 Jul 2022)

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

indi_celestron_aux

  • 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: 8 months 1 week ago by Maciek.
8 months 1 week 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
8 months 1 week 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.
8 months 1 week 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.
8 months 1 week 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.
8 months 1 week 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
8 months 1 week ago #78484
The topic has been locked.
  • Posts: 208
  • 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
8 months 1 week 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.
8 months 1 week 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
8 months 1 week ago #78494
The topic has been locked.
  • Posts: 3
  • Thank you received: 0

Replied by Christian Kemper on topic indi_celestron_aux

Jasem,

Let me know if I can help test the driver fixes. The combination of real mount and CCD simulator works really well for that purpose.

On a separate note: Have you considered making this into a generic telescope driver / mount model that just talks to the motor controller on arbitrary telescopes? Or pull the functionality into a separate mount model / telescope pointing plugin that can be used by telescope drivers? I started reading about the different approaches to aligning and calculating pointing models and I think it would be great if these research papers could be put into practice easily.
Celestron 130 SLT, ZWO 224, Orion Accufocus, Stellarmate / Astroberry
Last edit: 8 months 1 week ago by Christian Kemper. Reason: fixing typos
8 months 1 week ago #78512
The topic has been locked.
  • Posts: 541
  • Thank you received: 56

Replied by Magnus Larsson on topic indi_celestron_aux

Hi!
I'd be happy to test on my equatorial CGE-pro or AVX, if that helps. 

Magnus

Celestron C11, Skywatcher 100 ED Pro
Losmandy G11
Atik 383L+, ASI294
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 8 months 1 week ago by Magnus Larsson.
8 months 1 week ago #78513
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Thanks for the explanation, Jasem. Let me just comment a bit, maybe it will help in deciding the directions.
  1. Migrate to new INDI properties.
    Most welcome - I, frankly, lost track of the rapid API development in INDI.
  2. Add missing features (Track Modes, Track Rates)
    These may or may not be tricky to implement. The main principle of the driver is: get the RaDec for the object at this exact moment and point the scope at this direction on the sky whatever the directions of the axis are.  It gets there by sending gotos to the particular encoder positions and the calculating instantaneous angular velocities of the axis and updating them periodically (often, possibly too often even). So if we get recalculated positions of the planet, comet, asteroid for the current time it will follow its movement. Although, at present the tracking code does not update RaDec of the target after goto which leads to moon drifting slowly. Eliminating this assumption should not be that difficult if there is some way in the INDI API to update RaDec of the target during tracking without goto.
  3. Add more useful information (raw encoders)
    The data in AUX stream is really not encoder positions. These are angles calculated by motor controllers. Just presented as integers. I do not think the raw encoders are present in the AUX protocol.
  4. AuxProto was overhauled.
    Some changes there seemed to me a bit too radical - but this will show up in testing quite quickly, and simplification are usually beneficial.
  5. Simplify the driver.
    I agree, it got pretty convoluted at places. Fresh look will definitely help.
  6. Custom parking position? Not sure about this yet.
    This was on my todo list. E.g. I have only ESW horizon. Parking to the north is annoying and means long initial rotations, cord wraps etc. In my case it is only annoying, in some other cases it may be impossible due to physical constrains of the environment.
Now for your questions:
  1. Are you certain the 24bit values are SIGNED? It appears I'm getting conflicting reports about them being unsigned as well.
    I am sure of nothing, really. But they seem to be. The docs indicate so: 
    github.com/jochym/nexstar-evo/blob/maste..._AUX_Commands_10.pdf
    Page 13  Table 3: "Position is a signed (24bit) fraction of a full rotation."
    In my experience, they seem to be twos-complement 24bit signed integers for ALT and 24bit unsigned ints for Azm. I think that due to the properties of the twos-complement representation and periodicity of angles this may be the same, actually.  But we can test it easily enough.
  2. getNorthAZ is used for what exactly? Is it supposed to be 0 for north hemisphere and 180 for south?
    That was an addition by Fabrizio to make the EQ parking position correct. I am not sure if it is still required.
  3. What is "approach" command used for exactly?
    This is a fairly clever trick by celestron to reduce the influence of the backlash in the relatively cheap mechanics. You make the fast goto to the location which is offset by the small amount from the target, and then you approach the target always from the same direction with "slow goto" which reduces vibrations and cancels all backlash if you approach from the same vector as the tracking will take. It is implemented this way in HC (if I am not mistaken) and in skysafari.
  4. What's the parking/cord wrap toggled used for?
    To switch the cordwrap protection in the AZM motor controller and to set the direction it should not cross during gotos. I have noticed that it is not working correctly right now. The CW gets sometimes activated despite being switched off (you noticed this as well). It is probably a simple bug.
  5. Any good summary for cord wrap handling? Still not sure about this.
    This is/should be a simple switch - the mechanics of it is handled by the Azm motor controller. There are two controls: Switch On/Off, and direction (angle) of the "uncrossable" position. This position should be opposite your usual observing zone (e.g. in my case it should be N since I have only ESW horizon).
  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?
    Yes, I did. With many mistakes on the way. There is a short explanation in celestronaux.h. My best experimental value was  1.315 for the TRACK_SCALE. The current TRACK_SCALE comes from the guess (based on measurement) that 1arcmin/min = 1024 units of rate (thus TRACK_SCALE = 60*1024/(2^24/360) = 1.31836). Right now the tracking based on this is just "dead reckoning" without any feedback loop, and it seems to track well enough (with these coefficients) to give good 30-60s expositions in main focus without star movement. Since it is guesswork and experimentation it is absolutely open to discussion. I could not find it documented anywhere. OTOH 0.25"/s would translate to TRACK_SCALE=0.0051 which will be much too low. But this may be subject to consistency of our definitions of rate units. I think the comment in celestronaux.h is actually wrong and should be 1/1024 arcmin/min as a rate unit -> thus TRACK_SCALE = 1024 * 60 / STEPS_PER_DEGREE. Testing this is time-consuming, I did it by measuring time to take the mount to make full rotation with a laser pointer as an indicator and a particular value send as a rate.
I hope this helps. I would like to follow your rewrite, so please submit the changes to git and tell me when I should make a test build and run the tests
P.
The following user(s) said Thank You: Jasem Mutlaq
8 months 6 days ago #78520
The topic has been locked.
Time to create page: 0.598 seconds