Get Connected!
Come and join our community. Expand your network and get to know new people!
Book United Flights for Great Getaways
With United Airlines booking, fly affordably & have exclusive experiences. Enjoy comfort, luxury, & budget...
Show more
Book United Flights for Great Getaways
With United Airlines booking, fly affordably & have exclusive experiences. Enjoy comfort, luxury, & budget with reservations on United Airlines.
Steve,
Not sure about the old driver, you can likely compile and install it yourself, but let's see if we can get the V2 driver working for you ... I use it all the time (with my CP3, but I'm sure it was verified to be working with CP4 and CP5).
Can you connect to it with KStars/Ekos? If that shows an issue, can you send a full kstars log of your failed connections (make sure you have verbose logging on and logging for the mount driver checked). The usual issue for things like that it is trying to connect to the wrong port. E.g. if you are using a FTDI cable, you need to make sure you have the right /dev/ttyUSB0 or /dev/ttyUSB1 etc. If you are using ethernet with your CP4, I think there was some network protocol choice. If you don't get it working from that, can you also send screenshots of your INDI mount control tabs (e.g. Main Control and Connection)?
Mike Hanson at Astro-Physics has also verified all this works and can be a resource to help you.
Hy
Read More...
Nope. I spoke too soon. Somehow, in spite of all the changes, /dev/ttyUSB0 still goes away (only /dev/ttyUSB1 remains). Enough. Not going to fight this tonight. Willing to try anything else you might want to recommend another night.
Read More...
I'd like to install an "obsolete" driver. I've had problems connecting to my Astro-Physics GTO CP4 Mach1 with the V2 Astro-Physics mount driver from PHD with INDI but the old GTOCP2 driver, if I recall correctly, used to work for me. Unfortunately that driver is no longer installed when installing INDI. How do I install the old driver?
Read More...
Actually START_DAEMON must be set false from my experiments.
With that, and the chrony stuff, it's all good now.
Read More...
Yes for chrony add these 2 lines.
nano /etc/chrony.conf
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA
drift file /var/lib/chrony/drift
For START_DAEMON, I actually changed it to false to be sure to eliminate all conflicts. But if it works well with true then you might as well leave it like that
Read More...
Hello,
I wonder why there is no version 3.6.9 with indi version 2.0.6 or 2.0.7 on RPi4 with Ubuntu 20.04LTS ?
I tried to compile it from sources. Indi compile without problem but the driver for my qhy camera doesn't want to compile.
First I got that result :
[ 12%] Building CXX object CMakeFiles/indi_qhy_focuser.dir/qhy_focuser.cpp.o
/home/observatoire/Projects/indi-3rdparty/indi-qhy/qhy_focuser.cpp:34:10: fatal error: indijson.hpp: No such file or directory
34 | #include <indijson.hpp>
I fixed it with:
#include "/usr/include/libindi/indijson.hpp"
But that wasn't enough. I got that result:
/home/observatoire/Projects/indi-3rdparty/indi-qhy/qhy_focuser.cpp: In member function \u2018virtual bool QFocuser::updateProperties()\u2019:
/home/observatoire/Projects/indi-3rdparty/indi-qhy/qhy_focuser.cpp:132:24: error: cannot convert \u2018INDI::PropertyNumber\u2019 to \u2018const char*\u2019
132 | deleteProperty(TemperatureNP);
| ^~~~~~~~~~~~~
| |
| INDI::PropertyNumber
Stopped all my investigations.
Have you some suggestions ?
Read More...
Actually, Stephane, we did discuss this a few months ago
here
.
There, you recommendied
START_DAEMON="true"Besides getting rid of port conflicts, there remains the problem of using the GPS to also update the system clock, which this does not do..
In another post on the above thread , you recommended using the chrony application to update the system clock. But it seems that chrony may have changed a bit since then, as the /etc/chrony.conf file no longer mentions refclock. Would you be so kind as to update that recommendation as well? Thank you very much
Read More...
Hey Steve, serial comma is a PITA and this affects a lot of people. I am testing a small utility that will hopefully solve this problem once and for all. This will be a script that will mount your preferred devices under a static port like /dev/myAwesomeMount and we can feed then ekos with that value so that even if the real port will change, the linked one will be always fixed. Stay tuned
Read More...
Did you compile KStars as it is written there:
techbase.kde.org/Projects/Edu/KStars/Building_KStars_KF5
or did you also recompile all INDI-3rdparty?
Because there is no KStars 3.7 on the Raspbian repository yet I also would like to compile it.
Read More...
Ekos mounts the /dev/ttyUSB0 point for the dongle as can be seen in your image for the mount settings. And it will try to send on it the commands which will fail. The mount will be mounted on /dev/ttyUSB1 since the first port is used, but cannot be used by Ekos.
You must then remove the dongle and the USB cable from the mount to dismantle the dev points.
Systemd looks at the gspd file and first mounts the dongle with USBAUTO. With the value false, we prevent this. And START_DAEMON allows you to launch the gpsd service only on request, for example with Ekos.
Read More...
Thank you, Stephane! I remember similar (but not identical) issues with 1.7 and I will try this. However I would like to understand better. I don’t remember this exact file in 1.7 and I don’t understand why /dev/ttyUSB0 exists until Ekos tries to use it, and then /dev/ttyUSB1 comes into existence and lasts until ekos tries to use it, at which point /dev/ttyUSB0 is again available. But thanks again for this quick reply.
Read More...