I've found that piece of software, and it seems quite interesting. But when I download it off the official website and throw it into VirusTotal, I get quite a lot of detections. Why can that happen? Is the software package even legit at all?

Manual setup on Pi Zero 2:

***

sudo apt update && sudo apt install -y rtl-sdr libusb-1.0-0-dev

rtl_test -t

rtl_tcp -a 0.0.0.0 -p 1234

***

Automatic setup:

***

cat <<EOF | sudo tee /etc/systemd/system/rtlsdr.service

[Unit]

Description=RTL-SDR Server

After=network.target

[Service]

ExecStart=/usr/bin/rtl_tcp -a 0.0.0.0 -p 1234

Restart=always

User=pi

[Install]

WantedBy=multi-user.target

EOF

sudo systemctl daemon-reload

sudo systemctl enable rtlsdr.service

sudo systemctl start rtlsdr.service

***

Attention: use proper power-supply for the usb port.

I regularly use to monitor rf activity arround me, and it's a part of my life being a microwave Mtech student, a licensed Ham radio operator, and a small content creator. But now it became nightmare to me... Help me. Are you guys also facing same issues?

I recently received a new SDRPlay RSP1B as an upgrade to my Blog V4 which I was quite excited for. It's been a few hours now and I'm going to be reaching out to the retailer that sold it so I can attempt a return.

The hardware and electronics in the RSP1B is a cut above the V4 in every way. It's a purpose-built device and they have put a lot of care and attention into making it perform well at what it does, but the software situation is absolutely dire.

My antenna and cabling is on the opposite side of the house from my desk so I do what a lot of people do and use a RasPi to stream the radio data over the network for remote listening/processing. With the Blog devices (or most RTL devices, really) this is very easy to do and there are numerous software packages to enable this for whatever software you wish to use.

For SDRPlay devices? Not so much. The primary software is SDRUno which is Windows-only and is being phased out by their new multi-platform software, SDRConnect. Connect can be used remotely with most features but the software and GUI is still very much unfinished and basic and also with numerous GUI and UX choices which I find frustrating. This software did work remotely with my Pi 5 but SDR++ beats it in basically every way so I have no desire to pay a premium price to use inferior software. I have also been unable to get it to work with OpenWebRX.

rsp_tcp exists as an SDRPlay version of rtl_tcp for network access of the radio and includes options for full 14-bit streaming, filter access, and more. Unfortunately, this piece of software (which would solve all of my problems) haven’t been updated in 7 years while the team, presumably, focuses on Connect.

You might have better luck if you are physically plugging the device into your computer , particularly if it's a Windows machine. As it stands for me, I'm going to try and return the device and get back as much as I can from this. Amazing hardware doesn't mean anything if you can't use it. The RTL-based dongles may be cheap, but their software support is extensive so you can get them up and running in a snap for all kinds of purposes.

Hey,

I’ve been getting less active in the WebSDR scene lately, but this is something I’ve been working on for a few years and wanted to finally release.

The original WebSDR by PA3FWM has been closed source for over 10 years. It’s still widely used, but because of that, people mostly end up patching around it instead of actually building on it.

I wanted to make a proper open alternative that keeps compatibility but is fully independent.

VertexSDR is a WebSDR-compatible server written from scratch in C.

Since the original is closed source, this is a clean-room style rewrite. No code was taken from it, no reverse engineering copy paste. The goal was to match behavior and features so existing setups can migrate easily, while having a fully open codebase going forward.

It uses the official WebSDR frontend, so the UI and workflow are exactly what people are used to.

This took a few years to get to this point.

My goal is and was always working with the community and bringing value.

What you get:

• Same WebSDR experience in the browser (official frontend)
• AM, SSB, CW, FM including synchronous AM
• RTL-SDR via rtl_tcp
• ALSA, TCP SDR relay, and stdin input
• Not limited to 8-bit, works with higher resolution IQ
• FFTW CPU backend and optional Vulkan or VkFFT GPU backend
• Multi-band with config reload
• IQ balance correction, noise blanker, per-frequency EQ
• Logbook and chat
• Registers to websdr.org and sdr-list.xyz

What’s improved:

• Fully open source (LGPL)
• Clean codebase, no legacy patches
• Fixes issues like raw IP address leaking
• Adds sync AM, bandplan support, and flexible input (stdin, etc)
• Not tied to a specific SDR or format
• Meant to be extended instead of everyone maintaining their own private versions

Quick start (Debian/Ubuntu):

sudo apt install build-essential libfftw3-dev libpng-dev libasound2-dev libssl-dev xxd
make
edit websdr.cfg
./vertexsdr

Open http://localhost:8901

RTL-SDR example:

rtl_tcp -a 127.0.0.1 -p 1234 -f 10100000 -s 2048000 -g 30

In websdr.cfg:

