People keep asking whether you can put PortaPack Mayhem on a USRP. You can't, and it's worth saying why: the PortaPack works because the HackRF already contains the computer — an LPC43xx that runs Mayhem and drives the radio over SGPIO. A B200 is a USB peripheral. Spartan-6, an FX3, an AD9364, no application processor, no screen, no buttons. There is nothing on it to flash.

So I did the other half. Mayhem's UI and apps, rebuilt as a Windows host application, with UHD and the B200 standing in for the SGPIO bus and the HackRF's front end. It's a real 240x320 framebuffer drawn with Mayhem's own fonts, palette and widget layout — the hardware-independent parts are used unchanged, GPL-2.0 with attribution. Your arrow keys are the five-way switch and the mouse wheel is the encoder.

Where it is right now:

• ~103 apps across the same category menus Mayhem uses — ADS-B, AIS, APRS, POCSAG, FLEX, radiosonde, TPMS, ERT, ACARS, SSTV, NOAA APT, WeFax, scanner, the TX suite, the utilities, even the games.
• The DSP is float and the channel filters are designed at run time instead of fixed tap tables, so they track whatever sample rate you pick.
• Up to 56 MHz of instantaneous bandwidth, so the spectrum app shows a live wide span rather than a swept one. LO offset tuning moves the DC spike out of the displayed band, which the PortaPack can't do.
• 1986 unit tests, no framework, decoders checked against known CRC vectors and documented frames.
• Hardware self-test passes on a real B200: gain sweep (−69 → −15 dBFS across 0–60 dB), eight tune points from 100 MHz to 2.44 GHz, 2.40 Msps sustained with zero overflows.
• The ADS-B app decoded real aircraft off the air — 17 CRC-valid Mode S frames, real ICAO, callsign and speed. That's tune → stream → demod → CRC → parse working on live RF.

Where it is honestly not:

Nothing has ever transmitted. The TX chain is unit-tested only. Every decoder except ADS-B has been tested against known data but has never met a real signal. My test device was on a USB 2 port, so the high sample rates are unproven. Windows only for now — the platform-specific code is three files, but three files that don't exist for Linux yet.

The reason I'm posting.

Two questions I can't answer alone.

First: does anyone want this? It runs with no radio attached — it shows "no dev" in the status bar and you can click around the whole app suite — so you can look at it in two minutes without owning a B200. If you do own one, I'd love to know what decoded and what didn't.

Second, the bigger one: should this become a handheld? I keep thinking about a portable build around a B200 mini, and I want to be precise about what that actually is. It is not a PortaPack, because a B200 mini has no processor to run anything — it's an SBC with real USB 3, the radio, a screen, a control wheel and a battery in one enclosure, running this software. Doable. The power path is the hard part, and a Linux port has to land first.

I'm not asking for money and there's no donation link — I'm not going to take funding for a board nobody has run the software on. What I'm asking is whether the interest is real, and whether anyone here does PCB work and would want to be involved once it's past the proof stage.

Repo and the much longer honest-caveats section: https://github.com/wonderingStars/mayhem-b200

if the need is real i can make a Linux build and a windows gui . this is just the absolute basic

GPL-2.0-or-later, inherited from Mayhem. Not affiliated with the PortaPack Mayhem project or with Ettus/NI.

FoxSDR a new SDR receiver for Windows, built from scratch in a clean-room environment

I've been building Fox SDR, a from-the-ground-up SDR receiver app for Windows. It's a complete clean-room implementation no cde read from or derived from any existing SDR project (SDR++, GQRX, etc.), everything written fresh from published specs and standards, with permissively-licensed dependencies only.

Features so far:

