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...
I'll take a look at implementing some of this over the weekend. I think the illumination differences between the even and odd field would only occur with short exposures since the readout time would become insignificant at longer exposures. I don't have this camera, but I do have a Meade DSI I which also has an interlaced sensor and see this same thing. I do agree with your point regarding the readout time. 2s is crazy for a sensor that small and would make it almost useless for a guide cam.
Read More...
I'm glad that you were able to get some images out off it!
I started to implement binning and then put that on hold. I just double checked and see that the driver is still advertising binning support, which was not what I intended. Binning could be added without a lot of effort, but I wondered how valuable that would actually be given that the sensor is small and the pixels are already pretty large. But, someone who's motivated could do it 
Subframing is also not supported by the driver, but we understand enough of the camera control protocol that it could be.
I believe that the cooling is a setpoint-style interface. That is, the driver tells the camera the desired temperature and the camera is responsible for adjusting peltier power and fan speed to achieve the desired set point. The G3 hardware can only cool down to ~10c below ambient. If you set the cooling to something like 5C below ambient I would expect that you would see the power spike and then decrease as it reaches the setpoint and maybe settle somewhere around 50% (+/- 20%). You could also try experimenting with cooling in the orion capture studio and see if you see the same power/fan behavior. I suspect that the fan is controlled by the uC on the camera rather than through the driver. At least, that's what I would do if I designed the camera. Also, I don't think there were any write commands whose function wasn't figured out.
I would love to see what you were able to image with the camera!
Read More...