Firmware Receiver v12

Receiver firmware v12

Released	2026-05
Status	Superseded by v13
Pairs with dongle	v8+
Predecessor	v11
Notable	Critical mid-show stability fix.

Downloads

File	Purpose	Download
os4_receiver_v12.bin	App partition.	Download
os4_receiver_v12.bootloader.bin	Chip bootloader.	Download
os4_receiver_v12.partitions.bin	Partition table.	Download
os4_receiver_v12.boot_app0.bin	OTA "next-app" pointer.	Download

Release notes

Don't abort the show on radio dropout + clock-domain fix.

• The disconnect detection used now = millis() + clock_offset for lastCmdReceived but recomputed now with the latest clock_offset on the following loop iteration. A CLOCK_SYNC inside the same iteration would mutate clock_offset, so the next iteration's now - lastCmdReceived included the entire clock-offset delta — enough to trip the 5 s floor on any meaningful clock jump (e.g. an msync at daemon restart, or jitter compounding over minutes), even though no real time had elapsed. That manifested as a quick magenta ANIM_FLASHING_PURPLE flash mid-show and the receiver halting all subsequent cue fires. We now track lastCmdReceived in raw millis() so the disconnect math is monotonic and unaffected by clock-offset updates.
• Even on a real disconnect, we no longer clear isPlaying. The show is loaded locally with absolute synchronized fire times — a brief RF dropout doesn't invalidate any of that, and aborting the autonomous schedule is exactly the wrong response. The radio is still re-armed and we still flash purple so the operator sees the blip, but cues continue to fire on the loaded schedule. The operator can hit STOP if they want a hard abort.

Upgrade notes

• Strongly recommended for anyone running shows on v9–v11. Without this fix, a clock-sync inside an unlucky main-loop iteration could pseudo-disconnect the receiver mid-show and silently halt firing.
• No wire-protocol changes.

How to flash

• Wired only — pre-OTA (which lands at v15). Flashing a receiver.