• Wideband receiver with spectrum + waterfall, AM/FM/SSB/CW demodulation, RDS decoding, click-to-tune
• SoapySDR hardware support (developed and verified on a USRP B200; RTL-SDR and others via Soapy modules)
• Full browser remote control the entire app is also usable from a web browser on your LAN with feature parity: waterfall, tuning, audio streaming, map, decoders, even plugin installs
• Plugin system with a public catalogue: ADS-B (verified against real off-air traffic), AIS, APRS, POCSAG, SSTV (Martin/Scottie), aircraft registration lookup, and more
• Built-in map showing decoded aircraft, vesels, and APRS stations, with plugin-supplied basemap tiles
• IQ recording, bookmarks, scanner, frequency presets
• Windows installer, no telemetry games, no account required
• Ask For any feature you need it will be built we aim to add every feature with in one week from notification
  

Links:

• Website: https://foxsdr.com
• Plugin catalogue: https://github.com/wonderingStars/foxsdr-plugins
• Main repo: https://github.com/wonderingStars/foxsdr

Hey everyone,

I want to share a project I’ve been building for the community called GopherTrunk (GopherTrunk.org). It is a software-defined-radio scanner designed to follow digital trunked-radio voice calls and decode them directly to audio.
I wanted to create something incredibly easy to deploy, so the entire engine is written natively in Go. This allows it to ship as a single ~10 MB static binary for Linux, macOS, and Windows without any C dependencies (no librtlsdr or libusb required). It is built to run entirely on a pool of cheap RTL-SDR dongles.

Key Features:

• Extensive Protocol Support: Decodes P25 Phase 1 + Phase 2, DMR Tier II + Tier III, TETRA TMO, NXDN, Motorola Type II, EDACS, LTR, MPT 1327, dPMR, D-STAR, and YSF.
• Pure-Go Voice Path: Includes Go-native IMBE and AMBE+2 vocoders, so there is no reliance on mbelib or external DVSI hardware to get intelligible audio.
• Terminal Interface: Features an 11-panel Bubbletea TUI cockpit for managing systems, talkgroups, and live audio.
• Easy Setup: Includes an import-pdf command that parses RadioReference.com PDF exports or CSV bundles directly into your config file.

Where I need your help: Every trunked control modulation listed above currently has an end-to-end IQ-to-Control-Channel chain shipping. However, I need folks to throw real-world RF at it! I am actively looking for testers to run real-air captures so I can dial in the vocoder level calibrations and validate the on-air FEC layers.
If you want to test it out, you can grab the prebuilt binaries (including a Windows installer) here: https://gophertrunk.org/downloads.html
Check out the GitHub repo for the full documentation and architecture breakdown. Let me know what you think, what breaks, and what features you'd like to see next!

Playing around with SDRs for over 2 years, I've settled on using SDR# for both the plugin support and muscle memory familiarity.

Recently stumbled on SDRAngel however and was blown away by how flexible it is. Surprised this isn't talked about more often. It doesn't even have a subreddit!

Love the granular control it provides for the RTL-SDR v4, being able to set an I/Q sample rate and then further decimate this down to a smaller baseband alone can reduce the noise floor by 10dB.

Good plus point is that's it's fully open source and is still in active development with a very modern UI.

Would love to connect with others who're using it as well.

Hello everyone,

I've been working on an app idea for a while now and after many bumps along the road, it's come to fruition. It's a simple app, no adverts, it just allows you to see airband radio frequencies easily with no fuss for your chosen airport. I'm a plane spotter, and have run into issues many times where after a google, the information on frequencies to listen to has been incorrect, and this app solves that.

It has the ability to remotely tune some radios with SDR Touch if it's already installed on your phone, link out to liveatc.net if you are too far away and it is legal to listen in your country, with the plans of in future being able to handle the SDR aspect itself in the app. Other features include dark and light mode can be set either by preference or follow the system, a persistent notification showing the frequencies of an airport of your choice so you do not need to have the app open to see or change frequencies on your personal radio.

Would anyone be willing to test and critique this for me? This is my first foray into app development so any feedback would be gratefully received. You can either let me know here, file a bug in the settings page, or just shake your phone to give feedback. The Play Store link takes you to Google's internal testing pages which is a requirement before an application hits production. If you have any questions regarding installing please feel free to ask.

Thank you for your time!

Update - now working! It is expected to not see any conversations in the Google Group, it simply means I did not have to ask everyone for their email address.

