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.

Ok I'm getting close to submitting a PR for this, but I need access to remote system with an equatorial Celestron AUX mount.

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

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?

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

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.

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

Sounds great, looking forward to it. Please send me detail via a private message.

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.

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.  

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.

Karl: The AUX port is *NOT* an RS-232 serial port! You need a special level converter to connect PC serial port to AUX. You need PC-port for this. Please do not connect your PC to the mount by AUX port. You can destroy your mount, your PC, or both by doing so. If you have no PC-AUX adapter, use the HC serial port.

The TX and RX are tied together inside the scope someplace, hence the echo you are seeing.
The RTS and TX line are multi-master, no device owns the line.
You must hold your TX tri-stated while monitoring the RTS as an input. Only when RTS is high can you then control it as an output and then can output the TX. WHen done transmitting, tri-state TX and turn RTS back to an input
See this for a full gadget hanging off the AUX bus
AUX WIFI BT GPS

Attached is a pic of my version, only used as GPS input to AUX with my own coding.
 
but with the coding referenced in the link above can do all.

Gene