u/Comprehensive_Ship42

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

A few weeks ago I posted about **mayhem-b200** — PortaPack Mayhem's interface and its ~103 apps rebuilt as a native PC application, originally driving an Ettus USRP B200. Since then it's grown a **web portal**, and that's what this post is about.

## What's new

**It's no longer B200-only.** The radio side now runs through **sdrlink**, a small open server that puts any SDR on the network. It has a native UHD backend for USRPs, and a **SoapySDR connector for everything else** — RTL-SDR dongles, HackRF One, Airspy / Airspy HF+, LimeSDR, PlutoSDR, bladeRF, SDRplay... if there's a Soapy module for it, it should work. The apps automatically adapt to whatever radio is attached (gain ranges, bandwidth, TX capability all follow the hardware's actual caps).

**The web portal.** All of the apps in a browser grid — searchable, grouped by category, launch anything with a click. Apps used to just mirror their 240×320 screen into the browser; now there are **native panels** built for a real display:

* **ADS-B** — live aircraft table plus a map with real OpenStreetMap streets

* **AIS** — a dedicated vessel chart

* **Maps everywhere** — every geo-capable app (APRS, radiosonde, EPIRB, wardriving...) gets a proper street map, not a blank grid

* **Live spectrum + waterfall** streamed over WebSocket (FFT is done server-side, so it's light on the browser)

* Native tables, consoles and receiver controls for the rest

Everything is open source (GPL-2.0-or-later), the wire protocol is a published spec, and the whole thing runs on Windows and Linux.

## Looking for beta testers

This is one person's project and it has been tested hardest on my own bench (USRP B200 — live ADS-B aircraft decoded off the air, ~2000 unit tests passing). The SoapySDR path opens it up to hardware I don't own, which is exactly where I need your help:

* **If anything doesn't work — tell me.** Any radio, any app, any browser. A short note with what you plugged in and what happened is enough.

* **If there's a feature you want — ask.** Seriously. I will build any feature you ask for, providing I have the time. The native panels above exist because they were the obvious things people would want; your requests set what comes next.

Drop a comment or open an issue on the repo. Even "I tried it with an RTL-SDR and it worked" is genuinely useful data.

you need the both repos if you are using anything other than a ettus b200

Github repo : https://github.com/wonderingStars/mayhem-b200

Github repo https://github.com/wonderingStars/sdrlink-beta

A single WireGuard tunnel is one path. If you have more bandwidth than one tunnel can carry, or several clients that each want their own exit, today's options are a container per tunnel or a pile of hand-written ip rule scripts.

I wrote a small daemon that owns the routing table on a gateway box and gives you two modes per client:

• pin — one client, one tunnel, permanently
• bond — spread a client's connections across every live tunnel (ECMP)

The config is the whole interface:

tunnels:
  - /etc/wireguard/wg0.conf
  - /etc/wireguard/wg1.conf
  - /etc/wireguard/wg2.conf

clients: 172.20.0.0/24

routes:
  pin:
    - 172.20.0.10
    - 172.20.0.12
  bond:
    - 172.20.0.20

Four things that took a while to get right:

• fib_multipath_hash_policy=1 is mandatory, and the kernel default is wrong. At 0 the hash is L3-only, so every connection to a given server rides one tunnel. Torrents spread anyway, so a torrent-only test hides it completely.
• A tunnel being up means nothing. WireGuard only rekeys when there is traffic, so liveness is time-since-handshake. Interfaces sit up for hours blackholing whatever you route into them.
• Deleting an interface silently empties the table that routed through it — while the ip rule pointing at that table survives. A tunnel that drops and comes back leaves its pinned client with a rule to an empty table: every rule present, plan unchanged, exactly one client dead.
• Client traffic must be masqueraded onto the tunnel's own address. Cryptokey routing at the far end drops any source that isn't the address your provider issued, and it fails silently — handshakes fine, counters move, requests vanish.

Fails closed. No live tunnels means no path out, not a fallback to your ISP.

bondvpn leak-test drops every tunnel and probes from a throwaway netns attached to the client bridge — the same path a container's traffic takes, so the same rules apply. Probing from the host would prove nothing, since the kill switch lives in a forward-side chain.

• Single static Go binary, no dependencies, nothing to add to your compose file
• Linux, root, up to 5 tunnels (ships configured for 3)
• AGPLv3 — https://github.com/wonderingStars/bondvpn

deleted the last Post because the image was made using AI it was like a promote image from bing ai

Hi all,

I've spent the last while building sdrlink — a small server that runs next to your radio and exposes it over the network with a documented protocol. Tuning, gain, sample rate, and raw IQ streaming, so a client can drive your SDR from another machine without linking a vendor SDK.

The reason it exists: I wanted a PortaPack Mayhem-style app suite running on a PC against a real SDR. That client is mayhem-b200 — open source, GPL, ~90 apps ported from the Mayhem firmware, including an ADS-B receiver with a live aircraft map. sdrlink is the piece that lets it talk to hardware that isn't the USRP I develop against.

What I actually need testers for, honestly: I've verified all of this against an Ettus B200. The SoapySDR path — RTL-SDR, HackRF, Airspy, LimeSDR, PlutoSDR, BladeRF — is written, routed, and unit-tested, but I have never had one of those radios in front of it. The code reaches SoapySDR::Device::make() correctly; whether it then works with your dongle is exactly the unknown. If it falls over on an RTL-SDR v3 I'd genuinely rather find out from you

Straight answers to the things you'll ask:

• Windows x64 only right now. Linux is doable, not done.
• The connector ships as a binary during the beta. The client is fully open source; the wire protocol is documented, so you can write your own client against it.
• It checks in with GitHub periodically and this beta build is time-limited — when the beta ends it stops and tells you so. No user data leaves your machine; it's a visibility check on one repo, nothing else.
• You'll need the SoapySDR module for your radio installed.

Link: https://github.com/wonderingStars/sdrlink-beta

there is a step by step on how to isntall everything

Bug reports, "it doesn't see my dongle", and blunt feedback all welcome. Especially the blunt kind.

[effacé]

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.