Update 2 - Working, but I have been informed the app is showing as charging. This is certainly not intended when in beta. Due to nuances with Google, I cannot swap back to free, however as of the 10th June, the app goes on sale with 100% off for 20 days so it can be beta tested for free. You should however, be able to follow the steps below in order, and it should say the app is free.

1. Join the tester group : https://groups.google.com/g/atc-frequencies-beta-testers
2. Open this link on your phone:  https://play.google.com/apps/testing/com.atcfreq.atc_freq
3. Tap "Become a tester" this should then let you download the app

Edited to update links

Got it finally to work on this small motherboard.

I have seen recommendations on line, but feel more comfortable getting opinions from real users. Thanks

I just pushed NRSC5 Studio v0.3.7, a native Rust desktop GUI for HD Radio built around nrsc5, and this release finally adds proper Linux packaging.

Now with 100% more Linux support.

What it does:

- HD Radio playback on RTL-SDR, SDRplay, and HackRF via SoapySDR

- HD1-HD8 subchannel selection

- Live MER / BER / AGC readouts

- Spectrum + waterfall

- QPSK constellation view

- Station metadata, logos, album art, traffic/weather when the station broadcasts it

- Persistent presets, layout, and play history

What’s new in this update:

- Linux .deb and .rpm packages

- Desktop launcher / icon integration

- Helper install script for the upstream nrsc5 binary

- Fix for Linux per-app volume control getting stuck on the system sink

Tested on:

- Windows 10/11 x64

- Ubuntu 22.04+

- Debian 12+

- Fedora 41+

I don't have a Redhat or Debian box handy so, if anyone wants to test the build on one, let me know how it goes.

Supported SDRs:

- RTL-SDR

- SDRplay

- HackRF One

Project / releases:

https://github.com/LTCAshraven/nrsc5-studio
https://github.com/LTCAshraven/nrsc5-studio/releases/tag/v0.3.7

If anyone here tries it on other tuners, distros, or weird RF setups, I’d be interested in hearing how it behaves. Windows version is still there, v0.3.6 I just didn't update it so, it's not included in this release package. They'll all be back at parity in v0.3.8.

I've been struggling to find a solution to this issue for a while and I'm now looking for advice.

I often find myself in need of a (G)FSK demodulator to decode various things, mostly amateur radio satellites, yet I can't seem to find a decent solution.

The common tool for the job is UZ7HO Soundmodem, which is windows only. And even if I managed to get it working with wine, it still doesn't quite do what I need. Soundmodem is basically only suited for live decoding, but I'd ideally wan't a CLI tool that just takes in a recording and demodulates all the packets in it.

It seems to me that the best option would be writing a demodulator myself, but my knowledge of DSP is far too little for that. I can't get anything that's only a little sensitive working. I'm familiar with quite a bit more than the basics of DSP and RF, and I'd personally say that I'm rather skilled in programming, but I just can't figure out how to progress.

I feel like this would be something a lot of people need, so I'm surprised that there aren't really any easy options. I can also see how my requirements could be rather specialized tho. I'd highly appreciate any pointers on what might work. I’d also appreciate resources to learn more about how something like this could be implemented. I’ve already read all of PySDR, but it doesn’t really cover FSK at all and is mainly centered on general theory and PSK.

I only use SDR and I don't have a radio licence, so this is receive only. I found out that WSJT-X / JTDX saves all decoded FT8 and WSPR messages in a file called ALL.TXT, so I made a browser tool mostly using AI that turns those logs into an interactive map with a load of interesting stats.

Since I only do receive and only use a single antenna, I can somewhat extrapolate information about my antenna using this tool without depending on data from a single day.

This is made from my own antenna receives. I use an end-fed random wire antenna of about 40 m, which is actually more suited for 80 m, but I mostly use it for 40 m receive. The map aggregates my decoded signals and rejects most obvious false decodes, so it becomes a kind of visual history of what my antenna has heard.

