OrcSDR v0.4.0-beta.1 — release notes

Prepared 10 October 2026. Previous release: v0.3.0-beta.2.
Source: a000b27d2f6ffc1ff6b21a13dc5c959b12e337eb on main.

This beta adds native FT8 reception, FT4 reception and limited experimental JS8 Normal reception, together with Smart VFO controls, on-device clock setup and OrcDial connection improvements. OrcSDR remains receive-only. There is no transmitter, PTT or contact-making feature.

These notes describe the source changes and recorded tests. A source tag, successful build, package validation and live reception are separate milestones. The newly numbered package still needs its own installation and hardware acceptance; the earlier development-image results below are not a claim that this exact package has already been installed.

FT8, FT4 and JS8 reception

Native decoding on the Tab5

• FT8 and FT4 now use OrcSDR's native receive pipeline on the ESP32-P4. Signal acquisition, synchronization, error correction, CRC validation and supported message unpacking run on the receiver rather than requiring a laptop decoder.
• FT8 uses 15-second receive slots; FT4 uses 7.5-second slots. A correct UTC clock matters. Incomplete slots after a retune are skipped instead of mixing samples from different frequencies.
• The receive path supplies 12 kHz analysis audio through a separate DSP tap. While decoding is active it requests a lower RTL sample rate, reducing USB traffic and DSP load; leaving the decoder releases that request and restores normal dashboard reception.
• Candidate refinement and soft decoding improve recovery of signals between search bins. Accepted messages must pass the relevant validity checks. This does not establish WSJT-X sensitivity or coverage parity.
• FT8/FT4 decode SNR estimates use the conventional 2500 Hz noise bandwidth and have synthetic calibration tests. Real antennas, receivers, interference and clipping still need wider measurement. JS8's sender-reported SNR is kept separate from a measured receive SNR.
• JS8 Normal has experimental support for the verified directed-frame message subset. Host reference captures and a dated live soak provide evidence for that subset. Other JS8 speeds and unverified frame types remain unavailable; this is not a complete JS8Call replacement.

A complete receive workspace

• LIVE: spectrum/waterfall, receive-slot timing, selected band and mode, gain access and recent messages. Waterfall energy is distinct from a valid decode.
• DECODES: paged message history with time, available signal measurements, frequency offset and decoded station/grid information. Station details distinguish first heard, previously heard and user-marked worked state; receiving a message does not create a QSO.
• MAP: offline display of decoded station-reported Maidenhead locators. A locator is not a measured transmitter position.
• HUNTER: conventional FT8 band discovery. Fast hunt measures energy; decode hunt waits for complete receive slots and distinguishes quiet, energy, synchronization evidence and valid decodes. FT4 and JS8 hunts are not yet enabled.
• HEARD: persistent station history and conditions derived from received messages and the saved receiver location, including distance, bearing and station distribution when grids are available.
• SETUP: mode selection, receiver/decoder controls and optional expert tuning. Information popups explain each tab in plain language.
• SD logging records stations heard, not contacts. Heard history uses a checked journal. Developer tools can export supported receive data and heard-station ADIF; JS8 is excluded from that ADIF export.

Touch and OrcDial controls

• The dashboard works through touch alone. OrcDial is optional.
• Expert tuning provides direct frequency entry, six step sizes from 10 Hz to 100 kHz, and small or large step adjustments. Band/mode changes discard a custom dial so stale tuning does not silently carry over.
• OrcDial supports band selection, fine tuning, tab navigation and dashboard controls. Detents are coalesced while commands are pending so quick turns are less likely to be lost.
• The gain panel exposes available automatic/manual gain controls with input-level and clipping feedback. There is no universal gain setting: automatic gain clipped in one of the owner's tests, and manual gain helped. Direct-sampling HF bypasses tuner gain.

Reliability fixes included with the digital work

• Retuning during audio collection or decoding cannot relabel a result with a later band or dial frequency.
• Dashboard entry, tab changes and gain controls received repaint and stack-use fixes.
• Waterfall graticules remain fixed while the underlying signal rows scroll.
• Mode-specific timing and information text were corrected, including FT4's shorter slot length.
• Mode changes and exits release digital-mode sample-rate state rather than leaving another dashboard at the decoder's rate.

