I'm sorry if I sound bitter, it don't mean to be offensive in any way, it's just that the system keeps being troublesome.

I will try to reproduce while having logging switched on!

When I have noticed that my ASI 1600MM Pro is in 8-bit mode is usually immediately after startup. I just looked at both the default and my config files, and they both have RAW16 set as on. I'll try to document better when/if I see that again.

Has something changed in the driver, as I always used 16 bit mode exclusively and never had an issue with capture fails before. But now it seems to always flip to 8 bit on the first image taken. Is there any way to counter/force a behavior in the driver to get the 12 bits? Mine is the ZWO ASI120MM-S Monochrome USB3 version, and it seems to be the USB2 version people have USB issues with if that is related.

Have a look at Jasem's first comment (which is the fifth comment including the original post counting from the start of the thread) where he explains what the change was and why.

But that doesn't quite answer it though - what you see today now implies the camera always fails on the first image capture it takes because the first images is always in 8 bit mode. It now never takes a 16bit FIT with a revert to 8bit later on in the capture sequence after a fail.

Where as before I never had the failed to capture or receive image (or it constantly looping on the same exposure) using my 120. This is why wonder if there was a fundamental change to the driver which makes it now always fail on the first capture in 16bit mode, as apposed to the 16bit to 8bit change after a fail being the only change.

I've found a way to get 16bit on the first image taken, the "Loop" option in CCDciel will return a 16bit FIT at first, then swap to 8 bit after that. But pressing the "Preview" button doesn't, very strange!

Thanks for the clarification. The driver consists of two parts: a binary driver by ZWO and a wrapper in INDI. Perhaps ZWO needs to be contacted to understand why 16 bit with ASI120 cameras fails on Linux.

I've had the same experience. Took me by complete surprise and extremely disappointing. Had to throw away hours and hours of overnight data.

The only information I can contribute to the troubleshooting is that I recently installed 3.5.0 beta for MacOS, use the app on a MacBook talking to a remote server on the Stellarmate, and I spent a lot of time finding a location for the SM with good WiFi reception - meaning that I was starting and stopping the SM because it would come up in hotspot mode. I'd have to connect with an iPad to switch it over. Did this several times that night. Never ever occurred to me to check bit depth of 1600 before I started my sequence. Never saw that before with 3.4.3.

No, this automatic switch is only applicable to ASI120. If there is an issue in your case then perhaps it is some configuration issue either not being probably written, or not being properly read, or something else is resetting them to 8bit externally.

Not sure if related or not. I have not had much of a chance to play with real skies, but tonight was clear, so am trying out the latest from git.

I am not able to switch either of my ZWO cameras to 16 bit. They are normally both 16 bit, and just left that way. Tonight when I started things up, I get the message in the logs:

this is on both cameras:

The problem is this is after a fresh reboot. Nothing is streaming. I go into the INDI control panel to make sure, and everything looks fine. I can even start and stop streaming from the INDI control panel for either camera, and I can also start and stop streaming from the CCD tab. Everything works, I just cannot switch them to 16 bit.

I have attached the log to see f there is anything else of interest in there.

Jim

On a whim, I shut down INDI and moved the ZWO configuration files out of .indi and just kept them in my home directory. Now when INDI is started and I connect to the cameras, they are in 16 bit mode, but I still receive the same error trying to change them. At least locked into 16 bit more is more usable

Jim

The latest code in git seems to have fixed this problem for me. I am now able to swap from 8 bit to 16 and back without errors.