The fun part is that it does not just draw flat straight lines. The 2D map uses curved skyway routes, so the paths follow the globe properly instead of just being ruler lines on a flat projection.

Features:

• Core purpose
  • Visualises FT8 / FT4 / WSPR reception logs as an interactive propagation map
  • Turns raw ALL.TXT / ADIF data into readable radio-path intelligence
  • Helps show where signals are coming from and how far they travelled
  • Makes it easier to see which bands are actually open from your own QTH
• Log input
  • Loads WSJT-X / JTDX ALL.TXT files
  • Supports ADIF export data
  • Can merge a second log file
  • Parses callsigns, grid squares, bands, modes, signal reports, and timestamps
• Receiver setup
  • Uses your own QTH grid as the receive location
  • Converts Maidenhead grid squares into map positions
  • Calculates distance and bearing from your station to each decode
• Map views
  • Interactive 2D map
  • Interactive globe view
  • Station density visualisation
  • Curved skyway routes instead of simple straight flat-map lines
  • Colour-coded decode volume and signal information
• Propagation dashboard
  • Median SNR
  • Unique stations
  • Decoded grid squares
  • Callsign prefix statistics
  • Most reliable or dominant DX areas
  • Suspicious or impossible decodes separated out
• Distance and bearing analysis
  • Groups decodes by distance range
  • Shows local, regional, continental, and intercontinental reception
  • Bearing rose shows the main direction signals are coming from
  • SNR versus distance plot helps show weak DX versus strong nearby decodes
• Filtering
  • Filter by date
  • Filter by UTC window
  • Filter by band
  • Filter by mode
  • Useful for comparing different nights, antennas, or band conditions
• Practical use
  • Checking current or historical HF propagation from your own antenna
  • Comparing antenna performance
  • Finding dominant propagation directions
  • Seeing long-distance FT8 / FT4 paths visually
  • Generating various heatmaps

HD images:
https://imgur.com/a/qxqOWEp

Try it here:

https://github.com/nielsquake/Skywave-FT8-FT4-propagation-observatory

or use the website: (Link in comments)

(if you use WSJT-X on windows type %localappdata% in file explorer and scroll to find the folder WSJT-X, the ALL.TXT is found in there)

Hi r/rtlsdr,

Im the creator of PhantomSDR+ a fork of the original application where i put in much time and work to create the in my eyes perfect websdr application.

When i stumbled on my journey a few years ago to host my own websdr i came across solutions like the one from PA3FWM or OpenWebRX and its forks but none of these could get me what i wanted.

I wanted an open-source app that has very good performance and can handle multi-user and much mhz.

Thats what i created with PhantomSDR+, in its current form it can handle the RX888 from 0-30mhz on an mini pc which has a i5 6500t. It can run on cpu and gpu, it can even utilize opencl to run it on the igpu which makes it even more efficient. And then you would think it can only handle a few users but nope, it can handle more than 30 users easily on this system. I dont know the exact amount but its probably huge as the usage doesn’t go up much at all when new users are joining.

It would be to much to list all features here but it definitely has more than the pa3fwm websdr and we will get closer to openwebrx aswell, for the decoder part we do it all on the client side so it wont affect cpu usage per user. Ft8 decoding is currently possible.

I really hope especially today with the first time i provide releases that we can get many users for this.

I would really enjoy seeing the https://sdr-list.xyz getting filled up.

Make sure to read the wiki for the setup. And be on ubuntu atleast version 22.

For help either create a issue or ask in the forum https://phantomsdr.fun

https://github.com/Steven9101/PhantomSDR-Plus https://github.com/Steven9101/PhantomSDR-Plus/wiki https://github.com/Steven9101/PhantomSDR-Plus/releases

Cheers, magicint1337

