×

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
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.

  • Posts: 333
  • Thank you received: 24
Jasem,

I have some code for the indi_celestron_gps - allows the changing of the backlash settings for the mount. Tested tonight and it works well. It has helped improve the guiding, by tweaking with PHD2.

If this is of interest, please let me know the best way to send the code to you for evaluation/review/or...

I also have some test code for a more precise slew. This is still in testing.

Cheers!
6 years 5 months ago #20123

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

Sure, submit it as PR on Github.
6 years 5 months ago #20128

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

  • Posts: 333
  • Thank you received: 24
I will clean up the Backlash code, and once done I will attempt a Pull Request as soon as I figure it out in GitHub (I am assuming I need to fork or something.)

Moving on to the Nudging precise slewing...

Question: Does anyone have any ideas to determine from the RA/DEC coordinates to determine which N/E/S/W button to press to increase or decrease the RA/DEC position?

Any help, pointers or such would be welcomed.
Last edit: 6 years 5 months ago by Stephen.
6 years 5 months ago #20154

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

  • Posts: 333
  • Thank you received: 24
Jochym,

I have been working on celestron_gps driver for the AUX commands through the serial->USB celestron connection, through the handcontrol:
- backlash settings work
- got an unsync command from Celestron too (not done yet)

Perhaps you can help me out with the MC_SLOW_GOTO command. I can issue the command; however, I am am having trouble interpreting how to manage the MC_SLEW_DONE.

The Symptom is that once the command is issued, the mount continues in the one direction - i.e. I am testing the ALT command first,
e.g. hc_pass_aux_cmd(PortFD, MESSAGE_LENGTH, ALT, MC_GOTO_SLOW, result[0], result[1], result[2], RESPONSE_LENGTH, response )

Once issued the mount does not stop the slow move and just continues. It is clear I do not understand, and would appreciate any pointers.
6 years 4 months ago #21252

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

  • Posts: 456
  • Thank you received: 76
This symptom can happen if you send commands (such as query slew done) to the mount too quickly.
I wrote a mount controller that uses AUX commands through the handset. I wait 1second between 'query slew done' commands.
See line 169 here github.com/dokeeffe/auxremote/blob/maste...nt/MountService.java
Derek.
6 years 4 months ago #21259

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

  • Posts: 200
  • Thank you received: 57
Sure I can help.
Do not issue any AUX movement commands when working with celestron_gps driver. The hand controller does not keep track of your commands and you are messing up its idea of the motor controllers (MC) state. You are basically fighting with HC over the control of MC. This is not going to work. You can set/adjust some of the settings - essentially when HC does not keep the state and reads it every time out of the MC. The SLEW_DONE messages may be captured by the HC or the tracking commands by the HC are messing up your GOTO.
Mixing of the protocols is really risky in my opinion - been there, done that. I think you should be very careful which commands you issue in this mode.
OTOH it can be done - I have implemented GPS emulator inside the nexstarevo driver which provides gps data to the HC.

BTW: This work will be very valuable in the nexstarevo driver. I did not implement the serial connection yet and I can use any help there is ;)
6 years 4 months ago #21260

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

  • Posts: 333
  • Thank you received: 24
Ah, Thank you for confirming. I had actually start using parts of the AuxCommand class in the celestron_gps driver. It was working well but resulted in the same symptom. So I simplified things down, resulting in the same symptom. So I will stop working on the move commands in this way.

I have looked as using the nester-evo driver to add in serial instead of IP. I was stuck at the connection point in the design to say.... do not use IP, use serial connection.

If you can point me to the correct place to make the decision point, I can try to work the serial part in, to test and see if I get it. If I do then I will gladly work it a bit more to see if I can help.

I am assuming sending the AuxCommands through the HC is still valid to add in serial to the nester-evo driver.
Last edit: 6 years 4 months ago by Stephen.
6 years 4 months ago #21309

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

Time to create page: 0.942 seconds