Why should you buy dedicated astronomy camera, and not to try to invent your own

[Vulisha]

I want to share my story with you how I decided to create my own astronomy camera.

Disclaimer: typing on phone so expect typos!  

Disclaimer#2: big block of boring text, you can simply jump to conclusion on the end. 

 

How it started! 

It all started with me not liking to pay for a sensor and even more SoC that will be outdated when I can buy only sensor and plug it in my own SoC, and then change sensor as I please or need. Best cameras now have 256 or 512MB of ram, while RaspberryPi has 1GB up to 8GB. Jackpot isn't it? No, it is not! 

So my journey started with buying Rpi 3B+(~50usd) and V1 camera, just to test will it work, as that camera is few dolars. I was able to connect it to indi and get image. That was enough for starters and then I decided to order RPI High Quality camera with IMX477(50gbp+25%tax).

RaspberryPi HQ Camera 

Initially Linux V4L2 for HQ Camera do not work as expected. There are no gain or shutter speed controls. Luckly there are dedicated INDI drivers for RPi HQ Camera. Unfortunately I spent days to decipher how to enable "long exposure mode" It is done by capturing first image of 10s and second of 15s. RpiHQCam can take 230s exposure and that is not half that bad and can capture decent astrophotography images. Cam has small pixels, has a lot of read noise, and too high resolution for guiding. So I had to modify drivers to add binning and for guiding, it is not bad, works, it has small delay(1-2s) for download but usable, and more than enough sensitive. 

Dead Rpi... 

Then my RPI died and I had to buy new one, during shortage, Pi 4b 1gb(60 eur + power 15 eur). 

Planet season! 

Then the planet season came, and problems came as well. Indi driver does not support streaming, so no luck in high speed imaging using INDI but never mind I can use console! 

There are two implementations of drivers for HQ Cam, legacy that is used by INDI and focuses on gpu, and Libcamera, that focuses on cpu. But bith of them use kernel driver that has only 4 modes fullress at 10fps, 2x binned at 40 and 50fps, and 4x binned at 120fps. 120fps is more than fine, but 4xbinned is not good. Driver does not support Analog crop, so changing region of interes and resolution does not effect FPS at all. So me being software developer I decided to rewrite kernel drivers. 

I am software developer! 

So I planned to add Analog crop and dynamic FPS that will increase based on resolution. I will not bore you with details at this part, but I failed miserably. Almost all of the registers are locked under Sony NDA, and I tried to reverse engineer thst stuff but it is a no, if you cannot get documents under NDA, just forget about it. You can be greatest developer, let alone me, no luck there. Rpi engineers have this in mind, but reluctant to confirm they will implement it. 

Arducam to the rescue

I heard about Arducam and I saw they have IMX462, great little chip. So. I ordered that as well, 50USD+25%tax.

And ended up limited there as well it has only single mode 60fps at fullhd. ROI is not implemented, neither are other modes. As Arducam can do something per request I asked them to add 720p at 120fps unbinned. They responded that minimum order quantity is 1000 chips for that change 

Then I discovered that IMX290 and IMX462 have same registers, but max implementation is again fixed 60fps.

Settle as 60 fps

OK fine, I will settle with 60FPS, not so bad right? Indeed not so bad. I decided to go with that. As Arducam supports only newest RPI OS Bullseye my Astroberry is not supported so I needed separate raspberry pi. So I bought another one, 8gb version(100 eur), shortage, only model available. 

Next issue I had was saving speed and my sd card was not fast enough. So I bought SSD(40eur) and USB 3.0 dock(10eur) that doesn't work at USB 3.0 port on Rpi if you use wifi. Something with cable and interference so I plugged it to usb 2.0.

Start to record! 

There are two modes to record raw using console. Libcamera-raw, where you have to know bayer matrix, and libcamera-vid - -codec yuv420 where ffmpeg converts video to something usable. Unfortunately arducam has bug with yuv420 unable to convert it, while same procedure for imx477 works perfecy, and no one responds on my issue reported so first night of imaging can go to trash. Second day of imaging using raw, also can go to trash as I have failed to convert it to something usefull, no one from arducam responds. 

How about long exposure 

Arducam IMX462 is limited at 15s long exposure, so.... anyone wants to buy IMX462?

Ending costs

Rpi3b+, Rpi4b1gb, Rpi4b8gb, Imx477, Imx462, ssd and dock roughly sums up to 450 eur with taxes. Player One Mars II costs ~250 eur with taxes(there was a sale) , can take 2000s long exposure, goes over 200 fps, and I think it has passive cooling(or that is next one) . 

Additional hardware limitations 

Now even more boring part.

You are not only limited with software. You are limited by hardware as well. Rapsberry Pi has two MIPI CSI-2 Lanes available for camera, that is roughly 2GBPS that limits max speed to raw resolution multiplied by bits of mode, all in all 2gbps cannot handle fullhd at 120FPS, USB3.0 cameras have 5GBPS. This can be worked around by buying RPi CM4, that has 4 lanes for camera so 4GBPS.

 

Conclusion!

Well it could all come just to this. Even if you have good technical knowledge, and you have good will, and time you are limited by NDAs, software and hardware limitations. Save your self a trouble and just buy what needs to be bought.

Anyone wants to buy one rpi and Arducam 😂

Not to be only bearer of the bad news, these mages were captured with HQ Camera and Mak 127.

Edited September 19, 2022 by Vulisha

[Dark Raven]

There was a similar thread on this forum earlier, but I'll repeat in short. No, RpiHQCam will never come close to dedicated AP camera. Regardless good work on your part, I'm sure you learned a lot. Stacks were against you from the beginning, but before you give up all together you might want to check this blog and GitHub:
Hubble Pi — The MagPi magazine (raspberrypi.com)

GitHub - RemovedMoney326/Hubble-Pi: Documentation, Resources and Python Codes for portable Astrophotography and KStars Setup with Raspberry Pi 4 and HQ 12MP Camera Module

This guy appears to have made similar project, but not sure if he got further than you did.

Do check his documentation as well for details:
HubblePiDocumentation.pdf (hu-berlin.de)

Good luck and be sure to let us know if you make further progress.

Edited September 20, 2022 by Dark Raven

[Vulisha]

Well firstly I would like to thank you on link to that thread I will do my best to help that person. 

 

Indeed while RPi HQCamera cannot match true Astrophotography cameras of new generation, it is not at all that bad, see samples below, I will upload a few. For long exposure is quite acceptable, unfortunately for planetary imaging you are limited with NDA. I was hoping my hands would be free but they are quite in chains. It is not that sensor(s) are not capable, opensource software ended being megaclosedsource under probably million dollar NDAs. IMX462 would preform brilliant, if I had options

 

See rest of the images here: https://terramex.neocities.org/astro/index.html

Edited September 20, 2022 by Vulisha

[Dark Raven]

3 minutes ago, Vulisha said:

I will do my best to. help that guy. 

ROTFL 😂

Made my evening... I didn't scratch under the surface, just remember seeing the article in MagPi.

[Vulisha]

I mean on guy in thread on forum, not HubblePi guy, I was aware of hubble pi since I started but it did not fit to my plans. 

Edited September 20, 2022 by Vulisha

[Dark Raven]

39 minutes ago, Vulisha said:

not HubblePi guy,

After seeing your impressive galery, I'm sure you could help him too. 

Btw, off topic, what are the odds...

 

 

 

[Vulisha]

Not my gallery unfortunately, but indeed very impressive. 

I do not own Redcat or iOptron. Not that I would mind owning it