Hacker News Reader

Comment by duskwuff | Hacker News Reader

> Is it high-frequency noise from an unshielded clock?

I bet that's it.

2560x1440 @ 60 Hz with CVT-RB timings has a pixel clock of 241.5 MHz. The TMDS bit rate is 10x the pixel clock, and 2415 MHz is right in the lower end of the 802.11 band.

If the Pi can be convinced to use CVT blanking, that'll raise the pixel clock to 312 MHz, which should be fine.

View on HN

This is the answer. That mode puts the second harmonic going out of the HDMI cable smack in the 2.4GHz WiFi band (the fundamental would be at 1/2 the bit rate).

Now the question is who screwed up. Is it a leaky cable? Is it bad PCB design? Is it a problem internal to the SoC? Is it a power delivery issue? Knowing the RPi foundation and Broadcom, I bet one of them screwed this up for all RPis and it isn't just a bad cable.

I'm trying to understand this so I don't know a lot of what's going on here, but why is the fundamental half the bit rate instead of the bit rate?

I'm not 100% sure, but I'm assuming because of Double Data Rate transfers: https://en.wikipedia.org/wiki/Double_data_rate

Imagine a signal that alternates every second (e.g. 10101010). This has a frequency of 1/2 Hz, not 1 Hz, because it repeats every 2 seconds.

I so badly want this to be true - it's like a perfectly designed bug!

And unlike hdmi 2.0, 1.4 wont have scrambling in, so any termination issues will sing quite well.

> And unlike hdmi 2.0, 1.4 wont have scrambling in, so any termination issues will sing quite well.

Not an electrical engineer: which measures are usually adapted to handle termination issues?

Moar power, isolation, and voltage regulators.

And grounding!

I thought something similar: Pixel clock or some harmonic of it feeding back into the wifi chip via the power lines (image search says the chip is in a metal box, so should not be via over-the-air-RF). Thanks for doing the math.

Forcing a different pixel clock is probably the easiest fix, and since the ports claim to do 4kp60, that should be possible (if the display supports it).

Not the numbers the calculator I found online came up with, but I had the same thought. I'm thinking that changing the refresh rate could solve the problem.

The calculator I was using was:

https://tomverbeure.github.io/video_timings_calculator

Changing the refresh rate would work too, but some monitors can be pretty picky about that.

That reminds me of this: https://bellard.org/dvbt/

Reply on news.ycombinator.com