Waves on raspberrypi camera feed, Ground loops? electrical interference?

Question

I run a video recorder in a vehicle built on Jetson Nano (Very Similar to raspberry pi). It runs on 5V . The vehicle has a 24V power supply. I power the video recorder with an automotive-grade 24V to 5V converter.

The Jetson nano is connected with a Raspberrypi Camera with a Flat ribbon cable. When I record video, I get a wave-like noise on the video feed at random times. And if the wave appears, it appears in a 1 second interval(only from what I see, no measurements/tests done) . This is the connection diagram and voltage differences between nodes.

The ground of the Jetson board and Ground from the vehicle body are not connected, there is a potential difference of some mVs. That is what is depicted in the diagram.

The software guys working on the camera driver say this could be electrical interference. We have a similar setup in our lab environment and we are not able to reproduce the noise. We doubted the power supply, vibration, 4G LTE interference, GPS interference. The cable used to connect the camera with the board sometimes touches the HDMI/display ports of the Jetson Nano board.

Datasheet Camera : https://cdn.sparkfun.com/datasheets/Dev/RaspberryPi/ov5647_full.pdf

Sample video : Video1 Video 2 Color lines

Sometimes the lines are coloured and some times the are white

What could be different from a vehicle and the lab environment, how do I ensure the grounding is good in the vehicle. And how do I test and ensure if this is due to electrical interference? Or any other interference?

Is this caused by ground loops?

This is the convertor used, the sellers say this is non-isolated buck converter and there are isolated ones which are used in radio related devices for less noise, does this have anything to do?

Answer 1

On first thought, it does sound like the car setup is interfering. However, you can NOT say for sure if you haven't tested your "car-based" setup outside the car. Also, we do not have enough information in hand regarding the complete car setup (eg. all the devices connected to 24V and near the Jetson board) but don't despair and go through the following troubleshooting steps to determine a potential interference source yourself (it might be a long process but there is no other way).

In what follows, I am assuming that you are using a unique and fully functional video recorder that you have tested on your good Jetson lab setup, for any test on the bench and in the car.

Verify the Car-based Jetson setup in the lab

Take it out completely from the car and plug it to a 5V power wall supply in your lab. Is it working as expected?

If not, you want to identify the "bad" component: is it the camera, is it the Jetson board or is it the cable between the two? To do so, swap the two cameras along with the ribbon cable between the "car-based" and the "good working" setup and test again, does it follow the board or the camera?

If it follows the camera + ribbon cable, swap the two ribbon cables. Does it follow the camera or the cable?

Verify the 5V DC-DC converter in the lab

If you encountered no issue with the previous step, take the 5V DC-DC converter out of the car and plug it in a 24V power wall supply. Plug the "car-based" Jetson setup to the converter and test again. Is it working as expected?

If not, you may want to look at why is the 5V DC-DC converter interfering with your setup.

• If you have a second DC-DC converter, swap it. Does it give you a better result?
• Are the Jetson and DC-DC converter well-grounded together?
• Any noticeable spikes on the output?

Identify the interference source in the car

You have verified that your "car-based" setup is working great out of the car, this is already great news! Install it back in the car for the next step.

Now comes the hardest part which is to identify the noise source in the car. For this, you'll need to be able to turn ON and OFF (or plug to/unplug from power), one by one, all the possible devices connected to the 24V power feed and any device in proximity of the Jetson, camera and 5V DC-DC converter.

Hopefully, when a device is off, you'll notice an improvement or degradation. Note this down and report it here, so we can try to help you further. Keep-on going with turning off devices one by one, you may observe more interesting results.

It could definitely be more than one device, so each time you are turning one device off and re-testing your setup, make sure to note any change in the camera stream visual. If you see a noticeable change but not the stream is still not completely fixed, keep that device off and keep-on going.

If despite all your efforts you cannot identify an interference source in the car, you're not in luck! At that point, it could well be the "car-based" setup (5V DC-DC + Jetson + Camera) misbehaving in the car despite working fine on a bench-top supply. This is good, you have still isolated the issue to this part of the system only.

If you have identified the source and your stream is now completely fixed, then bravo you know who the intruder is! At that point, we can review how could this device interfere with your Jetson setup, you'll have to send us more information about that device :)

Identify Car-based setup issue in the car

This may be the reason you came in the first place but until you haven't gone through the previous steps, there is no reason to land here right away.

Here are general things to look for:

• Is the Jetson setup mounted in an electrically isolated enclosure (besides the camera lens)? If not, can you source a metal enclosure to test?
• Does the mounting orientation matter? (eg. vertically versus horizontally)
• Are all the cables involved in the setup in good condition? Have they been tested in the lab too? If not, take them to the lab and test them.
• Is there any (even tiny) flakiness in any of the connectors involved in the setup?
• Is the setup temperature-dependent? (eg. is the car ambient temperature warmer or colder than the lab)
• Are there any other environmental condition change between the lab and the car?

