Metro RP2350 DVI output defaults to 72Hz refresh (capture cards like 60Hz)

[samblenny]

CircuitPython version and board name

Adafruit CircuitPython 9.2.7 on 2025-04-01; Adafruit Metro RP2350 with rp2350b

Code/REPL

# No code needed to trigger the bug, just:
# 1. Connect HSTX DVI adapter to an HDMI capture card with HDMI passthrough to a TV
# 2. Power up the board with an empty code.py
# 3. Let CircuitPython supervisor initialize the default picodvi.Framebuffer config

Behavior

When I connect the Metro's HSTX port to a DVI adapter and connect the DVI adapter to a TV, the TV shows the CircuitPython console. But, it reports that the video mode is 640x480@72Hz (not 60Hz).

When I try to capture the video output with an AverMedia GC551G2, it says "Not Supported". That makes sense because many capture cards and video scalers appear to generally expect 60Hz refresh for lower resolution video modes (based on my reading of various manuals). My impression is that TVs and monitors that have VGA or component video inputs may be more flexible about accepting a range of refresh rates.

This is what the capture card output looks like when I boot the Metro RP2350 with an empty code.py:

Description

No response

Additional information

If I change microcontroller.cpu.frequency from its default of 150MHz down to 125MHz (because 150/72*60 = 125), then the TV reports a 60Hz refresh rate and the capture card immediately starts working happily, like this:

[tannewt]

I bet we can scale the HSTX clock down to get 60hz. 720x400 may work better for you because that mode is ideally 70hz.

[samblenny]

I tried cpu.frequency clock settings at 1MHz increments between 104MHz and 150MHz for 720x400. Most of those worked on my circa-2013 Samsung TV (60Hz, 70Hz, 72Hz, and 75Hz refresh). But, none would sync with my AverMedia GC551G2 capture card. According to the EDID info as detected by Linux display settings, the card only supports 640x480, 720x480, 720x576, 1280x720, 1280x800, and 1920x1080.

When I forum searched previously to see what people like for taking 720x400 captures from old DOS games (the primary context where that resolution shows up), it sounded like the general opinion was that it was difficult to do. I saw mention of using VGA or component-video to HDMI converters. People also suggested pro video gear like the Aja U-Tap or Extron video scalers.

Anyhow, this is the test code that I used for 720x400 (works with TV, does not work with capture card):

from board import CKP, CKN, D0P, D0N, D1P, D1N, D2P, D2N
from picodvi import Framebuffer
from framebufferio import FramebufferDisplay
import displayio
from microcontroller import cpu

displayio.release_displays()

# Adjust clock scaling so DVI video will sync with TV.
# My Samsung TV can do 720x400 in cpu.frequency ranges 105..127 MHz (@60Hz),
# 128..132 MHz (@70Hz), 133..138 (@72Hz), and 140..144 MHz (@75Hz).
# None of those frequencies are supported by my AverMedia GC551G2.
cpu.frequency = 130000000

fb = Framebuffer(720, 400, clk_dp=CKP, clk_dn=CKN,
    red_dp=D0P, red_dn=D0N, green_dp=D1P, green_dn=D1N,
    blue_dp=D2P, blue_dn=D2N, color_depth=2)
display = FramebufferDisplay(fb)

This is the test code that I used for 640x480 (works well on TV and capture card in the "60Hz" refresh rate range as reported by the TV):

from board import CKP, CKN, D0P, D0N, D1P, D1N, D2P, D2N
from picodvi import Framebuffer
from framebufferio import FramebufferDisplay
import displayio
from microcontroller import cpu

displayio.release_displays()

# Adjust clock scaling so DVI video will sync with capture card.
# AverMedia GC551G2 can do 640x480 in cpu.frequency range 120..134 MHz.
# Samsung TV says that whole range uses video mode 640x480@60Hz.
cpu.frequency = 130000000

fb = Framebuffer(640, 480, clk_dp=CKP, clk_dn=CKN,
    red_dp=D0P, red_dn=D0N, green_dp=D1P, green_dn=D1N,
    blue_dp=D2P, blue_dn=D2N, color_depth=4)
