Paweł replied to the topic 'GPSD altitude' in the forum. 1 hour 6 minutes ago

It was probably originally missed by me due to the fact that I am east of the 0 meridian ...
But the altitude should be exactly the same - are you sure you have a 3D fix?
The screenshot shows it was 240s since last fix. Are you testing indoors?

Read More...

Paweł replied to the topic 'indi-nexstarevo issues and questions' in the forum. 2 hours 53 minutes ago

One more thing - The celestron-nexstar driver will not work with the usb-aux cable. I hope you do not mean usb-serial cable. The AUX socket is different and *must not* be connected to regular serial line (actually it is serial with different voltages and wiring). I hope you did not fry your mount!
Furthermore, this is completely different protocol. For the celestron-nexstar driver you need a correct usb-serial adaptor with small RJ plug at the end.
You can connect it to the base of the hand-controller and use it that way. It is quite straightforward and should work if you get permissions right.
The nexstarevo driver uses low-level AUX protocol which is present in the WiFi transmission and in AUX sockets on the mount.

Read More...

Paweł replied to the topic 'indi-nexstarevo issues and questions' in the forum. 3 hours 3 minutes ago

@tmdag - I am glad you are trying to make my driver work.
First - it is not going to work via the cable (yet). The other ways of communication are not implemented but planned. Unfortunately the AUX protocol is a bit tricky.
So wifi-only for now.
Regarding the connection: what is the sequence of blinking of your mount wifi-light. It should be fast (not connected, waiting for client) - slow (Client assigned IP, no connection yet) - constant (Client connected).
If wifi light is constant please run the driver with debugging (you can also run indiserver with extra -v to get even more debugging) and upload the log. We will se what is wrong. If you are running on linux and have python3.6 available you can also run it against the simulator from the source directory to eliminate problems with your network/ap/etc.
Also check if you have alignment system active - sometimes this could be a problem. Make also sure that you have your position correctly entered. Evo is an alt-az mount and really needs to know your position.

Read More...

Paweł replied to the topic 'Capture & Solve -> Slew to Target...' in the forum. 2 months ago

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.

Read More...

Paweł thanked norikyu in topic SkySafari middleware? 2 months ago
Paweł replied to the topic 'Image Autoguiding' in the forum. 2 months ago

Not much - since I got swamped by work and other duties - but it is not abandoned at all. Thanks for the ping.
Unfortunately the FFT libraries are much more convoluted in their API then I thought - using them from the higher-level languages. There is a substantial amount of code to write to prepare the data before transformation if we want to keep it portable. Jasem has written small bits in ekos to interface with it if I remember correctly but I got stuck on joining them together. I was hoping to return to my indi projects in autumn. Not yet :(.

Read More...

Paweł replied to the topic 'Capture & Solve -> Slew to Target...' in the forum. 2 months ago

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.

Read More...

Paweł replied to the topic 'Capture & Solve -> Slew to Target...' in the forum. 2 months ago

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.

Read More...

Paweł replied to the topic 'Capture & Solve -> Slew to Target...' in the forum. 3 months ago

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.

Read More...

Paweł replied to the topic 'Re:Capture & Solve -> Slew to Target...' in the forum. 3 months ago

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.

Read More...

Paweł replied to the topic 'Re:Capture & Solve -> Slew to Target...' in the forum. 3 months ago

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.

Read More...

Paweł replied to the topic 'Re:Capture & Solve -> Slew to Target...' in the forum. 3 months ago

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.

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!