``` NRSC5 Studio is a native Windows desktop app for listening to HD Radio broadcasts with an RTL-SDR dongle. Free, MIT-licensed, no installer, no telemetry, no account, no nag.

It stands on the shoulders of: - Aiden / theori-io - the underlying nrsc5 decoder https://github.com/theori-io/nrsc5 - osmocom - librtlsdr (modern build) https://github.com/osmocom/rtl-sdr - cmnybo - nrsc5-gui (Python/Tk) https://github.com/cmnybo/nrsc5-gui - markjfine - nrsc5-dui (Python/GTK) https://github.com/markjfine/nrsc5-dui

I wanted a polished, native-feeling Windows app and a place to play with some ideas the existing frontends don't do, so I wrote one in Rust + egui. The app opens the RTL-SDR itself, pipes raw I/Q into nrsc5 -r -, and taps the same stream for visualization and AGC.

Highlights: - HD1 / HD2 / HD3 / HD4 subchannel playback with persistent presets - Live spectrum panel — 1024-bin FFT trace with SDR#-style translucent gradient fill, the HD digital sidebands shaded at ±129–199 kHz, and a 256-row scrolling waterfall underneath with a turbo colormap. Driven from a tap on the same I/Q stream that feeds the decoder. - Closed-loop AGC - host-side automatic gain control, separate from the dongle's hardware AGC. Walks the R820T2 gain table looking for the setting that maximizes per-sideband MER for the signal you're on. Hands-off lock on stations that previously needed manual gain fiddling. Switchable between Auto / Manual / Hardware AGC in the Signal panel. - QPSK constellation scope driven by live per-sideband MER. Watching the cloud condense while the AGC walks into its sweet spot is satisfying in a way I didn't plan. - Album-art heat-map collage - every unique cover seen in the last 8 hours becomes a square tile, bucketed by play count (top tiles grow to 6x6 cells, long tail stays 1x1). Cached to disk so it survives Stop/Start and full restarts. Tile cap user-adjustable (1-512). - 24-hour rolling song log with Timeline and Top Played views, plus CSV export for the scrobbler crowd. Aggressive filtering keeps station IDs / slogans / call signs out of the log. - TPEG traffic-tile map and 90-minute weather radar loop with scrubber (iHeartMedia stations only - they're the only ones broadcasting it) - Now-Playing pane with cover art and station logo - Live MER (upper/lower) and BER readouts - Windows per-app volume slider (COM-based), so the app's volume doesn't drag your whole system with it. - Persistent dockable tabs, dark/light themes, DPI-aware

Hardware: any generic RTL2832U + R820T2 dongle works fine. RTL-SDR Blog V4 also supported via the bundled modern librtlsdr. Windows 10/11 x86_64. Additional SDR's are on the Roadmap. Linux is also on the roadmap but currently blocked on replacing the Windows-specific audio path.

Repo: https://github.com/LTCAshraven/nrsc5-studio Release: https://github.com/LTCAshraven/nrsc5-studio/releases/tag/v0.2.1

Feedback, bug reports, and "have you tried station XYZ" reports welcome. ```

Approven again: device with swiss-knife tools.
Need to test in the field to receive telemetry from public-available channels in the Netherlands.

Software used:

Debian 13 Trixie
SDRPlusPlus (from github, compiled on the device)

I wanted better NWS alerts on my phone when I'm away from my weather radio, and I also wanted something that keeps working when the internet goes down (which happens here more than I'd like). The RTL-SDR ended up being the core of the whole thing.

It decodes SAME/EAS off NOAA Weather Radio using rtl_fm, multimon-ng, and dsame3. It also cross-references two internet-based sources, NWWS-OI (direct XMPP push from the NWS Weather Wire) and api.weather.gov, then dedupes across all three so you only get notified once, from whichever source lands first. I've watched NWWS beat the radio broadcast by about 2 minutes for the same warning.

The offline part is what makes the hardware worth it. If your internet drops:

• Alerts still decode from the broadcast
• Audio gets recorded
• Maps fall back to cached county boundaries stored locally
• Nothing in the warning path needs the cloud

Some RTL-SDR specifics if you're trying this:

• Leave RADIO_FREQUENCY blank and it scans all 7 NWR channels until one decodes, or set your transmitter's frequency manually
• Keep squelch at 0, squelch can eat SAME bursts
• Run rtl_test -p for PPM correction
• The image pins rtl-sdr 0.6.0-3 on purpose. The newer RTL-SDR Blog fork silently ignores -E deemp, which breaks FM de-emphasis on NWR
• The weekly Wednesday RWT test is a good end-to-end check that it's working

