OrcSDR v0.2.0-beta.6 Multi-Dongle RC4
RC4 is an experimental prerelease for multi-dongle testing. It replaces RC3 and adds hardware-tested RTL-SDR Blog V3C support while preserving the RTL-SDR Blog V4 as the primary regression baseline.
Downloads
OrcSDR-Tab5-v0.2.0-beta.6-multidongle-rc4.binis the complete merged image for M5Burner at its default address.OrcSDR-Tab5-v0.2.0-beta.6-multidongle-rc4-native-app-0x10000.binis the application-only ESP-IDF image for address0x10000.OrcSDR-Tab5-v0.2.0-beta.6-multidongle-rc4-local-m5burner.zipcontains the split firmware images and installation helpers for local use.SHA256SUMS.txtcontains the release image hashes.
The final merged RC4 image was installed using M5Burner and successfully booted on the physical Tab5 before publication.
RTL-SDR Blog V3C support
RC4 adds hardware-tested support for the USB-C RTL-SDR Blog V3C.
The V3C presented several problems that were not visible with the Blog V4:
- Its factory USB description was not specific enough to identify it reliably by name.
- OrcSDR therefore identifies the attached R820T2/R860 tuner through a hardware probe instead of depending only on the USB description.
- Initial V3C reception was displaced by approximately 1.755 MHz. For example, a station broadcasting on 99.1 MHz was received when OrcSDR displayed approximately 97.33 MHz.
- This was not an OrcSDR display or station-database problem. The tuner and digital demodulator were using different intermediate frequencies.
The official RTL-SDR Blog Windows driver was exercised as a black box while its USB control traffic was recorded. Those first-party captures showed that the V3C uses a matched 3.570 MHz intermediate-frequency configuration.
The original partial repair changed only the tuner PLL to 3.570 MHz. The RTL2832 demodulator was still using the Blog V4-derived 1.814972 MHz setting:
3.570000 MHz - 1.814972 MHz = 1.755028 MHz
That difference directly matched the tuning error observed on real FM stations.
RC4 configures both sides of the V3C receive path to the captured 3.570 MHz setting. No station-specific offsets, display compensation, or catalog corrections are used.
Physical testing confirmed:
- 96.1 MHz displays as 96.1 MHz and receives KEZL with matching RDS.
- 99.1 MHz displays as 99.1 MHz and receives The Beat with matching RDS.
- Cold-start tuning and live retuning agree.
- Unplugging the V3C, connecting a Blog V4, and returning to the V3C restores the correct receiver profile.
- The firmware boots with USB-C power and on battery power.
- The established Blog V4 tuning path remains unchanged.
Manual gain behavior and relative V3C sensitivity are still being evaluated. Differences compared with SDR#, the official desktop driver, or a Blog V4 should be reported with the frequency, antenna, gain settings, and serial log.
What changed since RC3
- Adds hardware-tested RTL-SDR Blog V3C detection, initialization, streaming, and FM tuning.
- Identifies ambiguous V3C hardware through its tuner chip instead of relying solely on USB product text.
- Uses the confirmed 28.8 MHz V3C crystal configuration.
- Matches the V3C tuner PLL and RTL2832 demodulator at a 3.570 MHz intermediate frequency.
- Preserves the complete Blog V4 initialization and tuning behavior.
- Leaves the Nooelec profile unchanged because its tuner behavior has not yet been confirmed with equivalent physical evidence.
- Keeps frequencies below 24 MHz blocked on receivers that do not report the necessary HF capability.
- Keeps unsupported automatic gain, RTL AGC, Bias-T, and other receiver-specific controls disabled.
- Retains the USB transfer configuration of three 32 KiB transfers.
- Includes the matching ESP-Hosted C6 firmware inside the Tab5 application.
Test results
The exact packaged RC4 image passed:
- Driver policy and receiver-profile tests
- Driver truth-hygiene checks
- ESP32-P4 driver compilation
- OrcSDR script self-check
- Blog V4 driver regression
- On-device UI regression
- Five-cycle V3C dashboard smoke test
- Ten-cycle FM, P25, and LoRa radio scan soak
- AM regression using 12 frequency and filter combinations
- Complete AM station scan across all 119 channels
The AM scan completed, displayed the save-or-discard result prompt, restored the previous frequency, and restored radio audio.
One brief blue screen was observed during the first radio scan attempt. The device recovered completely, and the serial record contained no restart, panic, backtrace, or uptime reset. A fresh ten-cycle scan soak then passed. This observation remains documented for continued testing.
Bias-T was not tested.
Receiver status
- RTL-SDR Blog V4: Tested baseline. Existing initialization, HF support, gain controls, RTL AGC, and Bias-T capabilities remain unchanged.
- RTL-SDR Blog V3C: Hardware-tested for detection, initialization, streaming, FM reception, RDS, retuning, hotplug, USB-powered boot, and battery-powered boot. Gain calibration and comparative sensitivity remain experimental.
- Earlier RTL-SDR Blog V3 variants: Experimental. Reports should include the exact case and connector style.
- Nooelec NESDR SMArt V5: Experimental. Initialization and reception still require more physical testing.
Community contributions and provenance
The multi-dongle work has benefited from community reports, testing, proposed code, serial logs, and hardware access. A contribution can be valuable even when its code is not merged: failed tests and proposed approaches help expose hardware differences and define what must be verified.
Thank you to:
@merendaiofor opening OrcSDR Discussion #64 and helping start the public RTL-SDR V3 testing effort.@unixpunkfor testing multiple RTL-SDR generations and reporting V3 boot-loop behavior.@mihaifireballfor the investigation and implementation effort contributed through OrcSDR PR #24.@Lunarhopfor the experimental Nooelec work and esp-rtl-sdr PR #19.@fachinformatikerfor testing the Nooelec NESDR SMArt V5 and supplying detailed serial logs through OrcSDR issue #77.@mhaberlerfor additional Nooelec and USB-host investigation.
Community PR #24 was reviewed but not merged. Subsequent V3 support in esp-rtl-sdr was independently implemented from first-party hardware captures. A similarity audit found no incorporated source from PR #24 or librtlsdr.
Nooelec PR #19 was also reviewed but not merged. Its submission, test build, and surrounding reports helped establish the hardware and testing problem and informed what required independent verification. Current Nooelec support remains provisional and does not claim confirmed reception.
The active review lanes are:
Known limits
- V3C manual gain behavior and relative reception quality still require additional calibration and comparison testing.
- Nooelec NESDR SMArt V5 reception has not yet passed repeatable physical acceptance.
- LoRa reception has improved, but intermittent missed traffic and long processing times for difficult CRC-failed captures still need work.
- Bias-T was not tested during this round.
- Unfinished station-database generators, scraped station data, and catalog experiments are intentionally not included.
C6 firmware
Every RC4 release image contains the matching ESP-Hosted C6 firmware inside the Tab5 application.
The release validator confirmed that the complete C6 image is embedded byte-for-byte. Internet access is not required to reinstall the embedded C6 firmware.
If the internal C6 needs repair or updating, use the existing option under:
Settings → Firmware & Updates
What testers should report
For V3, V3C, or Nooelec testing, please include:
- Exact receiver model and connector style
- Installation method
- Frequency and band tested
- Antenna used
- Manual or automatic gain setting
- Whether the spectrum and waterfall moved
- Whether static, audio, RDS, or another known signal was received
- Whether the displayed frequency matched the received station
- Unplug and reconnect behavior
- A complete serial log from cold boot through the test or failure
Antenna choice can affect what is received. Reception reports are more useful when they include the antenna used.
Provenance
- OrcSDR firmware source/tag:
5b8e4ba919e27f7f7f33790236cf7006da3e33f4 esp-rtl-sdrsource:9db9244c829392e7be5f320873decbd71ce20401- ESP-IDF:
5.5.4 - USB transfer configuration: three 32 KiB transfers
- ESP-Hosted C6 source:
e1a4f5492ac44fa248d77ac971d2055f8c565442 - C6 SHA-256:
4fb818cf0d292745c63e1a264a319d631250d25352d7467d30acf9d68c4c275a - M5Burner image SHA-256:
9291f49b83f18bd0574f9a36c3ab0b9e9d6cc41ad22e0e38122b46e78855459b - Local M5Burner ZIP SHA-256:
bc1cd5f845ca6f8bebf8ea5ae738fdf81d46461638c3f6b5cc71458b7296cf40 - Native application SHA-256:
4f31add61b1838cde046d1061e3609863c0e421986e4eb2e38dfd4fb202dfc25