Recorded FT8 receiver acceptance

On 9 October 2026, the owner accepted FT8 reception on all four tested dongles:

Setup: Tab5 in Springfield, Oregon; 40 metres at 7.074 MHz; externally powered MLA-30+, with dongle bias tee off. The session began on main 52cd8bd; subsequent driver checks used a build with the diagnostic self-check updates included in this release. These are bounded reception results, not a sensitivity ranking or acceptance of every band, antenna, dongle revision or hot-swap sequence.

The owner also confirmed Wi-Fi and OrcDial reconnection after a later power reboot. A watched V3c driver-test run was disrupted by the test harness; the owner accepted the dongle and treated that disruption as a harness caveat. That observation is not classified here as a receiver failure.

Smart VFO, scopes and clock setup

• Home resolves tuned frequencies to labelled US band profiles, with suitable default modes, channel rasters and per-band tuning steps. Only the US band dataset is supplied in this work.
• AUTO applies a band's usual demodulation mode; manual mode choices and step preferences can be retained per band. Frequency and demodulation mode are separate controls.
• Direct tuning, gain, mode and filter popups keep more of the spectrum/waterfall visible. Home spectrum rendering uses display smoothing and peak hold without claiming altered RF measurements.
• RGB565 waterfall colour handling was corrected across the affected radio scopes.
• OrcDial Home VFO controls include frequency steps, band information, mode, span, filter and keypad actions.
• Settings now supports local date/time entry and UTC offset selection. The RTC stores UTC; local time is a display choice. Optional NTP synchronization requires an existing Wi-Fi connection and runs on request.

OrcDial and Wi-Fi reliability

• Trusted pairing and connection lifecycle handling were improved across Tab5 and OrcDial.
• Channel locks require acknowledgement evidence from the channel actually used. Failed channel changes retain the real channel instead of recording an unaccepted choice.
• Timed-out connections receive bounded retries; disconnect, forget and cancellation clear retry intent. Saved-channel writes are checked and retried with a delay when storage fails.
• Failed ESP-Hosted initialization, connection or version negotiation can enter the existing bounded recovery path instead of leaving Wi-Fi down until reboot.
• Boot-cycle tooling records tablet, Dial and C6 observations separately. Development tests also identified C6 back-powering through a downloader adapter, which can hide a real coprocessor power reset.

Receiver diagnostics and regression testing

The integrated driver remains pinned to esp_rtl_sdr v0.9.3; this release does not introduce a new driver version.

• The firmware diagnostic self-check now recognizes Nooelec Smart V5 and checks its required capabilities.
• The host gate is named -DriverRegression; the older -Driver080Rc2 and -Driver080Rc3 switches remain aliases. Driver versions are recorded for provenance rather than used as a stale pass threshold.
• Tests check receiver capabilities, exact requested/applied frequencies, HF routes, active IQ delivery, getter health, gain/AGC transitions and restoration.
• Nooelec V5 probes respect the driver's 100 kHz–1.75 GHz limits. Out-of-range requests must be rejected without disturbing the stream.
• Gain/AGC writes are exercised on a tuner frequency, rather than assuming tuner gain acts on direct-sampling HF.
• A stopped stream cannot pass merely because its accumulated byte count advanced. Restoration uses bounded polling and must succeed before the overall gate reports a pass.
• Driver-mode reset tests preserve the splash gate and normal startup staging. Bias-tee testing remains off by default.

These are diagnostic and host-harness changes. The self-check update does not change receiver tuning, gain processing, DSP, decoder behavior or waterfall rendering.

What was verified

• All four dongles received FT8 in the owner's dated setup above; the owner accepted the receiver test round.
• The digital-mode host regression suite passed, including optimized and sanitizer variants, synthetic SNR checks and OrcDial semantic controls. FT8 diagnostic tests also passed.
• P25, POCSAG, pager storage, radio scan and web-audio host suites passed during the pre-release regression session. Python repository and tooling tests passed.
• Focused driver-harness tests pass, including stopped-stream rejection, delayed restoration, initial RTL AGC restoration and rejected restoration responses. Runner and release-readiness self-checks pass.
• Documentation truth checks pass. PR #182's documentation and user-guide CI checks passed after review fixes.
• CodeRabbit completed the initial review of PR #182. Its five findings were addressed or supported with evidence; a completed follow-up review was not established before the owner authorized merge.
• A clean native ESP-IDF 5.5.4 build from merged a000b27d completed. The initial untagged merged image's bootloader, partition table and application matched the built components. The numbered package also rebuilt successfully: its application reports v0.4.0-beta.1, the merged binary has SHA-256 5e9469eafc3042e79c3b4d5270c5feb152bbf82a1a7045618f38c76b13f2b523, and test-m5burner-bundle.ps1 passed its manifest, embedded-C6, checksum and ZIP-content checks.

