Thank you! If this is well tested and produce the expected results, then it should be incorporated in the driver when the binning is changed.

It should also be tested on IMX219 camera, I saw driver supports that sensor and unit test should be ran, I did not test that as I don't have Gtest. I am actually .net developer so I am kind of out of my league here but managing

And of course taking value from GUI should be implemented, as I just hard-coded 2. Programmatically changing resolutiom to 1/2 would be nice to have. 
But for my personal use it can remain hardcoded as I would always use binned mode. 

I finally managed to do a star test, and binned results are impressive. Since it was not mounted stars drifted a bit, I missed a focus a bit as well, and lens is garbage. It is 134mm FL 34mm D, 5s exposure with analog gain 12.

 

Since 2x2 is hardware binning it has impressive result. And binning is definitely must have as it increases sensitivity and download lasts 1s, so it can be used for guiding as well.


Also very very important note, if you do not set correct resolution in binned mode(2028x1520 or less),it will completly break everything and you need to restart whole RPi, as camera is stuck in exposing mode.

Impressive! Any ideas how can we inquire if binning is supported or not? and the range? Then it would be easy to code in.

Wow, good job! I have to try.

Is there a limit to the max exposure?

Thanks Tomas. 
EDIT: Just saw this, yes there is 200s exposure limit(although it could possibly go to max of 230)

Jason, I do not think we can get binning data from camera, but it is defined in raspberry documentation: www.raspberrypi.org/documentation/accessories/camera.html.
All 3 cameras support only 2x2 hardware binning, but in different modes. I am not sure does this driver support OV5647 sensor, I doubt it. 
There are lot of modes but I think we are interested only in 2x2 binning at full resolution as we can easily crop image afterwards, and hi speed recording is not intended in this usecase.

We could create mapping class per sensor name (as we do have that information from camera)  and using that class set Sensor mode and Max Resolution (half of max y and x provided by camera). 

Here is one more result Helix nebula on 60/330 apo in light poluted area: 

Both 200s gain 12 and I think gain 16 on not binned one(but I do not see difference between 12 and 16. 
New one was not autoguided just tracked, guiding failed for some reason. 

Another issue that i found, and solved by Hardcoding is that "Plate Solving" automatically takes "Max Resolution" in that case it breaks the system, so I hardcoded the use of 2028x1520.
Again, implementation of binning and auto having resolution would solve this problem

Great, now all we need is to adjust the driver to set the correct modes per sensor to achieve this.

So I got a baby in house now, so no time for astronomy , but my only true test with rpi hiq camera, this is only 50 minutes (15x200) on 60/330. So capable cheap device. 


 

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: