I've noticed that after a recent update on my Manjaro machine, that I can no longer adjust the offset of my RisingCam 571 to be above 31 ADU... I used to have it set at 256 (where on low gain mode at 100 gain the minimum value would always be above 0)
So now I can't take images that are compatible with the ones already taken for my project, unless I can downgrade whatever is causing this...
Also, I notice many settings in the indi control panel in Kstars have their names clipped off, and I can't resize the spacing between the property name label and the button/text field, so I just plain do not know what some of the settings are besides the first 5/6 letters... Anyone else have this issue?
Regarding the problem of the momentary interruption of the fan and the peltier at the beginning of a shot: I don't know if it can be useful or if it has already been reported... But the problem exists only if you start the shot from the EKOS, even as a shot singles, without starting a programmed sequence. However, if you start a shot from the control panel then the room works perfectly, i.e. it does not interrupt the operation of the fan and the tec. This thing, in an empirical way, leads me to think that it's not an sdk problem, but a kstars/ekos problem...
Of course, I set all the parameters and save the sequence.
The problem occurs only if I start shooting from the EKOS panel. Both in the case of starting a single shot (acquire preview) and starting a sequence. If I start a shot from the INDI control panel then everything works...
I thought offset adjustment was a new feature and the camera only had 31 ADU maximum. I do now know why you could set it to 256. Maybe it is a software offset. because the sensor can only support up to 4095 from 65535 at 16-bit mode.
Sorry for the late reply. I still can't get used to opening the forum every day, and I have been busy recently. I am so sorry.
So yes, based on the info, your cam is an older version and the whole system went off when CAMERA_STOP or switch resolution is called.
Maybe when INDI starts triggering, it would call switch resolution, even if it is the same resolution but the procedure would call the CAMERA_STOP.
Or maybe after the sub is finished, INDI would call CAMERA_STOP to put it to reset mode.
Neither of them is necessary if the user does not switch the resolution.
We seem to be discussing two different scenarios:
- Risingcam and other varieties of camera using libtoupcam
- Omegon cameras using libomegonpro
Using the omegonpro software, our veTEC571 (purchased from Nimax two weeks ago) is working fine apart from having to set the temperature manually before starting capture... Almost certainly something I've overlooked when saving the capture sequence. It will however maintain that temperature accurately all night over many exposures.
The Risingcam 571 variants received both hardware and firmware updates recently. Amongst other differences, the old cameras have the power input diagonally opposite the usb3. The new cameras, beneath. I wonder if the issues mentioned here are anything to do with older models?