×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Capture & Solve -> Slew to Target...

  • Posts: 200
  • Thank you received: 57
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.
The following user(s) said Thank You: Stephen
6 years 7 months ago #18661

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
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.
6 years 7 months ago #18665

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
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.
6 years 7 months ago #18666

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
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
6 years 7 months ago #18667

Please Log in or Create an account to join the conversation.

  • Posts: 456
  • Thank you received: 76
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
The following user(s) said Thank You: Stephen
6 years 7 months ago #18670

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
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.
The following user(s) said Thank You: Derek, Stephen
6 years 7 months ago #18671

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
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.
6 years 5 months ago #19907

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
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.
The following user(s) said Thank You: Stephen
6 years 5 months ago #19933

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
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):
#!/bin/bash
 
SRC="`pwd`/../master/"
 
( cd libindi
    cmake -DCMAKE_INSTALL_PREFIX=/usr/local . ${SRC}/libindi
    make
)

and build_3rd.sh:
#!/bin/bash
 
SRC="`pwd`/src_"
drv="gpsd nexstarevo"
 
for d in $drv ; do
( cd 3rdparty
    (
    mkdir -p $d
    cd $d
    if [ -e ${SRC}${d} ]; then
        SRC_DIR=${SRC}${d}
    else
        SRC_DIR=${SRC}master
    fi
    cmake -DCMAKE_INSTALL_PREFIX=/usr/local . ${SRC_DIR}/3rdparty/indi-${d}
    make
    )
)
done
 

I hope it helps.
The following user(s) said Thank You: Stephen
6 years 5 months ago #19934

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
Thank you Jochym. I will update you on how it goes. The Backlash settings may actually be working now, and will share as soon as done.

The nudging concept I have seen a few approaches in code so far:
- using the MC_SLOW Aux Commands
- using the 'r' precise command verse the 'R' used by celestron_gps

In your opinion, is using the MC_SLOW effectively the same as the precise command?

I am considering testing the distance to target and if it is with 1-2' then switching to the precise command. If this is known to already not improve things I will focus more on a pulse/nudge routine - assuming I can get there :)

Cheers!
6 years 5 months ago #19938

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
In my experience the slow approach tends to be more precise and gentle. The Celestron software uses it. But I suspect the accuracy increase is mostly due to the constant approach *direction* consistent with the one used at calibration. For the less precise mount that could be the crucial factor.
The following user(s) said Thank You: Stephen
6 years 5 months ago #19939

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
I see. I will try to add and test the precise slew first when under 2' and see if it can make Slew to Target more repeatable, and report back. It can be a week and a bit before I getting a chance to do this. If I can get below 200px the cropping can be less that it is useful.

Thank you for the help.
6 years 5 months ago #19953

Please Log in or Create an account to join the conversation.

Time to create page: 0.762 seconds