Recently, we came across SimTX, an open-beta multiplayer shortwave radio simulator. Everyone shares the same simulated band, so whatever one user transmits from their virtual station can be picked up by anyone else, simulated propagation permitting. The website suggests running a pirate station, making your own numbers station, or just tuning around and listening.
For realism, the ionosphere is based on IRI-2020 climatology with live ionosonde data assimilated on top, groundwave and noise follow ITU-R models, and every link passes through a Watterson fading channel with Doppler, multipath and storms. Users can transmit from a mic, an audio file or raw IQ from GNU Radio in modes including AM, SSB, CW, NFM, WFM, WSPR and FT8, and can even launch and track their own satellites.
To receive, the SimTX app runs a local rtl_tcp bridge, so SDR++ or any other rtl_tcp-capable SDR program can tune the simulated band as if it were an RTL-SDR, without any real radio hardware. The app runs on Windows, macOS, and Linux, and accounts are created via Discord. The software does not appear to be open source. The demo video below shows a song broadcast from a simulated Amsterdam and received 1145 km away in Budapest.
This may be useful for playing around with and seeing what different TX/RX variables and propagation effects do to signal reception.
We broadcast a song through a simulated ionosphere
Thank you to RTL-SDR.COM reader Andrea for writing in and pointing us to a recent Stanford University press release about Zerina Kapetanovic and her team's research on "thermal noise communication", a way to send data wirelessly without generating any RF signal at all.
With this communication method, the transmitter simply switches its antenna between two loads, such as a dummy load and an open circuit, which the receiver sees as slightly "hotter" or "colder" thermal noise that encodes binary data. The study claims that a conventional RF transmitter uses up to 1,000 times more energy, making this a possible alternative to RFID tags and low-power wireless sensors.
Our reader Andrea also pointed out that the receiver in one of Zerina Kapetanovic's earlier experiments on the same topic was built around an RTL-SDR. Back in 2022, Zerina Kapetanovic and her team published a paper (pdf upload) demonstrating the idea at 1.42 GHz. Their receiver was a horn antenna, two LNAs with about 84 dB of combined gain, a bandpass filter, and an RTL-SDR, with processing on a laptop or Raspberry Pi. The transmitter was a simple RF switch connected to an antenna and switched between a 50 Ohm dummy load or ground. They achieved a data rate of up to 26 bps and a range of up to 7.3 m at 5 bps, and built a solar-powered, battery-free transmitter that sent indoor temperature readings over five days.
A new paper (not available freely yet) from Kapetanovic and her team builds on this idea and improves the data rate to the kilobit-per-second range, and adds capacity measurements and error correction, which was a limitation of their earlier experiment. The paper and press release also explain why this idea works at room temperature, making the analogy that the receiver's LNA works as a sort of 'electron refrigerator', slowing down electrons and making them appear colder.
We are unsure if the new setup still uses an RTL-SDR. However, readers who have built a Hydrogen line radio telescope have already built a nearly identical setup to the 2022 paper. In the press release Kapetanovic notes that "We've built a system that others could very easily implement", so this may be an interesting experiment to try for anyone who already has an H-line setup.
The thermal noise receiver setup from the 2022 paper
Just last week we posted about ESP32-SDR, which is custom firmware for ESP32's indpendently discovered by two experimenters that transforms them into a full software defined radio.
Now, h0m3us3r, one of the discoverers of the ESP32-SDR hack, has discovered a way to turn a Gemtek W1700K Wi-Fi 7 router, which uses a MediaTek MT7996 chip, into a wideband software-defined receiver. Compared to the ESP32's maximum 80 Msps sample rate, this newly discovered Wi-Fi chip captures a massive 320 MSps. And most importantly, unlike the ESP32, the router has a built-in 10 GbE Ethernet SoC, which lets you stream full-bandwidth data out and ingest it on a PC.
As a result, you can capture the entire 2.4 GHz band and a wide portion of the 5 GHz band live and stream the spectrum to a Linux host running a live spectrum and waterfall display.
Other devices that run the MediaTek MT7996 Wi-Fi chip include the Banana Pi BPI-R4, GL.iNet Flint 4, and Gemtek XR1710G, however it is unclear if this firmware will run on those devices.
The entire 2.4 GHz Wi-Fi Spectrum at the max 320 Msps sample rate.
AI Disclaimer: Claude is listed as a contributor to the repo.
Thank you, Chris, for writing in and sharing news about the recent launch of FliteGrid's hex claiming scheme. FlightGrid is a crowdsourced drone-tracking network that will pay feeders in an eligible hex grid $50 a month to run a drone-detection sensor. Chris explains:
The US government is building out Unmanned Traffic Management (UTM), which will be the equivalent of air traffic control for drones. This will make it possible to automate things like shipping, emergency response, infrastructure inspections, and more all over the country. To do that, they'll need awareness of every drone in the sky just like they have for every plane today, and FliteGrid is our solution to providing it.
The devices themselves are custom sensors that receive Remote ID transmissions. That's the standard the FAA created for drones to transmit identifying information, which it now requires all drones in America to broadcast. Serial number, location, altitude, operator location, etc. Remote ID can be broadcast on four different protocols, so we've got four receivers in each piece of hardware; two WiFi and two Bluetooth. That data is then uploaded onto the SkySafe platform, which provides a realtime map of every drone in the sky.
The catch to getting paid is that you need to 1) pay a $100 refundable deposit to receive their hardware, and 2) place and run it in a hex grid that offers to pay. The paying hex grids are mostly around US airports and critical infrastructure right now, so you'd need to live in, or have access to a roof in those areas to host the device. Payment is given in USDC, a stablecoin cryptocurrency pegged to the US dollar.
FliteGrid Hexes: Red - Claimed, Green - Available to claim with $50 p/m payout, Purple - Requested by community, Black - Requestable.
FliteGrid/SkySafe is able to pay users because operators of critical infrastructure and large facilities such as airports, universities, energy infrastructure, the US military, DHS, and the DOD will pay for real-time awareness of the airspace above them. SkySafe has been around since 2015, has raised around $50M in funding, and has contracts with many of the previously listed organizations. Chris notes that the service has already been used successfully in operations like busting gangs smuggling drugs into prisons via drones.
The FliteGrid sensor appears to be a computing device with WiFi and Bluetooth radios repurposed to detect Remote ID, with each radio connected to a higher-gain external antenna. Recently, on the blog, we have seen DIY Remote ID detectors made from ESP32s and other commodity Bluetooth hardware.
Since a 2024 mandate, drones over 249 g in the USA must transmit Remote ID signals for tracking and identification purposes, similar to how ADS-B is used for larger aircraft. For ADS-B, flight aggregation services such as FlightAware/FlightRadar24/ADS-B Exchange etc. already exist, with volunteer feeders setting up stations that can cover up to 400km. However, unlike ADS-B, Remote ID is transmitted with single-digit milliwatts of power, compared to a minimum of 70W for ADS-B, so its reception range is limited, making a dense distributed reception network like SkySafe for Remote ID very important. Individual SkySafe hex grids cover just under 1km of area.
FliteGrid cannot detect drones that are not transmitting Remote ID, though Chris mentions that government infrastructure and facilities may use normal radar to detect these. A radar detection that does not correlate with a SkySafe detection would confirm that a drone is a potential threat.
Back in 2025, we posted about ESPARGOS, a phased array of many patch antennas, each connected to an ESP32 WiFi microcontroller. ESPARGOS could be used to determine the direction of arrival for WiFi signals and create a live augmented reality heatmap.
Recently, the ESPARGOS team has made an exciting discovery. They found that several ESP32 chips have an undocumented feature that lets the firmware bypass the fixed WiFi and Bluetooth functionality and instead capture raw IQ baseband samples. As a result, several ESP32 models can now be used as an internal SDR covering 2.2–2.7 GHz, plus 4.8–6.0 GHz on the ESP32-C5, with up to 80 MS/s sample rate and roughly 13–54 MHz of analog bandwidth, depending on the chip.
However, for use as a general-purpose PC-connected SDR, the output bandwidth is insufficient, so only snapshots of data can be exported to a PC. This means that the SDR will only work as a spectrum analyzer, and demodulating or decoding continuous radio data is not possible with just an ESP32. The exception is the new ESP32-S31, which can stream continuously at up to 16 MS/s over its Gigabit Ethernet interface, with a SoapySDR driver for GNU Radio and gqrx coming soon. If you want to try it yourself, the ESP-WebSDR page lets you flash the firmware to most ESP32 dev boards directly from your browser and view a live spectrum and waterfall.
Furthermore, ESPARGOS notes that phase-coherent IQ sample capture is now possible with their hardware. This means ESPARGOS is no longer limited to WiFi and Bluetooth signals; it can now perform direction finding on any arbitrary signal in the 2.4 GHz band. The team also says phase-coherent transmissions would be possible, but they aren't implementing them right now because they could be misused.
It also seems that, independently, at least two other projects discovered the same or similar features around the same time, but to solve different problems.
Over on Reddit, user /u/h0m3us3r discovered the same feature and uploaded it to GitHub on Sept 26, and recorded a video showing an ESP32-S3 working as an SDR with an FPGA used as a USB3 front end. Unlike ESPARGOS, h0m3us3r's project streams the raw IQ data to a PC continuously via the FPGA rather than in snapshots, so full demodulation/decoding on PC should be possible. However, the current prototype uses the FPGA to clock the ESP32, which results in poor phase noise. So if the clocking issues can be resolved, an ESP32 combined with an FPGA could make a standard general-purpose SDR, like the RTL-SDR, but with a 2.2–2.8 GHz frequency range and up to 80 MHz of bandwidth.
Another project that seems to be using a somewhat similar finding is C5VRX, which was first uploaded to GitHub on August 13. C5VRX uses an ESP32-C5 as a 5.8 GHz real-time FPV video receiver. Although this project appears to use a different mechanism, the result is similar: it uses an undocumented IQ data stream on the ESP32 to sample FPV signals and demodulate them onboard, outputting analog composite video through a simple resistor DAC. The project is still a work in progress and doesn't yet work reliably at range.
Thank you to Gerrit (PA3BYA) for writing in and sharing a hardware project he completed that combines an affordable optical encoder and a microcontroller with custom firmware to create a high-resolution USB mouse wheel for SDR tuning. Many people prefer using a knob to tune through the bands rather than a keyboard and mouse. Gerrit writes:
Although I initially developed it for use with the RTL-SDR, it is actually a general-purpose tuning solution that can be used with virtually any SDR software. Many SDR projects use a cheap mechanical rotary encoder with, for example, 24 pulses per revolution.
But why settle for a 24-pulse mechanical encoder when an affordable optical encoder can provide 600 pulses per revolution? For this quick SDR experiment, I combined a high-resolution optical encoder with a tiny Digispark ATtiny85 and turned it into a standard USB mouse wheel for tuning.
The result is a surprisingly simple and platform-independent tuning control that works with SDR software on macOS, Windows, Linux, and even a Raspberry Pi.
The encoder he used is a cheap Chinese part, costing around 17 Euros. However, one interesting issue that Gerrit encountered was that the cheap encoder would not reliably operate when powered from 5V, even though the operating voltage was specified as 5V to 24V. To fix this, he suspected that the input LDO was dropping too much voltage at the low 5V end, so he modified the encoder by shorting the input and output of the 78M05 regulator, to allow direct 5V power without any dropout.
His firmware for the ATtiny85 is open source and can be found on GitHub.
USRP B210 Chinese clones can now be commonly found on marketplace sites for less than USD$300. This is a bargain, considering that an original USRP B210 (board only) costs US$2,387. The disadvantage is, of course, janky ported firmware that doesn't support all the available features and doesn't maximize the available performance.
Recently, Fabrizio Francione wrote in and wanted to share his new firmware and software project, called "NNJ-SDR++ UHD Edition V1.0". This project consists of improved firmware that unlocks the full sample rate, fixes various problems, and enables the onboard GNSS receiver. It also includes a modified SDR++ frontend that exposes more controls. Fabrizio writes:
The work involved substantial FPGA and software development rather than simply customizing the SDR++ interface. Starting from the original B210-compatible architecture, I progressively redesigned and extended several areas of the firmware, including improved CIC numerical handling, RX/TX fixed-point processing, BRAM-based asynchronous transport FIFOs, CIC passband compensation, a wideband FIR receive path, ADC clipping/overload telemetry, runtime FPGA control and diagnostics, and a dedicated wideband profile for operation at up to 56 MS/s.
I also finally integrated the board's onboard u-blox MAX-M10S GNSS receiver directly with the FPGA, including GPS UART data, internal PPS capture and timing telemetry, while preserving external 10 MHz reference and PPS support.
On the host side, I developed a customized UHD 4.10 environment and SDR++ frontend for both Windows and Linux. The application exposes RF filter bandwidth, LO offset, reference lock, PPS status, GNSS information, firmware telemetry and other board-specific controls directly from the SDR++ source panel.
One particularly interesting part of the project was making sustained 56 MS/s operation practical across both operating systems while retaining B210/UHD compatibility.
The Firmware is not open source or free, and Fabrizio is selling it for US$19.90.
Thank you to p0larpatch for writing in and sharing with us his project called "Bluewatch," which uses a Raspberry Pi to detect when new Bluetooth devices appear in your neighborhood. While Bluewatch doesn't use an SDR and only uses a standalone Raspberry Pi, it may still interest our readers. p0larpatch explains the project below:
Get alerts when new Bluetooth devices appear in your local neighbourhood.
The real strength shows up once you actually start using it: categorize the devices you already know, your own phones, your TV, the smart plugs, the neighbour's robot lawnmower, whatever's expected around you, and BlueWatch filters all of that familiar traffic out of the way.
What's left standing out is the interesting part: the moment an unrecognized device enters the radio range of whatever's running BlueWatch, it surfaces immediately instead of being buried under dozens of devices you've already triaged.
The dashboard stops being a wall of MAC addresses and turns into an actual presence radar for your surroundings. You notice the one device that doesn't belong, not the fifty that do.
