Testing Hubble Network’s Bluetooth-to-Satellite Link from Budapest

Thank you to Zoltán Dóczi for writing in and sharing his blog post about trying out Hubble Network’s direct-to-satellite Bluetooth service. Hubble is a growing LEO satellite constellation service (currently about seven satellites are up, with a planned 60) that claims that off-the-shelf BLE chips can send small telemetry packets straight to its satellites without any extra hardware. To test this, Zoltán ran Hubble’s Zephyr-based satellite sample on a +20 dBm Silicon Labs EFR32MG24 board with a PCB antenna, and later added an ESP32-C6. The devices were powered by an 18650 cell and left on a flat roof in Budapest from August until late September.

Locally, the transmitter was clearly working. He picked up bursts every 10 seconds near 2.482 GHz with a Signal Hound BB60C, a HackRF One running an Android RF analyzer app, and his ESP32-based ESPARGOS receiver array. The signal turns out to be narrowband and frequency hopping across 19 channels at the top of the 2.4 GHz band, rather than standard BLE advertising.

Unfortunately, over about eight weeks, the Hubble dashboard recorded zero satellite packets. The cause appears to be that Hubble’s satellite service currently only covers the USA, which was not clear in the onboarding documentation at the time. Satellite access also requires a paid “Live” organization, not the free Sandbox account he used. SatNOGS observations of HUBBLE-6 telemetry on 401.1 MHz confirmed that the satellites themselves were healthy. While this was a negative result so far, mostly due to his EU location, Zoltán's post is a useful write-up for anyone thinking of experimenting with the service. He notes that his next step is to try decoding the uplink frames locally with a PlutoSDR.

Hubble Network outdoor test with EFR32xG24 transmitter and HackRF for test reception (Left), Measured spectrum with Signal Hound BB60C (right)
Hubble Network outdoor test with EFR32xG24 transmitter and HackRF for test reception (Left), Measured spectrum with Signal Hound BB60C (right)

Mobile-Whip: A Compact Battery Powered Mini-Whip Style Active HF Antenna for Handhelds and SDRs

Thank you to RTL-SDR.COM reader Ernie (NH7L), who wrote in and wanted to share news about the “Mobile-Whip” antenna, an open-source active receive antenna from GitHub user skuep.

The design is based on the well-known PA0RDT Mini-Whip, but it is built for portable use. It runs from a single 18650 lithium cell with an onboard USB charger, or from 5V USB, the 4.5V bias tee on the RTL-SDR Blog V4, or a standard 12-15V Mini-Whip bias tee. It uses an ultra-low input capacitance LTC6268 op-amp instead of a JFET, draws about 20 mA, and is only 200 mm long. That makes it small enough to mount directly on a handheld like an HF-modded UV-K5, a portable receiver, or a dongle SDR. It is designed for 100 kHz to 30 MHz, but the author says it also works reasonably well on FM and 2m.

The project is a first-revision preview with some known issues. A revision B with better VHF/UHF performance is reportedly in the works. There is no reverse-TX protection yet, so pressing PTT with it attached could destroy it. The KiCad files, simulations and JLCPCB-ready assembly files are on GitHub under the CERN-OHL-P-2.0 license. Assembled boards work out to roughly €25 each.

In two YouTube videos from a Polish ham, the Mobile-Whip is compared against a 27 MHz telescopic whip on several receivers, including the Radtel RT-950 Pro, UV-K5, ATS Mini, and Malahit DSP2. The tiny PCB antenna generally comes out ahead. On the RT-950 it even receives Polish Radio on 225 kHz longwave, which the telescopic whip could not. He does note that its high gain can overload receivers with poor front-end filtering.

The "Mobile-Whip" a PA0RDT Mini-Whip inspired portable antenna for HF
The "Mobile-Whip" a PA0RDT Mini-Whip inspired portable antenna for HF

Mayhem Mobile: Run PortaPack Mayhem Apps on a Browser or Android with an RTL-SDR or HackRF

