1. 18
  1.  

  2. 9

    tl;dr: The pixel clock on the video running at that resolution “conveniently” overlaps with the 2.4 GHz radio band.

    1. 2

      Sounds like in the rush of releasing a Pi 4 they forgot to test EMI sheilding!

    2. 2

      So now I’m curious how exact the overlap has to be. There are a number (3 non-overlapping?) of wifi channels, at (slightly) different frequencies. Does anyone know if this stomps on only one channel? or if it leaks across them all? What determines how wide a frequency range it stomps on? So many questions…

      1. 1

        It stomps on 2.4 GHz. 5 GHz is fine, seemingly.

        1. 1

          Sorry, I meant that 2.4Ghz is a number of different frequency ranges: https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)

          If the pixel clock is running at - say - 2.417 GHz, does that interfere with channels 5-14? I imagine it does, since I don’t expect the interference to be exact, but I’m curious as to how much “spread” there is and what determines it.

          1. 2

            It’s a narrow spike near the centre frequency of channel 1, overlaps 1-3 and maybe 4?

            https://mobile.twitter.com/assortedhackery/status/1200056633898029061

            But RF receivers don’t have perfect filtering, so it’s possible this is strong enough to swamp the receiver even when it’s tuned to other channels.

            I haven’t seen anyone discussing whether other Wi-Fi channels work, or not.

            1. 2

              Thank you! Now I should go and learn some of the basics of RF circuits.

      2. 2

        A good summary: https://www.cnx-software.com/2019/11/29/raspberry-pi-4-wifi-fails-when-setting-hdmi-to-2560x1440-resolution

        Video timing calculator where the magic number 241.5MHz pops up (as noted on HN): https://tomverbeure.github.io/video_timings_calculator

        If the pixel clock theory holds, changing the refresh rate or timing method should fix it.

        I don’t have a screen that supports that resolution, but I might try with force-screen-resolution anyway. That’s a tool I wrote to bypass broken EDID on my Pi4.

        1. 1

          Can’t reproduce the problem.

          I’m typing this on a RPi4 (4GB, stock firmware) with a pixel clock of 241.5MHz connected to my 2.4GHz WiFi.

          cvt -r 2560 1440 60 indeed produces the suspected pixel clock of 241.5 MHz, and I configured my screen to this exact “modeline”, with all the parameters in it (using my tool above).

          The only surprise is that my screen works in higher resolution than it has. The screen’s overlay even says “2560x1440@60.0Hz” when it switches. Note that 60.0Hz is 59.951Hz rounded to one decimal.

          1. 1

            50Hz works too, with --timing=CVT.