Overview
Next up is planning and selecting cameras. This is quite an interesting topic, but there’s relatively little to show, so this post will be a bit shorter, with less images.
Picking the sensor
The most straight forward starting point is to pick out the sensor we want, and then build around it, so let’s get into the important specs.
When talking about sensors, there are a few common specs everyone is familiar with. Namely, these are resolution and framerate. Interestingly, we don’t really care about either.
The dashcam setup will be severely video bandwidth limited, so we actually want the least number of pixels and framerate, to minimize how much the video encoder will chew up details.
In my quick experiments, roughly 1080p-ish resolution, at 15FPS would be a decent target to work with. That’s about 2MP. Pretty much every single modern sensor can do that, so this is not much to narrow our search by.
Now, let’s talk about the more interesting specifications. There are two that we care about a lot: low light performance, and dynamic range. Low light performance is straightforward, the car will be parked at night, the camera needs to be able to see in darkness. Dynamic range is more interesting.
Imagine trying to take a photo of a dark object with the sun in the background. This is close to impossible with a regular camera. The extreme brightness in the background requires the sensor to turn the exposure down, so that nothing is blown out. However, that also makes the dark object completely disappear. Manually exposing the dark object will result in the background being so incredibly bright, that it completely clips and just looks like a white blob.
The issue here is dynamic range. The camera cannot simultaneously capture the tiny differences in light on the dark object, while there’s a massive light source in the background.
To combat this issue, several methods exist. The sensor can be made just really really good, and have inherently great dynamic range, but that gets very challenging very quickly, so trickery is needed.
The most common method is multiple exposure HDR. The idea is to take a bunch of separate images with different exposure levels. One image will have the bright object perfectly exposed but the dark object too dark, one image will have the dark object perfectly exposed and the bright object overexposed, etc.
Then, a fancy algorithm can be used to merge all of these images into a single one, where all of the varying brightness objects are properly exposed.
This method works fairly well, and is very widespread. However, there’s one massive issue: as a single frame is constructed from multiple exposures, motion blur or ghosting can happen. If any movement happens between the individual exposures, the final image will be messed up. There are algorithms that try and correct for this, with varying results.
Ultimately, this is a no-go for my dashcam.
There are quite a few other methods to achieve high dynamic range, with various tradeoffs, but let’s jump to the one that fits my use case the best: subpixel HDR.
The idea is simple: instead of the sensor being made up of a bunch of equal pixels, let’s make multiple different sizes. The small pixels will be less sensitive to light, and the large pixels will be more sensitive. This means the sensor can take both an “underexposed” and “overexposed” image at the exact same time, preventing the motion artifacts.
There is a great article about this on e-con Systems’ website, with actual images and comparisons to multiple exposure HDR.
Going for subpixel HDR narrows down our sensor options from tens of thousands to a handful, mostly from Sony. My choice ended up being the Sony ISX031. This is a 1920x1536 30/60FPS sensor, but most importantly, it has a built-in ISP.
Image sensors don’t just magically output an image. The data needs to be processed in several ways, autoexposure and white balance need to be continuously adjusted, etc. This is an incredibly complex task, handled by an Image Signal Processor.
Developing and tuning an ISP is basically black magic, and it needs to be fine tuned to a specific sensor or use case. Typical camera modules also tend to have very bad ISPs that don’t just lack the magic, but are actively horrible.
The integrated ISP in the ISX031 solves this issue: it’s specifically made and tuned for the sensor it’s contained within. The sensor’s output is a preprocessed, beautiful, high dynamic range image, with no adjustments to worry about. It also has an LED Flicker Mitigation feature, which uses magic to make flickering LEDs not flicker on video.
The ISX031 also happens to have amazing low light performance, so it is the perfect choice for my dashcam.
The camera interface
Next up is picking what interface to use for connecting the sensor to the Compute Unit, which the previous blog post was about.
The native output interface of the sensor is MIPI. It works great, as long as you have short wires, which I don’t. Let’s see what options we have.
Stick with MIPI all the way through, and get some heavily shielded cable to make a 3 meter run work: this is the simplest solution in some ways, but the most painful in some others. MIPI-CSI requires at least 3 high speed twisted pairs for this setup, plus a handful of low speed communication signals. Signal integrity, and interference caused are a major issue with this setup.
Use a USB camera module: these modules use a MIPI to USB converter IC (or probably an entire cheapo ISP, that has most of its features turned off) to immediately convert MIPI to USB before any signal integrity issues can pop up. There are two big problems with this:
- the terrible ISP scenario is still a pain, as we will lose even the small amount of control we have over the ISX031, because the cheapo ISPs don’t properly expose controls over USB.
- USB is problematic in itself: the ISX031, in its full resolution output mode, generates over 350 megabytes per second of image data. That is around 8 times faster than what USB2.0 can do. USB3.0 can handle it just fine, but it brings its own signal integrity and noise issues, so we’re back to square one. (USB3.0 actually uses higher signaling speeds than MIPI, for this specific sensor)
Go the proper route: GMSL or FPDLink. These are the actual, reliable, proper solutions for my problem. Put a small GMSL/FPDLink serializer IC near the sensor, pipe MIPI into it, attach a coax or a single twisted pair cable, run that for as long as you need, and put a deserializer at the end to get back MIPI. The problem? Money. In single digit quantities, those two ICs cost well over 50usd. I’d also need custom PCBs, and probably spend a bunch of time debugging things. This would definitely be the proper solution, but it requires both time and money, neither of which I have at the moment.
I went searching for ISX031 camera modules, and I found the Arducam B0476. It’s a USB3.0 module with a 118 degree horizontal FOV lens. That settles our interface question, because I couldn’t find any other reasonably priced modules.
However, this camera was already quite expensive, and I needed 3 more. So, back to looking at sensors, to find a cheaper option for the rear and side cameras.
I settled on the IMX662 for this task. No fancy HDR, but good low light performance, and cheap. No need for USB3.0 either, as a lower framerate, or MJPEG encoded video output is fine from these cameras. The cheap modules, like the one I got, do suffer from a handful of cheapo ISP related issues though. The autoexposure algorithm is quite bad, there’s no denoising before MJPEG compression(which makes the video quality terrible), and the ISP only exposes a select few resolution/framerate combinations, which doesn’t include the ideal ones I’d want.
I bought 3 Arducam B0576 modules, which don’t come with an enclosure, so I designed and 3D printed some.
Conclusion
With that, all four of the cameras are ready to install. In the next post, I’ll talk about finally using Single Pair Ethernet, design and make the controller PCB for the charger box, and write some ADIN1110 code.
The final blog post will include the installation of all the cameras and other hardware, along with a demonstration of the system’s full functionality.