Describe the bug
I have QHY600M camera, this camera has a readout modes 0 / 1 / 2 and 3. INDI driver default start with read mode 0 and it is working good. When I try to change read mode to 1 or other then camera stop working (I can not take an image). In INDI logs I found only one feed back information: "QHY CCD QHY600M-a7ca3c4: No response from camera!"
Camera back to normal when I restart INDI driver "indi_qhy_ccd", then it is perfect working on mode 0. Probably is something wrong with INDI camera read mode settings, because when I back from mode 1 to 0 and I tried to get image I always received information: "QHY CCD QHY600M-a7ca3c4: No response from camera!" - only driver restart solve the problem.

To Reproduce

1. Run driver: indi_qhy_ccd
2. Change camera 'read mode' from 0 to 1/2 or 3
3. Try to get a frame

Expected behavior
Only one information which I got is: "QHY CCD QHY600M-a7ca3c4: No response from camera!" and red marker beside camera expose in INDI panel.

Desktop (please complete the following information):

• OS: Gentoo Linux (kernel: 5.8.0)
• Version: Local INDI Library: 1.8.6, Code 1.8.6-tgz. Protocol 1.7. (GIT-version from 2020/07/08)

Log Files
"QHY CCD QHY600M-a7ca3c4: No response from camera!"

Hi all,
I want to know if the SQM reading done by indiduinometeoSQM has been calibrated against an official SQM device.

In the code is reported the formula for the SQM read in mag/arcsec2
mag_arcsec2 = log10(lux/108000)/-0.4;
Where this info came from???

I build my indiduinometeoSQM, but SQM values are much different from a Unihedron SQM that use a TSL237 sensor

In isWetRain function, it checks for rainConditions switch, but I don't see this switch getting defined anywhere? Right now it crashes, I added a condition to check if the pointer is null or not, but the property needs to be defined somewhere.

@pardo-bsso Do you know what the issue is?

Describe the bug
The Atik INDI driver does not detect the CMOS "Horizon II" camera. The default "No Atik cameras detected. Power on?" pop-up appears twice with KStars/Ekos, and the driver is not started in the INDI panel. The unexpected behavior is consistent from the command line.

To Reproduce
Exact steps to reproduce the behavior.

1. Connect the Atik Horizon 2 to the Linux computer, in a valid USB2 port.
2. Run indi_atik_ccd: indiserver -l /home/tallfurryman/dev/tmp -p 7626 -vvv indi_atik_ccd.
3. Message appears in log: No Atik cameras detected. Power on?

Expected behavior
Atik Horizon 2 is detected and can be used by INDI clients. This same test is able to detect and operate an Atik 314E without issues.

Screenshots
Output of dmesg relevant for the port the camera is plugged in, showing EHCI:

Output of dmesg when connecting the camera:

Output of lsusb when the camera is connected (Atik Horizon 2 on USB2 port 1, ZWO EFW and Arduino on USB1.1 ports 3 and 4:

Desktop (please complete the following information):

• OS: Lubuntu 18.04 i386
• Version INDI 3rd-party 7c25c27
• Atik library in /usr/local/lib/libatikcameras.so.2.2.6

Log Files
The only content of the log generated by the test above is the following:

2020-04-26T12:51:42: : No Atik cameras detected. Power on?

The command line shows several additional lines:

After the INDI Core and INDI 3rd party split, the Circle CI build scripts need to be revised to work. I revised them, but I'm not sure how to make the indi-3rdparty builds run against the latest libindi ?

@jochym
@eric-vickery

My Atik 460 does not connect to indiserver on Unbuntu 19.xx, but on Raspi Buster and on Artemis,Win7
Lodestar and QHY5 are working erverywhere.

:~$ indiserver indi_atik_ccd
2020-02-07T08:45:56: startup: indiserver indi_atik_ccd
Child process 17635 died
2020-02-07T08:45:57: Driver indi_atik_ccd: stderr EOF

2020-02-07T08:45:57: Driver indi_atik_ccd: restart #1
Child process 17651 died
...
020-02-07T08:46:07: Driver indi_atik_ccd: restart #10
Child process 17797 died

2020-02-07T08:46:08: Driver indi_atik_ccd: Terminated after #10 restarts.
2020-02-07T08:46:08: good bye

OS:
Ubuntu 19.10
fresh install off indi-full from ppa 2020-02-07:12:04:73

Describe the bug
When compiling indi-3rdparty the webcam component does not get configured by cmake and thus does not get compiled. The compilation is done as advised in the README, starting with
cmake /path/to/source
The output then implies indi-webcam would be built:
-- Since FFMPEG was found, INDI Webcam Driver can be built
However, the indi-webcam directory in the build folder is not created and cmake -L confirms that something is not as expected:
WITH_WEBCAM:BOOL=OFF

I'm surprised though, that I seem to be the first person having this problem, so I expect I'm doing something wrong...

I'm not all that familiar with the internals of cmake, so this might not be a "good" solution, but a small change to the main CMakeLists.txt produces the expected result:
changing option(WITH_WEBCAM "Install INDI Webcam Driver based on FFMPEG" On)
to set(WITH_WEBCAM On CACHE BOOL "Install INDI Webcam Driver based on FFMPEG" FORCE)
I have attached a patch applying this change, however I don't know if this has any unwanted side effects.
patch.txt

To Reproduce

1. Have FFMPEG properly set up, such that it is found by cmake
2. From an empty directory, call cmake /path/to/src/
3. Check that FFMPEG was found and whether the indi-webcam folder is created

Expected behavior
If FFMPEG is available an indi-webcam folder should be created in the build folder.

Desktop

• OS: Manjaro and Raspbian
• Git master
• cmake 3.17.3 (Manjaro, can't check for Raspian right now)

INDI Starbook driver does not currently support guiding as reported in the INDI forum thread PHD2 can't manage to connect the mount

Is it possible to add this feature to the driver @not7cd ?

I have compiled the driver for pentax. I have a K3II, and I cannot change the exposure time.
Each photo is taken with an exposure time of 1/17 even if I put 1 minute or 30 seconds.
With the indi_pentax_ccd driver I have the same problem.

Compiling indi-gphoto with libraw-0.20 throws an error because the data structures have changed:

.../indi-3rdparty/indi-gphoto/gphoto_driver.cpp:870:39: error: 'struct libraw_imgother_t' has no member named 'SensorTemperature'
  870 |             if (lib_raw.imgdata.other.SensorTemperature > -273.15f)
      |                                       ^~~~~~~~~~~~~~~~~
.../indi-3rdparty/indi-gphoto/gphoto_driver.cpp:871:66: error: 'struct libraw_imgother_t' has no member named 'SensorTemperature'
  871 |                 gphoto->last_sensor_temp = lib_raw.imgdata.other.SensorTemperature;
      |                                                                  ^~~~~~~~~~~~~~~~~
.../indi-3rdparty/indi-gphoto/gphoto_driver.cpp:872:44: error: 'struct libraw_imgother_t' has no member named 'CameraTemperature'
  872 |             else if (lib_raw.imgdata.other.CameraTemperature > -273.15f)
      |                                            ^~~~~~~~~~~~~~~~~
.../indi-3rdparty/indi-gphoto/gphoto_driver.cpp:873:66: error: 'struct libraw_imgother_t' has no member named 'CameraTemperature'
  873 |                 gphoto->last_sensor_temp = lib_raw.imgdata.other.CameraTemperature;

By changing lib_raw.imgdata.other.SensorTemperature to lib_raw.imgdata.makernotes.common.SensorTemperature it compiles again, but I still have to test if everything works. If you want I could open a pull request with the changes.

Describe the bug
When building all the 3rd party libraries and drivers using primary instructions, cmake fails on Raspberry Pi due to the addition of indi-sv305 package.

CMake Error at libsv305/CMakeLists.txt:40 (message):
Your architecture isn't suppored

To Reproduce
mkdir -p ~/Projects
cd ~/Projects
git clone --depth=1 https://github.com/indilib/indi-3rdparty
mkdir -p ~/Projects/build/indi-3rdparty-libs
cd ~/Projects/build/indi-3rdparty-libs
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DBUILD_LIBS=1 ~/Projects/indi-3rdparty

Temporary workaround for Raspberry Pi:

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DBUILD_LIBS=1 -DWITH_SV305:OPTION=OFF ~/Projects/indi-3rdparty

and

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DWITH_SV305:OPTION=OFF ~/Projects/indi-3rdparty

Regards...

I was not able to build indi-3rdparty on commit:

c18244d

Build error:

CMake Error at libricohcamerasdk/CMakeLists.txt:26 (message):
  Unsupported architecture: aarch64

Thank you in advance for your help

Describe the bug

When building, the following warning appears while configuring the build tree:

CMake Warning (dev) at indi-mgen/CMakeLists.txt:40 (add_executable):
  Policy CMP0003 should be set before this line.  Add code such as

    if(COMMAND cmake_policy)
      cmake_policy(SET CMP0003 NEW)
    endif(COMMAND cmake_policy)

  as early as possible but after the most recent call to
  cmake_minimum_required or cmake_policy(VERSION).  This warning appears
  because target "indi_mgenautoguider" links to some libraries for which the
  linker must search:

    pthread

  and other libraries with known full path:

    /usr/local/lib/libindidriver.so

  CMake is adding directories in the second list to the linker search path in
  case they are needed to find libraries from the first list (for backwards
  compatibility with CMake 2.4).  Set policy CMP0003 to OLD or NEW to enable
  or disable this behavior explicitly.  Run "cmake --help-policy CMP0003" for
  more information.
This warning is for project developers.  Use -Wno-dev to suppress it.

To Reproduce

1. Clone 3rd-party source tree
2. Configure the build with WITH_MGEN=ON (it is enabled by default)
3. Run the cmake configuration

Expected behavior
No warning should appear, CMakeLists.txt should be clean for indi_mgenautoguider.

Screenshots
n/a

Desktop (please complete the following information):

• OS: Ubuntu 18.04 i386
• Version: head

Log Files
n/a

Jeff Donaldson raised a few issues regarding the camera on Sourceforge and on INDI Forum

@dirkenstein Can you please take a look at these issues?

Problem: As a user of a non-debian based system, I would like to easily manage and update installs of indi-3rd party drivers on my systems. My distribution does not provide an option for nightly builds, and this is a desirable outcome.

Outcome: I would like for the community to have a way to enjoy nightly builds and debugging on distributions other than debian based. My own person usage is for Fedora, but this should also encompass RHEL, CentOS, and SUSE if possible

Alternatives: I have spent a great deal of time looking at build engines, packaging methods, including AppImage, considering copying what Christian had done before me, and have settled on the Fedora Copr system

It would be desirable to simply be able to add the indi-3rdparty-bleeding repo and use system based tools such as yum, dnf, rpm, etc to do package management of installed versions.

I am connecting my SX-56 ccd to ekos/kstars. I run an exposure and it times out. Camera is connected, cooler is on, shutter opens and closes, ekos counts down, clock stops at 0 and stalls. No error codes pop up on indi and it is stalled for a couple minutes before it tries attempt number 2. However, in the platesolving module the ccd will expose and the mount will slew. It is just not working in the capture module. I have connected dozens of other cables, even wiped my entire computer to start from new. In the platesolver it is only connected to the SX-56 as that is the only camera I have on the mount right now. I am running the latest Kstars on a mac book pro with catalina.

I did just realize that the camera is working in the solver because it si binned at 2x. the camera will not work when it is not binned. Please help!

P.S. I am not a coder. I am just a normal dude looking to use his camera. thanks!

Resolving #173 helped compiling the indi_gphoto driver, but there seem to be some issues left.

While taking pictures worked last night without any issues, the fitsheader in the images now states
BAYERPAT= 'GBRG ' / Bayer color pattern as opposed to BAYERPAT= 'RGGB ' / Bayer color pattern with libraw-0.19 (which as far as I know is correct).

I expect that is also due to changes in the libraw data structure and probably all metadata from the image should be checked.
I'll try to find the cause and also check the rest of the data and update this issue accordingly.

I cannot make an exposure with Sony NEX-3N using Sony-dslr driver.
Got every time the same error: [ERROR] Error starting exposure

I tried using gphoto CCD driver and I got the same behavior.

I'm on Osx Mojave with latest Kstars release 3.3.4 (idem with 3.3.6) and its embedded INDI Library.
Tested using local INDI server.

I tested using a remote INDI server on RPI in order to test latest Nightly INDI Library and got exactly the same issue.

It worth mentioning that my Nex-3N is in bulb mode (Writed on its LCD screen).

Please find attached log file.
log_16-51-22.txt

Also tried to use gphoto directly:
gphoto2 --debug --debug-logfile=gphoto.txt --capture-image-and-download
with log file here:
gphoto2.txt

I also posted the issue to gphoto/ligphoto2 GitHub:
gphoto/libgphoto2#439

Regards,

Christian.

I am not sure whether this is a general issue or depends on my configuration. I am using a ublox7-usb module with indi_gpsd. When I enable the automatic refresh (1s, 5s, or even manually), for every refresh, the time only increases by only one second. To my understanding, this is because the gpsd delivers a continuous stream and buffers this stream. When the buffer is then read with gps->read() only the next (but not the most recent report gets read. Therefore, I suggest the following change (works for me flewlessly):

Wrap the gps->read() in w a while loop which makes sure that the queue is empty:

while (1)
{
    if ((gpsData = gps->read()) == nullptr)
    {
        LOG_ERROR("GPSD read error.");
        IDSetText(&GPSstatusTP, nullptr);
        return IPS_ALERT;
    }

    if (!gps->waiting(0))
        break;
}

Description
Module
indi_gphoto

Scenario
Using a Canon 400D with no dedicated bulb widget/over USB bulb shutter control relies on camera set to 'Bulb' exposure manually on-camera and a shutter release cable.
Before the change df46e97 on 2020-03-23 all exposures when 'Force Bulb' is switched ON resulted in all exposures taken via the shutter release commands, whether the camera supports them or not.

Since updating now the module reverts to finding the best matching on-camera exposure setting and using that as the exposure setting, ignoring 'Force Bulb ON' in cases under the RELEASE_SHUTTER_THRESHOLD of 30 seconds.

When taking an exposure below 30 seconds the camera behaves well and expected, but changing to an exposure >30s the camera never reverts to 'Bulb' exposure mode on-camera and remains at the last set exposure time <30s that was taken. This is only solved by manually setting the camera by hand back into Bulb exposure time using the physical exposure wheel/dial.

However the camera remains locked in an exposure the entire length of the requested bulb shutter time, and the shutter release remains active even after the camera stops the exposure and the physical shutter is heard closing. The final file is then returned as an x length exposure but is in reality an exposure of length y where y is the last set <30s exposure value that was last taken and corresponds to the on-camera exposure setting that is displayed on the camera display.

To Reproduce

1. Ensure the DSLR is in Manual Mode, with Bulb exposure length set on-camera
2. Take an exposure of length x above 30s using indi_gphoto through Ekos
3. Receive image as expected of length x
4. Take and exposure of length y below 30s
5. Receive image as expected of length y
6. Set exposure of length x above 30s again
7. Camera stops exposing after time y, but remains locked in an exposure of length x and returns an image with all associated meta data/header data as if it is of length x but the actual image is consistent with one of length y in terms of noise/data.
8. Check on-camera display and it remains set to length y exposure length
9. Set camera back to 'Bulb' exposure length manually
10. Process repeats

Expected behavior
In scenarios where an exposure above 30s is taken, the camera should be returned to Bulb exposure length/mode even if it has been set below 30s by a previous exposure.

However the Canon 400D only reports back to the exposure widget that it is capable of up to 30s exposures and never lists a Bulb mode as is present in the fallbackShutterSpeeds[] array, so this mode is never chosen again once it leaves it for another supported exposure length and there seems to be no way of putting the 400D back into Bulb exposure length once it has been switched out of it. The only way of restoring >30s Bulb exposure behaviour is to manually reset the camera to Bulb mode through the physical camera controls.

Suggested Fix
Modify the change made to Bulb shutter mode in commit df46e97 on 2020-03-23 and ensure 'Force Bulb' remains strict and only uses the shutter release method of exposure length control rather than falling back to on-camera exposure length below 30s to ensure cameras like the 400D without Bulb shutter support (without a shutter release) can remain forever in the manually set Bulb mode on-camera without manual intervention, regardless of requested exposure times <30s.

Changing line 1071 of gphoto_driver.cpp from OR to AND ensures that 'Force Bulb' remains strictly enabled regardless of whether the camera supports the requested sub 30s exposure length
FROM
if (gphoto->force_bulb == false || ((gphoto->bulb_port[0] || gphoto->dsusb) && exptime_usec <= RELEASE_SHUTTER_THRESHOLD))

TO
if (gphoto->force_bulb == false && ((gphoto->bulb_port[0] || gphoto->dsusb) && exptime_usec <= RELEASE_SHUTTER_THRESHOLD))

This change will make 'Force Bulb' setting consistent over all exposure lengths and never fall back to on-camera exposure length settings, essentially nullifying the expected behaviour of 'Force Bulb' as a setting.

This change has been compiled and tested on a range of exposure times from 1/4000 (0.00025s) to 300s on the Canon 400D only and returns behaviour to as it was before the commit which caused these issues. Changing exposure times below and above the 30s threshold does not change behavious and Bulb Mode remains consistent and active on-camera.

Desktop

• OS: Raspbian 10 Buster
• Version: indilib-3rdparty v1.8.5
• Build: 2020-04-13T21:01:23Z
• Environment: KStars and Ekos

Log Files
With the described behaviour returning exposures without reverting to bulb mode.
Note it can be seen when the exposure widget is queried for exposure times no 'BULB' length is returning in index 0.
log_15-31-03.zip

With the single || to && change as described which produces expsosures of length 0.00025 - 300 seconds tested
log_17-37-10.zip

ldconfig: file /usr/lib/arm-linux-gnueabihf/libsbig.so.4 is truncated
ldconfig: file /usr/lib/arm-linux-gnueabihf/libsbig.so is truncated
ldconfig: file /usr/lib/arm-linux-gnueabihf/libsbig.so.4.9.9 is truncated

Here is the build error:

[ 84%] Building CXX object indi-gpsd/CMakeFiles/indi_gpsd.dir/gps_driver.cpp.o
/home/mobarre/AUR/libindi_3rdparty/src/indi-3rdparty-1.8.5/indi-gpsd/gps_driver.cpp: In member function ‘virtual IPState GPSD::updateGPS()’:
/home/mobarre/AUR/libindi_3rdparty/src/indi-3rdparty-1.8.5/indi-gpsd/gps_driver.cpp:252:18: error: ‘struct gps_data_t’ has no member named ‘status’
  252 |     if (gpsData->status == STATUS_NO_FIX)
      |                  ^~~~~~
make[2]: *** [indi-gpsd/CMakeFiles/indi_gpsd.dir/build.make:82: indi-gpsd/CMakeFiles/indi_gpsd.dir/gps_driver.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2131: indi-gpsd/CMakeFiles/indi_gpsd.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
``
The following comment has been left in gps.h:
      Move gps_data_t->status to gps_fix_t.status for better fix merging
       Add wspeedt, wspeedr, wanglem, wanglet, wangler to  gps_fix_t
       Remove unused gps_data_t.navadata_t.
       Add relPosL and relPosH to gps_fix_t.NED

Looking at their gitlab repo, it seems to have happened with release 3.21 of gpsd

Cheers !

Describe the bug
I tried to connect kstars indi client to a remote server that hosts aag_cloudwatcher_ng.
It works perfectly until I try to click "connect"
It looks like the corresponding driver is just "unloaded". All related windows/buttons disappear completely from the client.

To Reproduce
Run server with driver:
INDISKEL=/home/rock/projects/RemoteObservatory/conf_files/indi_driver_conf/indi_aagcloudwatcher_ng_sk.xml indiserver -vvv /usr/local/bin/indi_aagcloudwatcher_ng
Then connect with indi client through kstars. Click the connect button.
Here is the skeleton (rename fro .txt to .xml):

indi_aagcloudwatcher_ng_sk.txt

Expected behavior
I managed to connect to the aag_cloudwatcher with the regular driver (non -ng), so I would expect the ng to connect properly.

Desktop (please complete the following information):
Linux localhost.localdomain 4.4.180 #1 SMP Fri May 31 17:07:08 EDT 2019 aarch64 GNU/Linux
Distributor ID: Debian
Description: Debian GNU/Linux 9.9 (stretch)
Release: 9.9
Codename: stretch

Code version:
commit cab70bf
Date: Fri Feb 7 17:25:41 2020 +0300

Log Files
log.txt

ISSUE: MGEN3 is not recognized by the driver.

SOLUTION: MGEN3 shall be recognized by the driver.It will be okay, if not all features will run from the beginning,

minimum needed features.

• MGEN3 shall be recognized and connected
• search stars
• start guiding
• stop guiding

Alternative workflow:
Using USB IP Bridge to remote controll with Lacerta VirtualUI will work but is not processable in automation from the stratch.

Support from my side
Testing, log protocolls, poor reverse engineering, using my MGEN3

indi_gpsd has a nice feature that is to provide the system time rather than the GPS time. This allows to use an identical configuration, although the GPS device is not available. It would be even nicer, if in case the device can not connect, a simulation mode could be enables in which the system time and a user supplied position is distributed.

make fails for indi-3rdparty if no FFMPEG libraries are installed. Here is the matching output of cmake:

CMake Error at cmake_modules/FindFFmpeg.cmake:23 (file):
  file failed to open for reading (No such file or directory):

    /usr/include/x86_64-linux-gnu/libavdevice/version.h
Call Stack (most recent call first):
  cmake_modules/FindFFmpeg.cmake:100 (_FFMPEG_PACKAGE_check_version)
  CMakeLists.txt:107 (find_package)


CMake Error at cmake_modules/FindFFmpeg.cmake:23 (file):
  file failed to open for reading (No such file or directory):

    /usr/include/x86_64-linux-gnu/libavformat/version.h
Call Stack (most recent call first):
  cmake_modules/FindFFmpeg.cmake:117 (_FFMPEG_PACKAGE_check_version)
  CMakeLists.txt:107 (find_package)


CMake Error at cmake_modules/FindFFmpeg.cmake:23 (file):
  file failed to open for reading (No such file or directory):

    /usr/include/x86_64-linux-gnu/libavutil/version.h
Call Stack (most recent call first):
  cmake_modules/FindFFmpeg.cmake:134 (_FFMPEG_PACKAGE_check_version)
  CMakeLists.txt:107 (find_package)


CMake Error at cmake_modules/FindFFmpeg.cmake:23 (file):
  file failed to open for reading (No such file or directory):

    /usr/include/x86_64-linux-gnu/libswscale/version.h
Call Stack (most recent call first):
  cmake_modules/FindFFmpeg.cmake:151 (_FFMPEG_PACKAGE_check_version)
  CMakeLists.txt:107 (find_package)


-- Found FFMPEG: /usr/lib/x86_64-linux-gnu/libavcodec.so;/usr/lib/x86_64-linux-gnu/libavdevice.so;/usr/lib/x86_64-linux-gnu/libavformat.so;/usr/lib/x86_64-linux-gnu/libavutil.so;/usr/lib/x86_64-linux-gnu/libswscale.so, /usr/include/x86_64-linux-gnu
-- Since FFMPEG was found, INDI Webcam Driver can be built

And later on

-- Configuring incomplete, errors occurred!

As soon as I install libavcodec-dev and libavdevice-dev, the build succeeds.

@sWski In Ekos/Capture module, the cooler On/Off buttons are greyed out when using my MI G2-8300FW (anyway, I can set the desired temperature in the capture module or indi panel, and by doing this the cooler actually does its job).

But the on/off capability is interesting when using Ekos scheduler, so when jobs end, it can automatically warm up the ccd (I used to manually set the ambient temperature value to force this when I wake up, now I'm using indi_setprop for this, invoked as shutdown script).

I tried to track down this and it seems that the libgxccd library doesn't implement this on/off control (I may be wrong, though). Could this be done? If this is the case, then it seems that indi-mi should implement the property CCD_COOLER for the Ekos On/Off buttons to enable.

Thanks in advance. I understand this is secondary, just wanted to note that it would improve the experience using MI cameras with the Ekos scheduler.

Describe the bug

I have Sony Alpha A5000 (ILCE-5000).

Only about every 3rd exposure done by Ekos using indi_sony_ccd driver actually moves the shutter and captures new data. Other exposures don't cause the shutter to open or close, and stale data is downloaded as preview (from the successful exposure).

I have investigated this issue and provide a hack/patch that works for me.

Additional keywords: freeze, frozen, stuck,

To Reproduce

Reproduce it using Kstars+Ekos.

In profile editor, add Sony DSLR device. I have Sony Alpha a5000 (ILCE-5000) connected via USB in PC direct mode.
Run the profile.

1. Go to CCD tab.
2. Grab preview exposure. Preview should appear.
3. Move the camera so that it points to a different object (to compare previews).
4. Grab preview exposure. You will notice there's no shutter sound, and the preview is the same as in step 2.
5. Repeat steps 3-4 until a "fresh, real" preview appears (around 3 times).

Note, that no error is reported here.

This may or may not be relevant, but I also disabled LENR via telnet like so: ma1co/OpenMemories-Tweak#205 This requires installing OpenMemories Tweak app on the camera itself. I initially suspected it to be the problem, but even though this hack works (LENR is disabled), it didn't solve this issue. I'm not sure if it is required for my patch to work.

During the investigationI ran some gphoto2 commands to try to replicate the issue manually:

astroberry@astroberry:~/codez/indi-3rdparty/indi-gphoto/build $ gphoto2 -v --set-config bulb=1
gphoto2 2.5.23

Copyright (c) 2000-2019 Marcus Meissner and others

gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of gphoto2 under the terms of the GNU General Public
License. For more information about these matters, see the files named COPYING.

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.23         gcc, popt(m), exif, no cdk, no aa, no jpeg, no readline
libgphoto2      2.5.24.1       standard camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, EXIF, USB, serial without locking








astroberry@astroberry:~/codez/indi-3rdparty/indi-gphoto/build $ gphoto2 -v --set-config bulb=0 --wait-event-and-download=5s --force-overwrite
gphoto2 2.5.23

Copyright (c) 2000-2019 Marcus Meissner and others

gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of gphoto2 under the terms of the GNU General Public
License. For more information about these matters, see the files named COPYING.

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.23         gcc, popt(m), exif, no cdk, no aa, no jpeg, no readline
libgphoto2      2.5.24.1       standard camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, EXIF, USB, serial without locking
Waiting for 5 seconds for events from camera. Press Ctrl-C to abort.           
UNKNOWN PTP Property 5004 changed
UNKNOWN PTP Property 5004 changed
UNKNOWN PTP Event c201, Param1 ffffc001
Saving file as capt0000.arw                                                    
Saving file as capt0001.arw                                                    

You may notice, that even though I grab only one image, two files are downloaded (capt0000.arw and capt0001.arw). Sometimes it is1 file, sometimes 3, depending on the sequence of actions before. I can also run another pair of commands like above (bulb=1/bulb=0) immediately after without it getting stuck. This made me suspect that the issue is not withing libgphoto2, but with the indi driver. I thought that maybe the indi driver doesn't handle the situation where there are multiple files to be downloaded.

I have no idea why multiple files are generated to begin with. If someone could enlighten me, I'd appreciate it.

Expected behavior

Each preview should match the exposure. Each exposure should actually open/close the shutter and grab new data.

The following patch fixes the issue.

diff --git a/indi-gphoto/gphoto_driver.cpp b/indi-gphoto/gphoto_driver.cpp
index 9823d77..81a73f3 100644
--- a/indi-gphoto/gphoto_driver.cpp
+++ b/indi-gphoto/gphoto_driver.cpp
@@ -1358,7 +1358,9 @@ int gphoto_read_exposure_fd(gphoto_driver *gphoto, int fd)
         {
             case GP_EVENT_CAPTURE_COMPLETE:
                 DEBUGDEVICE(device, INDI::Logger::DBG_DEBUG, "Capture event completed.");
-                break;
+               pthread_mutex_unlock(&gphoto->mutex);
+               return GP_OK;
+                // break;
             case GP_EVENT_FILE_ADDED:
                 DEBUGDEVICE(device, INDI::Logger::DBG_DEBUG, "File added event completed.");
                 fn     = static_cast<CameraFilePath *>(data);
@@ -1368,8 +1370,8 @@ int gphoto_read_exposure_fd(gphoto_driver *gphoto, int fd)
                 // JM 2018-08-06: Why do we really need to reset values here?
                 //reset_settings(gphoto);
 
-                pthread_mutex_unlock(&gphoto->mutex);
-                return result;
+                //pthread_mutex_unlock(&gphoto->mutex);
+                //return result;
             case GP_EVENT_UNKNOWN:
                 //DEBUGDEVICE(device, INDI::Logger::DBG_DEBUG, "Unknown event.");
                 break;
@@ -1380,6 +1382,7 @@ int gphoto_read_exposure_fd(gphoto_driver *gphoto, int fd)
                 {
                     pthread_mutex_unlock(&gphoto->mutex);
                     return -1;
+               //      return GP_OK;
                 }
                 break;

Desktop (please complete the following information):

• OS: Linux astroberry 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux
• Version

$ gphoto2 -v
gphoto2 2.5.23

Copyright (c) 2000-2019 Marcus Meissner and others

gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of gphoto2 under the terms of the GNU General Public
License. For more information about these matters, see the files named COPYING.

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.23         gcc, popt(m), exif, no cdk, no aa, no jpeg, no readline
libgphoto2      2.5.24.1       standard camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, EXIF, USB, serial without locking

$ apt list --installed | grep indi

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

indi-aagcloudwatcher-ng/unknown,now 1.5-2 armhf [installed,automatic]
indi-aagcloudwatcher/unknown,now 1.4-3 armhf [installed,automatic]
indi-aok/unknown,now 1.0 armhf [installed,automatic]
indi-apogee/unknown,now 1.9-3 armhf [installed,automatic]
indi-armadillo-platypus/unknown,now 1.0-3 armhf [installed,automatic]
indi-asi/unknown,now 1.7 armhf [installed]
indi-astroberry-amh/unknown,now 0.3-1 armhf [installed,automatic]
indi-astroberry-diy/unknown,now 2.6.4 armhf [installed,automatic]
indi-astroberry-piface/unknown,now 2.2-1 armhf [installed,automatic]
indi-astromechfoc/unknown,now 0.1-3 armhf [installed,automatic]
indi-atik/unknown,now 2.6 armhf [installed,automatic]
indi-avalon/unknown,now 1.10 armhf [installed,automatic]
indi-bin/unknown,now 1.8.5 armhf [installed,automatic]
indi-dreamfocuser/unknown,now 2.1-3 armhf [installed,automatic]
indi-dsi/unknown,now 0.2-3 armhf [installed,automatic]
indi-duino/unknown,now 1.3 armhf [installed,automatic]
indi-eqmod/unknown,now 1.0 armhf [installed,automatic]
indi-ffmv/unknown,now 0.2-3 armhf [installed,automatic]
indi-fishcamp/unknown,now 1.1-3 armhf [installed,automatic]
indi-fli/unknown,now 1.5-1 armhf [installed,automatic]
indi-full/unknown,now 1.8.6 armhf [installed,automatic]
indi-gphoto/unknown,now 2.9-4 armhf [installed]
indi-gpsd/unknown,now 0.5-3 armhf [installed,automatic]
indi-gpsnmea/unknown,now 0.2-3 armhf [installed,automatic]
indi-maxdomeii/unknown,now 1.3-3 armhf [installed,automatic]
indi-mgen/unknown,now 0.1-3 armhf [installed,automatic]
indi-mi/unknown,now 1.8-1 armhf [installed,automatic]
indi-nexdome/unknown,now 1.4-3 armhf [installed,automatic]
indi-nexstarevo/unknown,now 0.4-3 armhf [installed,automatic]
indi-nightscape/unknown,now 1.0-3 armhf [installed,automatic]
indi-pentax/unknown,now 1.0 armhf [installed,automatic]
indi-qhy/unknown,now 2.6-4 armhf [installed,automatic]
indi-qsi/unknown,now 0.9-3 armhf [installed,automatic]
indi-sbig/unknown,now 2.1-3 armhf [installed,automatic]
indi-shelyak/unknown,now 1.0-3 armhf [installed,automatic]
indi-starbook/unknown,now 0.8-3 armhf [installed,automatic]
indi-sx/unknown,now 1.15-2 armhf [installed,automatic]
indi-talon6/unknown,now 2.0-3 armhf [installed,automatic]
indi-toupbase/unknown,now 0.2-3 armhf [installed,automatic]
indiwebmanagerapp/unknown,now 6:1.5 armhf [installed,automatic]
libayatana-appindicator3-1/stable,now 0.5.3-4 armhf [installed,automatic]
libayatana-indicator3-7/stable,now 0.6.2-3 armhf [installed,automatic]
libindi-data/unknown,now 1.8.5 all [installed,automatic]
libindi-dev/unknown,now 1.8.5 armhf [installed,automatic]
libindi1/unknown,now 1.8.5 armhf [installed,automatic]
libindicator3-7/stable,now 0.5.0-4 armhf [installed,automatic]

Log Files

original logs

log_bugged.txt.

One of many original logs. I may have done some aborts in this log file so you may encounter some junk, however it's not the cause of the problem :) Here's the important bit: you will notice that only one GP_EVENT_FILE_ADDED event is handled per exposure. After it's handled, the control is returned to the caller. This means, that only one file can be downloaded per exposure. So the case of multiple files per exposure is not handled correctly.

For some reason, until all queued up files are downloaded, the shutter doesn't work.

Sometimes when I pressed some button on the camera at this moment, I would get the error message "writing to memory card unable to operate". I disabled saving to SD card via Ekos interface but it didn't help. So I suspect what the error message really means is "Waiting for client to handle all GP_EVENT_FILE_ADDED events".

To drain the queue, I have to schedule multiple exposures. Note, that even though "Starting exposure" log is produced, there's no shutter sound in most cases.

Excerpts:

DEBUG	5.596671 sec	: Exposure complete.
DEBUG	7.456848 sec	: File added event completed.
DEBUG	7.457044 sec	: Deleting aborted image... Name: (capt0000.arw) Folder: (/)
DEBUG	7.565348 sec	: Could not determine image size (Unspecified error)
DEBUG	14.444694 sec	: Requested CCD Frame is (0,0) (5456 x 3632)
INFO	14.444989 sec	: Starting 6 seconds exposure.
DEBUG	14.445069 sec	: Starting exposure (exptime: 6 secs, mirror lock: 0, force bulb: true, exposure index: 0)
...


DEBUG	30.351691 sec	: Exposure complete.
DEBUG	32.238162 sec	: File added event completed.
DEBUG	32.238307 sec	: Downloading image... Name: (capt0001.arw) Folder: (/) Delete from SD card? (false)
DEBUG	32.404074 sec	: Could not determine image size (Unspecified error)
INFO	32.571951 sec	: Exposure done, downloading image...
DEBUG	34.932984 sec	: read_libraw: raw_width: 5504 top_margin 0 left_margin 0 first_visible_pixel 0
DEBUG	34.933235 sec	: read_libraw: rawdata.sizes.width: 5472 rawdata.sizes.height 3656 memsize 40011264 bayer_pattern RGGB
DEBUG	35.202770 sec	: read_libraw: memsize (40011264) naxis (2) w (5472) h (3656) bpp (16) bayer pattern (RGGB)
DEBUG	35.247405 sec	: Subframing... subFrameSize: 39632384 - oneFrameSize: 39632384 - subX: 0 - subY: 0 - subW: 5456 - subH: 3632
DEBUG	35.740931 sec	: Uploading file. Ext: fits, Size: 39637440, sendImage? Yes, saveImage? No
DEBUG	36.790822 sec	: BLOB transfer took 1.04969 seconds
DEBUG	36.790981 sec	: Upload complete
INFO	46.274509 sec	: Starting 6 seconds exposure.

...

DEBUG	54.153053 sec	: File added event completed.
DEBUG	54.158079 sec	: Downloading image... Name: (capt0002.arw) Folder: (/) Delete from SD card? (false)
DEBUG	54.320478 sec	: Could not determine image size (Unspecified error)
INFO	54.492608 sec	: Exposure done, downloading image...
DEBUG	56.850036 sec	: read_libraw: raw_width: 5504 top_margin 0 left_margin 0 first_visible_pixel 0
DEBUG	56.850207 sec	: read_libraw: rawdata.sizes.width: 5472 rawdata.sizes.height 3656 memsize 40011264 bayer_pattern RGGB
DEBUG	56.928127 sec	: read_libraw: memsize (40011264) naxis (2) w (5472) h (3656) bpp (16) bayer pattern (RGGB)
DEBUG	56.972947 sec	: Subframing... subFrameSize: 39632384 - oneFrameSize: 39632384 - subX: 0 - subY: 0 - subW: 5456 - subH: 3632
DEBUG	57.444006 sec	: Uploading file. Ext: fits, Size: 39637440, sendImage? Yes, saveImage? No
DEBUG	58.508581 sec	: BLOB transfer took 1.06396 seconds
DEBUG	58.508714 sec	: Upload complete
INFO	125.834484 sec	: Starting 6 seconds exposure.

...

*** logs after patch ***

log_patched.txt

After applying the aforementioned patch: all the files to be downloaded (GP_EVENT_FILE_ADDED events) are 'drained' until GP_EVENT_CAPTURE_COMPLETE. The last file's data is the one passed to the caller. Driver works as expected.

I was inspired by this comment: gphoto/gphoto2#48 (comment)

Excerpt:

DEBUG	9.271595 sec	: Exposure complete.
DEBUG	10.450409 sec	: Event timed out #1, retrying...
DEBUG	12.417993 sec	: File added event completed.
DEBUG	12.418198 sec	: Deleting aborted image... Name: (capt0000.arw) Folder: (/)
DEBUG	12.530922 sec	: Could not determine image size (Unspecified error)
DEBUG	14.373861 sec	: File added event completed.
DEBUG	14.374023 sec	: Deleting aborted image... Name: (capt0001.arw) Folder: (/)
DEBUG	14.483128 sec	: Could not determine image size (Unspecified error)
DEBUG	16.224815 sec	: File added event completed.
DEBUG	16.224969 sec	: Deleting aborted image... Name: (capt0002.arw) Folder: (/)
DEBUG	16.334314 sec	: Could not determine image size (Unspecified error)
DEBUG	16.344237 sec	: Capture event completed.
DEBUG	72.498099 sec	: Requested CCD Frame is (0,0) (5456 x 3632)
INFO	72.498755 sec	: Starting 1 seconds exposure.

Is your feature request related to a problem? Please describe.
I have an EQ6-R Pro. I have not found a way to set the polar scope LED brightness without using the hand controller. If I set the brightness with the hand controller, and then use EQMod instead of the hand controller, the brightness reverts back to 100%. It is not saved. This makes it very hard to see Polaris.

Describe the solution you'd like
I would like an INDI parameter to set the brightness level of the polar scope LED. This would eliminate the need to have the hand controller connected when using the polar scope.

Describe the bug
Altair Hypercam 294C Pro produces no images after stopping image loop (twice) in Ekos.

To Reproduce

1. start indiserver, kstars, ekos, activate a profile with the Altair driver
2. Start Framing (in a loop) by pressing the double arrow icon
3. Stop the loop with the stop button
4. Remove the fits image pop-up
5. Repeat this two times
6. The third time no more image window popup appears while most og Ekos believes images are captured.

Expected behavior
Proper response to stop looping. Ekos continous to produce images all night long.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Ubuntu 18.04 on a HP laptop
• Version 1.8.4 and 1.8.5 (latest today)

Log Files
log_13-27-28.txt

Root cause analysis
In a test environment I reproduced the problem several times. Among other the attached logfiles shows that Event 0x04 (EVENT_IMAGE) is still received after the CCD Stopped command is issued.
Interestingly, if such an event remains unhandled, a new images can be captured and is properly handled, but after aborting an image capture twice, no further Event 0x04 are produced. Hence no images are downloaded anymore.

One more interesting observation is that when images are captured, and no more event 0x04 are produced a can disconnect and reconnect the camera in the INDI panel in EKOS/kstars, and then after the camera gets initialized again, a event 0x04 arrives before any new capture is started, as can be seen in attached logfile in line 743.

The unhandled event 0x04 may leave images in the DDR memory of the Altair cam, and apparently the CCD has some issues with this.

I have been looking into a way to abort a capture, and properly handling the 0x04 events from the camera. I investigated two strategies:

1. Handle the 0x04 event when capture is aborted by downloading the image, but not retaining it.
2. Handle the 0x04 event when capture is aborted by calling toupcam_Flush() method.

Both work and solve the problem.
The second solution has the advantage of avoiding a unnecessary download. The downside is that the method occurs in the toupcam.h file, but is not mentioned in toupcams API docs.
The first solution uses functions that are already part of the driver.

A pushed both approaches to my fork of this repository. Please take a look at both and let me know if I can prepare a pull request..
See: SevenW@3d41ba4
and SevenW@bab6a0a

on raspian buster with HQ cam
added indi-rpicam, build went well

on connecting to camera a warning fires:
2020-07-06T19:22:32: [WARNING] Connect: Unknown camera name: testc
2020-07-06T19:22:31: [INFO] MMAL device connected successfully!

no other options are available. When starting device it crashes

While looking at the indi-gphoto source in #173 and #176, I experimented with several aspects of the code which might lead to improvements. But since I have only hacked in the driver for a few days now I wanted to discuss these changes before I continue working on them.

• As far as I can see the call to raw2image() in is unecessary:
  

  indi-3rdparty/indi-gphoto/gphoto_readimage.cpp

  Lines 335 to 340 in 918e8c5

  	if ((ret = RawProcessor.raw2image()) != LIBRAW_SUCCESS)
  	{
  	DEBUGFDEVICE(device, INDI::Logger::DBG_ERROR, "Cannot convert %s : %s", filename, libraw_strerror(ret));
  	RawProcessor.recycle();
  	return -1;
  	}

  
  At least I can see no difference in the resulting image with and without it.

• With the aim to improve the situation with respect to #176 and changing frame dimensions I changed the way how the raw image is converted. Now the whole raw frame is decoded, and not only the image area as reported by libraw. This way the image cropping can be done by the user, so in principle one could get the old behavior (libraw-0.19), the new behavior (libraw-0.20), or the original canon behavior by defining the respective starting x and y values.
  On the one hand this leads to simpler code and more flexibilty, on the other hand it is harder for the user to know what parameters should be used. By setting "intuitive" values (starting values of 0, width and height as stated by the camera manufacturer), one would get black borders and not the whole image.

• In order to handle the shifting bayer patterns with different offsets I set the XBAYROFF and YBAYROFF tags if the respective margins are uneven. This would replace

  indi-3rdparty/indi-gphoto/gphoto_ccd.cpp

  Lines 1487 to 1492 in 918e8c5

  	// Align all boundaries to be even
  	// This should fix issues with subframed bayered images.
  	// subX -= subX % 2;
  	// subY -= subY % 2;
  	// subW -= subW % 2;
  	// subH -= subH % 2;

• When testing this I realized that kstars does not seem to respect those tags when debayering an image. The captured fits file is correctly rendered in siril. I did not look where the debayering takes place, if it is in kstars or indi.

• I removed lots of unused code, most of it for the dcraw related functions

All the changes can be seen in knallio@3c34350. Of course they are highly experimental...

Please let me know if any of this might be helpful/usable and if I should continue working on this.

Hi.
I'm trying to add a guide cam to my rig: I bought a Omegon Pro guide cam. I understand that this cam uses indi_toupcam_ccd driver but the the driver crashes at start:

2020-08-17T12:18:57: Driver indi_toupcam_ccd: stderr EOF
2020-08-17T12:18:57: Driver indi_toupcam_ccd: restart #9
2020-08-17T12:18:57: Driver indi_toupcam_ccd: pid=1561 rfd=6 wfd=12 efd=14
Child process 1556 died
2020-08-17T12:18:58: Driver indi_altair_ccd: stderr EOF
2020-08-17T12:18:58: Driver indi_altair_ccd: Terminated after #10 restarts.
Child process 1559 died
2020-08-17T12:18:58: Driver indi_toupcam_ccd: stderr EOF
2020-08-17T12:18:58: Driver indi_toupcam_ccd: restart #10
2020-08-17T12:18:58: Driver indi_toupcam_ccd: pid=1563 rfd=4 wfd=8 efd=12
Child process 1561 died
2020-08-17T12:18:59: Driver indi_toupcam_ccd: stderr EOF
2020-08-17T12:18:59: Driver indi_toupcam_ccd: Terminated after #10 restarts.
Child process 1563 died

Desktop (please complete the following information):

• OS: latest Raspbian OS running on a Raspberry Pi 1B+
• Indiserver: latest installed using astroberry apt repository;

I have no more details to give :(

Could anyone help me?

Describe the bug
indi_qhy_ccd didn't compile, I received compilation error.

To Reproduce

1. Install indi-1.8.3
2. Build and install libqhy from indi-3rdparty-1.8.3
3. Try build indi-qhy
   3a. mkdir BUILD && cd BUILD in indi-3rdparty-1.8.3 directory
   3b. cmake -DCMAKE_INSTALL_PREFIX=/usr ../indi-qhy/
   3c. make

Expected behavior
A compilation bug appear in indi-3rdparty-1.8.3 version, with all previous versions is no problem.
Compilation process stopped with error:
error: 'SetQHYCCDBufferNumber' was not declared in this scope
SetQHYCCDBufferNumber(USBBufferN[0].value);

Desktop (please complete the following information):

• OS: Linux Enceladus 5.4.7-gentoo #1 SMP Wed Jan 1 21:32:43 CET 2020 x86_64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz GenuineIntel GNU/Linux
• GCC: gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1)
• CMake: cmake version 3.14.6
• Version INDI: 1.8.3

Log Files
-------------- CMAKE LOG:
cmake -DCMAKE_INSTALL_PREFIX=/usr ../indi-qhy/
-- The CXX compiler identification is GNU 8.3.0
-- The C compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found CFITSIO 3.41: /usr/lib64/libcfitsio.so
-- Found INDI: /usr/lib64/libindidriver.so;/usr/lib64/libindiAlignmentDriver.so (found version "1.8.3")
-- Found QHY: /usr/local/lib64/libqhyccd.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.6.3")
-- Found USB1: /usr/lib64/libusb-1.0.so (found version "1.0.21")
-- Performing Test USB1_HAS_LIBUSB_ERROR_NAME
-- Performing Test USB1_HAS_LIBUSB_ERROR_NAME - Success
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Performing Test COMPATIBLE_FORTIFY_SOURCE
-- Performing Test COMPATIBLE_FORTIFY_SOURCE - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jbielanski/Dokumenty/PROGRAMY/INDI-Astronomical-Suite/INDI/indi-3rdparty-1.8.3/BUILD
-------------- CMAKE LOG:

-------------- COMPILATION LOG:
make
Scanning dependencies of target qhy_ccd_test
[ 16%] Building CXX object CMakeFiles/qhy_ccd_test.dir/qhy_ccd_test.cpp.o
[ 33%] Linking CXX executable qhy_ccd_test
[ 33%] Built target qhy_ccd_test
Scanning dependencies of target indi_qhy_ccd
[ 50%] Building CXX object CMakeFiles/indi_qhy_ccd.dir/qhy_ccd.cpp.o
/home/jbielanski/Dokumenty/PROGRAMY/INDI-Astronomical-Suite/INDI/indi-3rdparty-1.8.3/indi-qhy/qhy_ccd.cpp: In member function 'virtual bool QHYCCD::ISNewNumber(const char*, const char*, double*, char**, int)':
/home/jbielanski/Dokumenty/PROGRAMY/INDI-Astronomical-Suite/INDI/indi-3rdparty-1.8.3/indi-qhy/qhy_ccd.cpp:1617:13: error: 'SetQHYCCDBufferNumber' was not declared in this scope
SetQHYCCDBufferNumber(USBBufferN[0].value);
^~~~~~~~~~~~~~~~~~~~~
/home/jbielanski/Dokumenty/PROGRAMY/INDI-Astronomical-Suite/INDI/indi-3rdparty-1.8.3/indi-qhy/qhy_ccd.cpp:1617:13: note: suggested alternative: 'SetQHYCCDBurstIDLE'
SetQHYCCDBufferNumber(USBBufferN[0].value);
^~~~~~~~~~~~~~~~~~~~~
SetQHYCCDBurstIDLE
make[2]: *** [CMakeFiles/indi_qhy_ccd.dir/build.make:63: CMakeFiles/indi_qhy_ccd.dir/qhy_ccd.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:110: CMakeFiles/indi_qhy_ccd.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

-------------- COMPILATION LOG:

Describe the bug
In indi_nexdome, per the thread on INDI forum, the following bug appears to be specific to the Nexdome driver - taken from MarkG's original post

https://indilib.org/forum/general/6272-nexdome-driver-will-not-slave-dome-without-abort-press.html

Per Jassem's concern re: the base class, there appears to be a second bug with the Simulator whereby it does not slew at all until EKOS is disconnected and re-started.

To Reproduce
Exact steps to reproduce the behavior.
"The dome will move to slave one time after unparking the mount but not after that. Also the manual CCW and CW buttons in the driver will work once only. Until, that is, the abort button is pressed, where the dome will then move to the correct mount azimuth. Similarly the CW & CCW buttons will again move the dome once, after each abort button press."

Expected behavior
The dome should slew as teh mount changes azimuth angles.

Screenshots
N/A - a movie can be provided if required.

Desktop (please complete the following information):

• OS: Stellarmate and KSTARS/EKOS on OSX
• Version [e.g. 1.7.6, GIT..etc] 3.4.2

Log Files
Make sure to enable logging and include log files https://indilib.org/support/logs-submission.html

Apparently there's a problem in packaging libricohcamerasdk on raspberry pi (raspbian buster).
Compilation seems ok, but debian packaging returns error:
dh_strip -plibricohcamerasdk objcopy: debian/.debhelper/libricohcamerasdk/dbgsym-root/usr/lib/debug/.build-id/f0/74b2974b6314837f82e0da73d645ef028a7564.debug: not enough room for program headers, try linking with -N objcopy:debian/.debhelper/libricohcamerasdk/dbgsym-root/usr/lib/debug/.build-id/f0/74b2974b6314837f82e0da73d645ef028a7564.debug[.note.gnu.build-id]: bad value dh_strip: objcopy --only-keep-debug --compress-debug-sections debian/libricohcamerasdk/usr/lib/arm-linux-gnueabihf/libRicohCameraSDKCpp.so.1.1.0 debian/.debhelper/libricohcamerasdk/dbgsym-root/usr/lib/debug/.build-id/f0/74b2974b6314837f82e0da73d645ef028a7564.debug returned exit code 1 dh_strip: Aborting due to earlier error make: *** [/usr/share/cdbs/1/rules/debhelper.mk:295: binary-strip-IMPL/libricohcamerasdk] Error 2
@karlrees any ideas?

This has been previously discussed here. --> indilib/indi#617

I would love to be able to use the SNAP port on my EQ6-R Pro via EQMOD. Is there a way to do this yet... even via a simple script?

This issue being reported in here at request of Jasem..

I have a SONY A55 which is not working with the SONY DLSR driver. I have attached two verbose logs of the event but the nub of the issue seems to be that the driver does not detect that the camera is in BULB mode - get a 'cannot find exposure widget' error.

FWIW This is also reporduceableon my NEX-6 and NEX-7 bodies - but I understand these have a different firmware structure to the Alpha models. Getting either to work would be great.

log_18-54-36.txt
log_11-16-45.txt

Describe the bug
Using my Canon 2000D with indi_canon_ccd (or indi_gphoto_ccd) version 3.0 in kstars causes the driver to crash and restart after capture or preview. Live view is not affected. On two different machines running indi_canon_ccd 2.9 and 2.8, respectively, there are no issues. (Edit: Same issue with different Canon DSLR (400D)).

To Reproduce
Exact steps to reproduce the behavior.

1. Connect Canon 2000D to computer
2. Start Kstars with Canon DSLR driver (indi_canon_ccd 3.0 loaded)
3. Shoot preview image

Expected behavior
The image being transferred to the computer and opened in a viewer.

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• kstars-bleeding and indi-full from stable release as well as nightly build

Log Files
org.kde.kstars.ekos.capture: Preparing capture job "/home/benjamin/Light" for execution.
org.kde.kstars.indi: Requested exposure 1 closes match is 1
org.kde.kstars.ekos.capture: "Capturing 1,000-second image..."
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[INFO] Starting 1 seconds exposure. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Starting exposure (exptime: 1 secs, mirror lock: 0, force bulb: true, exposure index: 1869115495) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Mutex locked "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting radio/menu widget iso: 5 (1600) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting new configuration OK. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting radio/menu widget imageformat: 9 (RAW) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting new configuration OK. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting exposure widget bulb index: 0 "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting radio/menu widget shutterspeed: 0 (bulb) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting new configuration OK. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Using internal bulb widget:eosremoterelease "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting radio/menu widget eosremoterelease: 2 (Press Full) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting new configuration OK. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Exposure started. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Time left: 999 ms "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Time left: -1 ms "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Closing internal shutter. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Using widget:eosremoterelease "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting radio/menu widget eosremoterelease: 4 (Release Full) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Reading exposure... "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Setting new configuration OK. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Exposure complete. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] File added event completed. "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Downloading image... Name: (capt0000.cr2) Folder: (/) Delete from SD card? (false) "
org.kde.kstars.indi: Canon DSLR EOS 2000D : "[DEBUG] Downloaded 0x0 (preview 0x0) "
org.kde.kstars.indi: Removing device "Canon DSLR EOS 2000D"
org.kde.kstars.indi: INDIListener: Removing device "Canon DSLR EOS 2000D"
org.kde.kstars.ekos: "Canon DSLR EOS 2000D is offline."
org.kde.kstars.indi: INDI Server: "2020-07-30T12:20:12: Driver indi_canon_ccd: stderr EOF"
org.kde.kstars.indi: INDI Server: "<delProperty device="Canon DSLR EOS 2000D"/>"
org.kde.kstars.indi: INDI Server: "Child process 144220 died"
org.kde.kstars.indi: INDI Server: "2020-07-30T12:20:12: Driver indi_canon_ccd: Terminated after #0 restarts."
org.kde.kstars.indi: INDI Server: ""
org.kde.kstars.indi: INDI driver "indi_canon_ccd" crashed!

When using the Streaming in INDI QHY Driver with a QHY183M, the stream fails and often locks up KStars if left alone too long.

1. Define QHYCCD as main CCD Driver
2. Start KStars
3. Open INDI Control Panel and select the QHY183M
4. Change to Streaming Tab
5. Turn Streaming On and wait
6. Image will be black and log will have streaming errors

It would be nice if Streaming worked on QHY183M cameras

I have found the issue. It appears to be around the discrepancy between the call to PrimaryCCD.getFrameBufferSize() (which returns 40MB) and the call to GetQHYCCDLiveFrame, which returns params that would indicate a 20MB Buffer is needed.

Just as a test, I compiled the code with a lot more debugging, showing sizes of expected buffers and actual buffers. They were off, the expected was 40MB and the reality was 20MB. I simply divided the expected by 2 in the call to Streamer->newFrame and it started to work. This is a hach, for sure, but it does show there is something off.

When building the indi-toupbase 3rd party driver I get an error during the make.
I have built several other drivers in the same environment without issue today.
Raspbian Buster on pi 3B+

pi@pi4:~/codedev/indi-3rdparty/build/indi-toupbase $ make [ 12%] Building CXX object CMakeFiles/indi_altair_ccd.dir/indi_toupbase.cpp.o /home/pi/codedev/indi-3rdparty/indi-toupbase/indi_toupbase.cpp: In member function ‘void ToupBase::pushCallback(const void*, const AltaircamFrameInfoV2*, int)’: /home/pi/codedev/indi-3rdparty/indi-toupbase/indi_toupbase.cpp:2108:22: error: ‘unique_lock’ is not a member of ‘std’ std::unique_lock<std::mutex> guard(ccdBufferLock);

Could you give me any pointers as to what might be wrong please.

Error on making indi-rpicam, missing files:

MMALConfig.cmake
mmal-config.cmake

On a regular indi install on RPi3. All regular dependencies installed
sudo apt-get -y install libnova-dev libcfitsio-dev libusb-1.0-0-dev zlib1g-dev libgsl-dev build-essential cmake git libjpeg-dev libcurl4-gnutls-dev libtiff-dev libfftw3-dev libftdi-dev libgps-dev libraw-dev libdc1394-22-dev libgphoto2-dev libboost-dev libboost-regex-dev librtlsdr-dev liblimesuite-dev libftdi1-dev libavcodec-dev libavdevice-dev

Reproduce:

1. Connect DSLR in "M" mode
2. set "force bulb" to OFF
3. In CCD TAB add a 1/1000s exposure to the queue
4. activate the queue
5. Picture taken is a 1/500s

Expected behaviour would be a 1/1000s picture taken.

Logfile:

[2019-09-17T13:11:53.645 CEST DEBG ][ org.kde.kstars.indi] - Canon DSLR EOS 5D Mark II : "[DEBUG] Finding optimal exposure setting for 0.001001 seconds in shutterspeed (count=37)... "
[2019-09-17T13:11:53.645 CEST DEBG ][ org.kde.kstars.indi] - Canon DSLR EOS 5D Mark II : "[DEBUG] Closest match: 0.002 seconds Index: 28 "
[2019-09-17T13:11:53.645 CEST DEBG ][ org.kde.kstars.indi] - Canon DSLR EOS 5D Mark II : "[DEBUG] Setting radio/menu widget shutterspeed: 28 (1/500) "
[2019-09-17T13:11:53.672 CEST DEBG ][ org.kde.kstars.indi] - Canon DSLR EOS 5D Mark II : "[DEBUG] Setting new configuration OK. "
[2019-09-17T13:11:53.672 CEST DEBG ][ org.kde.kstars.indi] - Canon DSLR EOS 5D Mark II : "[DEBUG] Using predefined exposure time: 0.002 seconds "

Ekos considers 0.001001 closer to 0.002 than 0.001 thus selects 1/500s.

Similar behaviour for other very short shutter speeds (Ekos chooses 1/1000 when 1/8000 was selected).

Kubuntu 19.04, KStars Build: 2019-09-18T13:06:05Z. Camera used: Canon 5D Mk2. Complete logfile see: https://indilib.org/forum/ccds-dslrs/5622-eos-1-4000-shuuter-speed.html?start=12#43479

Describe the bug
Astrolink4's "Reverse motion" setting has no effect on focusing direction.

To Reproduce

1. Run driver
2. Focus In
3. Enable "Reverse Motion" under "Focuser" tab
4. Focus In

Expected behavior
The focuser motion should have been reversed.

Desktop:

• OS: astoberry 2.0.1(raspbian 10 buster)
• KStars 3.4.2, indilib 1.8.5

Log Files
Enabling reverse motion

[2020-05-13T21:33:17.005 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] RES u:100000:250:0:100:500:1:0:0:446:3:1:1:0:0:1:0:0:2153:433: "
[2020-05-13T21:33:17.005 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] CMD U:100000:250:0:100:500:1:0:0:446:3:1:1:0:0:1:0:0:2153:433:: "

Disabling reverse motion

[2020-05-13T21:33:17.035 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] RES u:100000:250:0:100:500:0:0:0:446:3:1:1:0:0:1:0:0:2153:433: "
[2020-05-13T21:33:17.035 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] CMD U:100000:250:0:100:500:0:0:0:446:3:1:1:0:0:1:0:0:2153:433:: "

The "reverse motion" setting, which according to the code and this define is the 6th item (the one after 500 should be 1 when enabled on the device.

The device itself and the reverse motion setting is working fine. If I set the "Reverse motion" from the Windows Astrolink panel, it's working as expected. Later when I plug the Astrolink into my INDI setup again, I can see that the setting is read as 1 before being updated to 0 again on load (u = read, U = write) :

[2020-05-13T21:37:43.014 CEST DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Capture" )
[2020-05-13T21:37:43.033 CEST DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Focus" )
[2020-05-13T21:37:43.041 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] RES U: "
[2020-05-13T21:37:43.042 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] CMD u "
[2020-05-13T21:37:43.042 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] RES u:100000:250:0:100:500:1:0:0:446:3:1:1:0:0:1:0:0:2153:433: "
[2020-05-13T21:37:43.042 CEST DEBG ][ org.kde.kstars.indi] - AstroLink 4 : "[DEBUG] CMD U:100000:250:0:100:500:0:0:0:446:3:1:1:0:0:1:0:0:2153:433:: "

So my guess is bool IndiAstrolink4::ReverseFocuser(bool enabled) is always called with enabled = false no matter what the UI says. But I cannot find why looking at the code itself.

Hi,

I tried to use my Nikon 1 J4 with ekos using indi_gphoto_ccd. I soon realized that if was not possible to set the shutterspeed and that the issue was with gphoto. I then contacted gphoto developer which was very efficient in supporting me. The latest commit of libgphoto now allows to set the shutterspeed on Nikon J4. I decided to try the new libgphoto with ekos, so I recompiled ekos on a Mac, using the script from rlancaste, modified by me to pick up the latest commit of libgphoto and not the stable release. Compiling was successful, but some issues still remains.

While I see the shutterspeed property under the capturesettings panel in Indi Control Panel, and I can indeed change the shutterspeed from there (before, the shutterspeed property does not even show up), when I try to change the shutterspeed in ekos, or try to use a Preset is the Main Control tab of Indi Control Panel, the capture is always done with the shutterspeed previously set in the camera (either by the camera own control, or using the capturesettings tabs). I disabled Force BULB (the camera does not support bulb mode).

Any idea of what's wrong?

Thanks

I own an old Brightstar Mammut Lyuba camera which works fine on Windows with both native and ASCOM drivers (that are no more maintained since the company closed business). I would like to move my entire set-up to a full linux environement, with RaspberryPI / Astroberry, but unfortunately the camera is not recognized by the existing set of INDI drivers embedded in Astroberry (I tried MEADE DSI, Orion SSAG, Starshoot, all to no avail) and therefore cannot be used as main or guide camera. This camera ressembles the ORION Starshoot G3 very much. It seems to be based on some AVR32 AMTEL chipset from microchips (so it says from dmesg after plugging it into the USB port). Any advice on the relevant INDI driver to be used or any trick involving ASCOM Alpaca would be very much welcome. Thanks

There's still something wrong with the build for the indi-pentax package. It's packaging the astrolink4 driver instead of the pentax driver.

I'm still learning how all this packaging stuff works, but I think the source of the problem may be here: https://code.launchpad.net/~mutlaqja/+recipe/indi-pentax-nightly. The recipe is pulling in the source code from the indi-astrolink4 directory instead of indi-pentax. Didn't see a way for me to change the recipe or propose changes.

Describe the bug
Whener I try to compile the indi-asi driver, I get the following message (on several independent pc's):

/home/cobra/packages/indi-3rdparty/indi-asi/asi_camera_test.cpp:304:25: error: ‘CV_RGB’ was not declared in this scope
  304 |             cvSet(pRgb, CV_RGB(180, 180, 180));

To Reproduce
Try to compile indi-asi

Expected behavior
indi-asi compiles without error

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux (and Arch Linux ARM, both dont work)
• Version: Kernel 5.7.12

Log Files

Hi,

it looks that the latest release of Indi-asi and libasi got problems, I tried to compile Indi-asi driver today on various platform (RPI3, OrangePiPC+ and Pine64 LTS) and got every time the same issue:

CMake Error at CMakeLists.txt:364 (add_subdirectory):
add_subdirectory given source "asi-common" which is not an existing
directory.

CMake Error at cmake_modules/FindASI.cmake:68 (message):
ASI not found. Please install libasi http://www.indilib.org
Call Stack (most recent call first):
indi-asi/CMakeLists.txt:8 (find_package)

Regards