The final restoration/startup harness refinements were host-tested, not rerun on all four physical receivers. The whole release-readiness pipeline was not green end to end: the Wi-Fi host harness hit a host strlcpy declaration conflict, and LoRa corpus validation lacked dependencies/captures. These are validation gaps, not demonstrated FT8 RF failures.

Work still to do

PSK Reporter integration

PSK Reporter was used externally to choose active bands and compare station activity during testing. OrcSDR does not yet provide an integrated PSK Reporter service or automatic upload in this release.

Planned follow-up:

• Optional nearby/global band-activity lookup using the user's area or locator, to help select a band. External reports must remain separate from signals actually received by OrcSDR.
• Opt-in upload of eligible decoded reception reports, with clear receiver identity/location settings and reporting controls.
• Service-compliant polling, batching, rate limits, network-failure handling and duplicate control. Final service/API choices and acceptance tests remain to be designed.
• Keep core reception, decoding, maps and local history usable offline. Nothing should be uploaded merely because a user opens the FT8 dashboard.

Decoder and RF validation

• Broaden FT8/FT4 message-type and difficult-signal coverage; contest types and full reference-decoder parity are not claimed.
• Extend JS8 beyond the verified Normal directed-frame subset: independently verify other frame layouts, heartbeat/CQ handling, multi-frame assembly and additional speeds before enabling them.
• Enable FT4/JS8 Hunter only after their frequency tables and hunt behavior are verified.
• Expand exact-sample reference fixtures pairing captured IQ/audio with independent decoder outputs. PSK Reporter activity alone cannot prove an exact decoded message or zero false decodes.
• Measure current ESP32-P4 timing and load after decoder optimizations, widen long-duration testing, and compare automatic/manual gain on more antennas and receivers.
• Extend real-RF SNR and frequency calibration; add a user-facing SNR trim control if warranted. Existing synthetic results are not universal antenna performance claims.

Release and documentation follow-up

• Install and accept this exact numbered package on hardware; validate normal startup, Wi-Fi, OrcDial, reception and settings behavior.
• Complete the separate Wi-Fi host and LoRa fixture/dependency gates.
• Capture fresh screenshots and update the visual guides later. No new screenshots of this numbered package are claimed.
• Publish the reviewed FT8 wiki pages carried in PR #182. They are staged in the source repository; the live GitHub wiki is a separate repository.

Installation and saved settings

The M5Burner/webflasher image is a merged ESP32-P4 Tab5 binary written at 0x0. It spans the NVS region and resets saved settings, including Wi-Fi profiles, location and preferences. The current inspected M5Burner Share Burn implementation also requests full flash erase; no official NVS-preserving webflash option was confirmed.

For a settings-preserving update, use the established separate-region installer method: bootloader at 0x2000, partition table at 0x8000, application at 0x10000, compatible partition layout and no full erase. See M5Burner installation and recovery.

The application embeds the pinned optional ESP-Hosted 3.0.6 C6 update image. Installing the P4 package does not itself flash the C6; the existing Settings workflow controls that update. C6 2.12.6 and 3.0.6 are accepted. Consult the recovery documentation before changing coprocessor firmware.

Changes included since v0.3.0-beta.2

#163 OrcDial pairing/connection and boot reliability; #164 link and harness review fixes; #166, #167, #175, #177 and #181 nightly/CI improvements; #168 and #169 project links and attribution; #170 Smart VFO and clock setup; #172, #176 and #178 native digital-mode decoding, dashboard and reference validation; #180 Nooelec evidence; #182 capability-based driver gate and FT8 reception documentation.

See the FT8 implementation record, review fixes, JS8 status and FT8 setup/evidence for the dated supporting records.