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.

Yes that is what nexbridge is.

I understand more now. AUX can mean no need for a hand controller.

Currently I am still wrapping my head around the design and entry points. Over next days I will look at creating an initial hello world indi driver. Assuming my cpp skills still exist somewhere it should be fine.

Later, assuming I get somewhere, if I can help on the wired side I will.




Sent from my iPhone using Tapatalk Pro

FIY regarding the physical AUX port. I read somewhere that it needs a special cable and that if you make a mistake that you could cause damage to your computer that its plugged into or even the mount.
It is possible to send AUX commands to the mount through the handset and avoid this risk. That's what I'm doing in my system. The hand controller is not doing anything in this case, Its just a safer way to send aux commands to the motor controllers via a cable.
Derek

You are right. The AUX port needs level converter and just *looks* like serial port (and communication is over standard serial protocol). If you connect it with serial port you are indeed likely to fry at least one and possibly both ends of the connection. The HC serial socket is much better but it is not clean passthrough - you send commands with a prefix and you only get responses - so you cannot listen for broadcasts on the AUX bus - that limits possible functions a bit.
I have no AUX adaptor thus the HC variant will be implemented first, but the difference is essentially the prefix, so it will be simple switch.
I've also seen a nice hack with RPi0w mounted *inside* the HC providing the INDI interface to the HC.

Well, some time final became available and I am working on getting the Aux mc_slow goto working with the Slew to Target. I am also looking to add in the Backlash and PEC controls for the CGEM.

Please know there is nothing radical here, I am just adding functionality to the current celestron_gps driver.

Currently i am compile the celestron_gps_driver on my Mac via command line on using make within the libindi folder from git.

I would like to create a folder that would compile in 3rdparty driver directly on its own, creating the proper xml folders and such.

Is there a template folder that will do this that I can copy and move my current cpp files into?

I have tried to compile a single 3rdparty driver such as the indi-nexstarevo driver in its folder and I get errors -canot find INDI and such. Unfortunately, I have been spoiled with iOS development and the IDE, so make/cmake and such as new to me.

Any ideas? Thank you.

You can use the scheme developed for CI of single drivers. Look at .travis.yml in main dir and build-3rdparty.sh in travis-ci subdir. I am using this scheme for my development of nexstarevo. It is based on my local scripts for single driver compilation. I'll include these scripts in next post. It is definitely possible to have selected drivers compiled in separate subdirs.

Here are my scripts for single driver compile. You need to have in your build directory two build directories and links to following places:

1. src_master --> branch you are using
2. src_<driver-name> --> branch with the driver development. It may be the same branch but not need to be
3. libindi (build directory for the core library)
4. 3rdparty (build directory for the drivers)

The links point to the top of the tree - not to the driver directory. The driver name is the suffix of the driver dir without "indi-" prefix.
Here are the scripts (build_core.sh):
and build_3rd.sh:
I hope it helps.