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.
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.
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.
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.
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.
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.
So this is hardcoded binning, without framing it is fixed resolution! Framing is possible next feature. One day, maybe, I will integrate this to main driver so no need for two drivers. This driver is recommended for guiding, and dimmer targets.
Guide how to build is on section "Building individual 3rd Party Drivers".
Driver is currently based on v1.9.6 of indi, as there are some breaking changes in nightly build I have reverted them and I will put them back when nightly goes live. If I remember, you can send me reminder here if needed.
On little fun side of things, i was imaging Saturn other day with REGULAR driver, so unbinned. I framed Saturn to 900x800px to reduce download speed. Imaged with Skywatcher 127 MAK. Could have do better job with focus and post processing. Imaged 1500 frames at 0.05s, stacked ~100 of it. Raw streaming would be brilliant if it could be done. There is raspiraw implementation that allows 11FPS at full resolution, so framed it could go to 120FPS easily.
Last time we discussed libcamera was not good for our purpose due to speed limitations, now as I read it has become a lot faster.
can record unprocessed DNG files, and
can record full res(4056x3040) at 10FPS that is just 1 fps slower than mmal driver.
Unfortunately I am barely capable of altering this driver, and not even good in that as properly I should be able to implement binning in original driver, let alone doing full implementation. If someone with good knowledge is to setup everything and make basic image and stream, I might be able to help with integration of additional features if needed. I have no idea how could I use libcamera-still to get data to INDI or should I use that or just use sourcecode of libcamera-still and raw. It would be good if we could just use those commands and stream their data.
The stuff we need to integarate would be libcamera-still - that is giving us option to record raw DNG-s, that is I guess similar to FITs, and libcamera-raw for raw videorecording/streaming.
Interesting optional feature we could use for libcamera-raw would be possibility to save to "ramdisk" as that would enable us to have maximum speed, and then transfer data where needed when recording finishes( or even better while recording is progres slowly move from ramdisk to sdcard). This should be an option as it would not be good for RPis with 1gb of ram.