Periodic magenta noise on Camera 3 in multi-camera IMX519 grid on Jetson Xavier NX

Nvidia Jetson Cameras
1

Hi everyone, I’m running into a weird periodic magenta noise issue on my Jetson Xavier NX setup and I’m hoping someone can help me narrow it down.

Here’s my setup:

  • NVIDIA Jetson Xavier NX Developer Kit (16 GB)
  • Jetpack 5.1.2 (kernel 5.10.120-tegra-35.4.1-20230801124926)
  • Multi-Camera IMX519 HAT (firmware date: 2023-10-23)
  • Original 19V / 60W power supply
  • 4x IMX519 cameras connected

I recorded a test stream with this pipeline:

gst-launch-1.0 nvarguscamerasrc num-buffers=1000 ! "video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=30/1" ! nvv4l2h264enc bitrate=8000000 ! h264parse ! qtmux ! filesink location=periodic_magenta_issue.mp4

When I play it back, after a few dozen frames I start seeing magenta noise in the 4-camera grid. It seems to mostly affect one row (a camera pair). Sometimes part of the image turns magenta with noise mixed in, then it goes back to normal for a few moments, and then it comes back — repeating periodically.

Here’s a video of what I’m seeing: periodic_magenta_issue.mp4

Anyone seen anything like this before?

2

That’s an interesting issue. The fact that it’s periodic and seems to target one row in the grid suggests it might be tied to a specific camera channel. Can you try removing cameras one at a time and see if the problem disappears with a particular camera disconnected?

3

Good call. I went through and isolated each camera, and it turns out the problem is always associated with Camera 3. If I remove Camera 3 from the setup, the issue goes away completely — regardless of what resolution, framerate, or pipeline I use.

4

Alright, that’s a strong clue. Before we blame the camera module itself, let’s rule out the HAT’s compositor. Can you run through the composite modes via I2C on bus 9, device 0x24, register 0x24? Test each single-channel mode, then the double-channel combos, and finally the default four-in-one. Let’s see if the issue only shows up when Camera 3 is part of a composite.

5

Sure, here are my results testing each composite mode:

Single channel modes — all clean:

  • Channel 0: i2cset -y 9 0x24 0x24 0x02 — no issue
  • Channel 1: i2cset -y 9 0x24 0x24 0x12 — no issue
  • Channel 2: i2cset -y 9 0x24 0x24 0x22 — no issue
  • Channel 3: i2cset -y 9 0x24 0x24 0x32 — no issue

Double channel modes:

  • 0+1: i2cset -y 9 0x24 0x24 0x01 — no issue
  • 1+2: i2cset -y 9 0x24 0x24 0x11 — issue present, mainly on channel 3, sometimes channel 2

Four-in-one (default):

  • i2cset -y 9 0x24 0x24 0x00 — issue present, mainly channel 3

So single-channel modes are all fine, but any composite that includes Camera 3 triggers the magenta noise.

6

That’s pretty telling. But just to be thorough — have you tried swapping the ribbon cables between cameras? It’s worth ruling out a bad cable before concluding the module is faulty.

7

Yes, I swapped cables around. The problem stays with Camera 3 regardless of which cable is connected to it.

8

What about physically moving the camera to a different position on the HAT? If the problem follows the camera module rather than the HAT port, that would confirm it’s the module.

9

Did that too. Moved Camera 3 to a different position on the HAT, and the magenta noise follows it. Shows up in both double-channel and quad-composite modes wherever I place it. At this point I was skeptical, so I replicated the entire setup on a second Jetson Xavier NX unit — same exact behavior. Same periodic magenta noise.

10

Thanks for all the thorough testing. Here’s what the evidence points to:

  • Problem follows Camera 3 when its position changes → faulty camera module, not a HAT port issue
  • All single-channel modes are clean, even for Camera 3 alone → the sensor itself can produce clean frames, but something goes wrong when it’s composited with other channels (timing, sync, or data corruption)
  • Composite modes that include Camera 3 fail consistently
  • Independent of resolution, framerate, pipeline changes, and cable swaps
  • Reproduced on a second Jetson unit

Root cause: defective Camera 3 (IMX519 module).

Let’s do one more thing — remove Camera 3 entirely and run a test in the default four-in-one mode with the remaining three cameras. Just want to confirm everything is stable without it.

11

Removed Camera 3, ran the default four-in-one mode with the three remaining cameras. Problem completely gone. Doesn’t matter that there’s an empty position.

Here’s the recording: test_without_bad_camera.mp4

Then to be absolutely certain, I put the suspect camera back but in a different HAT position with a different cable and recorded another test. The magenta noise follows the camera.

Video: test_other_position_bad_camera.mp4

So yeah, it’s definitely the camera module itself. It’s an Arducam IMX519 Auto Focus Camera Module.

12

All three videos and your systematic testing make it very clear — the IMX519 module on Camera 3 is defective. The fact that it works cleanly in single-channel mode but corrupts composite streams suggests something is off with its MIPI output timing or data lane integrity under the multi-camera synchronization.

I’ve sent you a private message with the next steps regarding the faulty module. Please check your inbox.

13

Thanks for confirming. I’ve received your PM and sent the requested photos of the camera (front and back) through private message. Appreciate the help tracking this down — the I2C register testing approach was really useful for isolating it.

14

Glad we got to the bottom of it. For anyone else who runs into similar periodic magenta noise on a multi-camera IMX519 HAT setup with Jetson, the key takeaways from this thread:

  1. Start by isolating cameras one at a time to identify the problem channel.
  2. Use I2C composite mode switching (bus 9, device 0x24, register 0x24) to test each channel individually and in combinations.
  3. Swap cables and positions to rule out HAT ports and cabling.
  4. If the problem follows a specific module across all variables, the module itself is faulty.

We’ve confirmed the root cause here and I’m following up with the OP via PM for the next steps.