×

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

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 1 week ago #78640
The topic has been locked.
  • Posts: 544
  • Thank you received: 56

Replied by Magnus Larsson on topic indi_celestron_aux

Hi!
If a Celestron AVX or CGE-pro will do (both EQ), those are available for you right now. 
Magnus

Celestron C11, Skywatcher 100 ED Pro
Losmandy G11
Atik 383L+, ASI294
9 months 1 week ago #78644
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Ok tested on Magnus's CGE-Pro via PC port. While I can read from the mount, issuing GOTO has no response at all. Any idea what would cause this? Anyone with an equatorial mount can checkout the branch?
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
9 months 1 week ago #78750
The topic has been locked.
  • Posts: 103
  • Thank you received: 4

Replied by Gunter on topic indi_celestron_aux

Hi,
I have successfully tested my CGEM DX mount with the Celestron WiFi-Adapter called "SkyPortal" (it is identical with SkyQLink). I integrated the WiFi-device in my home network and used port 2000. It worked very well.

Gunter
8 months 3 weeks ago #79008
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

I'm going to need remote access to a Celestron equatorial mount that can be operated via PC port or WiFi. Magnus graciously granted me unlimited axis to his mount but we stumbled across a very weird issue and I would like to test with other equatorial mounts to see if we'll experience the same.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
8 months 3 weeks ago #79072
The topic has been locked.
  • Posts: 103
  • Thank you received: 4

Replied by Gunter on topic indi_celestron_aux

Hi, Jasem,

I would open up my network for you. You would need to connect by an VPN tunnel. But it will take a day to put everything in the right order, ok?

By Gunter
The following user(s) said Thank You: Jasem Mutlaq
8 months 3 weeks ago #79093
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Sounds great, looking forward to it. Please send me detail via a private message.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
8 months 3 weeks ago #79108
The topic has been locked.
  • Posts: 46
  • Thank you received: 6

Replied by Karl Rees on topic indi_celestron_aux

My other mount is in the shop, so I thought I'd play around with this driver and my old Nexstar SLT to put together a first smart-scope for my kids.  But it's not quite working out.  Has anyone tried this driver with an older (circa 2008) Nexstar SLT?  

It appears to be working directly through the handset, but the whole point of this driver to me at least is to connect directly to either the HS or AUX port.  For the HS port, I'm wondering if my USB-Serial (FTDI) adapter lacks symmetric voltage.  I'm trying to find a compatible adapter, but the ones on Amazon tend not to specify whether they support symmetric voltage.

For the AUX port, I've successfully used the SkyPortal WiFi module (which I lost) with this mount in the past, so my understanding is that I should be able to use the AUX port.  I've made my own cable, so maybe I did something wrong there.  Here's what I did:

RJ12 pin 1 <-> DB9 pin 8 (CTS)
RJ12 pin 2 <-> DB9 pin 2 (RX)
RJ12 pin 3 (not connected)
RJ12 pin 4 <-> DB9 pin 3 (TX)
RJ12 pin 5 <-> DB9 pin 5 (GND)
RJ12 pin 6 <-> DB9 pin 7 (RTS)

The driver thinks it is connected, but the mount does not respond to commands.  Looking at the logs, the driver does not appear to actually be receiving anything from the mount,  Rather it's just getting back an echo of what it sent, which it then ignores.

Looking deeper into the logs and the code, it appears to not be receiving a CTS signal.  detectRTSCTS() returns false.  There are no handshake errors, which I interpret to mean that waitCTS() is never seeing the TIOCM_CTS flag.  I'll spit out an excerpt from the log below just in case I'm misinterpreting.
DEBUG    6.428512 sec    : Connecting to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A16IRNH1-if00-port0 @ 19200
DEBUG    6.436192 sec    : Port FD 3
DEBUG    6.436338 sec    : Connection successful, attempting handshake...
DEBUG    6.436417 sec    : CAUX: connect 3 (serial)
DEBUG    6.792473 sec    : detectRTSCTS = false.
INFO    7.349836 sec    : Setting serial speed to 9600 baud.
CSER    7.400070 sec    : CMD <56>
CSER    7.400170 sec    : aux_tty_read: 3
ERROR    8.401306 sec    : Timeout error
INFO    8.401479 sec    : Detected Mount USB serial connection.
DEBUG    8.401557 sec    : Communicating with mount motor controllers...
CAUX    8.401638 sec    : CMD <     GET_VER>  APP ->  AZM
CSER    8.451916 sec    : CMD <3B 03 20 10 FE CF>
CSER    8.452100 sec    : aux_tty_read: 3
CSER    8.452221 sec    : aux_tty_read: 3
CSER    8.452312 sec    : aux_tty_read: 3
CSER    8.452436 sec    : RES <3B 03 20 10 FE CF>
CSER    8.452583 sec    : Got 4 bytes:  ; payload length field: 3 ; MSG:
CSER    8.452688 sec    : [3B 03 20 10 FE CF]
CAUX    8.452758 sec    : RES <     GET_VER>  APP ->  AZM
CAUX    8.452825 sec    : Got msg not for me (AZM). Ignoring.
CAUX    8.452903 sec    : CMD <     GET_VER>  APP ->  ALT
CSER    8.503168 sec    : CMD <3B 03 20 11 FE CE>
CSER    8.503328 sec    : aux_tty_read: 3
CSER    8.503422 sec    : aux_tty_read: 3
CSER    8.503501 sec    : aux_tty_read: 3
CSER    8.503595 sec    : RES <3B 03 20 11 FE CE>
CSER    8.503673 sec    : Got 4 bytes:  ; payload length field: 3 ; MSG:
CSER    8.503737 sec    : [3B 03 20 11 FE CE]
CAUX    8.503795 sec    : RES <     GET_VER>  APP ->  ALT
CAUX    8.503852 sec    : Got msg not for me (ALT). Ignoring.
INFO    8.503909 sec    : Got response from target ALT or AZM.
DEBUG    8.503965 sec    : Connection ready. Starting Processing.
INFO    8.504064 sec    : Celestron AUX is online.

The rest of the log goes on in much the same pattern: a new CMD is issued, it's echoed back in the RES, and is ignored.

Further information: the driver is showing version .10 and was self-compiled yesterday from the main branch.  The motor controller firmware is 5.18.  

This is not a super high priority for me, but I'm OCD when it comes to these things.  I'd hate to think I was just a small step away from solving it.  Thanks in advance for the help.  
8 months 1 week ago #79531
The topic has been locked.

Replied by Jasem Mutlaq on topic indi_celestron_aux

Thanks for the testing Karl. I've actually seen this very issue from Magnus mount as well (CGX IIRC). But it was intermittent. Sometime detectRTCCTS() would return false and all I see is echo, other times it works OK and responds to commands. I haven't been able to establish a pattern, appears to work most of the time. The only issue I had is that it would abruptly stop tracking/GOTO past a certainly hour angle and I was not able to resolve this issue, hence I asked for another test for Celestron equatorial mount which I wasn't able to do since then.
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 #79550
The topic has been locked.
Time to create page: 0.487 seconds