Thank you to RocketGod, one of the developers of the Mayhem firmware for the HackRF PortaPack, for writing in and sharing the news that he has released Mayhem Mobile. It lets you plug an RTL-SDR (including the RTL-SDR Blog V4), a HackRF, or a PortaPack in HackRF mode directly into an Android phone or tablet, with no PC, Zadig, or driver installation needed. It comes as a native Android APK (direct APK download) or as a WebUSB web app that also works plug-and-play on a desktop.

Along with ports of the Mayhem receiver apps, it adds a ham radio mode with SSB, CW, AM and FM, live FT8, PSK31, RTTY and CW decoding with auto mode detection, an ADIF logbook, and DMR and P25 decoding. It also includes a full rtl_433 port with over 370 protocols, plus ADS-B, AIS, APRS, pager, ACARS, BLE, RDS and satellite decoders, a wideband sweep waterfall and raw IQ capture.

With a HackRF, it can also transmit FM voice through the phone’s microphone with CTCSS and repeater offsets, as well as RTTY, Morse, APRS, POCSAG, OOK and Flipper .sub replay, all behind a safety prompt. As always, make sure you’re licensed before transmitting.

Mayhem Mobile Screenshot
Mayhem Mobile Screenshot

Mtk79ICAP: Another MT7921 Wi-Fi SDR Project with SoapySDR Support and 80 MHz Bandwidth

Last week we posted about BirriaSDR, which turns cheap MT7921-based USB 3.0 Wi-Fi dongles into a 2.4 / 5 GHz SDR. Now Daniel has written in about his project Mtk79ICAP, a similar project that uses a forked Linux mt76 driver and a patched MediaTek firmware to stream 14-bit I/Q from the chip’s internal capture engine.

The key difference is that Mtk79ICAP includes a SoapySDR module, so the dongle works directly in GQRX, SDR++, and GNU Radio Companion. It supports 20, 40, and 80 MHz bandwidths on both bands, including 80 MHz on 2.4 GHz, and Wi-Fi monitor mode can keep running in parallel while I/Q is streamed.

The project is still experimental and Linux-only, with uncalibrated levels and some variability at 80 MHz on 2.4 GHz. Still, with multiple teams now working on these dongles, the MT7921 is quickly maturing into a usable, low-cost wideband SDR.

Mtk79ICAP SDR Running on GQRX
Mtk79ICAP SDR Running on GQRX

RTL-SDR Running Directly on iPad without Jailbreak TestFlight Invitation

Back in June, we posted about work from Arved (DK5AV/M0KDS) that enabled RTL-SDR to run directly on iPad devices without requiring a jailbreak. Previously, RTL-SDRs couldn't run directly on any iOS device. The only workaround was to run an RTL-SDR remotely and connect to it over a network via rtl_tcp.

Arved recently received distribution entitlement from Apple, which now opens the door to submitting to the Apple App Store. However, Arved notes that he would like feedback from Beta testers before that happens, so he has shared a TestFlight link at https://testflight.apple.com/join/jUDtSBmb. 

We note that this currently will only work on iPad devices with a modern M-series chip. iPhones are not compatible because they use the A-series.

Arved also writes:

The host app also contains a few more features compared to last time. It has a diagnostics view to see if the driver talks to the SDR correctly. It also contains a built-in FM receiver (including stereo and RDS) for broadcast FM stations. But finally the most important feature on the iPad is probably the built in rtl_tcp Server which runs directly on the iPad itself. That way users can use any compatible rtl_tcp client already available on iOS with this driver. Examples would be CoronaSDR, VibeSDR etc.

In the driver I also added support for the V4 dongle (which didn’t work last time). Unfortunately I had to drop the FCxxxx tuners for now due to issues with the AppStore and its GPL license issues. The whole driver is now based on the open source GNURadio driver instead of librtlsdr due to licensing issues with the GPL. Maybe I can find a way to add the other tuners back at some point. The driver for the iPad is open source (same repo as last time). The API for this driver is also available as header so that other apps in the future can directly talk to this driver.

RTL-SDR Running Directly on iPad via USB — Demo with CoronaSDR, welle.io, SatDump & rtl_tcp (no JB)

SDR++ and SDR# Plugins For: FT8 / FT4 / WSPR / FST4 / FST4W / JS8 / Q65 / CW / RTTY / JS8 / Olivia / PSK31 and PSK63

