How about using INDI NexstarEVO driver which is based on the AUX commands?

Thank you. I will check it out.


Sent from my iPhone using Tapatalk Pro

Can I have a look at your code @dokeeffe please? I have implemented the whole AUX driver for indi: nexstarevo driver. The missing piece is the wired interface - right now it only works over wifi, and testing with german mount. So far I have tested it only on fork AltAz mounts but in principle it should work for equatorial orientation. Maybe We can use some of your code to improve the indi driver?
And you are right - standard celestron driver is a totally different beast.

The NexstarEvo driver is almost what you need - unfortunately it needs wifi connection to the telescope. I intend to implement wired link support in the future but have no hardware to test it on. It was never tested on the german mount as well.
But you should be able to use timed movement commands of the celestron driver to nudge the mount to the correct place.

I was just looking at the NexstarEvo driver and noticed the wifi, and no serial, connection. Thank you for confirming the serial and gem would be the missing parts. Looking at the new_open.c it seems that a serial connection could be added.

I was initial thinking was to extend one of the existing drivers in the fashion of the SkySafari Auxiliary driver. I started looking to extend the current indi_celestron_gps. Now that I see the NexstarEvo I am trying to determine direction.

The initial idea was using one of the current drivers to nudge it along monitoring the RA/DEC, and then plate solve again to confirm (perhaps it would be easier to start with turning PEC on and off first.). In the celestron driver, looking at the Park function and the tty_write PEC could be turned on and off, ideally sharing the same port. The nudge would then use the current get RA/DEC to read to confirm the nudge in the right direction and then correct/stop as needed. This did seem possible at the time... The other question was how to integrate into the plate-solve module so that after some accuracy was obtained with the slew to target and nudge to target would be used to complete, and so it would all be done within the scheduler.

I am still wrapping my head around the client/server design... nearly there. Seems my iOS program and made me forget more than I knew.

Please let me know if it would be adding to a current driver, or if the auxiliary driver concept may work. Perhaps, if abstracted out properly, for nudging at least, it could be used for other mounts as well.

I was just looking at the NexstarEvo driver and noticed the wifi, and no serial, connection. Thank you for confirming the serial and gem would be the missing parts. Looking at the new_open.c it seems that a serial connection could be added.

I was initial thinking was to extend one of the existing drivers in the fashion of the SkySafari Auxiliary driver. I started looking to extend the current indi_celestron_gps. Now that I see the NexstarEvo I am trying to determine direction.

The initial idea was using one of the current drivers to nudge it along monitoring the RA/DEC, and then plate solve again to confirm (perhaps it would be easier to start with turning PEC on and off first.). In the celestron driver, looking at the Park function and the tty_write PEC could be turned on and off, ideally sharing the same port. The nudge would then use the current get RA/DEC to read to confirm the nudge in the right direction and then correct/stop as needed. This did seem possible at the time... The other question was how to integrate into the plate-solve module so that after some accuracy was obtained with the slew to target and nudge to target would be used to complete, and so it would all be done within the scheduler.

I am still wrapping my head around the client/server design... nearly there. Seems my iOS program and made me forget more than I knew.

Please let me know if it would be adding to a current driver, or if the auxiliary driver concept may work. Perhaps, if abstracted out properly, for nudging at least, it could be used for other mounts as well.

Maudy / Jochym, yes of course, I hope the code is some use..... Its here on github github.com/dokeeffe/auxremote

Probably needs a bit of explanation as to why I did things the way I did. Normally an indi driver talks directly to the hardware, however I have a java application sitting in the middle that talks to the mount over serial (AUX commands) and then provides a high level HTTP API. The INDI driver is just a bare-bones shell that talks to the java application using HTTP. I also have an angular javascript client in the works but thats low priority....
I did this because I have more experience with java (my full time job) and I wanted something ultra reliable and well tested. I think I have about 90% test coverage. The entire thing is working really well for me with the CPC1100 on a wedge. I can align the mount from a cold start (power on) park/unpark is much more reliable for me than the standard driver. I also exposed PEC functions.

Most of the core logic is in the MountService.java
github.com/dokeeffe/auxremote/blob/maste...nt/MountService.java
The bit that nudges the mount if the target is <1deg is the slew method line 120.

One really important thing I learned is make sure you enable cord wrap AFTER unparking the mount (setting tracking and doing a sync) Otherwise it looks like the cord wrap does not get enabled. I learned this when testing once and almost crashed the scope into the wedge!!

Derek

I hope to work through some of this this week. Not sure what I am fully getting into yet.

I can say that last nights RPI3 imaging session worked amazingly well. The only thing pending is the nudging the mount to centre the RA/DEC:
- The celestron GPS driver controlled things well
- pulse guide calibrated a lot better then the ST-4
- PHD2 guided well consider how low NGC 7293 was
- the scheduler worked great.

The meridian flip needed my intervention to re-center which I am not good at yet - sigh, took about 30. Once done things continued on until twighlight.

If this nudging can be added... oh my! I may post back with questions as I work though things.

Jochym, have you looked at this library? github.com/rumengb/libnexstar

I am considering making an INDI wrapper for it, and before I get too far, I am wondering if you discarded this library for a specific reason.

This is a different protocol. This library uses high-level celestron/skywatcher protocol implemented by the hand-controller. The NexStarEvo driver in indi uses low-level AUX protocol to control the motor controllers. This is the only protocol available over WiFi in this scope.
OTOH the high-level protocol is already implemented by the celestron driver so there is no point in duplicating it. I think you can implement this "nudging" idea by simply scripting the INDI celestron/camera driver + astrometry in python and if it proves effective I am sure Jasem (or you yourself) will add it to the slewing logic as an option in Ekos.

Hmmm... I had been using nexbridge with RPI3 connected via serial cable at one time, and thought that was your wifi approach; I am not familiar with the NexStarEvo. I now infer your use of AUX and wifi is direct to the scope itself.

Okay, you have helped an provided food for thought, it s seems there are choices.Thank you.

Nexbridge is, as I understand, just a specialized bridge tcp<->serial and does not interpret the communications.
The nexstarevo is an indi driver for celestron wifi telescopes using celestron AUX protocol. Currently it should work with NexStar Evolution and other nexstar telescopes with skyfi adaptor. In the future I plan to implement also wired connection to any Celestron with AUX port (most of them).
It is similar in idea to EqMod driver for skywatcher mounts. Both talk directly to the motor controllers and play the role of hand controller.