Thanks for the help getting the HQ camera up and running. I'm new to the Raspi so I am wondering if you can point me to the file you updated for Plate Solving? I have run into a few issues that maybe you have run into and know how to work around. 1) Ekos KStars Focus always sets the resolution of the Camera back to 4056x3040. 2) When I run PHD2 and perform the camera image loop the driver crashes. I think it is due to PHD2 trying to set the resolution to 8112x6080 after the first image is requested.

Thanks for any help you can provide!

Hi Craig,

Issue is not in fact in resolution issue is in exposure time of 1s. There is indeed a bug in driver with 1s. I have fixed that locally but did not make pull request as I did not test it with regular setup as my configuration is heavily modified so I cannot do true test without returning everything to default, that I am lazy to do.

But to help people out here I will upload my Source Code from RPI right here so other people can build if needed my custom version.

Regarding guiding, I have typed everything I did in other thread, there is still one small thing I am trying to discover, but I have accidently burdened my mounts brain (shorted something on STM32 BluePilll ) and now I am waiting for new ones to come.
So uf you start ekos driver, and take 10s then 15s exposure you will "enable" long exposure mode, in that mode download slows down to ~3-4s, but you will be able to take exposures longer than 5 sec, what is important for imaging. As I was doing this by default every time I start ekos I noticed if i do not do that, download is much faster, but I did not find out what impact does ti have on quality of image for guding, due to problem above. If image quality is degraded and SNR is bad I prefer old mode, despite being slower.

Also not to forget, I turned off "noise reduction" in RPI camera using commands:

indilib.org/forum/general/7332-raspberry...uiding.html?start=12

Here is my custom edit of this driver, it is compiled so you can just go to that folder and run
sudo make install

If it does not work go through whole procedure:

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.