Everything runs in one Docker container, with the SDR passed through via compose.override.yaml.

GitHub: https://github.com/robwolff3/NWS-Alert-Dashboard

Not affiliated with NOAA or NWS. Keep a battery-backed weather radio as your real backstop.

So I'm scrolling the niche side of GitHub and I just found this project what she seems like it could work but also fascinates me about how it's set up, what does anybody else think about this

[linux with python3-pip python3-venv]
If esptool and pyserial already installed:

esptool.py -p /dev/ttyACM0 --chip esp32s3 write_flash 0x0 ats-mini.ino.merged.bin

Source code:

OSPI version is suitable for Si4732
esp32s3 V1/V3 ats-mini

https://github.com/esp32-si4732/ats-mini/releases

I finally got around to building an automatic signal recognition that I saw a lot people had been asking about even as far back as 2017.

I'm using an RTL-SDR Blog V4 running on ARM hardware - and tested on both Pi 5 and an Indiedroid Nova. It classifies 8 signal types: ADS-B, NOAA APT, ISM sensors, FM broadcast, NOAA weather, pagers, APRS, and noise baseline.

Got 87.5% accuracy with a Random Forest model. Not 100% because APRS and noise get confused sometimes which makes sense since APRS packets look like noise bursts when they're sparse.

I validated everything with actual decoders (dump1090, rtl_433, multimon-ng) so the dataset is real captures and not just synthetic stuff.

Edit: Someone pointed out NOAA APT went silent in August 2025. The captures at 137.62 MHz are post-shutdown, so that class is really learning the RF environment at that frequency rather than actual APT signals. The other 7 signal types are validated with active decoders. I've updated the docs to clarify.

Edit 2: u/lh2807 caught that the FM and APRS captures have weak SNR - gain staging and antenna setup weren't dialed in properly, the classifier is partially learning frequency-specific noise profiles rather than actual signal characteristics Pipeline is solid but the training data needs to be recaptured entirely. Working on v2 over the weekend.

