I've checked my Meade LPI-GM Advanced (Touptek imx178 rebadge) and see a maximum value of 16k, which matches what you're seeing except that I'm using a 14-bit sensor. I see the same thing with my 14-bit Canon T7.

It seems to me that what you're seeing is normal, or at least, not a problem. I stack with siril so unfortunately don't know if pixinsight needs additional configuration to handle this. It is odd that you don't see this with the ASCOM drivers, though.

Thanks,
Ben

Read More...

I don't have this camera, so can't reproduce your issue but is there an option to select 12-bit mode? Even with the data only using the lowest 12 bits of the 16 bit space, I'm surprised that this couldn't just be stretched.

Read More...

The driver is available in the standard indi release, so you shouldn't have to build it. I'm using Jasem's PPA and can install it by doing "apt-get install indi-orion-ssg3".

-Ben

Read More...

Debayering the images in kfitsviewer is not supported since the CCD for the DSI Color (ICX254AK) uses a complementary color filter array rather than the "standard" RGGB CFA. The CMYG CFA was used on some of these older cameras but is not really used anymore.

I don't have pixinsight, but a little searching seems to indicate that it can debayer these images.

Read More...

I pushed another branch called bin_no_deinterlace. This has the same changes as the other branch and an additional change to not deinterlace the frame if y-binning is enabled. I think this will work better, but I it would be nice if you could test both and find out for sure.

Read More...

I think the file should be at /usr/lib/udev/rules.d/99-orionssg3.rules. Do you still see this problem after rebooting?

Read More...

I finally got around to implementing binning and subframing. To try it out, do:
git clone github.com/bgilsrud/indi-3rdparty.git
cd indi-3rdparty
git checkout ssg3_updates

Then you can build the drive like you normally would. I don't have one of these cameras, so I can only simulate how I think it should behave and I was able to see the USB sequences that I was expecting. I think the most useful test would be to take a recognizable image with binning enabled...there's a good chance that the frame will be reassembled incorrectly. The code will still attempt to deinterlace the downloaded image, which I'm thinking is not correct when binning is enabled.
 

Read More...

I'm glad to hear it works!

How did you install the driver? It should come with a udev file (99-orionssg3.rules) to automatically set the permissions, so I'm not sure why that's not working.

Read More...

Cool shot, Andrew! It's really neat to see the noise at the edges and see how it gets cleaned up as more images overlap toward the center.

Sorry, I've been a little distracted lately, but I'll get to the changes that we mentioned in the next day or so. The issues you mentioned with the short exposures could be related to timing of the download code. Unless the camera has some external memory, the little microcontroller in the camera can't buffer a full frame so it's possible that it needs the host to be ready (ie, have requested a bulk transfer) before the exposure is done. It's possible that the driver isn't meeting that timing for super short exposures. I think this would be difficult to fix without changing things too much. It would be a lot simpler to limit short exposures to a value that we know works. Any thoughts?

Thanks,
Ben

Read More...

Hi Emmanuel,
I would start by double checking that the usb device file has the correct permissions. The driver comes with a udev file that should take care of this, but maybe it's not working correctly?

Do:
ls -alh /dev/bus/usb/${BUS}/${DEVICE}

where BUS and DEVICE are determined by the lsusb output (004 and 003 in your output above).

Read More...