I’ve been testing the Inno-maker IMX462 camera for several experiments over a period of multiple years. It’s a sensor targeted for low light conditions, offered at a low price, and given those features I found that it’s a valuable alternative to the stock Raspberry Pi cams. I also found the image quality sometimes is lacking especially when using it in the low-light conditions where it should actually excel. I’ve dived into some of the details on how we can improve the image quality and found some nice tricks along the way. Recently I decided to ask the manufacturer if they were aware and if they would revision their product in the future. You never know right… But as it turned out, Inno-maker was already aware of some of the issues that I found and actually they already did have a new revision out there. To quote their words:
Thank you very much for the detailed explanation provided in your blog. We truly appreciate the effort you put into documenting your findings. May I know roughly when you purchased our IMX462 camera module? We already solved this issue around the middle of last year by replacing the LDO. The older versions indeed had this problem.
My camera board is bought in 2023 so unfortunately I’m using on of those affected boards. Inno-maker was kind enough to send the newer revision board in order to compare it to the older one. So here I am again, testing the image quality of the Inno-maker IMX462, but this time using the latest revision with LDO fixes.
Left: Inno-maker IMX462 old rev (modified), right: new revLeft: Inno-maker IMX462 new rev, right: old rev (modified)
The tests are as following. I started comparing with the stock lens which contains an IR filter, and then took several pictures with different kind of exposure times (10ms, 100ms, 1s, 10s) and different kind of gain settings (0, 49, 98). I can added an IR light source (3 IR LEDs) and repeated the same process. Afterwards I swapped the stock lens with one where I’ve removed the IR filter from, and redid all once again.
All pictures were taken in Low Conversion Gain mode, which is the default in the linux kernel. Next I’ll share the pictures as I’ve obtained them, no image editing has been done (not even rotation).
stock lens with IR filter, no IR leds
shutter 10ms – gain 0shutter 10ms – gain 49shutter 10ms – gain 98shutter 100ms – gain 0shutter 100ms – gain 49shutter 100ms – gain 98shutter 1s – gain 0shutter 1s – gain 49shutter 1s – gain 98shutter 10s – gain 0shutter 10s – gain 49shutter 10s – gain 98
stock lens with IR filter + IR leds
shutter 10ms – gain 0shutter 10ms – gain 49shutter 10ms – gain 98shutter 100ms – gain 0shutter 100ms – gain 49shutter 100ms – gain 98shutter 1s – gain 0shutter 1s – gain 49shutter 1s – gain 98shutter 10s – gain 0shu tter10s – gain 49shutter 10s – gain 98
modified lens without IR filter, no IR leds
shutter 10ms – gain 0shutter 10ms – gain 49shutter 10ms – gain 98shutter 100ms – gain 0shutter 100ms – gain 49shutter 100ms – gain 98shutter 1s – gain 0shutter 1s – gain 49shutter 1s – gain 98shutter 10s – gain 0shutter 10s – gain 49shutter 10s – gain 98
modified lens without IR filter + IR leds
shutter 10ms – gain 0shutter 10ms – gain 49shutter 10ms – gain 98shutter 100ms – gain 0shutter 100ms – gain 49shutter 100ms – gain 98shutter 1s – gain 0shutter 1s – gain 49shutter 1s – gain 98shutter 10s – gain 0shutter 10s – gain 49shutter 10s – gain 98
analyses
First things first, simple physics do apply here:
increasing the exposure time helps in capturing details in low light conditions
increasing gain helps in low light condition when you want to restrict the exposure time, but brings lower quality images as a result due to noise
That being said, as you notice the pictures turn out a bit red-ish. This is due to the PI its power LED being roughly the only source of light directly pointed to the target background in a completely dark room. This assumption gets confirmed as soon as I switch on the IR LEDs. The latter easily outshines the power LED. The IR light appears a bit white-ish compared to the reds from the power source. We see this confirmed for the 10s exposure shots with the stock lens (with IR filter), when you compare the pictures with or without IR led. The images are still unedited, except for rotation.
left: IR LEDs + power LED active, right: only power LED (10s shutter – gain 49)
But the impact is huge when we repeat that shot without IR filter.
left: IR LEDs + power LED active, right: only power LED (10s shutter – gain 49)
The change in overall brightness is so huge that the image even gets over-exposured! So if you’re looking into nightly security applications I highly recommend removing the IR filter plus adding a IR light source as it will allow to capture dramatically more details! It even allows us to set the shutter to 100ms and still see details in the room’s background, which when repeated for the other LED/filter combination is simply not possible.
But the most important question here is: how is the quality when we start increasing the gain. Let’s widen the image up for some detail:
shutter 10s – gain 98 – stock lens – no IR light source (only power LED) – LCG mode
At those high gain settings it’s perfectly natural that we get noise added to our image. But what I find important here is that we see no banding at all. Okay, you may say there the most left side of the picture is a lot less bright than the right side, but that’s due to the power LED being blocked by that clamp that holds everything in place. It’s just shadow casted over the background, but it does indeed looks it bit weird this way. Now remember one of the picture I took in the past, with IMX462 from the first batch…
IMX462 v1 – shutter 100ms – gain 98 – modified lens – IR light source (only power LED) – LCG mode
And compare that with the same image lens, IR source, exposure and gain settings on the PI 2 that I’m currently using for the current tests:
IMX462 v2 – shutter 100ms – gain 98 – modified lens – IR light source (only power LED) – LCG mode
Although the lightning setup may differ over the tests back than and now, what’s important here is that we don’t see any of those banding issues here anymore!
Is Wifi impacting the analog picture quality? Let’s test:
shutter 10s – gain 98 – stock lens – no IR light source (only power LED) – LCG mode
Again the lighting may have been slightly different to previous tests, like the standby LED of a new device in that room, but in general we again see that there is no banding at all, even with the gain at its maximum level.
Conclusive thoughts
Left: Inno-maker IMX462 new rev, right: old rev (modified)
As it turns out, the Inno-maker IMX462 has become an even better alternative for lowres Raspberry Pi cameras, specially outperforming the Pi cams in low light conditions. It offers good value for superior night sight, and now with the new revision some of the pains of the first revision has been tackled. So if you’re still looking for a good bang-for-back security sensor, the Inno-maker IMX462 may be your board of choice.
Already more than a year ago I started exploring astrohotography. Even lacking much experience with image sensors I started diving into building a DIY solution using the Inno-maker IMX462. It’s a rather cheap sensor that can easily be bought on Amazon, and compared to the Raspberry Pi branded cams should offer much higher sensitivity in low-light conditions due to the STARVIS technology.
Inno-maker IMX462
I remember the first outdoor shots were kind of OK’ish, but I wasn’t entirely satisfied either… Here is a shot of the Orion nebula:
Once we start zooming in we can easily spot that the picture quality is far from perfect. There is lots of horizontal banding noise:
Horizontal Banding Noise (hbn) clearly visible in the RAW image
I red that noise is to be expected when using the raw camera output. But I also found, for instance in this example, that you had to make your “dark frames” which are fed into a noise reduction function to filter out most of the sensor noise.
Left: with dark frame subtracted, right: without. Image courtesy of star-surfing.com
This dark frame is essential for improving image quality. It’s basically taking a picture with the camera covered up, using the same settings as your “light frames (= your normal pictures). The dark frame will contain nothing but the sensor noise. This info can than be subtracted from the light frames, and as a result the noise will be largely removed in the final outcome. I tested this and yes, that works quite good…
So I concluded that this is the maximum quality we can get from the Inno-maker IMX462 sensor and that we really need to be looking at longer exposure times. For plain outdoor shots a 10-15s shutter time may work, but when taking shots through the telescopes the shutter time has to be drastically reduced as the earth’s rotation is now also magnified and therefore the objects as seen through the telescope move rapidly across the telescope’s field-of-view. What I needed was good tracking to compensate Earth’s rotation. I gave up on the telescope for now as tracked telescopes are rather expensive and instead started looking into building a cheap star tracker combined with the default Inno-maker lens which should allow my to make many 10s shots which can than be stacked together. I’d loose the zoom of the telescopes, but instead I was hoping for very detailed shots of the entire night sky.
When the summer came most of the astro stuff was put to a rest, but now that winter is nearly there I finally picked up again and that’s when I came across some stories about improving the image quality through some modifications. There was the High Conversion Gain (HCG) software mod that I discussed earlier, but there is also this correlation of power supply noise and image quality. So that got me questioning if maybe there are some more gains to make. It could indeed be yet another way of performing noise reduction (aside of creating “dark frames” and HCG), and as an hardware enthusiast I couldn’t help myself investigating this a bit more.
Power supply noise
So how did I bump into this? Well it started when I was looking around if any new STARVIS sensors would have been released over the past couple of months. I ended looking again at the StarlightEye, an open-source camera board that utilizes the IMX585 sensor. Picture below.
StartlightEye by will127534
It’s one of the very few boards out there that features the new STARVIS2 technology, which makes the sensor even more sensitive than the IMX462 that I own. I looked around on the issues that were reported for this camera board, and that’s when I stumbled upon an issue complaining about horizontal banding: IMX585 Power – Horizontal banding and 3.3V power rail noise.
The creator of the ticket, Bob Morrison, was also noticing a horizontal banding issue during his tests with higher gain values:
IMX585 horizontal banding on StartlightEye v1
He got very dramatic results, even more banding than what I saw. Bob states that the STARVIS sensors are very sensitive to noise, even though the STARVIS sensors are in fact designed to work in low light condition. This is where they normally should stand out, and I have to agree with him there! He mentions testing on a Raspberry Pi 5. The 3V3 supply may not be up to the task. In some other thread on the Raspberry Pi forums we actually got a confirmation by 6by9 (an official RPI engineer) that the PMIC (the power supply of the RPI) was also generating a bit of noise on their GS (global shutter) camera. At least for me it seems the older Raspberry Pi boards may also be affected.
Bob his idea is the following:
I haven’t put an oscilloscope on the supply rail, but I think what is going on (just from watching the current output on my benchtop supply, now supplying the camera board) is at high gain the sensor photocell amplifiers demand a sudden big step up in current at the end of each exposure as the image data is read out, amplified, A/D converted and shoveled to the MIPI interface. My guess is the Pi’s rail briefly rings in response, and the ring wrecks the performance of the on-sensor amps.
And finally his solution was to isolate the camera board from the Pi’s 3V3 rail, and powering the sensor through a linear 3.3 volt bench-top power supply.
The Github issue goes on with the creator of the camera board, will127534, confirming that he noticed the same issue on his RPI5 device and V1.0 of the camera board. After some trial and error Will finally fixed the issue in version v1.6 by rolling out his own 3V3 power supply on the camera board. We will dive into details later on. Surprisingly this version was released only 2 weeks ago at the beginning of October 2024, many months after the initial complaint. Yet in the end Will did a very good job designing this sensor board, plus also taking up the task of improving the design to fix the banding issues. The product is a bit too pricey for me, if he would have had a € 50 STARVIS board up for sale I may have picked it up.
Now looking back at the Raspberry Pi forums thread I referred earlier, the complaint is very similar. It’s even using the same Inno-maker IMX462 sensor as I have, but while I have had it attached to RPI 1, 2 and 3, Mat had it attached to a Pi4. Mat tested different RPI OS versions, and different device tree configs, even rebuilding libcamera from source, but nothing would help. What’s nice is that Mat also had the option to compare against other sensors like the RPI HQ-cam and the GS-cam which didn’t had the issue. Sohonomura2020, one of the forum visitors, also responded in the thread stating that the power regulation and filtering has to be very carefully designed as any fluctuation in analog VDD is easily noticed at higher gain values. And as being someone designing and selling his own custom Raspberry Pi camera boards he may know at least some of the pitfalls.
Low noise power regulatotors
Before we dive into how power is sourced in the IMX462, let’s first quickly comprehend what we expect from a good low noise power regulator. In essence there are 2 types of power regulators. Linear regulators and switching regulators. Switchers have become very popular last few decades as compared to linear regulators they allow very efficient power regulation with less power loss in the FETs and thus less colling is required plus higher power outputs can be achieved. Sounds all very nice, but the downside of all that switching is that the output level contains quite a bit of noise, even though filtering is applied. For conventional electronics the small ripple doesn’t play an important role since all communication is digital anyway, but for analog circuits such as ADCs this may be a real show stopper.
Linear regulators however are far better in producing low noise power, but instead are not very efficient and produce a lot of heat when supplying “high” amounts of heat. Typically you’ll find that the regulator, if it has to drop for example from a 5V imput voltage to a steady 3V3 (thus a 1.7V drop), that at supplying 1A it would use 1.7V * 1A = 1.7W. Look on the internet for resistors that can handle 2W and you’ll quickly notice that is a lot of heat to handle! Linear regulators go back many decades and typically require a minimum drop voltage to you need to take into account when designing your product as the regulator will not allow any lower. For example some will not be able to drop less then 0.7V, and thus if you start from a 3V3 input voltage the output voltage will not ever reach higher than 2V6. Nowadays we do have “low dropout” variants, typically referred to as LDO‘s, which feature lower dropout voltage so that for example at the same 3V3 input a 3V output can be achieved. Further more, the higher quality linear regulators will also come a feature called PSRR. Power Supply Rejection Ratio (PSRR) is the ability of an amplifier to maintain its output voltage as its DC power-supply voltage is varied. In effect input ripply will be rejected by the fast response time of the LDO. So this is exactly the type of power regulator that we want.
Let’s try to get a better understanding on what parts are actually involved on our IMX462 and Raspberry Pi boards.
Main powering circuit: the MIPI-CSI cable
Many camera boards such as the Inno-maker IMX462 are powered directly through the MIPI interface, meaning the camera board doesn’t have an additional 5V power connector. Here is the pinout again for that interface, taken from the RPI3 B+ schematics:
The 3V3 power circuit on Inno-maker IMX462
Below is a shot of the back side of the Inno-maker IMX462. I admit it’s not the greatest shot…
Small intermezzo: the bigger in metal wrapped chip is the clock oscillator for the image sensor. You must configure your linux device tree with the output frequency of this chip. In our case it’s a 74.25 MHz clock source.
More in our interest are the power regulators though. At the top side of my picture we find a bunch of small lineair regulators directly connected to the 3V3 pin on the MIPI-CSI connector. From left to right:
YJAA (SGM2019) : adjustable 300mA low dropout linear regulator, probable set to 2.9V
YJ12 (SGM2019) : fixed 300mA 1.2V low dropout linear regulator
4VK4 (LN1134) : fixed 300mA 1.8V low dropout linear regulator
In a nutshell this is how the sensor is wired up:
Sony doesn’t open source their camera sensors datasheets so I can’t tell the very details of how every pin should be routed. However, I found a design of an open source IMX290 USB3.0 camera which can be used as a reference because the IMX290 is roughly the same chip as the IMX462. Let’s look for a power pins:
Basically the chip is powered from 3 main power sources being 1V2, 1V8 and 2V9. The VDDHAN / VSSHAN pins are for analog power, and those are wired up to the 2V9 power source. And it is the analog circuit existing of the analog-digital converters that convert light into digital data that is powered through this power source. A good VDDHAN is therefore crucial in the ADC phase of our image pipeline. So the most interesting regulator from the list mentioned earlier is the one marked with YJAA. It’s the adjustable version of the SGM2019, with it’s output set to 2.9V via a resistor divider. The chip is widely available, but it does not seem to be particularly know to the audiophiles out there who are (also) keen on low noise regulators. Still, according to the datasheet this SGM2019 is a low-noise high PSRR regulator though and should actually be a fairly decent candidate for powering the analog ADCs of the image sensor.
The 3V3 power rail on Raspberry Pi
After having a look at the camera board we can starting tracing in the direction of the source. It does come with a notice that the power regulator for the Raspberry Pi may be different across the various versions of the Pi, even for minor releases.
The PAM2306 is a dual step-down buck converter capable of delivering 1A per channel. The same PMIC is also found for Raspberry Pi 1 (A+ and B+), Raspberry Pi 2 (all), Raspberry Pi 3 (model B only), Raspberry Pi Zero (all). The 3V3 rail is delivered by output channel 1. Additionally there is also a 3V3A rail specially designed for the analog audio, and can be found through the AUD_3V3 label. The reduced schematics however don’t show which regulator is responsible for this power. But I don’t think it may interest us either as it is probable a very low power regulator, plus there are also some complaints about analog audio quality so I guess it’s not free of noise either.
Other boards such as the Raspberry Pi 3B+ or the Raspberry Pi 4 may have a different PMIC. Tracing the 3V3 label on the Pi4 we see that the supply is originating from the XR77004 regulator:
XR77004 PMIC on Raspberry Pi 4
THe XR77004 PMIC is a mysterious chip. Not a lot of info is available if you look up this exact number. On its basis it is in fact a MaxLinear MxL7704-R3 chip which features 4 Buck converters that each output a different voltage rail. The chip is programmable through I2C, and hence allows to be tweaked for the specific use case of the Raspberry Pi, but also enabled overvolting the ARM chip for overclocking purposes. Regarding the output rails, VOUT1 (Buck 1) is the one supplying the 3V3 and it can deliver up to 1.5A of current. But, I don’t know if you noticed it in the above schematic, there is also a dedicated “analog 3V3” (marked as 3V3A) on the Raspberry Pi which also comes from the PMIC. This volt rail is produced by an extra internal 100mA LDO. The Raspberry Pi only uses it for analog audio and the regulator is certainly not strong enough to additionally support camera boards.
What others have done
Although our IMX462 boards looks rather empty on the back, it does use the lineair regulators that we want for less noisy power. During my search I stumbled upon a Texas Instruments camera boards called the TIDA-020003. It’s a reference design for automotive 2MP cameras and it uses the TI TPS650330-Q1 power regulator. This PMIC is specifically designed with automotive sensors in mind as aside of a couple of high efficient buck converters it also comes with a LDO regulator specifically for feeding the analog circuits of the image sensor. Some specs of this LDO:
VIN range from 2.5 V to 5.5 V
VOUT range from 1.8 V to 3.3 V
Low noise and high PSRR (Power Supply Rejection Ratio)
Adjustable output voltage through I2C
Up to 300-mA output current
The interesting specs here are ‘low noise’ and ‘high PSRR’. The PSRR is the ability of the LDO to maintain its output voltage.
This is also a LDO for up to 300mA. There is no mention of it being low noise or high in PSRR. Small side-note here: be aware of re-creating this open-source project yourselves. There have been lots of complains about the open-sourced materials, where some are stating that it is better to start all over from scratch. A lot of comments have also been removed from the comments section, so be skeptical about that.
Then there is the StarlightEye open source camera board that I already mentioned earlier. They moved away from powering the camera board via the 3V3 from the CSI2 connector, but instead added a 5V connector. The 5V is first regulated by the TPSM82821 step-down converter, and finally the analog 3V3 (apparently the IMX585 uses 3V3 for its analog ADCs) is created by the TPS7A90. The latter is again a LDO, 500mA, low noise, high PSRR.
Selecting an LDO linear regulator
The way forward is clearly placing a better power regulator somewhere along the way to the 2V9 analog pins of the IMX462 sensor. I was hesitation a lot between selecting either the LT3042 from Linear or the TPS7A90 from TI. The LT3042 has been discussed in various audio forums, however the TPS7A90 was also introduced as being a succes for the StarlightEye cam. Finally I found these cheap Chinese made CJMCU-3042 boards on Alibaba featuring the LT3042 so I just ordered a pair for experimenting with, as I was hoping that in the end it wouldn’t make of a difference. Both are high performance low-dropout high PSRR linear voltage regulators with a Vrms down to few millivolts.
CJMCU-3042
Measuring noise
Wait, before we start modding, can’t we measure the noise? After all it’s just voltage going up and down. It would be a nice way to compare the mods on an engineering level. Well, indeed, but to perform good noise measurements you got to own expensive equipment which I currently don’t own. So I have to disappoint here, though for those interested here is a video of noise measurements performed on the LT3042 regulator that I selected for my experiments.
Using the CJMCU-3042 board
Ok, let’s dive into what the CJMCU-3042 board has to offer. There is no off the shelve manual for these boards, or not that I could find. Lucky me though, as a guy named Carlmart already made an overview on the DIYAudio forums of what components are used in this little board.
So from what I understand is that the Chinese manufacturer took the reference design from the datasheet and put that into practice. So basically if you connect 5V to the input pins, you get 3V3 at the output. And indeed, I hooked it up and that’s exactly what we get. The board does not tie the EN/UV and PGFB pins to the IN pin as it shows on the ref design. Instead it leaves you with the option of choosing how you want to integrate these pins. For our application however it doesn’t matter much and we can tie them together manually by doing some soldering. Power tested: we’re ready for IMX462 modification!
2V9 mod: replace SGM2019 with LT3042
MY plan of attack started with replacing the SGM2019 (marked YJAA) that’s used for the 2V9 with one of these CJMCU-3042 boards. To reduce the dropout voltage (and therefore heat output) we will power the CJMCU-3042 board from the 3V3 rail of the Raspberry Pi. After doing so the board produces around 3V which is slightly too high for the analog circuits. Maybe it does work, but I’m not planning to take any risks here. So I modified the LT3042 board to get 2V9 instead. To do so:
replace 33K2 resistor (R6) which is marked blue in one of the above pictures with a 28K650 resistor (and power the board from 3v3). It’s not an off the shelve resistor value, but you can get close by combining few resistors.
To put this board in place of the SGM2019 we should have a look at how this chip it’s pins are layed out:
The OUT pins is the one that produces the 2V9. We should disconnect this pin and hook our LT3042 to the sensor board instead on this location. On the Inno-maker IMX462 sensor board the YJAA can be found near the side of the sensor. Cut the pin as shown in the picture below:
Now let’s hookup the CJMCU-3042:
Don’t mind the extra LEDs board. It’s just there to perform experiments in totally dark scenes. Here is a shot of the back:
And one from the camera board:
And here is the first result. I used a 100ms exposure with gain maximized so that banding would be at its worse.
shutter 100ms, gain 29.4dB, LCG mode, LT3042 power regulator
PS: don’t mind the vertical band, it’s not a sensor issue but instead due to running a bugged linux kernel. Here is what it looked like before the mod:
shutter 100ms, gain 29.4dB, LCG mode, YJAA power regulator
The outcome is a dramatic change, but also a bit of a double edged sword… I succeeded in removing the horizontal banding, so that’s really nice, but as a side effect a lot more noise has been introduced! I wasn’t really hoping to face new side effects… So I thought that maybe the wires that feed the 2V9 to the sensor board are a bit too long so I reduced the power path by actually mounting the CJMCU-3042 board onto the camera board:
Plus, as said, the bug in linux kernel also caused visual artifacts. So one of the RPI engineers fixed the bugged kernel, I updated to this one and I performed again the same test as earlier.
shutter 100ms, gain 29.4dB, LCG mode, LT3042 power regulator
And finally it seems that I made a step forward. The banding is gone and due to the non bugged kernel the vertical artifact is also gone which helps to slightly improve image quality. Nice!
… but not yet entirely noise free… I wonder, is there more to gain?
3V3 mod: replace RPI switching regulator with LT3042
I thought of the possibility that some small ripple is still getting through somehow producing some extra noise on the ADCs. At least it could not be because of heat since we actually moved the power regulator further away. So I though that perhaps I should reconnect the YJAA regulator again as it was originally, and then use the LT3042 for powering the entire sensor board. Hereby replacing the RPI 3V3 switching regulator with a linear regulator, though this linear regulator would still be powered from the 5V switching regulator if the PI. The YJAA would than take the already well regulated power from the LT3042 which would have than already filtered the banding away. One way to do so is to cut away the 3V3 that comes through the MIPI-CSI2 port. However I’m not sure that the LT3042 is powerful enough to power the entire camera boad. After all it’s limited to 250mA which is still not a lot at 3V3. Another thought was to only replace the 3V3 that goes to the YJAA regulator. One could cut loose the YJAA IN and EN pins, and hookup the CJMCU-3042 board (which produces 3V3 from a 5V power source). Even easier, at least with the mods in it’s current state, would be to power the CJMCU-3042 board that provides 2V9 with a second CJMCU-3042 board (remember I had bought 2) that provides the 3V3 from the Pi’s 5V. That should be feasible!
2x CJMCU-3042
Auwch! That’s NOT what I expected! The sensor is having some serious issues, and I hope it didn’t get damaged along the way! I quickly reverted this modification and checked again, luckily all went back working as expected. What a relief!
3V3 mod: ELCO filtering
One other thing I could easily try is to add an additional Electrolytic Condensor (ELCO) that helps stabilizing the 3V3 power rail that goes into our CJMCU-3042 board. I took my box of de-soldered hardware and found this 6V3 820uF ELCO that used to serve in a computer mainboard. I placed the ELCO on the input pins of the CJMCU-3042.
And the result:
shutter 100ms, gain 29.4dB, LCG mode, LT3042 power regulator + 3V3 ELCO
Nothing spectacular if you ask me. There is still a lot of visible noise in the picture, but I guess we should be OK with that since actually we’re maximizing the analog gain here. I would swear there is maybe a little bit less noise in this one compared to not the picture without the ELCO. But maybe that’s just me. At least the quality didn’t get worse either so I’d recommend adding the ELCO if you have a spare one around.
Final test
And now a final picture with HCG enabled, the CJMCU-3042 in place for delivering 2V9 analog power and an ELCO on the 3V3. By setting gain to 98 (29.4dB) plus having High Conversion Gain enabled we test the maximum analog sensitivity:
shutter 100ms, gain 29.4dB, HCG mode, LT3042 power regulator + 3V3 ELCO
Now let’s compare again against our first test on gain 98:
shutter 100ms, gain 29.4dB, LCG mode, YJAA power regulator
Comparing those we can say that:
we solved the banding issue
the sensor has become even more sensitive, allowing more detail in dark scenes
overall picture quality improved
Conclusive thoughts
As proven in this article we can easily improve image quality on the Inno-maker IMX462 by replacing the analog power circuit with a better one. It’s a mod that I would easily recommend to anyone who’s looking into using higher gain values. But who is to blame here? I guess that camera boards vendors should not solely rely on the carrier boards for delivering proper and clean 3V3 power. It may be true for custom embedded products, but my assumption now is that many maker boards out there (like RPI) don’t focus that much on it. The other way around you could also say that when those DIY boards features a MIPI-CSI interface, it should also care about clean analog power for those camera devices. Then again, we’re only talking about very narrow use cases like astro-photography and taking shots of the night scenery. I guess it’s hard to blame anyone in this situation, so let’s not point any fingers here. Instead it’s important that you as a system builder are well aware of what a good camera is build of. So when your product is build for using high gain camera settings, you should make sure the analog power to the camera sensor is of good quality instead of introducing noise on the sensor’s ADCs.
Update September 2025
After being in contact with the Inno-maker support team it appears that they are aware of the situation and already provided a fix. To quote their words:
We already solved this issue around the middle of last year by replacing the LDO. The older versions indeed had this problem.
My module was bought in 2023 so that explains why it has those visual artifacts. I haven’t tested yet with the newer revision though, so if anyone has some feedback on that please add your comments to this article.
after hours coding 