Saved SPI option 9, 23 October 2026

Status: Passed native, build and V3/V4 setting checks. Firmware source: d6853f4521b6676298260c1c49095369a106000e.

get radio.fast.caps
set radio.fast.spi 9
get radio.fast.spi

The integer label 9 selects 8,888,888 Hz, approximately 8.889 MHz. It does not select 9,000,000 Hz. The setting is saved without floating-point storage or a file-format change. 0 restores the board's original default.

Availability and defaults

The option is advertised by tunable radio HALs on the supported ESP32, ESP32-S3 and ESP32-C3 boards when the permitted clock is at least 8,888,888 Hz. The pinned ESP32-C6 core cannot select this divider and does not advertise it. Current nRF52, RP2040 and STM32 radio buses do not offer it either. Unsupported selections are rejected before changing or saving the policy.

Seven older ESP32 targets now use a tunable bytewise HAL: Heltec V2, GEPRC Linkflow 900, T3S3 SX1276, T-Beam SX1276, T-LoRa V2.1, Meshnology W12 and Waveshare ESP32-S3 LR1121. They retain their 2 MHz default, existing pins, SPI controller, bus ownership and byte transfers. Existing buffered targets retain their defaults too; enabling this option does not enable 16 MHz on targets that previously lacked it.

The existing capability record remains two bytes and the saved policy remains 24 bytes at format version 1. Native tests cover strict integer parsing, actual SPISettings mapping, unavailable choices, clock limits, saved and early boot restore, transaction failure handling and output bounds. The constructor test executes all eleven paths in the seven older targets. A further CLI case covers clock-only radios with no other acceleration features.

Builds and physical checks

Canonical builds passed for V3 Full observer MQTT Repeater, V4 Full observer MQTT Repeater, Heltec V2 BLE Companion and XIAO ESP32-C3 USB Companion. Their normal capacity and capability checks passed without feature reductions. The first C3 attempt was stopped during a slow dependency download; the final build used the identical cached, pinned RadioLib commit.

Both physical repeaters were updated through application-only USB writes. Complete application readback matched the candidate images, partition tables and OTA selection metadata stayed unchanged, and readable saved settings were preserved.

Physical board	Verified body	Saved 9 after one normal reboot	RX profile switch count	Switch errors
Heltec V3	`B05EC4F8E75A2A24`	Passed, 8888888 Hz	8 to 332	0
Heltec V4.3 OLED	`C4E28F80E5FBDF2E`	Passed, 8888888 Hz	15 to 329	0

The short runtime check used primary 917 MHz and secondary 918 MHz, both BW 62.5 kHz, SF7, CR5, preamble 32, with the secondary receive-only. No test packets were deliberately transmitted. Core flags stayed zero and watchdog recovery counters did not increase within either measured startup epoch.

Both boards retain the normal new firmware with the option available. Cleanup restored their original selection 0 at 8 MHz, all seven fast features on, radio2 off, temporary profiles cleared and their saved preferences unchanged. The deliberate reboot resets volatile counters; it is recorded separately from unexpected recoveries.

Production getters report the requested/resolved SPISettings clock. They are not hardware-divider measurements. The earlier physical V3/V4 comparison verified the 80 MHz / 9 divider; this change adds a saved selector for the same requested clock. The timing campaign was not repeated. These checks qualify saving, reboot persistence and retune liveness, not RF packet delivery, BLE, CPU sleep or all firmware roles on physical hardware.

The sanitized evidence includes build and hardware results and hashes of the retained private receipts. Raw device identities and CLI logs are excluded.