NV3D Vision Restoration Project

RP2040 DIY emitter preparation

Updated 2026-09-15. The RP2040-Zero and Adafruit High Power IR Emitter have arrived. The user confirmed Adafruit 5639 wired In to GPIO2, GND to GND, and V+ to 5V. Original emitter preparation remains documented separately. No optical sensor is required for visual trials.

Status: the board-specific UF2 is flashed, the explicitly approved WinUSB package is installed, the real hardware clock probe passes, and the app’s emitter connection check reaches Ready. The host handles TinyUSB’s trailing empty packets and replies left by interrupted connections. Native tests include 600 seconds of simulated 120 Hz events, host protocol/USB framing tests and PIO instruction simulation. See protocol and firmware/setup instructions. The user now reports good OLED stereo at 120 Hz. LCD/QLED full-screen separation remains unresolved. The 0.3.0 preload trial did not sustain useful glasses activity. Firmware 0.4.0 adds generic LCD aperture calibration and OLED direct 240 Hz scheduling; it is flashed and the USB/clock probe passes. Optical testing is pending. Pin waveforms remain unmeasured.

240 Hz OLED BFI recovery, 2026-09-26

The user reconfirmed working glasses synchronization at 240 Hz with Black frame insertion enabled (Left / Black / Right / Black). A saved profile had instead selected ordinary Left / Right at 240 Hz. Restoring BFI recovered operation; no firmware flash or driver change was needed. Keep the calibrated phase, shutter widths and original eye order. A separate 120 Hz emitter test completed 1,200 commands with zero errors or late commands. The 240 Hz BFI presentation test also completed without reported presentation misses or emitter errors/late commands. These short tests do not establish sustained GPU-load stability.

The release includes vision_rp2040_probe.exe; close the app before using --clock, because the running app holds the USB connection. USB success alone does not prove the IR module or glasses are responding.

Intended display work

The editable app and firmware now implement a refresh-independent temporal aperture: settling delay, shutter duration, global/per-eye phase, transition guards and optional scan compensation. WinUSB transports commands; it is not where the optical timing is implemented. All sliders are visible together in the existing app. OLED 120/240 Hz and 240 Hz BFI remain separate from LCD timing. See LCD calibration for controls and the distinction between supported scheduling and observed optical results.

Source findings

Reviewed NTM-3D/RP2040-3D-Vision-Emitter revision 7bf75a09834497408ddbd277c40bbe1a64dfafff.

• Project README limits support to driver mode at 120 Hz and assigns IR output to GPIO2. Firmware is flashed as UF2 through BOOTSEL.
• USB descriptors emulate NVIDIA 0955:0007, with bulk OUT 0x01 and 0x02. Matching IDs are not proof of an original NVIDIA emitter. Runtime firmware is already on the RP2040; NVIDIA RAM firmware extraction is unnecessary.
• Command handling accepts enable and eight-byte eye packets. Our timing block at offset zero is ignored. Packet-arrival filtering assumes roughly 120 Hz; the timing field in our eye packet is not interpreted as a scheduling deadline.
• The same parser copies caller-supplied lengths into small register arrays without adequate bounds checks. Correct this before adding commands or exposing general register access.
• IR engine uses PIO/DMA waveforms and timer alarms with arrival-based clock filtering. Constants set a 3000 us alarm delay and 400 us inter-token gap. The gap is not a measured optical shutter duration.
• No top-level project LICENSE appears in the reviewed tree. Dependency licenses do not establish a license for all firmware. Resolve reuse/distribution terms before distributing a derivative; an independently implemented host protocol and scheduler remain an alternative. No upstream source has been vendored into this application.

Hardware preparation

Assuming the ordered Adafruit board is product 5639, it includes its own transistor driver and accepts a 3-5 V logic input. It needs pulsed operation, not a continuously asserted output. Adafruit product specification.

Intended connections, subject to verifying the received board’s labels and power path:

Adafruit signal	RP2040-Zero connection
In	GPIO2, 3.3 V logic
GND	GND
V+	USB-derived 5 V rail, after checking the actual board pinout and USB current budget

Use the module’s driver; never power its LEDs from a GPIO. At 5 V the module specification lists about 400 mA total instantaneous LED current. Firmware must start LOW, bound every pulse, and stop output on timeout. Do not copy the upstream bare-LED/direct-GPIO alternative. Verify pin labels rather than relying solely on wire colors. A USB data cable is needed for flashing and operation. Manufacturer reference: RP2040-Zero.

Implementation work, in order

1. DONE: local ARM GCC 14.3.1/Pico SDK 2.2.0 build and board-specific UF2; pinned archives and source-derived firmware identity. Firmware is originally implemented, with protocol facts studied from upstream references rather than vendoring their unlicensed source.
2. IMPLEMENTED, hardware pending: explicit RP2040 backend, product/serial/version/endpoint/VRP1 checks, vendor bulk USB and MS OS WinUSB descriptors. Original NVIDIA firmware upload is excluded from this path.
3. Define bounded messages for device-clock query, timing configuration, scheduled eye events, stop and status. Include session generation, sequence ID, device timestamps, queue capacity and late-event counters. ACK configuration and reject unsupported rates/durations. Parser tests must cover truncation, oversized lengths and stale sessions.
4. Execute IR edges using PIO/DMA plus a hardware-timer scheduler. Define each eye’s open/close token timing explicitly, validate waveform overlap, and separate IR pulse width from requested lens-open interval. Retain an immediate stop and host-loss timeout. First hardware mode: 120 Hz LR only.
5. Map host QPC to the RP2040 clock with repeated timestamp exchanges, accounting for USB round-trip uncertainty and drift. Send short-horizon future events early; use presentation feedback to correct predictions. On a missed display frame, stop/blank, discard queued generations and reacquire eye order. An already emitted pulse cannot be undone.
6. Connect the wizard’s phase/duration controls to acknowledged firmware values; add firmware version, clock uncertainty, queue health and actual executed-event reports. Disable unimplemented controls. Preserve separate SDR/HDR profiles and include emitter/firmware identity in calibration validity.
7. Run parser/scheduler simulations for delayed USB, missed frames, disconnect, clock drift and restart before hardware arrives. Then validate USB enumeration, stop/reconnect, visible shutters, eye identity and screen-wide separation on G80SD 120 Hz. Repeat SDR/HDR and ten-minute stability checks, then Hisense 120 Hz. Higher rates remain experimental.

Timing limits

Device-side scheduling can reduce dependence on individual USB arrival times. It cannot make GPU presentation and USB atomic or reveal when the panel emits light. Clock exchange also cannot eliminate unknown one-way USB delay. We must measure available host/device timing and use visual calibration for optical alignment. A stable free-running 120 Hz emitter alone will drift relative to the display.

HDR remains in the Windows rendering path; the IR waveform does not encode SDR/HDR. Changing HDR can still require another phase/duration profile because display behavior may change.

The first deliverable on arrival is controlled shutter activity with reliable stop, followed by synchronized 120 Hz stereo. A successful firmware flash or green status LED is not successful glasses calibration.

This site is open source. Improve this page.