Thank you to ReLLL for writing in with an update on his decoder plugins, which we previously posted about as the “Advanced FT8/FT4 DX Decoder” just yesterday. 

Kondor Weak Signal Modes Decoder is the renamed and expanded version of the original plugin. It now decodes WSPR, FST4, FST4W, JS8, and Q65 in addition to FT8 and FT4. Its features include: A day/night DX map with SNR colors, station and country statistics, a DX activity bearing display, searchable tables, SQLite and CSV logging and optional forwarding to GridTracker.

ReLLL also added a new plugin called Maverick Text Modes Decoder (formerly CW Notebook) which decodes CW, RTTY, JS8, Olivia, PSK31 and PSK63. It provides a CW transcript with Markdown logs, simultaneous frequency tabs, spectrum discovery, pinned priority signals, and RX SNR readouts.

Both plugins now support standard SDR++ 1.2.0 and SDR++Brown 1.2.1 on Apple Silicon Macs running macOS 15 or later. There is also now a downloadable Windows preview for SDR#.

ReLLL welcomes reception reports, bug reports and UI ideas via GitHub Issues or X @FoxOnTheRunTr.

Kondor Weak Signal Modes Decoder
Kondor Weak Signal Modes Decoder

BrowSDR Update: Multi-SDR Support, LimeSDR, and Decoders for ADS-B, AIS, ACARS, RS41, rtl_433, BLE and DMR

Back in April, we posted about BrowSDR, an open-source browser-based SDR receiver by Joel (jLynx) that talks directly to SDR hardware via WebUSB, with no software install required. Joel has written in to let us know it has received many updates since then. The biggest is support for multiple SDRs at once, each with its own receiver tab, tuning, waterfall, and VFOs, and a single WebRTC sharing link that gives remote listeners access to all of them. LimeSDR-USB is now supported at up to 61.44 MSPS, and Airspy R2 support has been fixed.

Many new in-browser decoders have also been added, including ADS-B and AIS tracking with live maps, VHF ACARS with readable message explanations, RS41 weather balloon tracking, and rtl_433 for weather sensors, TPMS, and other ISM devices. There is also passive Bluetooth Low Energy scanning for receivers covering 2.4 GHz, and DMR voice decoding, with P25, NXDN, and D-STAR still experimental. Reception improvements include stereo FM with RDS, automatic squelch, upconverter offsets, automatic gain for HackRF and LimeSDR, a Signal Discovery panel, and a reworked POCSAG decoder.

Joel notes that all new features have been tested on real hardware, including our RTL-SDR Blog V4, the LimeSDR, and the HackRF Pro. The open-source code is available on it's Github repo.

BrowSDR Interface with POCSAG Decoding
BrowSDR Interface with POCSAG Decoding

Live TEA1 Decryption Support Added to an osmo-tetra Fork

Over on GitHub, su4am has published a fork of the well-known osmo-tetra-sq5bpf TETRA decoder that integrates TEA1 cipher support based on CVE-2022-24402. Back in 2023, we first posted about the TETRA TEA1 vulnerability discovery. Midnight Blue, a security research team, discovered this vulnerability as part of their TETRA:BURST research. The discovery found that a key-scheduling flaw reduces the effective keyspace from an impossible-to-brute-force 2^80 down to 2^32, which is small enough to brute force in a few minutes on a commodity GPU. This fork combines the osmo-tetra-sq5bpf TETRA decoder with Midnight Blue’s TETRA_crypto library so that recovered 32-bit keys are applied on the fly to encrypted voice bursts directly inside the decoder.

Importantly, we note that the fork does not crack keys by itself. The tetra-rx decoder outputs “key recovery candidate” tuples from the air, which you then feed into a separate GPU tool (SQ5BPF’s teatime) to actually brute force the reduced keyspace. Recovered keys are added to a keyfile and loaded live, so decryption begins on the next burst without restarting the pipeline. The fork also adds a dual-socket TRA output, letting you monitor decrypted and unencrypted traffic simultaneously with two telive-2 instances. 

We want to warn that intercepting or decrypting communications you are not authorized to receive is illegal in most countries.

TETRA Decoding (with telive on Linux)
TETRA Decoding (with telive on Linux)