VLL emitters — options & status

A Micro Scout has no radio. Something has to physically blink light at its sensor, and this is every way anyone has found to do it, marked by whether it was tried on real hardware or only reasoned about.

Two facts shape all of it. The sensor is biased to red and near-infrared, so white light comes out weak and red or infrared is what you want. And VLL tells bits apart by the ratio between light and dark, not by absolute times, so the whole thing tolerates a scale of about 0.5 to 1.4. That tolerance is why a phone works at all.

Build detail lives in each emitter's own note. Parts: VLL emitters — options & status.

Compatibility = which platform can drive the emitter: yes, partial, no, or n/a.

Pick by platform

• iPhone / iOS: phone torch (Flash Force) works directly in Safari. For hardware, use the bridge: flash once from a computer, then control from Safari (no app, no Web Bluetooth). Pybricks, a serial line and the tower cannot be driven from iOS.
• Android: everything web-based works in Chrome: phone torch, Pybricks hub (Web Bluetooth), lego-blockly (Web Serial).
• Windows: Pybricks (Chrome), a serial control line, RCX and light brick, and the USB IR tower via WinVLL (turnkey).
• macOS: Pybricks hub (Chrome) or a serial control line and an LED: both work today.
• A dead end everywhere: a smartwatch flashlight — the toggle call has too much per-use latency for 20–40 ms VLL pulses.

See Link directory for the tools (JorgePe mindstorms-vll, WinVLL, lego-blockly, Pybricks, ESP Web Tools).

Others got here first

Three published projects send the same 7-bit command and 3-bit checksum frame:

The last one drives the phone camera torch, the same emitter as Phone torch (Flash Force), and reached it independently. Flash Force also sends baseband infrared and drives a hub LED through Pybricks, covers the whole 0 to 127 command range, and queues a program rather than sending one code.

A screen, and why it disappoints

Flashing a black and white patch of a monitor or tablet in the VLL timing, with the sensor against the glass, needs no hardware at all. It works badly enough that you will blame the brick.

Two things fight it. Contrast is worse than a torch, and the refresh rate quantises the timing: 60 Hz gives 16.7 ms a frame against bits of 20 and 40 ms, which leaves no room. A 120 Hz screen halves that quantum to 8.3 ms. A pre-baked video helps a little, because the on and off times live in the frames and there is no runtime jitter, but the refresh ceiling stays.

It was never a period method either. LEGO filled a Micro Scout through a Scout, an RCX or the tower, never a screen.

A wire holds steadier than a torch

Measured, and the reason is latency rather than light: a wired path carries the 20 ms unit with margin to spare over the quantisation a USB link adds, where a phone torch has the camera stack between the code and the lamp.

What to shine, by what you want to drive