openStream() only established the TCP/TLS connection; it never checked
the HTTP status code. A 4xx/5xx response (wrong stream path, station
temporarily down, etc.) still returned a valid client handle, so
streamWhileEnabled() entered its pump loop, immediately read 0 bytes
(no body), and returned -- skipping the kReconnectDelay branch
entirely, which only fired when openStream() itself returned nullptr.
run()'s outer loop then retried immediately: a full TCP+TLS handshake
in a tight loop bounded only by network RTT, not the intended 5s
backoff -- observed live at roughly 2 attempts/second.
This mattered beyond wasted reconnects: a concurrent full FM band scan
(POST /api/tuner/scan/full, which legitimately takes 70-135s) lost its
HTTP connection outright while this loop was running, before this fix.
After adding the status-code check and routing non-2xx through the
same reconnect delay as a failed connection, the same scan completed
cleanly twice in a row under the same conditions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /api/streaming's JSON parser only accepted "http://" URLs,
rejecting any "https://" URL with invalid_json before ever attempting
a connection. Nearly every real internet radio stream today is HTTPS-
only, so this made the feature fail for essentially any station a
user would actually try.
Two changes were needed together: the parser now accepts both http://
and https://, and web_radio_stream.cpp's esp_http_client now attaches
ESP-IDF's built-in CA certificate bundle (crt_bundle_attach) so the
TLS handshake actually verifies -- CONFIG_MBEDTLS_CERTIFICATE_BUNDLE
was already enabled in sdkconfig but never wired up here. Requires
adding mbedtls to main's PRIV_REQUIRES (esp_crt_bundle.h lives there).
Confirmed live: an https:// stream URL now gets accepted by the API
and produces a real HTTP response (404, from a guessed-wrong path) --
before this fix it never reached the network at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SoftAP SSID, Bluetooth name, and mDNS hostname now use the "igiRadio"
prefix (igiRadio-<serial>, igiradio-<serial>.local), matching the iOS
app's name instead of the firmware project's repo name. Confirmed live:
igiradio-CC4DB4.local resolves, the old digiradio-CC4DB4.local no
longer does.
Also adds the app-side briefs/notes accumulated today (active_source,
volume contract, VU-meter polling, RDS availability) as a single
up-to-date file to hand to Cursor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GET /api/tuner/status and the full FM band scan always returned an
empty station_name, on every frequency, regardless of signal quality
-- confirmed live on multiple >35 dB SNR channels before this fix.
Three independent problems, found by reading the Si4684 datasheet
(AN649 Rev.2.0) instead of guessing further:
1. FM_RDS_CONFIG (property 0x3C02) was enabled (RDSEN=1) but with both
block-error thresholds at 0 ("no block errors"), so almost any
real-world RDS group -- routine with ordinary multipath/noise, even
on a strong signal -- got rejected from the FIFO outright. Raised
to the datasheet's most tolerant recommended setting (2, "3-5 bit
errors detected and corrected").
2. FM_RDS_INTERRUPT_FIFO_COUNT (property 0x3C01) was never set at all,
defaulting to 0 -- which the datasheet states disables RDSFIFOINT
permanently. Si4684Driver::readFmRds()'s "received" flag reads
exactly that bit (FM_RDS_STATUS RESP4 bit 0), so it could never be
true, and Si4684Tuner::refreshStatus()'s RDS poll loop broke out on
its first iteration every single time, before ever touching the
accumulator. Set to 1 (fire as soon as one group is queued).
3. The real bug, once groups actually started arriving:
RdsMetadataAccumulator::applyGroup() read the two Program Service
name characters from Block C and computed the segment index as
(blockB >> 1) & 0x3. Per ETSI EN 62106 §3.1.5, PS characters for
group type 0 (both 0A and 0B) are always in Block D -- Block C
holds alternate-frequency codes (0A) or a repeated PI code (0B),
never text -- and the segment address is blockB bits[1:0] with no
shift. This function had no dedicated test before now, which is
how a wrong block/bit pair could ship unnoticed: the old test
fixture encoded the same bug in its "expected" input.
Confirmed live after all three fixes: station_name and radiotext both
populate with stable, plausible content across repeated reads (not
noise) on a real broadcast signal.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Implements GET /api/audio/levels, reading all six 1×RTA level-detector
cells on demand (no background polling, no caching -- only runs when
called, per explicit request this session).
The read mechanism is the ADAU1701's documented Data Capture Register
(address 2074/0x081A, datasheet Rev.0 pp.30,36: write a (program-step,
register-select) pair to configure what the register mirrors, then
read back a 3-byte 5.19 twos-complement value). The per-meter program-
step indices are taken verbatim from SigmaStudio's own compiler output
(Firmware/ADAU1701-Firmware/IC 1_DigiRadioFinale/net_list_out2/
trap.dat), not invented -- the datasheet explicitly says these indices
must come from that compiler-generated file.
Confirmed live: all six points return distinct, plausible dBFS values,
and the output meters track a master-volume change.
Also folds two pieces of live user feedback into the app brief: the
volume slider should reach +12 dB (the firmware's real ceiling), not
stop at 0 dB, and the new levels endpoint is what a "VU meter" UI
section should poll instead of faking one.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bass Boost1/SPhat1 enhancement blocks
Replaces the 74-parameter ADAU1701 program with the new 224-parameter
SigmaStudio export. The new netlist has no mixer -- MX1 is an
exclusive selector (DC1) passing through exactly one of three stereo
pairs (radio/bluetooth/beep) instead of blending them with independent
gains. core::MixSource/MixerState are gone; core::ActiveSource plus
IDsp::selectSource() replace applyMixer()/setInputVolume() throughout
the driver/service/API stack. AudioProfile.mixer -> activeSource;
the HTTP "mixer" JSON object -> a single "active_source" string.
DC1 turned out to need a raw 32-bit integer (0/1/2), not the 5.23
fixpoint its compiled TYPE_DC1 macro implies -- confirmed live by
writing both encodings and listening for which one actually switched
sources. Documented in Adau1701Driver::selectSource() and
adau1701::paramSourceIndex().
Bass Boost1 and SPhat1 are real ADI algorithm blocks in this revision,
so core::applyEnhancementsToEq() (the old EQ-band-overwrite hack for
bass/stereo enhancement) is deleted; IDsp::setBassBoostLevel()/
setStereoSpreadLevel() scale each block's compiled coefficients toward
identity/unity instead. Confirmed live: Bass Boost audible on real
program content (not a static test tone -- the algorithm is dynamics-
based), Stereo Spread audible but subtle. The EQ "locked" flag from
2026-08-24 (enhancements silently overwriting manually-set bands) no
longer applies to bands 1-5.
A full sweep of all 223 non-DC1 named parameters (writing each back to
its own compiled default) completed with zero failures, confirming the
whole new address space is reachable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the new SigmaStudio project export (Sigmastudio.zip, source
screenshot) alongside the existing project archives in Sigmastudio/,
rewrites docs/adau1701-sigmastudio-analysis.md for the 224-parameter
program (exclusive source mux replacing the old mixer, Bass Boost1/
SPhat1 dedicated blocks, unimplemented VU-meter readback), adds the
DigiRadioFinale figure/table to the manual, and adds a brief for the
iOS app side (active_source API shape, enhancement semantics change)
to hand to Cursor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every boot path constructs SigmaStudioTcpServer as a named local,
start()s it, then moves it into NetBootstrap. The moved-from local's
own destructor still runs stop() right after, which used to do an
unconditional activeListenFd().store(-1) -- clobbering the singleton
the moved-to (real, running) instance had just inherited. From then on
acceptLoopTask() called accept(-1, ...) == EBADF forever, on every
single boot, breaking every SigmaStudio Remote Connection attempt.
stop() now only clears the singleton via compare-exchange against its
own listenFd_, so a moved-from husk with no fd of its own leaves the
real instance's registration alone. Keeps a recreateListenSocket()
self-heal in acceptLoopTask() as a safety net for EBADF from any other
future cause, though it's no longer expected to fire in normal
operation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
designPeakingEq() mapped the RBJ cookbook's a1/a2 straight into the
ADAU1701 Param EQ cell's A0/A1 registers. The cookbook's difference
equation subtracts the feedback terms; the ADAU1701 cell adds them. Any
nonzero band gain therefore applied positive instead of negative
feedback at the target frequency, so the biquad's state diverged and
railed to a constant (inaudible DC) value -- the "any EQ/enhancement
change goes completely silent, even the beep test tone" bug.
Confirmed live: SigmaStudio's own direct safeload writes to the same
registers (correctly signed by its own tool) only distorted, never
silenced, which pointed at this driver's own coefficient math rather
than the DSP chain or the safeload mechanism itself.
Adds a host test asserting Jury stability for the ADD-convention
denominator across the actual bass/stereo-enhance gain values and the
GainDb range extremes, so a regression trips ctest instead of requiring
a live listening test to notice.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause (found via SigmaStudio firmware analysis requested this
session): NVS was initialized AFTER HardwareBootstrap::boot(), which
internally calls AudioService::loadAndApply() to restore the saved
mixer/EQ/master-volume profile. Every nvs_open() inside
NvsAudioProfileStore::hasProfile()/loadProfile() failed with
ESP_ERR_NVS_NOT_INITIALIZED (0x1101), silently swallowed as "no saved
profile" -- the audio profile was never actually restored on any boot,
regardless of how many times it was saved via PUT /api/audio/profile.
Fixed by moving secure_store::initEncryptedStorage() to the top of
app_main(), before HardwareBootstrap::boot() (nvs_flash_init() has no
hardware dependency, so this is safe).
Second, related bug: HardwareBootstrap::boot() called
AudioService::applyRadioFirstMix() unconditionally right after
loadAndApply(), discarding any just-restored mixer/master values on
every boot. loadAndApply() now returns whether it actually restored a
profile from NVS; the radio-first fallback only applies when nothing
was saved.
Verified live: a distinct mixer+master+5-EQ-band test pattern now
survives a full reboot exactly as saved (previously always reset to
factory default). DAB/FM/BT unaffected.
Also: added a "locked" flag per EQ band in the audio profile JSON --
band 0 is always locked (fixed high-pass, Adau1701Driver::applyEq()
never safeloads it) and bands 1-2/3-5 are locked whenever
bass_level/stereo_level is active (core::applyEnhancementsToEq()
overwrites them with formula-derived values). This was previously
undiscoverable from the API -- GET echoed back the stored, inert value
with no indication it wasn't what was actually playing.
Full register-by-register analysis of the compiled SigmaStudio program
(signal chain, all 74 Parameter RAM addresses grouped by function, HTTP
API mapping, every endpoint tested live) in
docs/adau1701-sigmastudio-analysis.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends the existing FM/DAB ANTCAP EEPROM persistence pattern
(Eeprom24aa::writeFmAntCap/writeDabAntCap) to the crystal trim found by
POST /api/tuner/xtal-calibrate, which previously only applied live and
was lost on every reboot.
- Eeprom24aa gains readXtalCalibration()/writeXtalCalibration() at word
addresses 0x02 (ibias), 0x03 (ctun), 0x04-0x07 (xtalFreqHz,
big-endian), right after the existing FM/DAB ANTCAP bytes.
- HardwareBootstrap::boot() now boots ADAU1701 before Si4684 (needed so
the EEPROM read, which borrows ADAU1701's I2C bus, can happen before
Si4684's boot() call, which takes the crystal trim as an argument),
loads the saved trim if present, and falls back to the compiled-in
defaults (ibias=72, ctun=0, xtalFreqHz=19199750) otherwise.
- POST /api/tuner/xtal-calibrate now persists every successful live
recalibration automatically ("persisted":true/false in the response)
via a new saveXtalCalibration()/net::AntennaCalibration::saveXtal
bridge, mirroring the ANTCAP save pattern.
Verified live: boot log confirms "Xtal not calibrated" before the first
save, "Xtal calibration loaded: ibias=72 ctun=0 xtal_freq_hz=19199750"
after, surviving a reboot; DAB/FM tuning unaffected (DAB CNR 17-19dB,
locked).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- NvsAudioProfileStore used the key "audio_profile_json" (18 chars),
exceeding NVS's 15-char key-name limit. Every nvs_set_str call failed
silently with ESP_ERR_NVS_KEY_TOO_LONG (0x1109): applyProfile() always
updated live DSP audio correctly, so the bug was invisible except as
"store_failed" in the HTTP response and settings never surviving a
reboot. Renamed to "audio_profile" (13 chars); confirmed live, EQ/mixer
changes now persist across a reset.
- The hand-rolled JSON extractJsonString()/extractJsonBool() helpers
(duplicated per-file: TunerJson, DspParamJson, StationListJson,
WebRadioJson, WifiProvisionJson, AudioProfileJson, plus inline mac/name/
save parsing in BluetoothJson) matched only the exact literal
`"key":"value"` / `"key":true`, with no tolerance for a space after the
colon. Standard JSON encoders (e.g. Swift's JSONEncoder in its default,
non-compact mode) emit `"key": "value"`, which silently failed to parse
as invalid_json/missing_field. Numeric fields were already fine
(strtoul/strtof skip leading whitespace per the C standard); fixed only
the string/bool extractors to skip whitespace after the colon before
matching the value.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 2026-08-16 IBP=1 override (commit 6974095) was applied alongside a
separate, simultaneous fix to Si4684's PIN_CONFIG_ENABLE and credited
with turning static into audible music. SerialInputRegister (0x081F) is
a single register shared by every SDATA_INx pin on the ADAU1701, so the
override also applied to the ESP32 streaming input, not just Si4684's.
Live A/B testing today (DAB, FM, and ESP32 web-radio, all isolated via
mixer gain, with and without ADAU1701 DSP bypass, with and without BT
A2DP codec changes) narrowed the hiss to this one shared register.
Removing the override and leaving IBP at its compiled default (0x00)
resolved the hiss on both the Si4684 and ESP32 paths, confirmed by ear.
Also:
- Add a runtime HTTP API (GET/POST /api/bluetooth/a2dp-codec) to change
the BT1035 A2DP codec bitmask without reflashing, used to rule out
AAC/SBC codec choice as a contributing cause.
- Extend the ADAU1701 boot-time EQ diagnostic to read back all 6 bands
(previously band 0 only) using the correct 5.23 fixed-point format.
- Note EEPROM persistence for ANTCAP/crystal calibration as TODO.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
The Feasycom BT1035 programming user guide's own pin table (§2.2, pin
34 SYS_CTRL) reads "Delay 100ms, pull high" -- the previous reset
sequence here asserted SYS_CTRL high at the very same instant as
RESET, with zero lead-in delay, racing the module's own documented
power-on requirement (the datasheet's §4.7 separately confirms
SYS_CTRL must be asserted >20ms before internal regulators even start
powering up). Rewrote resetAndInitOnce() to hold both pins low for a
100ms lead-in matching the guide exactly, then bring SYS_CTRL high,
then an extra 50ms settle margin before releasing RESET into a module
that's had a chance to actually power up first.
This is verified correct against the manufacturer's own documented
timing and is worth keeping regardless of its effect on any one
symptom, but it does NOT fully explain this project's intermittent
BT1035 boot failures ("no spontaneous UART bytes after hardware
reset"): a deep investigation session confirmed the same failure
still occurs, at the same rate, across genuine physical power cycles
(not just soft resets) with this fix applied, extended UART listen
windows (tested up to 10s vs the normal 3.5s), and independently
schematic-verified-correct GPIO pin assignments, UART TX/RX wiring,
AT command bytes, and shared 3.3V regulator sizing. Unlike the
Si4684 ARG1-offset bug earlier this session -- which failed 100% of
the time, deterministically, from a real code defect -- this failure
is non-deterministic across identical power-on sequences with
identical code, which does not match a firmware logic-bug signature.
Root cause remains open; see docs/si4684-rf-investigation-report.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
BLE provisioning used protocomm Security1 with the device serial
number as proof-of-possession, on the reasoning that pairing should
require reading something off the physical unit. In practice the
companion app has no easy way to read that serial without a manual
step, so it was deriving the PoP from the BLE advertising name
instead (DigiRadio-XXXX -> XXXX) -- but that name is broadcast openly
to any scanner, so it was never actually secret. The PoP added
app/firmware coupling (an exact-match string derived independently on
both sides) without adding real secrecy, and a mismatch there was
silently blocking provisioning entirely. Switched to Security0 (no
PoP, no encryption) -- the same trust level as the SoftAP setup path
this runs alongside, which is already an open network.
Separately, bumped the nvs partition from 24 KiB to 64 KiB. The small
original size was a suspected contributor to intermittent
NvsAudioProfileStore::saveProfile() store_failed under this project's
accumulated write traffic (wifi creds, station_list,
audio_profile_json, last_preset) -- flagged but not applied in an
earlier commit today. otadata/nvs_keys/phy_init shift forward to make
room; they still fit before ota_0's existing 64 KiB alignment
boundary, so ota_0/ota_1/dsp stay at their original offsets. Applied
via idf.py erase-flash flash (required whenever partition offsets
move) and verified: fresh boot enters SoftAP + BLE setup mode with no
partition-table warnings, and the previously-saved FM ANTCAP
calibration (stored in the 24AA025E48 EEPROM, unaffected by the NVS
partition change) still applies automatically after re-provisioning
Wi-Fi.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
BT1035Driver::boot() had zero retry on the reset+AT-init sequence — a
single hardware RESET# pulse followed immediately by AT commands,
with no second attempt if the module didn't come up in time. This is
the most plausible explanation for the intermittent "no spontaneous
UART bytes after hardware reset" / "AT init failed" boot failures
logged in docs/si4684-rf-investigation-report.md and observed again
live this morning on otherwise-identical hardware/wiring — classic
power-up timing jitter, not a permanent fault. Extracted the reset+
init sequence into resetAndInitOnce() and wrapped it in a 3-attempt
retry loop with a short delay between attempts; the one-time GPIO
config and UART driver install stay outside the loop since they don't
need repeating. Root cause of the underlying jitter is still open.
BluetoothJson.hpp was the only *Json.hpp module in the core with zero
host test coverage (status/scan/paired serialisation, auto-reconnect/
connect/speaker parsing) — every sibling module already has one.
Added bluetooth_json_test.cpp following the existing tuner_json_test
pattern; ctest now covers 20 suites instead of 19.
Documentation catch-up, found doing a full firmware re-review at the
user's request:
- POST /api/tuner/calibrate-antenna and the antcap field on
POST /api/tuner/tune (added in a previous commit, never documented)
are now in ch-api.tex.
- kFirmwareVersion was still hardcoded "0.8.5" despite the RF fixes,
BLE provisioning, phone streaming, antenna calibration, and generic
DSP param API landed since that version's actual release commit
(0a1188a). Bumped to 0.9.0 everywhere it's mentioned (health JSON,
the manual's title page, intro, classes, and API chapters).
- instructions.md and docs/TODO.md still described the firmware as
frozen at 0.8.5 awaiting hardware-in-the-loop testing that has since
happened extensively; docs/TODO.md's H5 verdict specifically still
said "suspect U6 RF ground (re-open PCBWay)" for a bug that turned
out to be firmware, not hardware — actively misleading, corrected.
Both files now summarise the post-0.8.5 HIL findings and current
open items (BT1035 root cause, intermittent HTTP unresponsiveness
under load, antenna-limited signal quality, possibly-undersized 24 KB
nvs partition).
Verified: idf.py build, doxygen (0 warnings), check-manual-sync,
check_si4684_blobs, ctest (20/20), two-pass xelatex manual build all
green. Flashed and confirmed live: fw reports 0.9.0, BT1035 booted on
the first attempt post-flash.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Retesting DAB service-list retrieval later the same night (after the
service-list body-parsing fix and antenna calibration work) found it
far less reliable than the earlier confirmation: locked with
excellent FIC quality (97-100) but GET /api/tuner/services kept
returning service_list_empty for 30-65+ seconds.
readDabEventStatus()'s SVRLISTINT bit is gated by AN649 Property
0xB300 DAB_EVENT_INTERRUPT_SOURCE, bit0=SRVLIST_INTEN, default 0x0000
(disabled) at power-on — never written anywhere in this driver.
configureAfterBoot()'s DAB branch already writes a similarly-named
DIGITAL_SERVICE_INT_SOURCE (property 0x8100), but AN649's own text
for 0x8100 is internally inconsistent between its prose and its bit
table (VHFCAPS/VHFSW, a front-end switch field) — almost certainly a
pdftotext -raw extraction artifact merging two adjacent property
tables, the same failure mode already logged this session for
AN649/adau1701.pdf extraction. Only 0xB300's own section reads
internally consistent with its own prose, so it — not 0x8100 — is the
one that actually gates SVRLISTINT.
Verified live: the service list came back complete and correct (22
real station labels) on the next test after reflashing. Not proven
conclusively faster than before given DAB acquisition timing is
inherently variable and this was only tested once post-fix, but the
property write is unambiguously correct per its own AN649 section
regardless.
Also logged, NOT fixed: intermittent multi-second HTTP unresponsiveness
(connection timeouts even on /api/health) observed independent of this
change, both before and after — heartbeat kept logging on schedule
throughout so the system didn't crash, only the HTTP server (or
something it was blocking on, most likely a Si4684 SPI/CTS wait)
stalled and recovered on its own. Root cause not yet found; details
and next-session candidates in docs/si4684-rf-investigation-report.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Confirmed live tonight that the Si4684's automatic front-end tuning
(FE_VARM/VARB properties) is measurably suboptimal on this board: a
129-value ANTCAP sweep (0-128, AN851 Appendix A) at four different FM
frequencies found antcap=102 beats auto-tune by +6 to +11 dB RSSI and
+3 to +11 dB SNR everywhere tested, consistent with the front-end
network component mismatch already logged in
docs/si4684-rf-investigation-report.md — the board's actual matching
network differs from the AN851 reference network those auto-tune
constants were derived from, so a fixed empirical override
compensates for a gap the chip's own algorithm can't see.
Wiring, bottom to top:
- Si4684Driver::tuneFm() already took an antCap byte; threaded it
through core::ITuner::tuneFm() and si4684::Si4684Tuner::tuneFm() as
a new parameter (default 0 = auto, unchanged behaviour for every
existing caller).
- TunerService::tuneFm() takes an optional override instead: omitted,
it falls back to a new defaultFmAntCap_ member so every ordinary FM
tune (seek, scan, station recall, live UI) benefits automatically
once calibrated, not just calls that pass antcap explicitly.
- POST /api/tuner/tune gained an optional "antcap" field for sweeping
live without touching the saved calibration.
- POST /api/tuner/calibrate-antenna commits a sweep result: writes it
to the 24AA025E48 EEPROM's user-writable region (word address 0x00,
separate from the factory-locked EUI-48 at 0xFA-0xFF) via a new
Eeprom24aa::writeFmAntCap()/readFmAntCap() pair, and immediately
updates the live TunerService default — no reboot needed to take
effect, though HardwareBootstrap::boot() also loads it at every
boot so it survives power cycles. Same net::AntennaCalibration
function-pointer bridge pattern as PhoneStreamSink/BleProvisioning,
so components/net stays free of eeprom24aa headers.
Verified end to end on hardware: swept and found 102, saved it via
the new endpoint, confirmed the live default changed immediately,
then power-cycled and confirmed the boot log reports "FM ANTCAP
calibration loaded: 102" and a subsequent default tune reflects it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
audio confirmed working, quality traced to signal strength not firmware
Live retest confirms both fixes from f9f3e58 on real hardware: the DAB
service list now returns 22 correctly-decoded real station labels
(was empty), and playing a selected service produces actual crackly
audio rather than silence — the first tried service (CNR 7dB) was
fully soft-muted, the second (CNR 8dB) was audible but degraded,
matching DAB's FIC-vs-audio-subchannel robustness gap rather than a
code defect. Antenna/front-end calibration promoted to the primary
remaining TODO for both bands.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Two independent live-hardware bugs found testing on real DAB signal
tonight (board reconnected after this session's feature work):
1. Si4684Driver::fetchDabServiceList() double-counted the already-
consumed SIZE field when computing the body offset: it added a
phantom "List Size(2)" on top of the 7-byte STATUS/SIZE header
already stripped out, shifting the service-count byte and every
service entry by exactly 2 bytes. AN649 documents SIZE/DATA_0/
DATA_N generically for GET_DIGITAL_SERVICE_LIST and defers the
actual DAB payload layout to a supplemental "Digital Services
User's Guide" we don't have, so the previous "AN649 Table 14"
citation for that layout was never actually sourced from AN649 —
it was guessed. Re-derived the real layout by cross-checking
hitech95/si468x_dab_receiver's si468x_core_cmd_dab_get_service_list()
(a working Linux driver for the same command), which also shows
the payload is SIZE-2 bytes, not SIZE bytes — fixed the read-length
sizing (payloadSize+5, was +7) to match. This is what made
GET /api/tuner/services always come back empty even with a locked
ensemble.
2. SetupWebServer registers 41 HTTP routes but httpd_config_t::
max_uri_handlers was still 40 (set before several endpoints landed
this session). esp_http_server's httpd_register_uri_handler()
fails silently past the limit, logging only a generic
"no slots left" warning with no indication of which handler was
dropped — the 41st and therefore last-registered route,
POST /api/stations/tune, was silently unroutable (404) on every
boot since whichever commit pushed the count past 40. Bumped to 56
for headroom.
Both confirmed on hardware: fresh flash boots with zero httpd
warnings; DAB service list fix not yet re-verified against a live
ensemble pending user retest (board was between test sessions).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Replace separate Audio/EQ tabs with a unified profile picker (built-in + local presets), keeping mixer access and applying full profiles to the device.
Co-authored-by: Cursor <cursoragent@cursor.com>
Supports POST /api/streaming for HTTP MP3 stations and phone PCM push for on-device audio files, with a dedicated Stream tab and preset for Radio Monte Carlo.
Co-authored-by: Cursor <cursoragent@cursor.com>
Adds graphic EQ, vertical mixer faders, redesigned home and FM layouts, and an Audio tab for quicker access to DSP controls.
Co-authored-by: Cursor <cursoragent@cursor.com>
Introduces a new SwiftUI app with HTTP REST device control, mock mode for UI development, BLE-based discovery, and documented architecture aligned with the firmware API.
Co-authored-by: Cursor <cursoragent@cursor.com>
ch-api.tex only covered a subset of the routes SetupWebServer.cpp
actually registers. Backfilled the ones that had grown undocumented
over the last several sessions, plus this session's three new ones:
- POST /api/wifi/scan (existed, undocumented)
- POST /api/tuner/scan, POST /api/tuner/scan/full (full FM band scan,
this session's item 1)
- POST /api/audio/beep, GET /api/dsp/params, PUT /api/dsp/param
(generic ADAU1701 parameter access, this session's item 4)
- PUT /api/stream/phone (phone PCM streaming, item 2, commit e8f79c4)
- GET/POST /api/streaming (web radio config, existed, undocumented)
- POST /api/bluetooth/scan, POST /api/bluetooth/connect,
GET/POST/DELETE /api/bluetooth/speaker, POST /api/bluetooth/reconnect
(existed, undocumented)
Also added a subsection under "Boot and network state machine"
covering BLE provisioning (commit 74c40ee) — it isn't an HTTP
endpoint so it doesn't fit the \apiendpoint table, but belongs next
to the SoftAP/STA state description it's additive to.
Verified: tools/check-manual-sync.py passes, and a full two-pass
xelatex build of the manual compiles clean (no undefined references,
no errors) with the new sections in place.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Wraps ESP-IDF's official wifi_provisioning manager (BLE transport,
protocomm Security1, NimBLE host) so a phone can join the device to
Wi-Fi over the ESP32-S3's own onboard BLE radio, without first
connecting to the 192.168.4.1 SoftAP. Chosen over a custom GATT
service specifically so the existing generic "ESP BLE Provisioning"
iOS/Android apps work today, before the dedicated DigiRadio app
exists — same standard protocol either app would speak.
net::ble_provisioning::start() is additive, not a replacement: it
runs next to the current SoftAP + POST /api/wifi HTTP route inside
NetBootstrap's startSetupMode(), and failing to start it is
non-fatal (same pattern already used there for the SigmaStudio TCP
bridge) — SoftAP setup keeps working either way. Proof-of-possession
is the device's own serial number (same source as the SoftAP SSID),
so pairing requires reading it off the unit rather than being wide
open. On WIFI_PROV_CRED_SUCCESS the received wifi_sta_config_t is
converted to the same core::WifiCredentials type the HTTP handler
uses and saved through the same ISecureStore, then the device
reboots into STA mode — one persistence path regardless of which
transport provisioned it.
BT1035 is unaffected: it's a separate UART-attached classic
Bluetooth module for A2DP output. This uses the ESP32-S3's
independent internal BLE controller, switched to NimBLE (smaller
footprint than Bluedroid, the only host stack needed for a single
peripheral-role GATT service). App binary still has 33% free flash
after pulling in wifi_provisioning/protocomm/NimBLE.
Verified: idf.py build, doxygen (0 warnings), check-manual-sync,
check_si4684_blobs, ctest (19/19) all green. Not yet tested with a
real BLE provisioning app or on hardware — board is disconnected
this session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
New endpoint accepts chunked, header-less, 16-bit LE stereo PCM @ 48 kHz
in the request body and writes it straight to the shared I2S sink for as
long as the connection stays open. Chosen deliberately unencoded (no
MP3/AAC/Opus decode) to keep this path as simple and low-risk as
possible — the companion app controls the encoding on its side.
Extracted the I2S TX channel that used to be owned outright by
web_radio_stream.cpp into main/esp32_i2s_sink.cpp, shared by both
producers with a simple tryAcquire()/release() exclusivity guard — web
radio streaming and a phone PCM stream would otherwise fight over the
same physical wire. web_radio_stream.cpp now acquires/releases around
each streamWhileEnabled() cycle instead of owning the channel itself.
net::PhoneStreamSink is a plain function-pointer struct (not a class
hierarchy) threaded through NetBootstrap::start() -> SetupWebServer::start()
-> HttpRouteContext, so components/net stays free of I2S driver headers;
main/phone_stream.cpp supplies the concrete functions (bound to
esp32_i2s_sink) and does the int16->ADAU 32-bit-slot conversion, batched
per chunk rather than per sample for the same reason as the web radio
stutter fix (6974095/7e65394 lineage).
Verified by build only — not confirmed live yet (board disconnected this
session); the actual phone app that will exercise this endpoint doesn't
exist yet either.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
New core::IDsp::writeRawParam(address, value) safeloads any named
Parameter RAM cell in the compiled SigmaStudio program (74 cells: mixer/
Beep1/PEQ coefficients/limiter thresholds/etc — the same set SigmaStudio's
own Remote Connection, components/net/SigmaStudioTcpServer, already has
full access to). Value is a plain SigmaStudio floating coefficient,
converted to ADAU 8.23 fixpoint via the existing core::floatToFixpoint823.
Adau1701ParamTable.hpp holds the name->address table extracted from
Firmware/ADAU1701-Firmware/DigiRadio_IC_1_PARAM.h; core::DspParamJson
handles the wire format without core/ depending on the adau1701 driver
(net/SetupWebServer.cpp bridges the two, consistent with how other
JSON DTOs are supplied their data by the net layer).
GET /api/dsp/params lists every cell (name + address) for discovery.
PUT /api/dsp/param {"name":...,"value":...} writes one. Deliberately no
domain validation, matching the trust level already implied by the
existing SigmaStudio TCP bridge being reachable on the same network.
HTTP routes were registered in the SetupWebServer.cpp change committed
alongside the FM band scan feature (3a10ed7).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
writeFrame() called i2s_channel_write() once per decoded PCM sample (up to
1152 separate driver calls per MP3 frame), each with its own locking/DMA
bookkeeping overhead. Now accumulates a whole frame into one buffer and
writes it in a single call.
The I2S TX channel also used the ESP-IDF default DMA config (6 descriptors
x 240 frames = ~30 ms of buffering at 48 kHz), leaving almost no headroom
against network jitter in this single-task fetch+decode+play pipeline.
Widened to 12 x 480 (~120 ms) so a brief HTTP stall doesn't immediately
starve the DMA and audibly crackle.
Both are static/architectural fixes verified by build only — not confirmed
live yet (board disconnected this session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
New TunerService::scanFullFmBand(): tunes to the band bottom then seeks up
repeatedly (reusing the existing hardware-seek + RDS-name-poll machinery
from scanForStation()) until the sweep wraps back around, collecting every
station that clears the existing scan RSSI/SNR thresholds. Returns the
list without touching saved presets or leaving the tuner in any particular
place — callers decide what to do with the results.
New POST /api/tuner/scan/full endpoint (core::TunerFmScannedStation DTO,
serializeTunerFmBandScanJson). Blocks for the whole sweep like the existing
/api/tuner/scan.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
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>
Redundant AT+RESET sent right after the hardware RESET# pulse could interrupt
the module mid bring-up; boot-banner probe window (1500ms) was too short for
the real +VER banner (~5s), causing spurious "AT init failed". 5/5 clean
boots after fix vs ~1/13 before.
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>
Streaming (main feature this session):
- New WebRadioConfig/WebRadioJson core types, ISecureStore-backed persistence
- New webradio::WebRadioService (thread-safe live config) + GET/POST /api/streaming
- web_radio_stream task now runtime-toggleable (no reboot), no hardcoded URL
- Content-Type diagnostic: warns clearly when a URL is a webpage, not an audio stream
Boot cleanup:
- Removed boot-time auto FM/DAB tune, auto-beep, and the (now-concluded) Si4684
crystal IBIAS/CTUN empirical sweep from main.cpp — tuning/beep are on-demand
via the existing REST API only
Web UI:
- Modernized styling (cards, gradients, toggle switches, light/dark theme)
- New Stream tab wired to /api/streaming
Fixes found via real idf.py build (not just clangd):
- Restored wrongly-removed si4684/Si4684Tuner.hpp include in main.cpp
- Fixed MP3Decode() argument types in web_radio_stream.cpp (unsigned char**/int*)
Quality-gate fixes:
- Host-test stub headers (esp_log.h, freertos/*) so TunerService.cpp's
scanForStation logging/pacing compiles for station_service_test /
integration_service_test instead of running stale binaries
- Added WifiScanner and WebRadioService manual sections; filled in missing
Doxygen docs on BluetoothService, i2s_sdata_probe, test_firmware, Bt1035At
- Ignore clangd's .cache/ index directory
Also includes prior uncommitted work carried in the tree: Wi-Fi/Bluetooth
device scan REST API and UI (WifiScanner, BT scan), SigmaStudio TCP bridge,
and the current ADAU1701 SigmaStudio DSP program export.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Initialise NVS before integration startup, recover from encrypted-partition mismatches without re-enabling encryption, and improve provisioning logs and POST body handling.
Co-authored-by: Cursor <cursoragent@cursor.com>
Bundle crystal, LDO, ESD, and module PDFs under Hardware/DATASHEET plus ODB++ gerbers and pick-and-place for the 2026-08-05 board release.
Co-authored-by: Cursor <cursoragent@cursor.com>
Refresh BOM (2026-07-09 CSV), Gerbers, EasyEDA project, pick-and-place, and schematic export; document corrected ADAU crystal/PLL strapping and Si4684 reference clock in the manual; add PCBWay acknowledgement on the back cover only.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add wrapping table columns, breakable paths, and ragged callout boxes in digiradio-manual.sty, then reflow long endpoint headings, JSON examples, and hardware/driver tables to stay within page margins.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add gitignore rules for aux, log, toc, fls, fdb_latexmk, listing, out, and pdf so only source .tex/.sty stay in version control.
Co-authored-by: Cursor <cursoragent@cursor.com>
Switch BT1035 bring-up from Line-In to I2S slave (AT+AUXCFG=3, AT+I2SCFG=67) to match the ADAU1701 PCM routing, confirm 2 kΩ I2C pull-ups on R1/R16, and sync firmware docs, AGENTS rules, and the DATASHEET bundle.
Co-authored-by: Cursor <cursoragent@cursor.com>
Rename conflicting TikZ step style to drstep, add missing ch:firmware label, and use TeX Gyre Heros font fallback instead of Linux Biolinum O.
Co-authored-by: Cursor <cursoragent@cursor.com>
Align README, manual, and backlog to 0.8.4; add Web UI System tab for OTA/DSP uploads, serial in health header, FM seek down, and BT1035 paired list plus auto-reconnect API.
Co-authored-by: Cursor <cursoragent@cursor.com>
Replace angle-bracket suffix placeholders that Doxygen parsed as invalid
HTML tags, restoring a clean WARN_AS_ERROR build on Ubuntu CI.
Co-authored-by: Cursor <cursoragent@cursor.com>
Stream application binaries to the inactive OTA slot via POST /api/system/ota,
validate the esp_app_desc project name in core, and cancel rollback after a
healthy network boot through OtaService::confirmBoot().
Co-authored-by: Cursor <cursoragent@cursor.com>
Decouple the SigmaStudio RAM download from compiled-in adau1701_program.c:
DRAD v1 blobs in the dsp partition with embedded fallback, POST /api/dsp/program,
and host-tested blob parse/serialize helpers.
Co-authored-by: Cursor <cursoragent@cursor.com>
Read the factory 24AA025E48 serial after ADAU I2C boot, derive SoftAP SSID, BT name, STA hostname, and expose serialNumber on GET /api/health with graceful fallbacks.
Co-authored-by: Cursor <cursoragent@cursor.com>
Replace factory with ota_0/ota_1, otadata, and a dsp data partition on 4 MB flash; enable bootloader app rollback for future OTA work.
Co-authored-by: Cursor <cursoragent@cursor.com>
Enable GPIO_PULLDOWN_ENABLE during gpio_config so RSTB cannot glitch high before gpio_set_level(0), and add manual validation notes explaining why the internal pull-down complements the external one.
Co-authored-by: Cursor <cursoragent@cursor.com>
Align root, Software, and Firmware READMEs with security, CI, web UI, blob policy, and six-band EQ details.
Co-authored-by: Cursor <cursoragent@cursor.com>
Update READMEs, manual chapters, agent guides, CONTRIBUTING, and TODO to reflect T1–T8 done, encrypted NVS, CI gates, and pending HIL checklist.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add initEncryptedStorage, development-mode Kconfig defaults, production overlay, and security HIL docs; wire NetBootstrap through encrypted NVS bring-up.
Co-authored-by: Cursor <cursoragent@cursor.com>
Expand local-only firmware README, add check_si4684_blobs.py to verify gitignore and clean history, and gate main with a new si4684-blobs workflow job.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add now-playing view with metadata polling, six-band EQ controls, full REST coverage, companion-chip badges, and gzip-www helper for the embedded setup page.
Co-authored-by: Cursor <cursoragent@cursor.com>
Document firmware capabilities, version milestones, CI, API summary, and updated project structure after integration service and metadata work.
Co-authored-by: Cursor <cursoragent@cursor.com>
Replace the services stub with IntegrationService for boot preset recall and tune orchestration, persist last preset in NVS, and remove invalid @return tags that broke CI on T4 metadata headers.
Co-authored-by: Cursor <cursoragent@cursor.com>
Ship station reorder, DAB playing ids in presets, RDS PS/RT and DAB DLS in tuner status, Si4684 data-service read, host tests, and UI now-playing lines.
Co-authored-by: Cursor <cursoragent@cursor.com>
Clear doc-block warnings so doxygen exits 0, add GitHub Actions
for host tests, Doxygen, and manual sync, and document CI in the manual.
Co-authored-by: Cursor <cursoragent@cursor.com>
Adopt the prioritised task list for the coding agent and document
fw 0.7.0 status plus the full HTTP API in Software/README.
Co-authored-by: Cursor <cursoragent@cursor.com>
Expose discoverable mode and A2DP control over REST, add persisted
DAB/FM preset list with web UI, and document gaps in docs/TODO.md.
Co-authored-by: Cursor <cursoragent@cursor.com>
Expose Si4684, ADAU1701, and BT1035 boot flags via CompanionChipStatus after
HardwareBootstrap; update API manual schema for Slice 8.
Co-authored-by: Cursor <cursoragent@cursor.com>
Remove legacy DigiRadio_Manual.tex/PDF and stub main.tex; point docs/ at the
canonical manual. Update README and CONTRIBUTING paths.
Co-authored-by: Cursor <cursoragent@cursor.com>
Implement Bt1035Driver AT init (AT+AUXCFG=1), core AT parser with host tests,
wire boot into HardwareBootstrap, and document DAB/FM tuning workflows in ch-si4684.
Co-authored-by: Cursor <cursoragent@cursor.com>
Expose POST /api/audio/stereo-enhance and bass-enhance with 0–100 levels,
persist enhancements in AudioProfile, and document the virtual EQ mapping in
the manual and SigmaStudio chapter.
Co-authored-by: Cursor <cursoragent@cursor.com>
Document the ADAU1701 schematic chain (sigma-chain.jpg), cross-link from
hardware/firmware chapters, skip safeload on fixed high-pass band 0, and
match EqProfile default peaking frequencies to SigmaStudio.
Co-authored-by: Cursor <cursoragent@cursor.com>
Safeload mixer/EQ/master on the ADAU1701, persist AudioProfile in NVS,
expose /api/audio routes and web UI controls, with host tests and manual sync.
Co-authored-by: Cursor <cursoragent@cursor.com>
Extends the gzipped page with DAB/FM tune, service list, play, and FM seek
against the /api/tuner endpoints.
Co-authored-by: Cursor <cursoragent@cursor.com>
michele
