×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

ASI294MC flips to 8 bit mode during exposure

  • Posts: 207
  • Thank you received: 14
I upgraded to Kstars 3.6.9 stable and am testing different cameras.
I noticed that when I take a frame with my ZWO 294MCPro the Bitpix flips from 16bit to 8 bit !
Screen shots attached.
This never used to happen.
Before exposure:

After 1sec exposure:
2 months 1 week ago #98906
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
Hi Nick,

I updated to today's Indi and KStars (git) and tried to reproduce with my ASI294MC-Pro. After a 1s exposure, the FORMAT remained at Raw 16 Bit.

Did you update Indi and Indi-3rdparty, too?
I don't know whether this would have any effect but did you re-try "SAVE" in Indi control panel / Options?

Currently my settings look like this:


2 months 1 week ago #98911
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
One thing I noted in your settings is "high speed mode = 1". I'm not sure but this mode could limit the bit depth of the cam thus the 8bit mode after the first exposure.
What happens if you set "high speed mode" to 0? IMO the only use case that may profit from hsm=1 is lunar/planetary imaging that requires very high frame rates.
For deep sky imaging I would leave it at 0.
Last edit: 2 months 1 week ago by Alfred.
2 months 1 week ago #98913

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
Hi Alfred. I have never used HishSpeed mode setting on this camera, I was just messing around to see if that would fix it.
I've set it back to 0 as it always has been for the last 4 years.

Did an apt upgrade on server and client, but they are both already fully up to date.
Same issue.
The problem seems to start when the drivers load. If I edit my camera profile: 'ZWO CCD ASI294MC Pro_config.xml'
and manually set 8 bit off and 16 bit on, then when I start up, the camera immediately switches to 8 bit mode.

My server is Armbian arm64 Jammy 22.04 (ie Ubuntu 22.04)
kstars-bleeding-data/jammy,now 6:3.6.9+202402010456~ubuntu22.04.1 all [installed,automatic
My client is Linux Miint 21.2 (Ubuntu 22.04)
kstars-bleeding-dbg/jammy,now 6:3.6.9+202402010456~ubuntu22.04.1 amd64 [installed,automatic]
Looks like 01 Feb release everywhere.

I am not using nightly versions and don't want to go down that rabbit hole.
Looks like your patch level doesn't have this issue
I guess I might have to wait. I'll use a previous working version until then.

Thanks for testing.
Nick
2 months 1 week ago #98917

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
Hi, Maybe the problem is that a pre-release/nightly version of 3.6.9 has been put into the release binary repository ?
I see 3.6.9 isn't due for release until 01 April ?
This is not such a great idea if so.
Nick
2 months 1 week ago #98918

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
Ok I just tested the same setup with kstars 3.6.8 and the ASI294MCPro camera works fine.
It starts on 16 bit and stays there.

I would say there is some sort of bug in the binary version of kstars 3.6.9 that I have.
It was installed from the ppa
deb ppa.launchpad.net/mutlaqja/ppa/ubuntu jammy main
so not a nightly build, but the stable release.
Client x64 Linux mint 21.2 (ubuntu 22.04 base)
Server arm64 Armbian (ubuntu 22.04 base).
kstars runs on the client so not an issue with the server.
Nick
2 months 1 week ago #98927

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
Ok tried 3.6.8 and 3.6.9 09 fec 2024 build and both work.
Now I try the 3.6.9 01 Feb release it now works.
Looking at the .xml profile 'ZWO CCD ASI294MC Pro_config.xml' I see it is now much bigger and has been re-ordered.
I suspect the old one was somehow incompatible with the new version.
When I ran 3.6.8 or 3.6.9-09 Feb it saved a new version on exit.
Just guessing.
Nick
2 months 1 week ago #98929

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
Excellent news, problem solved! Let's hope future upgrades are not affected by such teething problems.
Last edit: 2 months 1 week ago by Alfred.
2 months 1 week ago #98937

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
I think the moral of this story is that you need to re-generate a device profile when upgrading kstars.
I had the profile from an older release (3.5.x I think) as I hadn't used this camera for a while as it had been on another system not using kstars.
2 months 1 week ago #98938

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
I've had similar issues with other hardware in the past. Although it doesn't sound reasonable at first, clicking "SAVE Configuration" in the Indi / Options TAB can make a difference. However, I don't know whether or not this would have fixed the xml profile in this case.
Last edit: 2 months 1 week ago by Alfred.
2 months 1 week ago #98939

Please Log in or Create an account to join the conversation.

  • Posts: 207
  • Thank you received: 14
No. In this case I set the correct bit size and saved many times. The problem is that save worked but did not turn a corrupt file in to one that the
new version of ekos could understand. Maybe because the format of the original was just too out of date. I've had a similar problem years ago
but I had forgotten. It is only later when 3.6.9 started magically working and I looked at the difference between the new file and old one i realised
that new one was very different.
2 months 1 week ago #98949

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
This begs the question why does the transition work flawlessly with some setups but not with others. My probably naive expectation would be that a click at "SAVE" would trigger the config file being written in the then-current format, overwrite older versions and make the program work as expected. Obviously this was not the case here.

At some point my system must have made the necessary changes without my intervention.
2 months 1 week ago #98954

Please Log in or Create an account to join the conversation.

Time to create page: 0.836 seconds