×

INDI Library v1.9.8 Released (29 Sep 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

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
9 months 3 weeks ago #78520
The topic has been locked.
  • Posts: 103
  • Thank you received: 4

Replied by Gunter on topic indi_celestron_aux

Hi Fabrizio,

can you Tell me the Port to use with SkyPortal? The Standard 2000 do not connect.

by Gunter
9 months 3 weeks ago #78522
The topic has been locked.
  • Posts: 64
  • Thank you received: 9

Replied by Fabrizio on topic indi_celestron_aux

Hi Gunter,
sorry, my setup is all wired with USB to serial converters, no WiFi. So, I cant help you.
Fabrizio
The following user(s) said Thank You: Gunter
9 months 3 weeks ago #78525
The topic has been locked.
  • Posts: 64
  • Thank you received: 9

Replied by Fabrizio on topic indi_celestron_aux

 The purpose of function getNorthAz is to make the cordwrap work even if the mount is powered up when the scope is not pointing at North. Since the CPC mount zeros the motor encoders at power up, getNorthAz compute the offset between North and scope direction at power up. This offset is subtracted in cordwrap angular computations. If the mount is not aligned, getNorthAz returns zero, otherwise it returns the real North azimuth.
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 9 months 3 weeks ago by Fabrizio.
9 months 3 weeks ago #78527
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Thanks for clarification Fabrizio, I forgot how it was supposed to work.
P.
9 months 2 weeks ago #78531
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Do you mean SkyPortal (SkySafari) driver? It connects to the indi server, not to the scope.
The 2000 port is a port of the Wi-Fi module in the telescope. You can connect to it with CAUX driver, Celestron SkyPortal or SkySafari.
The SkySafari *driver* speaks LX200 protocols on different port and acts as a bridge between indi server and the SkySafari application.
P.
9 months 2 weeks ago #78532
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Quick follow-up about signedness of angles in AUX commands. I have reviewed my notes and it seems that the angles are indeed 24bit unsigned ints which are farctional full rotations. So 360deg = 2^24 in the angle field.
P.
9 months 2 weeks ago #78535
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Thanks! Ok, so I'm thinking about the tracking & guiding now.

1. Equatorial Mode: Mount is tracking sidereally (or using custom rate), so the driver should not perform any active tracking on its own beyond that. Guiding pulses are sent directly to the mount via AUX commands.
2. Alt-Az mode: Is the Celestron on-board controller doing any tracking on its own? or it purely expects MC_SET_POS_GUIDERATE and MC_SET_NEG_GUIDERATE ? If the latter, then the AUX documents suggests we do this every 30 secs (why)? What if we perform the variable rate adjustments each second? Furthermore, since we are actively tracking now by calculating the difference between current and target alt-az position, how does guiding come in the picture? If we use the regular AUX Guide pulses, this would actually shift out tracking target slightly in the sky by a couple of steps. But then the active tracking computes current vs. target positions and does not account for guiding, so it ends up fighting back[/b] any guide pulses.

So before I continue down this path, I wanted to know your thoughts on this. Thanks!
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 #78554
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

The initial driver was intended only for the AltAz mount, like the Evolution. The Eq mode is an afterthought. Nevertheless, the same approach will still work for Eq, since no mount is perfectly aligned and the input from the alignment routines can be still used to correct rates in Dec and RA - thus eliminating the necessity for very precise polar alignment. Thus, I would not switch to a completely different tracking mode for Eq mounts. Since the standard Eq mode (sidereal rate in RA + guiding pulses) is much simpler, it should be fairly easy to add it as a switchable option. Remember that not everyone has a guider - thus removing corrective guiding would make the driver less functional. As for the fight between the tracking and guiding pulses: I do not know really. But, I think that it should be fine since we are controlling the speed not the position and the target position is not changing. Thus, we are correcting only the errors of the mount not the tracking rates and target position.The motor controllers handle constant angular velocity and two types of goto movements. You specify angles for the gotos, and then you specify the tracking rates in both axis (with MC_SET... commands). These rates are constant - if you switch off the driver or lose the connection, the scope will keep rotating with constant angular velocity. That is why it may be unsafe to operate without limit switches or supervision. The 30s period is arbitrary and probably fine for visual observing. It is definitely not enough for high-Alt positions (the AZ rate changes rapidly). We are actually sending adjustments every second in the current driver based on +/- one-minute position difference. The controllers seem to have no problem with this rate of adjustments. In my view the guiding does not shift the position on the sky it only corrects for the errors in the mount. The tracked position (thus also tracking rates)  does not change. So in this respect we should be fine as long as we are not reading back the encoder positions to modify the rates. The first version of the driver actually did just that, and I had huge difficulties with making it consistent. At present, the tracked position is changed only when we use movement controls. But in this case we are supposed to move the tracked position on the sky (that is an assumption). 

Do not hesitate to ask if something is still unclear. The interplay between tracking, guiding and manual movement is really tricky to get right. I do not think we can avoid making some assumptions. Otherwise, there are simply too many degrees of freedom.
 
P.
9 months 2 weeks ago #78556
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

One more thought. I really do not know what happens after the guide pulse. I guess encoders got updated, and the effect is the same as would be if we moved the mount with slew commands. But this is just my guess. It is possible that the MC hides this update and subtracts the guided angle from the reported position. In other words: if the position on the axis does not change after guide pulse, we are good. Otherwise, we need to do this subtraction in the driver by keeping track of the guiding shifts - this may be tricky but seems doable (the guiding pulses are simulated anyway, thus there is a strict relation between length of the pulse and actual number of steps shifted).
P.
9 months 2 weeks ago #78557
The topic has been locked.
  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indi_celestron_aux

Last night there was some nice weather and I decided to run a bunch of tests of a current driver. Most of my previous comments and conclusions stands, but I have a little bin more data and some additional conclusions and comparisons.
It was run with astroberry compiled caux and other drivers and kstars compiled from git.
  • My setup was deliberately sloppy - no precise levelling or pointing. I just moved my mount to the balcony, connected, it levelled the tube with marks on the mount and started.
  • First, I checked the "point to the moon" scenario - it does not work. Here we are worse than skyportal/skysafari. It <em>should</em> work if we would have all our ducks in the row in the alignment subsystem. It should be able to handle the rigid rotation in both axis (shifted zeros) without any problems. Something is wrong either in my handling of the plugins or in the plugins themselves. So Maciek was <em>right</em>. Jasem, please during your refactor pay attention to my usage of the alignment routines. They are programmed after one of the tutorials, but maybe I did something wrong. BTW, instructions of skyportal tell us to do the same and I remember it got confused few times when I didn't.
  • The alternative scenario: point to the northern horizon (my pointing was +/-10deg approx), do a goto some object, center it and sync, repeat two more times. This works fine even with visual centering (no plate solver). The result was adequate for visual observing.
  • A similar procedure with plate solver and sync points (30-60deg) around the target worked much better.
  • By doing 3-7 sync points, I was able to reach the field rotation barrier with my expositions (60-120s).
  • I run the setup alternatively between skysafari and indi by disconnecting the  CAUX driver and connecting SS. Without dropping calibration in both. It worked for at least four cycles. I synced the positions in SS on bright stars and live view in the camera. The first was a bit tricky, but the rest were easy. I had to go outside only once during the run.
  • There seems to be no large qualitative difference between these drivers. The SS is a bit smoother in operation (being on the tablet). There seems to be some quantitative advantage to SS with alignment. It is more tolerant and the accuracy falls off slower with the distance.
  • Both internal and SVD plugin worked similarly with a small edge towards internal. The nearest plugin did not track.
Maybe this will help Jasem in identifying weak and strong places to work on/transplant to his refactored driver and help users getting the current driver working.
P.
The following user(s) said Thank You: Maciek
9 months 2 weeks ago #78601
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Ok I'm getting close to submitting a PR for this, but I need access to remote system with an equatorial Celestron AUX mount.
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 #78640
The topic has been locked.
Time to create page: 0.487 seconds