Thanks for posting! I followed the other posting in raspberry-pi-hq-autoguiding to this forum so I had the 1s fix as well. I noted a few diffs between the files that I didn't specifically see in your diff you posted on page 6. Though now that I see them I should have looked closer at the driver package. I'm going to try with these changes and if that doesn't work I'm going to reinstall the OS and start from scratch. Thanks again for your work.

In mmalcamera.cpp

-- if (!strcmp(cameraModel, "imx477")) {
xPixelSize = yPixelSize = 1.55F;
}
++ if (!strcmp(cameraModel, "imx477")) {
xPixelSize = yPixelSize = 3.1F;
}


In mmaldriver.cpp
-- SetCCDParams(static_cast<int>(camera_control->get_camera()->get_width()),
static_cast<int>(camera_control->get_camera()->get_height()),
++ SetCCDParams(2028,
1520,
16,
-- uint32_t nbuf = PrimaryCCD.getXRes() * PrimaryCCD.getYRes() * PrimaryCCD.getBPP() / 8;
++ uint32_t nbuf = 2028 * 1520 * PrimaryCCD.getBPP() / 8;

-- // | CCD_HAS_STREAMING // Does the CCD support live video streaming?
++ | CCD_HAS_STREAMING // Does the CCD support live video streaming?

Indeed I did play a bit more with that version I sent. I updated pixel size to get accurate SNR, because of "false" hard coded binning I implemented i would get incorrect SNR.

Also I started playing with streaming, for future planetary capture, but did not get very far so if you click stream everything crashes, or you can comment out that line so you do not accidently click it.

You do not need to reinstall OS for this, you can easily reset it to default. Keep me updated I am interested how it works for other people as well.

This workarround seams to fix non working long exposure times after first 1 sec exposure:

github.com/indilib/indi-3rdparty/issues/271

Outta, I had some cloudy skies around my home recently but updating the resolution in the driver fixed the issue with PHD2 and the Focus tab in ekos. I had to make a new instance of the camera but when I did it properly would set the resolution to 2028x1520 and stopped trying to double the resolution each image. The one item I'm now investigating is I cannot get ekos to expose for longer than 7 seconds. If I use a time >7s I see the exposure time decrement but once it hits 7s it skips to 0 and processes the image. So for instance if I use an exposure of 10s it counts down from 10 to 3 and then skips to 0. I'm going to try Simon's workaround to see if that fixes my long-exposure problem.

Hi Craig,

If you want longer exposures you have to fo workaround.

Simon above said you have to take 7s exposure, but for some reason that does not work for me.

For me to enable long exposure mode you have to take two images, first one has to be 10s and second one 15s.

10s will fail at around 6s mark, but second 15s will be finished completely and from now on long exposure is activated, untill you restart INDI. You have to do this 10-15s every time you reconnect equipment.

Mind you that enabling long exposure mode will result in much slower download, not recommended for guding. Fine for capturing.

Is it possible now to create a Pull Request for these changes to the GIT repo?

Unfortunately not. I can only do PR for 1s fix. That is just one > to >=.

Regarding binning, that is just plain hardcoded as I have no Idea how UI communicates with driver, and for it to be switchable we would need to expand functionality and method signatures to accept additional parameters, and I do not have time to do that at this moment but all my code is in zip, if someone has knowledge, time, and is willing to do it, feel free, I can even explain something if needed.

How about utilizing libcamera so that we can have a driver for both 32bit and 64bit Raspberry PI? is this a lot of work? I'd say even if it is, it would be great if he can half some skeleton driver based on libcamera that at least can capture images and can then be subsequently imporoved.

Hi Jason,

As I read, it is a mixed bag in astronomy usecase. Main highpoint of libcamera is enhanced post processing of the image, and we do not need that in astronomy. It impacts performance a bit, but it could ease up adding support for cameras, and steaming could be easily implemented. But there comes new issue as libcam-raw can handle max FPS of 40, while raspiraw goes up to 130FPS for HighQuality camera. Although we do not have streaming either way at this moment...

Best option for astronomy should be V4L2, but it does not work best with Hi Quality Camera, as controls are bad.

Libcam is future but has some impact on highspeed imaging while legacy driver has good performance but implementation is not the best.

Another benefit of libcam is support for additional chips form likes of arducam like IMX290, and others.
I was looking into it a bit but did but did not get far. Driver could be named Indi-libcam.
Maybe if someone experienced could make architecture/design/simple prototype us amateurs could work on implementation.