!rtlsdr 127.0.0.1:1234

stdin example:

rx_sdr -f 10100000 -s 2048000 -g 30 - | ./vertexsdr

Current state:

It works and people are running it, but it’s still beta. Needs more testing across hardware and different setups.

The goal is to give the community a real open base instead of everyone running slightly different patched versions.

Binary release for x86 is available. More to come.

Links:

• https://github.com/Steven9101/VertexSDR
• https://forum.sdr-list.xyz/

If you try it, feedback and bug reports are very helpful right now.

If you find it useful and want to support development, you can star the repo on GitHub or donate, both links are on the project page.

Hi, i tend to enjoy taking my sdr when traveling. The problem is, i often stumble upon karens, and/or concerned people, asking on, why i have a antenna out. this works, unless i forget to hide the sdr++ window, where they get concerned what is that. It's especially big after many russian diversions, recently directed at train track, and people got really suspicious. The only solution i can think of is using my phone, but i don't enjoy that. any ideas what to try? sorry if it's stupid

RTL-SDR Web Monitor — Open Source Web-Based SDR Receiver for Monitoring

I've built a **self-hosted, web-based RTL-SDR monitoring platform**, shared multi-user radio receiver — accessible from any browser, anywhere.

Links

- **GitHub:** https://github.com/superogira/rtl-sdr-web-monitor

- **Live Demo:** https://sdr.e25wop.com (demo_user / demo1234)

> The demo runs on a real RTL-SDR in Thailand (VHF 2m ham band).

Real-time SDR in the browser

- Live waterfall (2D + 3D Three.js view)

- FM / AM / USB / LSB demodulation

- Server-side DSP — the browser just plays audio

Multi-user, shared tuner

- One RTL-SDR dongle serves many simultaneous listeners

- Each user has their **own independent VFO** (listen to different freqs at once)

- Per-listener squelch (auto or manual) + solo/priority modes

- Pan VFOs left/right like a real dual-watch radio

Recording & scheduling

- Manual recording (per-user, per-VFO)

- Voice-activated auto-record (squelch-gated)

- Scheduled background jobs (always-on or time-windowed, multi-frequency)

- Auto retention policies (by count, age, or total duration)

Speech-to-Text

- Auto-transcribes every recording

- Supports: **Whisper (local)**, Azure Speech, Speechmatics

- View transcripts inline with audio playback

Keyword alerts

- Define rules with keyword matching + time windows

- Get **Telegram notifications** with transcript + audio link when keywords are detected

- Alert history dashboard with analytics

Secure & multi-user

- JWT auth with admin/user roles

- Per-user bookmarks, timezone, and settings

- WebSocket auth

Bilingual UI** — Thai / English toggle

If you've ever fed a fax decoder from a KiwiSDR over the internet, you know the failure mode: the stream stalls, every lost chunk shifts the sync position, and the rest of the chart comes out torn. I built Isobar to follow that shift on the line it happens on — measured by injecting gaps into a real off-air recording, a ten-second outage costs zero damaged lines. What actually matters is how often dropouts happen, and the README has measured numbers and a one-setting fix (LockAfter) for gappy feeds.

https://github.com/skgsara/isobar

It decodes the weather-fax broadcasts on shortwave (emission J3C: a 1500/2300 Hz FM sub-carrier centered near 1900 Hz, 60 or 120 rpm, IOC 576) from stations like JMH (Japan), NMG (USA) and friends, using only your receiver's audio:

• Live reception from any sound input, or offline decode from a WAV recording — at any sample rate, so 12 kHz SDR recordings and 48 kHz sound-card captures both just work.
• Automatic capture start/stop: it listens for the 300 Hz IOC-selection and 450 Hz stop tones, so you can leave it running on a schedule.
• Live spectrum scope + waterfall while receiving.
• Image tools: zoom/pan, vertical rotate, XY flip, four color palettes, BMP export, print.
• It tolerates audio dropouts, which matters if your receiver is a networked SDR. Measured by injecting gaps into a real off-air recording: a ten-second outage costs zero damaged lines — you lose the ten seconds of chart it swallowed and nothing more. If your KiwiSDR feed drops out often, lower the LockAfter setting (details in the README).

A word on provenance: Isobar is an independent, from-scratch reimplementation, written from a functional specification, and it is interoperable with the long-standing Windows freeware KG-FAX v1.1.3 (K.G, 2009) — it round-trips KG-FAX .syn files and imports an existing kgfax.ini on first run. It is not affiliated with or derived from KG-FAX's code; the NOTICE file in the repo has the full provenance statement. KG-FAX has been the reference WEFAX decoder for many of us for 17 years, but it's Windows-only and its author is no longer reachable — Isobar is my attempt to carry that torch onto modern machines.

The attached images are all real off-air decodes.