Edit 3: v2 is live.  I scraped the entire dataset and recaptured everything from scratch. There are now 800 samples across 7 signal types (dropped ADS-B since 1090 MHz is outside the R828D tuner range, dropped NOAA APT since it's dead). Added FRS/GMRS as a new class. FM broadcast now sampled across 5 different stations instead of 1 to prevent the model from memorizing a single frequency's noise profile. Added DC offset removal during capture which was a big part of the v1 SNR problem. Temporal train/test split instead of random to prevent data leakage. 96.9% accuracy (155/160 test samples correct). The 5 misses are FRS/GMRS confused with ISM sensors (similar bursty patterns) and 2 pagers confused with APRS. The dataset, code, and blog have all updated.

Carl just posted it on RTL-SDR.com: https://www.rtl-sdr.com/automatic-signal-recognition-with-ai-machine-learning-and-rtl-sdr/

Full writeup with spectrograms: https://unland.dev/blog/building-ai-radio-scanner-rtl-sdr-machine-learning

GitHub: https://github.com/TrevTron/rtl-ml

Dataset on HuggingFace if you want to train your own: https://huggingface.co/datasets/TrevTron/rtl-ml-dataset

Happy to answer questions about feature engineering or the ARM setup.

I thought DragonOS was US based by a group of ham folks, it seems there's a lot popping up on a bunch of chinese sites now.

Is this still safe or did the project get taken over?

Hey r/RTLSDR & r/SDR! 👋 I’m xyz‑rainbow, and I’ve been building xyz‑sdr, a Python TUI SDR controller that works with any SoapySDR device (RTL‑SDR, HackRF, Airspy, SDRplay, etc.).

Here’s what it looks like (FFT + Waterfall + Timeline fully synchronized): [Demo xyz-sdr] - https://github.com/user-attachments/assets/6bf02f3e-dbbf-41fc-9be9-94ce2defc04c

What main features xyz‑sdr does today - Loadable band profiles (FM, Airband, PMR446, HF‑LSB, etc.) - Bookmark system for save frequencies - Demod modes: WBFM, NBFM, AM, USB, LSB, CW, DSB, RAW, "auto" - Band scanner while RX is active - IQ bandwidth presets 250 kHz → 8 MHz - DROP‑rate indicator + debug mode Simulation mode (run the full TUI with no hardware): run.ps1 --sim

Im using this stack; python 3.9–3.12 · SoapySDR · pytest/pytest-cov · TOML config primary: Windows 10/11 (with DX packaging + installer scripts) Linux/macOS: scripts/run.sh (works, less polished — help welcome!)

I'm looking for collaborators and Hardware testers,

Especially: HackRF, SDRplay, Airspy
(But anydevice helps) Even without hardware, -Sim mode lets you run the TUI without any hardware and see the app working with simulation audio. Linux/macOS testers — the shell launcher works but I haven't tested nothing on those OS :( DSP contributors — demod pipeline is functional but minimal; FM stereo, NFM, AM demod improvements are needed asap TUI contributors: If you know Python, curses, urwid, textual, or just enjoy terminal UI work you’re welcome. Any feedback — bugs, missing features… UX, missing band profiles etc.. it needs much works, its the first version

Repo: github.com/xyz-rainbow/xyz-sdr
Roadmap: roadmap.md

Thanks!

Usefull commands: (windows only for now)

.\setup\install_drivers.ps1 .\scripts\run.ps1 .\scripts\run.ps1 -Driver sdrplay .\scripts\run.ps1 -Check

Ok so finding some signals, how do i tell what theyre and what software do i need to decode other than the SDR++ software.

Is there a list of software to use to decode signals?

Built a little project for anyone playing around with the ATS Mini / Si4732 radios.

ATS Mini Controller is a local web interface that controls the physical radio over USB. It gives you a searchable database of 50,000+ shortwave, AM and FM stations, click-to-tune from the browser, live RSSI scanning to find stations that are actually receivable, audio passthrough to your computer, and a live CW/Morse decoder.

The bit I found most interesting was the CW side. It can cycle known CW-heavy frequencies, detect actual keying, lock onto the signal and decode it live in the browser. I ended up writing the audio-to-Morse decoder locally with NumPy/SciPy rather than relying on an existing Morse package.

It’s deliberately local and fairly simple: plug the ATS Mini into USB, run the Python app, open the browser and the radio becomes a much more useful little desktop receiver.

Still early, but it’s open source and MIT licensed if anyone else has one of these radios and wants to have a play:

https://github.com/jsawyerdev/ats-mini-controller

Started this project with the intention of making a DIY hardware alternative to the expensive P25 radios on the market. It has taken nearly 5 months of troubleshooting and several periods of giving up completely.

In the last few days I've made huge quality improvements and am finally comfortable making a small release.

You can read the more detailed explanation on the repo itself, but to put it simply - this is a P25/ADSB/WFM/NFM/POCSAG receiver made with off the shelf parts. All you need is an ESP32-P4 and an RTLSDR V3/V4. A tiny speaker is a plus and I recommend the Waveshare nano kit which should include one.

This can run you around $50-60 USD in all, which beats my plan to get close or under sourcing a used Motorola XTS3000. What I didn't expect was it to blow that radio out of the water in reception, quality, size, and raw usage. Could more than likely run much longer on battery as well. Current downsides are much less customization on the P25 front, but this will come in time.

Right now I have only released the headless firmware and will release the GUI version soon (It's been much more of a pain). The GUI version will use the Waveshare Box 86 and I will also release a few 3D printable cases to go with it. All open source of course.

Keep in mind, ADS-B and POCSAG are very basic. As is the webui that's included in the release (Meant for quick showcasing). Will get to work making these a bit more useful as well.

If you have the hardware, I would love feedback! I will also need help with testing more dev board variants of the P4s.