Root cause of FM/DAB "stonata" audio: xtalCtun=31/nominal XTAL_FREQ
defaults were never measured against this board's actual crystal
(Abracon ABM8-19.200MHZ-10-1-U-T, CL=10pF, two external 15pF load
caps). Fixed via CTUN trim by ear (31->0) plus a new live calibration
loop that reads the Si4684's own FM_RSQ FREQOFF field (broadcast
carriers are GPS-locked, so it's a free precision frequency reference)
to trim XTAL_FREQ with no lab equipment. Converged to CTUN=0,
XTAL_FREQ=19199750 Hz, residual -3/-4 ppm cross-checked on two
stations.
New tools/infrastructure (kept, not one-off):
- Si4684Driver::recalibrateXtal() + POST /api/tuner/xtal-calibrate:
live crystal re-trim without an ESP32 reflash.
- FM_RSQ FREQOFF exposed as "freqoff_ppm" in GET /api/tuner/status.
- tools/si4684_xtal_calibration.py: automates the trim loop.
- tools/si4684_antenna_calibration.py: AN851 Appendix A ANTCAP/VARM/VARB
sweep tool (same session, separate calibration).
- CONFIG_ESP32_I2S_TEST_TONE (off by default): isolates Si4684-specific
audio issues from shared-downstream ones by writing a tone directly
over the I2S bus the Si4684 also uses.
- SIGMA_WRITE_REGISTER_BLOCK/sigma_safeload_block now retry on NACK and
verify via read-back instead of firing I2C writes blind.
- FM de-emphasis set to European 50us (was left at the US 75us default).
- DAB_ACF_ENABLE restored to its previous 0x0000 with a citation
explaining why (tested the datasheet default of 0x0003, made things
audibly worse).
See docs/si4684-rf-investigation-report.md's 2026-08-23 entry for the
full elimination chain and docs/TODO.md for follow-up work (persisting
calibration results to EEPROM instead of requiring a firmware edit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
RESET# (pin 8) is no longer driven at all: reconfigured as a floating
input relying entirely on the module's own internal pull-up per
datasheet §4.8, as a diagnostic test to rule out host-side RESET# drive
as a contributor to intermittent boot failures.
SYS_CTRL (pin 34) now performs a genuine LOW(2.5s)->HIGH power-cycle on
every resetAndInitOnce() call rather than being asserted once ever:
previously every later retry from bt1035RetryTask silently reused an
already-HIGH SYS_CTRL line without ever actually power-cycling the
module.
Added read-only diagnostics on the CTS/RTS pins (physically wired,
named in board_pins.hpp since their original definition, never
configured by any driver code, host flow control disabled) to observe
their level around the boot-banner wait, after reviewing a sibling
project's PinScope report and re-reading the datasheet's UART flow
control and PA_MUTE default-function documentation.
Across ~45 minutes of live testing after these changes, zero successful
boots were observed - inconclusive on whether this improves anything,
but each change is independently correct per the datasheet. Escalated
to Feasycom support with the full findings. Documented in the RF
investigation report and TODO.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Git archaeology traced the boot sequence back to fd9d4ae (2026-08-15,
documented 5/5 clean boots), which removed a redundant AT+RESET and added
the boot-banner listen window in a single commit. Comparing that
validated design to today's working tree found one real structural
deviation: an intra-boot() retry loop (2 attempts, only 300ms between
hardware reset pulses) added earlier today, which never existed in the
validated baseline. The BT1035 datasheet's own Reset Protection timeout
(typically >1.8s) means a second pulse fired only 300ms later may not
reach a clean power-off state before repowering.
Removed the intra-boot() retry loop entirely (kBootAttempts,
kBootRetryDelayMs deleted) — boot() now makes exactly one attempt per
call, matching fd9d4ae. Retries remain exclusively at the
bt1035RetryTask level (whole clean boot() calls, confirmed live at
~31.8s apart). Banner wait (25s) and GPIO readback left untouched.
Documented the full commit-by-commit analysis and live test result
(structurally correct, hit-rate inconclusive on this sample) in the RF
investigation report and TODO for future sessions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BT1035 boot can fail with total UART silence even after the banner-timing
fix, on otherwise-identical, correctly-powered hardware. Confirmed via
multimeter (VBAT_IN, 1.8V_OUT, SYS_CTRL/RESET, TX all normal) and by
observing the same physical module both succeed and fail across different
boot attempts in one session, that this is intermittent, not a dead
module — the crystal is sealed inside the module and not inspectable or
fixable from our side.
Since the fault self-clears on a later attempt, mitigate with an
indefinite background retry task: if the initial boot() fails, keep
retrying with no artificial delay (each attempt already takes ~25-60s) so
a temporary failure becomes a bounded, self-recovering delay instead of
requiring a manual power cycle. Documented the full diagnostic session,
including the ruled-out theories and a possible future ESP32-S31 (native
Bluetooth Classic) migration path, in the RF investigation report.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extend the FM-only ANTCAP antenna-varactor override to DAB, mirroring the
existing mechanism end to end (driver, tuner, service, EEPROM storage,
HTTP API). Live sweep on real hardware found no ANTCAP value beating
auto-tune on the ensembles tested, so DAB stays on auto-tune by default.
Also fix BT1035 boot: the module's real boot banner doesn't appear until
~18-24s after RESET# releases, not the 3.5s previously waited; add a
2-attempt retry and a baud-rate probe fallback for diagnostics.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
readDabServiceData(): 6 of 7 response fields (dataSrc, serviceId,
componentId, byteCount, segmentIndex, segmentCount) read one byte too
early, using the old raw[4]=RESP4 convention instead of the correct
raw[5]=RESP4 (established elsewhere in this driver by getPartInfo() and
readDabDigRadStatus()'s own ficQuality/cnrDb fields). dataSrc landing on
the wrong byte meant the DAB dynamic label (PAD/now-playing text) check
(dataSrc == 2) could essentially never match — it has likely never worked.
Header buffer grown 24->25 bytes to fit the correctly-positioned last field.
fetchDabServiceList(): didn't match AN649 Table 14's "DAB/DMB Digital
Service List" layout at all — serviceCount read from the wrong byte, every
per-service field misaligned, componentId assumed 4 bytes wide (actually
2 per the spec), and only the first of a service's possibly-several
components was ever skipped past (desyncing every later entry). Rewrote
against the actual Table 14 field layout. Confirmed live yesterday this
was producing garbled service_id/component_id/label output
(component_id values decoding as literal ASCII spaces).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
readFmRds(), readDabDigRadStatus()'s acquired field, and
readDabEventStatus() all read raw[4] expecting AN649's RESP4 field, but
this driver's own established convention (getPartInfo(), and the
already-correct ficQuality/cnrDb fields in readDabDigRadStatus() itself)
is raw[5]=RESP4 (raw[0]=SPI lead-in, raw[1..4]=STATUS0-3). This is why
DAB_GET_EVENT_STATUS's serviceListReady never set — it was reading
STATUS3's ERRNR bit instead of RESP4's SVRLISTINT bit, so
/api/tuner/services returned service_list_empty forever regardless of lock
quality. Fixed all four sites; readFmRds()'s fifoUsed/blockA-D were
consequently also off by one and fixed together with it.
Confirmed live: first DAB ensemble locks in this project's history (3 found
sweeping freq_index 0-35, fic_quality=100, best CNR 20 dB on index 23), and
/api/tuner/services now returns real entries instead of service_list_empty.
The service-list entry contents themselves are still garbled (a third,
separate bug in fetchDabServiceList()'s body parsing, documented but not
fixed this session — see docs/si4684-rf-investigation-report.md).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Two independent bugs silenced the digital audio path from Si4684 into the
ADAU1701 even after the FM/DAB tune fix produced a real RF lock:
1. Si4684Driver::configureAfterBoot() wrote PIN_CONFIG_ENABLE (0x0800) as
0x0003, enabling both I2SOUTEN and DACOUTEN. AN649: "only I2SOUTEN or
DACOUTEN can be enabled at a time. If both enabled, only analog audio
output is enabled" — the chip silently fell back to its unused analog
DAC output on every boot. Fixed to 0x8002 (I2SOUTEN + INTBOUTEN),
matching the value hitech95/si468x_dab_receiver's working ALSA codec
driver uses (SI468X_PROP_I2S_ENABLED); I2SOUTEN alone (0x0002) was not
sufficient on this hardware. Also fixed AUDIO_OUTPUT_CONFIG (0x0302),
which was being written with a stray I2S-enable bit that property does
not have (its only real field is bit0 MONO).
2. Even with the chip correctly outputting I2S, the ADAU1701 received only
static. Traced with SIGMA_WRITE_REGISTER_BLOCK live overrides of
SerialInputRegister (0x081F, baked into the compiled SigmaStudio export
at ILP=0/IBP=0): IBP=1 (input data clocked on the opposite BCLK edge)
produced real, recognizable music instead of static on a locked, strong
FM signal — first confirmed end-to-end audio in this project's history.
ILP=1 made it worse and was reverted; IBP=1 kept as a runtime override
in Adau1701Driver::boot().
Remaining noise on top of the music is attributed to antenna quality
(RSSI/SNR fluctuated significantly between retunes of the same station on
the current improvised antenna) — not yet confirmed with a proper antenna.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
writeCommand() had no way to send a non-zero ARG1, since it always
hardcoded ARG1=0x00 before the caller's payload. Every command whose real
ARG1 needed to carry a flag (STCACK, INTACK, SERTYPE, DIGRAD/EVENT ack) or
whose payload needed to start at ARG1 instead of ARG2 was silently broken:
- seekFm(): SEEKUP/WRAP never reached the chip (always ARG2=0x00), so
hardware seek always searched down/no-wrap; masked by the existing
100 kHz software-step fallback in Si4684Tuner.
- startDabService()/stopDabService(): SERVICE_ID/COMPONENT_ID shifted one
byte right of their real ARG4-11 positions, with SERTYPE landing where
the spec requires a fixed 0x00.
- readDabServiceData(): same shift, plus STATUS_ONLY was bit3 (0x08)
instead of the correct bit4 (0x10).
- clearFmStc(), readFmRsq(), readFmRds(), fetchDabServiceList(),
readDabDigRadStatus(), readDabEventStatus(): these AN649 commands have
only ARG1 and no ARG2 at all, so the old two-argument writeCommand()
could never carry their ack/status flags — clearFmStc()'s STCACK never
fired in this driver's history (masked by FM_TUNE_FREQ/FM_SEEK_START
auto-clearing STC per their own spec).
writeCommand() gains a fourth parameter, arg1 (default 0x00, preserving
every already-correct call site); each caller above now passes its flag
through arg1 instead of the payload array.
Confirmed live: first locked:true and first genuine hardware seek (not
software-fallback) in this driver's history — 87.5 -> 98.3 MHz, RSSI +12
dBuV, SNR +14 dB.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
writeCommand() always prepends a fixed ARG1=0x00 byte before the payload;
tuneFm()/tuneDab() built their argument arrays starting at what the author
believed was ARG1, so every byte landed one slot right of its real AN649
position and an extra unused byte was appended. The chip never received the
requested frequency. This is the root cause of the months-long total RF
blackout (RSQ frozen at all-zero on every frequency/ANTCAP value) previously
attributed to a QFN exposed-pad hardware defect — that hypothesis is now
overturned, confirmed live: RSSI/SNR now read real, frequency-dependent
values with zero STC timeouts after the fix.
Also make BT1035 boot failure non-fatal in HardwareBootstrap::boot() so a
companion-chip fault no longer halts the whole device (Si4684 tuning, web
UI, Wi-Fi already isolate BT1035 readiness via CompanionChipStatus).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
FM blob confirmed byte-perfect and reproduces the identical no-lock symptom
seen on DAB, strengthening the hardware-side hypothesis over firmware.
PCBWay closed the dispute without X-ray verification. Records the BT1035
AT-init root cause (software, not hardware) as a calibration note against
over-attributing intermittent symptoms to physical damage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Si4684Driver::getPartInfo()/getSysState() existed but were never called, so
their byte-offset bugs never surfaced. Wired them into a boot-time diagnostic
log (part number, firmware revision, active image, streamed blob byte counts)
to check whether the loaded DAB/FM firmware images are genuine and intact, as
an alternative explanation to the QFN exposed-pad hardware hypothesis.
Fixed two rounds of off-by-one bugs found while doing this: the fields were
initially read one byte too far right (e.g. firmwareBuild was reading a flag
byte, not a version number); the first fix undershot in the other direction
by not accounting for readRaw()'s one-byte SPI lead-in before STATUS0 (already
documented and confirmed elsewhere in this file, in pollStc()) -- caught
because the "fixed" GET_SYS_STATE reported image=192 (0xC0), the exact
signature of STATUS3 with PUP_STATE=3 seen throughout this investigation.
All three response buffers were already sized for the lead-in byte, which
confirmed the correct fix.
Verdict, captured live: blob streamed bytes match local file sizes exactly (no
truncation), GET_SYS_STATE reports image=2 (DAB active, correct), GET_PART_INFO
reports part=4684 (matches expected Si4684 part number) with a plausible
firmware revision -- the loaded DAB firmware is genuine and intact. This closes
the last plausible firmware-side explanation for the FM/DAB no-lock symptom;
docs/si4684-rf-investigation-report.md and docs/TODO.md (P4/H5) updated with
the full record and verdict.
Also noted, not yet fixed: BT1035 AT-init now fails deterministically on every
boot (was a one-off earlier this session) -- see report's Open Items.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add docs/si4684-rf-investigation-report.md: full record of the FM/DAB no-lock
investigation (crystal, front-end matching, ANTCAP sweep, continuity, leading
EP solder-defect hypothesis, PCBWay report sent) plus the separate audio
profile NVS bug found and partially fixed this session.
- Fix sigma_i2c_write() (SigmaStudioFW.c): no retry on I2C failure meant a single
transient NACK anywhere in a long safeload burst (EQ apply = ~55 sequential
transactions) aborted the whole sequence. Added a 3-attempt retry.
- Add granular failure logging (AudioService::applyProfileToDsp/persistProfile,
Adau1701Driver::applyMixer/applyEq, NvsAudioProfileStore::saveProfile error
codes) to isolate the remaining NVS-side audio profile save failure.
- Si4684Driver::tuneFm gains an optional ANTCAP argument (default 0 = unchanged
auto-tune behavior) used during this session's front-end matching sweep.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
micheleandClaude Sonnet 5