Skip to content
Tech News
← Back to articles

Fixing an NZXT Signal 4K30 part 2: the green/pink video bug

read original get NZXT Signal 4K30 Capture Card → more articles
Why This Matters

This is a niche but instructive hardware-repair follow-up showing how a hobbyist used AI (Claude) to reverse-engineer a color-encoding bug in a discontinued USB capture device, highlighting both the fragility of consumer capture hardware and the growing role of AI tools in debugging firmware-level issues. It's relevant to tech enthusiasts and engineers interested in AI-assisted reverse engineering and the lifecycle of niche consumer electronics.

Key Takeaways
Worth a Look

NZXT Signal 4K30 Capture Card — If you're diving into HDMI capture quirks like RGB/YUV mismatches, having your own NZXT Signal 4K30 lets you tinker and test alongside this teardown. It's a compact USB capture device great for streaming or recording from consoles and other HDMI sources.

See NZXT Signal 4K30 Capture Card on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

Last year, I repaired an NZXT Signal 4K30 USB capture device that I bought on eBay for cheap. It was completely dead, and the cause turned out to be a bad solder joint on an inductor, which prevented power from getting to a crucial part of the board.

After I fixed it, I tried using it to capture signals from a bunch of different HDMI source devices to make sure it worked correctly. As I said in my last post about it:

I did find one 720p60 HDMI source that it doesn’t like — the captured video shows up as pink and green.

In that post, I also pointed to a few Reddit threads (1, 2) where similar issues had been observed on a PS5 and Nintendo Switch, respectively.

Here’s a snapshot of what captured video looked like from the one HDMI source that it didn’t like:

You can see that the colors are green and purple. They’re completely wrong. I knew from past experience with video encoders and decoders that this is very typical behavior if you have a mismatch between RGB and YUV video. I doubted it was faulty hardware, especially since other people on Reddit had seen the exact same symptom.

I left it at that. I didn’t care that this one device wouldn’t capture correctly, and I didn’t bother contacting NZXT about it. I’ve noticed that since then, the device seems to have completely disappeared from the market. You can’t buy it on Amazon or Newegg anymore, and NZXT’s website doesn’t mention it anywhere except under support. It’s pretty clear that NZXT exited the capture card market. If I contacted them now, I’d be shocked if they could do anything about it.

Last night, a thought randomly jumped into my mind. I’ve been using Claude to do some pretty in-depth reverse engineering and bug investigations lately. For example, here’s a reverse-engineered Linux kernel V4L2 driver for the Elgato Game Capture HD60 S that I investigated in depth a couple of years ago. What if I had it look into this problem? It would be a nice way to completely finish off the first post where I repaired the hardware problem. Together, could we fix the final issue, which I assumed was a firmware problem?

During the hardware repair, I had already documented all of the different components used in the device, so I gave that all to Claude, along with a description of the problem, pictures of the issue from the Reddit posts, NZXT’s last firmware update for the device released in 2022, and a checkout of a GitHub repository containing ITE’s driver for the IT6805 HDMI receiver IC used by the Signal 4K30. I also pointed out that I suspected it was some kind of RGB vs. YUV mismatch because I’ve seen this happen in the past when developing firmware for video devices.

15 minutes or so later, Claude got back to me with results. It agreed that it was a YUV vs. RGB mismatch issue. It pointed out what it thought were a few bugs in the firmware that looked promising. To be sure, it asked me to verify a few things about the detected signal. It told me that the Cortex-M0 microcontroller has a UART with debug output. I found the unmarked debug header on the PCB, figured out which pin was the TX pin (and the baud rate) with my portable oscilloscope, captured its output with the problematic HDMI source device attached, and pasted it back. I also used my reverse-engineered Game Capture HD60 S Linux driver listed above to provide more details about what type of signal the problematic source was outputting.

... continue reading