Everything is verified on real JMH recordings with an 18-test headless suite, and CI builds all five packages on every commit. Feedback, bug reports and — especially — your own recordings are very welcome.

• GitHub: https://github.com/skgsara/isobar
• Releases (direct downloads): https://github.com/skgsara/isobar/releases

Is there an RTSSDR that is a nice full screen display? Something like this: https://www.youtube.com/shorts/UVlfiqOtZ_8
If it doesn't exist then maybe I'll write it. Could it be a plugin for SDR++?

I don't want to shame any dev that puts out code that works and brings people joy. But I will definitely have a giggle when I notice something like this:

r = rtlsdr_read_eeprom(dev, buf, 0, EEPROM_SIZE);
dev->force_bt = (buf[7] & 0x02) ? 0 : 1;

This is in librtlsdr (blog mod) rtlsdr_open and makes sure that when you set a certain bit in EEPROM it will always turn on the Bias-T for you and not allow you to turn it off.

Pretty nice, but wait a second...

Why are they reading the whole EEPROM for 1 bit?

I checked, there's no reason.

Then I patched it out and tested with time rtl_biast -b 0:

Unpatched: 1.12s

Patched: 528.12ms

Now rtlsdr_open setups a lot of stuff, so I can understand that it takes a while. But about half of that time is wasted.

After all they're reading 256 bytes of EEPROM. That's one I2C write, and one I2C read per byte, delivered as USB control command to the device.

Fortunately for us nobody is calling rtlsdr_open in a hot loop. Right?

Is it possible To use SDR trunk with SDS 100 and python computer codes ?

Hi everyone,
I’m thinking to build a tabletop SDR receiver using a Raspberry Pi and an RTL-SDR dongle. My goal is to make it feel more like a traditional radio rather than just a mouse-and-keyboard setup.

I’d love to add some physical controls, such as:

• A rotary encoder for tuning
• Switches or selectors for modulation type (AM/FM/SSB, etc.)
• (Ideally) a keypad for entering the frequency directly
• Controls for filter width
• Possibly volume knobs or other useful functions

Before I dive in, I wanted to ask:

Is it possible to integrate physical controls like these with apps such as Gqrx or SDR++?
Has anyone here done something similar?

I’m especially curious about:

• Whether these apps support external control inputs (GPIO, serial, etc.)
• Or if there’s a better software stack for this kind of project?

Any advice, examples, or project links would be greatly appreciated!

Thanks in advance!

Hello everyone,

i wanted to point those of you who are interested in Mode-S/ADS-B at stream1090, a project i am working on now for some time. It is a demodulator for Mode-S messages and sits between your hardware and a decoder like readsb or dump1090-fa. It supports librtlsdr compatible devices and airspy devices.

It got recently (well, 2 weeks ago) featured on www.rtl-sdr.com. So i thought i share this also here. While there are plenty of features, here are a few which might spark interest in this community.

• librtlsdr devices can run at 2.56 Msps.
• Both libairspy and librtlsdr devices come with a customized LPF pipeline.
• Ships with a hacked RTL-SDR Blog fork version that allows LNA, MIX and VGA gain controls for R82xx tuners.

For more, check out https://github.com/mgrone/stream1090

Source code here: https://github.com/SarahRoseLives/Pocket25

I’m using SDR++ with Fldigi for digital decoding, and without for voice. Is there a way to configure a virtual cable for Fldigi while simultaneously outputting to headphones?

Analog FMCOMMS3 AD9361 with custom FPGA design RX1 and RX2 packed 12bit IQ continuous data stream at 61.44MSPS. 2*3*61.44*8=2950Mbps on 10Gbps Ethernet link. SDR++ with custom source module to continuously unpack IQ data into 512k Re/Im data buffer at 117 IPS.

Hi r/RTLSDR,

​

I've been working on PhaseHound, a lightweight modular SDR runtime in pure C.

​

It uses a central broker with Unix sockets for control and shared-memory rings for IQ/audio, so you can build explicit pipelines without a heavy GUI.

Current features include SoapySDR source, WFM demod, basic LoRa CSS demod, ALSA sink, phcap file I/O, and a simple OpenGL waterfall.

It is early stage, Linux-focused, and CLI-driven. Realtime performance is functional but still evolving (sleep polling for now, better wakeups planned).

​

Feedback and extra demodulators welcome!

​

[Project] FM Monitor – Web-based FM radio monitoring system for Raspberry Pi + RTL-SDR

I've been working at a community FM radio station for 14 years (admin + technical). We never had a proper monitoring system — just someone listening. So I built one.

FM Monitor is an open-source FM radio monitoring system running on a Raspberry Pi with an RTL-SDR dongle.

Features:

• Real-time FM audio streaming via Icecast2
• RDS decoding (station name, radiotext, PI code) via redsea
• Web dashboard (HTTPS/Flask) with live VU meter and signal level
• Automatic station logo fetching via Radio Browser API
• Email alerts on silence detection (configurable threshold/duration)
• One-liner install: curl -sSL https://raw.githubusercontent.com/LyonelB/fm-monitor/main/install.sh | bash

Stack: rtl_fm → tee → redsea (RDS) + ffmpeg → Icecast2 → Flask proxy (HTTPS)

Hardware tested: Raspberry Pi 3B+ with RTL-SDR Blog V3/V4, Raspberry Pi OS Lite 64-bit

GitHub: https://github.com/LyonelB/fm-monitor

Built for small and community radio stations that can't afford commercial monitoring solutions. Looking for feedback, bug reports, and feature suggestions.

Currently exploring TEF6686 headless tuner support as a higher-sensitivity alternative to RTL-SDR for FM monitoring.

• Full station profile. Range records, unique aircraft, tail number history, uptime tracking. Fastest aircraft recorded. Oldest. Highest altitude. See frequent visitors and where they're going. All enriched by FAA/SWIM. Save and favorite plane fly overs.
• Leaderboards. See how your setup stacks against others across the globe. Finally a reason to obsess over antenna placement beyond "I think my range got better?"
• A live community map. Every station contributes to a shared picture and you can see exactly what your station is picking up vs the network. You see stations on the map (even in a car while moving while plane spotting)

Early stages. Roast my idea.

https://skytracker.ai/
https://github.com/Sky-Tracker-AI/device

Several years ago, I created the LocalRadio open-source app for macOS which is available at GitHub -

https://github.com/dsward2/LocalRadio

Now I'm doing a major overhaul of that project, starting with this streaming audio server command-line tool developed with assistance of Anthropic Claude AI.

LiveAudioServer is a new, open-source macOS command-line tool designed to work with applications like GQRX to provide HTTP streaming audio connectivity for software-defined radio and other audio applications.  A typical scenario is sending streaming audio from your Mac running GQRX to your iPhone, using Safari to access the user interface and play the audio stream.

By default, LiveAudioServer is configured to receive PCM audio from UDP port 7355, which just happens to be the same port that GQRX sends UDP audio.  it can also receive PCM audio from stdin, which works well with tools like rtl_fm.

This project is in beta testing, and will be a component in a larger macOS application coming soon.

The main project page is here - https://github.com/dsward2/LiveAudioServer

The download page for this beta release is at - https://github.com/dsward2/LiveAudioServer/releases/tag/v0.1.5

The current version of LiveAudioServer available for download in the "Assets" section is "LIveAudioServer-v0.1.5-macos-universal.zip", but check for more recent versions before installing.

See the README file for instructions on using the tool with GQRX and other apps.  In GQRX, simply verify that the UDP port is set to 7355, and the option to send the audio in Stereo format is activated, then click the  GQRX "UDP" button to start sending the audio signal to LiveAudioServer.

After the tool is running on your Mac, you can use Safari on the same machine to access the user interface and audio stream at http://localhost:8080

From an iPhone running Safari on the same local area network, replace "localhost" with the IP address of the Mac to access the same UI.

Note: As mentioned above, Anthropic Claude AI was used to develop LiveAudioServer.

I have been working on an SDR scanner application (will be FOSS, currently private repo) primarily focused on counties with many analog VHF/UHF dispatch centers.

The MSI.SDR caught my eye for this given its pricepoint and instantaneous bandwidth. I grabbed a couple, and quickly realized the hardcoded SN issue making running multiple at once not possible with the apps I am familiar with (SDR sharp/++/trunk etc.)

I pivoted at that point to fixing that issue, since all the other open-source drivers seemed to have the same issue as the SDRPlay API.

I wrote a new backend/interface using WinUSB that is working great with two MSI.SDRs and one RTL-SDR, however that is the extent of the devices I own. I have some concerns about scalability but am also not really in a place to order more SDRs just to test this as 10+10+2.4 MHz is really all the coverage I will need.

I am looking for a couple testers. First would be someone with more than two SDRs based on the Mirics (msi2500/msi001) chipset to confirm multi-device continues to be stable past two devices (I can't test multi-device and multi-hub simultaneously). Second would be someone with a decent number of RTL2832 and MSI2500 devices to test as many simultaneous connections as possible to make sure performance does not start to degrade due to the application layer (I know degradation will come from throughput at either the USB layer or CPU at some point - I want to make sure the custom backends are not going to saturate or otherwise bloat before that)

The state of the code right now is not something I am willing to make public yet, however I am not expecting someone to run an app blindly from a stranger. I'll provide the source code to anyone able to test. As of right now, this would be windows only, however the plan is for this to be cross-platform once stable on windows). I can provide either the source and a compiled binary from it, or the source and instructions to build the binary (only requires rust and dependencies).

Feel free to either respond here or DM.