Adding a Status Display to a Capture Card

A small status display on a capture card provides a direct view of USB connectivity, capture parameters, and HDMI input information. The capture card sends status data over UART, while an independent MCU receives and parses it, renders the interface, and updates the screen dynamically.

The screen shows capture link status and parameters, so video images do not need to travel over UART. The capture card supplies the status, and the display MCU turns it into text, icons, and numerical values.

System structure

Capture card                   Independent MCU                  Display
Read USB / HDMI status ─UART─→ Receive, assemble, parse ─render─→ Update screen

The capture card sends complete status packets. The MCU reconstructs the fields from the serial data and updates the screen. New packets can reflect USB connection changes, capture start or stop events, and changes to input parameters.

Display examples: input and capture status at a glance

The following images show HDMI RX input status and USB/UVC capture status. Status indicators highlight connectivity, large text shows resolution, and separate areas present speed, frame rate, and video format for quick reading.

These images illustrate the board and display arrangement and the interface style. Their values and labels are demonstration content; actual readings must come from the UART status packet and are not capture performance specifications.

HDMI RX: checking input status

The HDMI RX page groups input information: 5V, HPD, and CLK status appear above the input resolution and video format. Green indicators are paired with labels such as ON and HIGH, conveying status through both color and text.

The implemented interface can also show hdmi_fps alongside the resolution as “width × height @ frame rate.” When checking the input link, users can inspect 5V, HPD, and clock status before reviewing the input parameters.

USB/UVC: checking host connectivity and capture parameters

The USB/UVC page focuses on capture: LINK represents USB connection status, SPD represents link speed, and the other areas show capture resolution, frame rate, and video format. Link speed can be displayed as FS, HS, or SS according to the protocol.

The implementation should also provide a separate UVC on/off indicator. USB connectivity and UVC activity correspond to usb_link and bit0 of usb_uvc_hdmi_clk, respectively; they should not be combined into a single status.

Mapping display information to protocol fields

The display MCU can organize the following information into two pages or separate sections on one page. Read USB capture and HDMI input parameters independently rather than copying the input resolution into the capture area.

Area	Displayed information
USB	Link status, link speed, capture resolution, frame rate, video format, UVC status
HDMI	5V status, HPD level, clock status, input resolution, frame rate, video format

UART status packet format

Status data uses a little-endian layout with no padding. On the wire, each payload byte is encoded as two uppercase ASCII hexadecimal characters, with a header and trailer:

"AA" + ASCII HEX for an 18-byte payload (36 characters) + "55"

Under this declaration, each frame contains 40 ASCII characters, or 40 bytes transmitted over UART. The header "AA" consists of two A characters, and the trailer "55" consists of two 5 characters; they are not raw binary bytes 0xAA and 0x55. Offsets below refer to decoded payload bytes, excluding the header and trailer.

Protocol details awaiting confirmation

The current declaration specifies an 18-byte payload, but the supplied fields cover only [0] through [16], totaling 17 bytes. The purpose of byte [17] has not been provided; it must not be assumed to be reserved or a checksum. The table provisionally places HDMI clock status at bit1 of [8], subject to confirmation with the sender. Resolve both points before implementing the receiver.

Field layout

Offset	Field	Meaning and values
[0]	usb_link	USB connection: 0=OFF, 1=ON
[1]	usb_spd	USB speed: 0=UNKNOWN, 1=FS, 2=HS (USB 2.0), 3=SS (USB 3.0)
[2]	usb_h_l	Capture width, low 8 bits
[3]	usb_h_h	Capture width, high 8 bits
[4]	usb_v_l	Capture height, low 8 bits
[5]	usb_v_h	Capture height, high 8 bits
[6]	usb_fps	Capture frame rate in Hz
[7]	usb_fmt	0=NONE, 1=MJPEG, 2=YUV422, 3=NV12, 4=RGB
[8]	usb_uvc_hdmi_clk	bit0: UVC status, 0=OFF, 1=ON; bit1: HDMI clock status, 0=OFF, 1=ON (bit assignment awaiting confirmation)
[9]	hdmi_5v	HDMI 5V: 0=OFF, 1=ON
[10]	hdmi_hpd	HDMI HPD: 0=LOW, 1=HIGH
[11]	hdmi_h_l	Input width, low 8 bits
[12]	hdmi_h_h	Input width, high 8 bits
[13]	hdmi_v_l	Input height, low 8 bits
[14]	hdmi_v_h	Input height, high 8 bits
[15]	hdmi_fps	Input frame rate in Hz
[16]	hdmi_fmt	0=NONE, 2=YUV422, 3=YUV420, 4=RGB, 5=YUV444
[17]	To be confirmed	Not defined in the supplied information

Decode USB and HDMI format enumerations separately. For example, value 3 means NV12 for USB but YUV420 for HDMI. The original labels MIPEG and UNKNOW are written as MJPEG and UNKNOWN here without changing their numeric values.

Decoding little-endian resolution values

Width and height each occupy two bytes, with the low byte first:

// p points to an ASCII HEX decoded payload that has passed length checks.
uint16_t usb_width  = (uint16_t)p[2]  | ((uint16_t)p[3]  << 8);
uint16_t usb_height = (uint16_t)p[4]  | ((uint16_t)p[5]  << 8);
uint16_t hdmi_width = (uint16_t)p[11] | ((uint16_t)p[12] << 8);
uint16_t hdmi_height = (uint16_t)p[13] | ((uint16_t)p[14] << 8);

uint8_t uvc_on = p[8] & 0x01;
// Use after the sender confirms HDMI CLK is bit1 of p[8]:
uint8_t hdmi_clk_on = (p[8] >> 1) & 0x01;

For example, width 1920 is 0x0780, stored as payload bytes 80 07 and transmitted as ASCII text "8007". Height 1080 is 0x0438, stored as 38 04 and transmitted as "3804".

MCU reception and dynamic updates

Separate serial reception, protocol parsing, and screen updates:

1. Receive into a buffer: Use UART interrupts or DMA to buffer incoming data. Avoid drawing the entire screen inside a receive callback.
2. Assemble complete frames: Data may arrive across multiple reads, or one read may contain multiple frames. Buffer according to the confirmed fixed frame length and validate the header, trailer, and HEX characters.
3. Parse status: Decode every two HEX characters into one byte, then parse multibyte values, status bits, and format enumerations by offset.
4. Update the state: Replace the status snapshot only after a complete successful parse, avoiding a mixture of fields from old and new packets.
5. Refresh the interface: Compare the old and new states and prioritize redrawing changed text, icons, and values to reduce unnecessary full-screen updates.

The payload's HEX text may also contain "AA" or "55", so searching for the next "55" is not enough to locate the end of a frame. Locate the trailer by fixed length. If validation fails, continue looking for a candidate header and reassemble the frame.

Unknown enumeration values can be shown as UNKNOWN, with the raw value retained for debugging. If no valid packet arrives for a defined interval, display “Status timeout” rather than presenting stale data as current. Set the timeout according to the transmission interval.

Integration checks

• Confirm UART voltage levels, baud rate, data bits, parity, stop bits, and a shared ground.
• Define byte [17] and confirm the bit layout of [8] and the complete frame length.
• Agree on the transmission interval and whether state changes trigger an immediate packet.
• Check display updates during USB connection and disconnection, UVC start and stop, and HDMI connection and disconnection.
• Test resolution, frame rate, and format changes, along with fragmented frames, consecutive frames, invalid characters, and receive timeouts.

Once the protocol is aligned, the independent MCU can use these fields to implement a status display that makes the capture card's connection and operating state directly visible on the device.