In none of those are leading you to the issue, at that point, I would look towards the video recorder device. Go back over the previous step, what's there something different compared to the lab setup that could affect the video recorder?

Good luck!

Answer 2

Stick a big electrolytic cap (25v at least preferable 35v or 50v what ever you have laying around) on the 24v line and see if that fixes it.

Car voltages are noisy and your jetson nano and camera don't look like they have any big noise filters, nor does your 24v line look like it was designed to power sensitive electronics

Answer 3

Let's closely consider the videos (instead of trying to make immediate quick fixes):

• the corruption appears in stripes. Full stripes, not partial stripes, and throughout the whole width of the screen;
• the stripes may have tints of useful image in them, thus it is not a total color corruption, but "adjustment" problem;
• VSYNC and HSYNC remain stable, picture does not flick of jump in the frame and on the screen;
• there're times of very clean picture, while it seems you always have the problem, in reality there're times when couple of frames are being displayed without corruption;
• sometimes, on the third video, the whole frame becomes color-biased.

Let's look into the camera interface. It is very simple, with VSYNC pulse, and HSYNC pulse, and data within HSYNC pulse time. Try figuring out that could happen at the interface level for the visible effects to appear - I can not find any. VSYNC/HSYNC corruption would affect image positioning on the screen, and horizontal misalignment. HSYNC problem would also cause horizontal misalignment and picture waving to the sides. This does not happen.

The problem with data is possible, VDD-DO is having typical 1.8V level. But the striped pattern says against spurious data corruption, and even if there's any interfering device around causing data level corruption I do not think it is going to be so synchronized causing pure stripes.

Thus I conclude that problem is NOT in the interface from the camera.

I suspect that problem is in camera itself. The corruption in the colors - corruption, not total overriding of color as we can see an image within the corrupt stripes - can be caused by bad incorrect calibration of the black level. The calibration, per datasheet, is performed:

The bottom "optically shielded" pixels, as well as side pixels, may be used by the camera firmware to adjust black level - for each frame in overall, and for each line individually:

I do think there's something wrong with black levels. Either something optically causes the control sensors to give wrong levels as a reference for black (e.g. something in the car emitting the light - even at the spectrum not visible to the eye - obstacle radar, weather radar, or just LED of the car security system), or it is an EMI problem causing corruption of signals inside the camera causing it using wrong black levels.

From the datasheet I see that it is possible to turn BLC off through bit 0 of BLC CTRL00 register. You also can turn ABLC off using bit 6 of BLC CTRL02 register. No idea what will happen as documentation does not give any further information on programming the camera.

One of the simplest tests comes to the mind: cover the lens (completely) with something solid not letting (any) light through it and see if stripes persist. Shield the whole body of the camera against the light and using metal cage against the EMI (having shield grounded to the camera's ground), and see if stripes persist.

Next, there must be guidelines for the automotive device designs. Please review them and ensure you formally comply to them. I hope you have already done it, mentioning just in case to be sure that you do not catch some known problems because of that.

Answer 4

This is relatively low frequency stuff, i would look for a rogue DC/DC that is not very stable for any reason. Try disconnecting any of them and replacing with a lab supply. So start with what is easy to remove, the big 5V one.

Answer 5

The interface from the camera to the Nano is MIPI CSI-2. CSI-2 sends sync signals in-band as part of the data payload, but requires a separate clock pair to synchronize data byte frames.

Looking at the result, my guess is that some large solenoid is putting out enough magnetic field to disturb the CSI-2 lines or perhaps the sensor itself, given the row-oriented nature of the failures.

If your camera is in the same housing, that noise may be getting kicked onto your ground plane on the Nano and playing havoc with the sensor. Try adding some common-mode filtering (e.g., common-mode chokes, ferrite beads) to all the power and I/O lines. Also, ground the box to the vehicle body.

If the camera is NOT in the same housing as the Nano, don't do that. CSI-2 is a low-power LVDS technology that is designed for in-device links, not for long distances.

Instead, consider converting to FPD-Link or GMSL at each end of the camera cable (you can buy these as standard sets.) GMSL and FPD-Link are self-clocking serdes standards that use a single coax for camera connection. They both support power-over-coax and I2C, all on the same single coax wire. GMSL and FPD-Link use industry-standard FAKRA connectors.

This self-clocked serdes approach solves a lot of problems in the vehicle environment that CSI-2 cannot possibly address. I encourage you to follow their example.