Here is one more result Helix nebula on 60/330 apo:
Screenshot-404.png
200s gain 12 and I think gain 16 not binned one(but I do not see difference between 12 and 16.
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
Read More...
Thanks Tomas.
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).
Screenshot-403.png
Read More...
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
Screenshot-20210928-225752-01.jpg
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.
Read More...
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 dont have Gtest.
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.
Read More...
I managed to get binning working with this driver. Beside better sensitivity binning achieves lower download speed that is now around 1s.
Binning is set by changing sensor mode. There are 4 modes, but actually only mode 2 is useful here as it is full res 2x2 binning. Also there is no separate vertical or horizontal binning. I had to make few more little changes here as well to make this working.
Here is difference in non properly focused countertop of my kitchen:
Screenshot-12.png
I did not make pull request as I have no idea how to make this binning to take value from UI so you have to rebuild every time if you want to change binning.
Here is git diff if someone wants to try:
diff --git a/indi-rpicam/mmalcamera.cpp b/indi-rpicam/mmalcamera.cpp
index bbc36f1..2175bc2 100644
--- a/indi-rpicam/mmalcamera.cpp
+++ b/indi-rpicam/mmalcamera.cpp
@@ -38,7 +38,7 @@ MMALCamera::MMALCamera(int n) : MMALComponent(MMAL_COMPONENT_DEFAULT_CAMERA), ca
getSensorInfo();
- selectSensorConfig(0 /* What ever 0 means */);
+ selectSensorConfig(2 /* What ever 0 means */);
configureCamera();
diff --git a/indi-rpicam/mmaldriver.cpp b/indi-rpicam/mmaldriver.cpp
index fbb1804..2adf7c2 100644
--- a/indi-rpicam/mmaldriver.cpp
+++ b/indi-rpicam/mmaldriver.cpp
@@ -67,13 +67,13 @@ void MMALDriver::assert_framebuffer(INDI::CCDChip *ccd)
{
LOGF_DEBUG("%s()", __FUNCTION__);
int nbuf = (ccd->getXRes() * ccd->getYRes() * (ccd->getBPP() / 8));
- int expected = 4056 * 3040 * 2;
+ /* int expected = 4056 * 3040 * 2;
if (nbuf != expected)
{
LOGF_DEBUG("%s: frame buffer size set to %d", __FUNCTION__, nbuf);
LOGF_ERROR("%s: Wrong size of framebuffer: %d, expected %d", __FUNCTION__, nbuf, expected);
exit(1);
- }
+ }*/
LOGF_DEBUG("%s: frame buffer size set to %d", __FUNCTION__, nbuf);
}
diff --git a/indi-rpicam/raw12tobayer16pipeline.cpp b/indi-rpicam/raw12tobayer16pipeline.cpp
index f78f697..6438494 100644
--- a/indi-rpicam/raw12tobayer16pipeline.cpp
+++ b/indi-rpicam/raw12tobayer16pipeline.cpp
@@ -59,9 +59,9 @@ void Raw12ToBayer16Pipeline::data_received(uint8_t *data, uint32_t length)
{
uint8_t byte;
- assert(bcm_pipe->header.omx_data.raw_width == 6112);
- assert(ccd->getXRes() == 4056);
- assert(ccd->getYRes() == 3040);
+// assert(bcm_pipe->header.omx_data.raw_width == 6112);
+// assert(ccd->getXRes() == 4056);
+// assert(ccd->getYRes() == 3040);
int maxX = ccd->getSubW();
int maxY = ccd->getSubH();Read More...
Hi Colin,
Yea, I was actually trying to reply to post from previous page but forum does not. work well woth quotes in mobile so I used just quick reply and post seems out of. contex.
I use exactly that driver that you linked and it works almost as good for me as I would expect only issue is extremely low native exposure of cam itself so. it basically it cannot be called astronomy camera.
Read More...
I have SV105 and using V4L2 driver it works good, but I bought better cable. Rarely freezes, but it is not so sensitive and 0.5s max exposure time is disaster. Also for my version you have to set Gain to 67, because in 68 it goes back to 0 amd 100 is around 40 actually and 67 is 100.
Read More...
I was going through the code and noticed this part with comment :
selectSensorConfig(0 /* What ever 0 means */);
That is actually binning mode, as per documentation:
Screenshot-20210920-231444-01.jpg
Just to note this is for high quality camera, different modes are for different cameras.
Also interesting thing is that zero is "Automatic" but explenation of that part is missing from documentation except this note for all cameras:
Anything output res below 1296 x 976 will use the 2 x 2 binned mode.
If automatic works then setting resolution to half should activate binning automatically, but I am not sure how to test that. Maybe by picturing fixed long distance target(lamp) with different resolutions but same exposure?
Also I am unable to build and test this mode by changing modes "selectSensorConfig" could someone try to change that and try?
Read More...
Probably yes, but blind solve is much better than no solve at all.
I always use sync option and I see if solve is near my target.
Also internal solver does not work at all, but I do not care too much as online is working.
Read More...
My sir, you are a genius! Solving as baby both internal. and online(online little better)
Inwas going mad already 
Read More...
I do not agree with that.
You can easily disable that by running a script you mentioned(I created startup.sh script that runs few commands that I run before ekos), and sometimes you do not want that disabled, as I am using this camera for plate solving, I want noise to be reduced so I enable DPC.
Also as this is root command it would require entering password every time you start indi, it does not make sense.
I think most important feature needed is implementation of binning, further speeding up of download(binning would help there as well)
Also i have a weird bug, I first have to take 10 s exposure that takes 5 seconds, and then i have to take 15s to enable long exposures. If I do not do that, every exposure is locked at 5s for some reason.
I think Lars is too busy now to make any changes on code of rpi camera.
Read More...