I recently added native Alpaca support to Cartes du Ciel and CCDciel. So you can now use devices connected to a remote Windows computer from the application running on Linux or Mac, and use a mix of INDI and Alpaca devices if you want.
This is interesting for a multi-platform application because this extend what we are accustomed to do with INDI, by using the devices connected on Linux or Mac from any other platform.
Sure at some point this is can be a "concurrent" for INDI but I prefer to see the complementary this protocol offer.
And if the equipment manufacturer start to offer a native Alpaca support for their devices this will be much better for us than the old Windows technology they actually use.
I make some testing today but I cannot find a sure way to reproduce the problem.
After many connection, disconnection, reboot I only get the issue one time. This is strange because at the telescope I get it every time if I connect in the wrong order. Maybe the powered usb hub make a difference in the power sequence? I will try later.
In this case the wheel position show 129, and if you try to set a new position it never finish. You ear the motor to turn a bit, stop, turn again and never finish.
A sure way to get position=129 is to connect the driver before the efw2 as completed it's rotation after power on. But in this case it work when you send a new valid position.
BTW, thank you Jasem for the x86 libatik, it work fine.
It is interesting if we can trace this problem but I not see anything hardcoded in the driver.
The max position is returned by ArtemisEFWNmrPosition() and the current position (the 128+1) by ArtemisEFWGetPosition(), so the problem is in the Atik library or the efw itself.
Maybe adding some debug print may help to understand the problem.
Sometime I also get this error with position 129, it was always present, also with the previous version of the driver.
For me this occur when the wheel is powered before the computer. This may cause some initialization problem.
A simple solution I use in this case is to stop the Indi server, remove the power from the EFW2 but not the usb, plug the power again, wait it finish to turn before to restart Indi server. After that I can use the 7 filters without problem.
CDC and CCDciel do not use a static list of driver, drivers.xml or other, but instead they connect to a already running indiserver to retrieve the list of devices currently loaded and use this DRIVER_INTERFACE property to know the capability of the driver. Then the selection box for each device type is filled with only the matching devices.
azwing wrote: I simply wonder why it was recognized by KStars and not by CDC.
I don't know why it worked in Ekos without that, maybe Ekos directly watch some other properties like FOCUS_ABSOLUTE_POSITION ?
I agree the new theme is very good.
But there is still a problem with the Standard Properties page, half of the text in unreadable because of white text on light blue background:
Good you can restore the previous version.
I tested my 314 with the current git version on a Rpi2 and it work without problem. So it is just a matter to update the ppa with this version.
Sorry, this log is for Xenial, need to be checked too.
For Bionic the last build is from December 4 and not updated since.
Maybe you need to build this driver from source to continue testing.
I use a 314 without problem with the last version of the driver.
But if you use indi-atik 2.0~201811230011~ubuntu18.04.1 armhf this not include the API 110 added on December 12, and not the mutex added on November 26.
I remark now the last build on the nightly ppa have failed , probably libatik was not build before the drivers:
[ 25%] Building CXX object CMakeFiles/indi_atik_ccd.dir/atik_ccd.cpp.o /usr/bin/g++ -I"/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf" -I"/<<PKGBUILDDIR>>/indi-atik" -I/usr/include/libindi -I/usr/include/libatik -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -O1 -Wa,--noexecstack -Wall -Wextra -Wno-unused-but-set-variable -g -o CMakeFiles/indi_atik_ccd.dir/atik_ccd.cpp.o -c "/<<PKGBUILDDIR>>/indi-atik/atik_ccd.cpp" /<<PKGBUILDDIR>>/indi-atik/atik_ccd.cpp: In member function ‘virtual void ATIKCCD::debugTriggered(bool)’: /<<PKGBUILDDIR>>/indi-atik/atik_ccd.cpp:1240:75: error: ‘ArtemisSetDebugCallbackContext’ was not declared in this scope ArtemisSetDebugCallbackContext(this, &ATIKCCD::debugCallbackHelper); ^ /<<PKGBUILDDIR>>/indi-atik/atik_ccd.cpp:1242:56: error: ‘ArtemisSetDebugCallbackContext’ was not declared in this scope ArtemisSetDebugCallbackContext(nullptr, nullptr); ^ CMakeFiles/indi_atik_ccd.dir/build.make:65: recipe for target 'CMakeFiles/indi_atik_ccd.dir/atik_ccd.cpp.o' failed
This is the date the Indi source code was modified, I have no idea about Kstars release for the Mac.
Maybe it can be good that Indi can be updated independently of Kstars also on the Mac.
I don't know of a batch editor for the fits header, generally I only need to read them. Using a generic batch editor like sed is probably too dangerous for the file integrity.