display = FramebufferDisplay(fb)

[samblenny]

Figured out how to actually read and decode the capture card's EDID info using edid-decode on Debian.

This is the relevant part of the output for the video modes supported by the AverMedia GC551G2:

$ ls /sys/class/drm/*/edid
...[listing of edid files to try]
$ edid-decode /sys/class/drm/card0-HDMI-A-2/edid
...
Block 1, CTA-861 Extension Block:
  ...
  Video Data Block:
    VIC  63:  1920x1080  120.000000 Hz  16:9    135.000 kHz    297.000000 MHz (native)
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC  96:  3840x2160   50.000000 Hz  16:9    112.500 kHz    594.000000 MHz
    VIC  95:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz
    VIC  94:  3840x2160   25.000000 Hz  16:9     56.250 kHz    297.000000 MHz
    VIC  93:  3840x2160   24.000000 Hz  16:9     54.000 kHz    297.000000 MHz
    VIC  32:  1920x1080   24.000000 Hz  16:9     27.000 kHz     74.250000 MHz
    VIC  31:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz
    VIC  20:  1920x1080i  50.000000 Hz  16:9     28.125 kHz     74.250000 MHz
    VIC  19:  1280x720    50.000000 Hz  16:9     37.500 kHz     74.250000 MHz
    VIC  18:   720x576    50.000000 Hz  16:9     31.250 kHz     27.000000 MHz
    VIC   5:  1920x1080i  60.000000 Hz  16:9     33.750 kHz     74.250000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    VIC   3:   720x480    59.940060 Hz  16:9     31.469 kHz     27.000000 MHz
    VIC   1:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
...

[samblenny]

hmm... that previous video mode list may have been inaccurate. I managed to accidentally plug the USB cable in only part way. So maybe the capture card was running in USB 2.0 mode instead of 3.x? This is the result I got from edid-decode after I fixed the cable and started over. It's pretty similar:

  Video Data Block:
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC  96:  3840x2160   50.000000 Hz  16:9    112.500 kHz    594.000000 MHz
    VIC  95:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz
    VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
    VIC  31:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz
    VIC  94:  3840x2160   25.000000 Hz  16:9     56.250 kHz    297.000000 MHz
    VIC  93:  3840x2160   24.000000 Hz  16:9     54.000 kHz    297.000000 MHz
    VIC  63:  1920x1080  120.000000 Hz  16:9    135.000 kHz    297.000000 MHz
    VIC   5:  1920x1080i  60.000000 Hz  16:9     33.750 kHz     74.250000 MHz
    VIC  20:  1920x1080i  50.000000 Hz  16:9     28.125 kHz     74.250000 MHz
    VIC  34:  1920x1080   30.000000 Hz  16:9     33.750 kHz     74.250000 MHz
    VIC  33:  1920x1080   25.000000 Hz  16:9     28.125 kHz     74.250000 MHz
    VIC  32:  1920x1080   24.000000 Hz  16:9     27.000 kHz     74.250000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    VIC  19:  1280x720    50.000000 Hz  16:9     37.500 kHz     74.250000 MHz
    VIC  17:   720x576    50.000000 Hz   4:3     31.250 kHz     27.000000 MHz
    VIC  18:   720x576    50.000000 Hz  16:9     31.250 kHz     27.000000 MHz
    VIC   3:   720x480    59.940060 Hz  16:9     31.469 kHz     27.000000 MHz
    VIC   2:   720x480    59.940060 Hz   4:3     31.469 kHz     27.000000 MHz
    VIC   1:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
    VIC  22:  1440x576i   50.000000 Hz  16:9     15.625 kHz     27.000000 MHz
    VIC  21:  1440x576i   50.000000 Hz   4:3     15.625 kHz     27.000000 MHz
    VIC   6:  1440x480i   59.940060 Hz   4:3     15.734 kHz     27.000000 MHz
    VIC   7:  1440x480i   59.940060 Hz  16:9     15.734 kHz     27.000000 MHz

[tannewt]

The 27mhz pixel clock ones could be interesting! I don't think we'll want to go faster than that.

I'd like to try extending the vblank period to fix this instead of changing the clock rate. Theoretically we can extend vblank to refresh the frame at the intended rate.

[samblenny]

It would be great if the vblank extension thing you're suggesting could avoid slowing down the main clock.

For 27MHz modes, my impression is that many displays and capture cards probably support 480p. I wonder if it would be possible to use the HSTX config to automatically put a frame of black, or perhaps a configurable color, around smaller frame buffers, so long as they fit within 720x480.

[edit: hmm... upon further reading, maybe 480p (4:3) is actually just a fancy name for 640x480, 480p (3:2) is 720x480, and 16:9 480p isn't actually a thing? these video modes are so confusing. In any case, it would be great if it was possible to find a mode that generally worked across common capture cards and displays, including the cheaper ones.]

[tannewt]

This is what 720x400 @ 70hz has been for me. It is close to 16:9. Works on my TV at the office and at home. My XR1 Lite ($60) can also capture it just fine.

[tannewt]

Moving to long term because the non-standard speed works with most things.

[samblenny]

FWIW, I got tripped up by this again on 10.0.0-alpha.4. I'm trying to do a Playground guide that uses USB Host and DVI out. I'd like to use my HDMI capture card to take clean images for the guide. At the moment, the best I'll be able to do is photographing a fuzzy upscale off the TV.

After a fresh firmware install, the Fruit Jam boots to 640x480@72Hz (according to my TV). Sync with the TV is marginal (initially refused to sync, then did okay after a reset). Sync with my capture card doesn't work. If I try messing with microcontroller.cpu.frequency, it breaks USB host mode, so that's not a viable workaround in this case.

I guess my only option at this point is to try buying new capture cards until I find one that works at 640x480@72Hz? I'd rather not do that if I can avoid it. I'd feel differently if the Fruit Jam was running at a more common refresh rate for 640x480.

From my perspective, this seems like a thing that could end up causing trouble for a fair number of other folks once the board is readily available and people try hooking up to a wider variety of HDMI devices (capture cards in particular). Maybe I'm wrong about that though.

[todbot]

Is the garbled video that I'm experiencing related to this issue? I'm finally trying HSTX DVI output on Metro RP2350 and the demo code in the Learn Guide is scrambled like the timing is off on my little test HDMI display (see below).
I notice that microcontroller.cpu.frequency defaults to 150 MHz and if I change it to 125 MHz, then the display can parse the output and the image shows up correctly. A handful of other other CPU frequencies were tried and only 125 MHz seem to work.

This happens for both 320x240x16 and 640x480x8 on both 9.2.8 and 10.0.0-alpha.6.

[samblenny]

I only tested with two devices, but both of those, when they got mad about sync rates, just gave me a black screen with an error message overlay. No clue what it would have looked like on screen if they'd actually tried to draw the signal that they were complaining about not being able to sync to. The clock rate adjustment thing sounds similar though.

edit: my ultimate solution to this was to keep an eye on ebay auctions for the EVGA XR1 Lite until I was able to snag one for a reasonable price.

[WolfWings]

The RP2350 HSTX-DVI outputs run at double-pumped CPU clock speed, with the 'clock' pin at 1/10th of that per the DVI spec. This means that the 'pixel clock' they're generating is cpu clock speed / 5 so by default? 30Mhz. Shifting them down to 125Mhz CPU clock speed drops that pixel clock to 25Mhz.

The 'VGA 640x480' 60Hz timings require 25.175Mhz pixel clock, with VESA requiring a minimum of 0.5% clock tolerance but in practice because generating exactly 25.175Mhz with PLLs is such a hard thing versus plain 25Mhz most devices will accept 25Mhz happily.

Changing the video timings to a pixel total of 800x625 (exactly 500k pixels per frame, 160 hblank/145 vblank for 640x480) requires a pixel clock of 30Mhz for 60Hz display so things align better if the video capture device will accept that, some will and some won't. Both the 720x400 and 640x480 modes can be run inside the 800x625 geometry as a possible 'alternative video timing' option flag to consider?