A complete plan for demonstrating the app in front of an audience: what to prepare, the exact demo sequence, what to say while it runs, and what to do if something goes wrong. Timings come from the app’s own estimate formulas and the simulation results. Rehearse on your actual phones before the day.
Back to the documentation index.
“These two phones have Wi-Fi, Bluetooth and mobile data switched off. We’re going to send a photo and a narrated video from one to the other using nothing but the screen and the camera, then a message using only sound.”
Switch on Airplane mode on both phones in front of the audience. It is the most convincing moment of the demo.
| Check | Why |
|---|---|
| Same APK installed on both phones | The Light frame format is versioned; mismatched builds reject each other’s frames |
| Both phones charged above 60% | Full brightness and the camera drain the battery fast |
| Camera, microphone and storage permissions granted | Avoid permission pop-ups on stage. Open Receive → Light and Receive → Sound once each to trigger them |
| Screen protectors clean, camera lens wiped | Smudges blur the QR modules. Focus and sharpness matter most for decoding |
| Screen timeout set to 2+ minutes | The app keeps the screen awake while streaming, but not on other screens |
| Do Not Disturb on | A notification banner over the QR code costs frames |
| Media volume at maximum on the sender | For the Sound demo and for video playback on the receiver |
| Received album cleared | So the audience sees the new item appear in Adaptive Comm |
Time each one. If the Light transfers are much slower than this, see Troubleshooting before the event.
Turn on Airplane mode on both phones and show it.
Don’t demo Vibration. The channel is experimental and real phone-to-phone transfers usually fail (Known Issues §2.8). If someone asks, explain the idea (short and long buzzes felt by the accelerometer) and say it’s work in progress.
Home → ⋮ → Developer tools → Simulation Lab → scenario optical-degrades → run. Watch the log: the adaptive engine sees the light channel collapse, scores it about 0.27 against about 0.70 for sound, and switches to sound. Present this as the decision logic only. The run itself currently ends FAILED, because a transport bug stalls the transfer before the switch (Known Issues §3.2). For a run that ends in SUCCESS, pick optical-always-good.
What the HUD means:
| HUD item | Say this |
|---|---|
| SCAN / LOCK / DONE | “Scanning for codes; locked onto a transfer; file complete.” |
| CAP | “Camera frames per second, usually about 30.” |
| DEC | “How many QR codes per second we actually read. It never needs to be every one.” |
| NEW | “Pieces that gave us new information.” |
| DUP / RED | “Pieces we already had. Harmless.” |
| x / K symbols | “The file is split into K pieces. When we have K independent ones, we’re done.” |
The fountain analogy.
“Imagine filling a glass from a fountain. You don’t care which drops land in the glass, only that enough of them do. The sender sprays an endless stream of coded pieces, each a different mix of the file. Any K of them, give or take one or two, rebuild the whole file. So if my hand shakes and I miss frames, nothing is lost. I just catch the next ones.”
Why the QR codes are small.
“We tested this with a simulated phone camera. A dense QR code gets read about 13% of the time from a hand-held phone; a smaller one gets read almost every time. Sending less per frame but reading nearly every frame is much faster overall.”
Why sound works in a noisy room.
“Each sound frame carries error-correcting parity. The receiver also knows which bytes it is unsure about, and that doubles the damage it can repair.”
Why there’s no “delivered” tick.
“The screen can’t hear back from the camera. There’s no return channel at all, which is exactly why one screen can feed any number of phones at once.”
One-to-many. If you have a third phone, point both receivers at the same sender screen at once. Both finish independently.
| What you see | What to do (calmly) | What to say |
|---|---|---|
| Receiver stuck on SCAN | Move to about 20 cm; get the whole QR in the brackets; tap the preview to focus; try 2× zoom; tilt to kill glare | “The camera needs to see the whole code. Let me frame it.” |
| DEC very low, counter climbs slowly | Rest elbows on the table; move out of a reflection | “Steadiness matters more than anything for a camera.” |
| Counter stops at “x / K” | Keep holding. If the sender stopped, tap Resume streaming | “Nothing is lost. The receiver keeps every piece it has.” |
| Sound: “too damaged” rising | Volume up, speaker towards the mic, move closer, or resend on Rugged | “The room is loud, so I’ll use the robust profile.” |
| Sound: nothing at all | Tap Enable microphone; check that the tone meter moves while the sender plays | |
| Silent: the Silent band 18–20 kHz meter stays flat | Media volume to max on the sender; swap the phones’ roles; otherwise switch the sender to Audible | “Not every phone speaker reaches 19 kHz. The audible band is much more dependable.” |
| Video won’t play on an iPhone | Use an MP4 sample (iOS doesn’t play WebM) | |
| Something is truly broken | Switch to the Simulation Lab and explain the design there | “Here’s the same pipeline under a simulated channel.” |
Golden rule: never restart the receiver mid-transfer to “fix” it. Progress survives re-aiming, leaving the screen and camera restarts, but pressing Clear discards it.
| Transfer | Channel / profile | Pieces (K) | Expected time |
|---|---|---|---|
| “Hello from sound!” (24 B) | Sound / Standard | 1 | ≈10 s (2.4 s if the first frame lands) |
| “sos” (10 B) | Sound / Rugged | 1 | ≈12 s (3 s if the first frame lands) |
| “Meet at gate 3” (21 B) | Sound / Silent (inaudible) | 1 | ≈19 s (4.8 s if the first frame lands) |
| 2 KB sample photo (≈3.4 KB after re-encode) | Light / Auto (160 B) | 21–22 | ≈3 s |
| 5 KB sample photo (≈8.6 KB) | Light / Auto (240 B) | 36–37 | ≈5 s |
| 10 KB sample photo (≈16–18 KB) | Light / Auto (330 B) | 50–55 | ≈8–9 s |
| 20 KB sample photo (≈32–35 KB) | Light / Auto (330 B) | 98–105 | ≈16–17 s |
| Speed of light, 78 KB video | Light / Auto (330 B) | 243 | ≈38 s |
| How QR codes work, 136 KB video | Light / Auto (330 B) | 422 | ≈65 s |
Derivations: Calculations. Photos are re-compressed at send time and grow by about 60–70% (Known Issue 4.1); the table uses the measured sizes from Media Pipeline §8. Don’t send the 5 KB samples by Sound: they end up over the 8 KiB Sound limit.
| Question | Short answer |
|---|---|
| Is it encrypted? | Not yet. Anyone who can see the screen or hear the sound could decode it. See Security. |
| How far does it work? | Light: 15–25 cm. Sound: across a table, up to a couple of metres in a quiet room. Vibration needs the phones touching, but it’s experimental and not reliable yet. |
| Why not just use Bluetooth? | The point is communication with no radio at all: air-gapped, radio-silent or emergency situations, and one-to-many broadcast with no pairing. |
| How fast is it? | Light: about 1.3–2.5 KB/s in practice. Sound: 11–36 bytes per second audible, 3.4–5 bytes per second silent. |
| Why can’t I hear the Silent mode? | It plays one tone at a time at 18.3–19.9 kHz, above most adults’ hearing and above nearly all room noise. Same error correction and fountain code as the audible band. See Sound Channel §14. |
| Why FSK and not ASK or PSK? | Loudness (ASK) changes with distance and echoes, and phase (PSK) is scrambled by echoes, hand movement and the two phones’ unsynchronised clocks. Frequency survives all of that, so the receiver only picks the loudest of 16 tones. See ADR-10. |
| How many ms per bit? | Each tone carries 4 bits. Standard plays 8 tones for 93 ms: 2.9 ms per bit raw, 4.6 ms per bit after error correction. Silent plays one tone for 46 ms: 11.6 ms per bit raw, about 25 ms after error correction. |
| Can we see the frequencies? | Yes: Sending now on the sender and Hearing now on the receiver, in kHz, with a spectrum strip. |
| What if frames are lost? | The fountain code makes lost frames irrelevant. Only the number of good frames matters. |
| Can many phones receive? | Yes, for Light and Sound. Every receiver finishes independently. |
| What is the adaptive part? | The engine scores channels on throughput, reliability, latency, confidence and stability, and switches with hysteresis. Today it runs in the Simulation Lab and developer tools; in Send/Receive you pick the channel yourself. See Adaptive Engine. |