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?
You were just right ! Access rights related to the above file were rw-rw-r.
I added write access to all (file owner and group is root), so I changed file access properties to rw-rw-rw. The camera is now connected, and giving regular pictures with EKOS either as main CCD or autoguider. Cooling is also ok. It's just so great to have this almost unknown camera back to business !
Only trouble is that if I disconnect the USB cable and connect it back again, the device number is updated, and I have to chmod 666 again the BUS/DEVICE file. There may be a way to avoid this little pain.
I installed it through the package manager under the raspbian / astroberry environment, searching for INDI, and locating the orion g3. No git, no .deb execution, no compilations...
I'm really not a linux expert, sorry about this. Where is the file you mention supposed to be located ?
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.
I got your code cloned and built. I am trying to shoot some recognizable images with it but since it is mid-day here I need to do short exposures to avoid maxing out the pixel counts. This means that the issue with short exposures that I mentioned before is rearing its ugly head. I will try to get some properly exposed subframed and 2x2 binned images and/or captures tonight and let you know how that part of the code is working. In the meantime though here is a packet capture of the problematic 0.25 second exposures. I took a first exposure, which seemed to download just fine, then waited a few seconds and tried a second one. The second one downloaded but it paused for a really long time during the download. Hopefully this capture has what you need to figure out why this is happening. In any case though I will investigate the subframing/binning code tonight when it is a bit darker.
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.
After an extended break from the G3 (a new ASI camera and not a lot of astro photography) I worked through the build of the indi-orion-ssg3 driver tonight and took a couple of test shots.
Not connected to a scope (it's raining here so that would not have helped much).
Very big thanks to those who stuck with this and got it working.
Looking forward to trying it on the sky sometime soon and see what it does..