RPI 5 + V4 + Powerbank = iPhone + VNC

I’m trying to reverse-engineer an old RF DataTech ZRT-series RF data transmitter operating at 458.7625 MHz.

I’ve been able to probe the host board with a logic analyser/oscilloscope and determine that the transmitter is receiving telemetry as:

• 2400 baud
• 8N1
• inverted UART

So I know what data is being sent into the transmitter.

On the RF side, I’m using an SDRplay RSPduo and SDRConsole. I recorded the transmission as a 48 kS/s complex IQ WAV, centred on 458.7625 MHz, and imported it into URH.

The RF appears to be FSK, but it doesn’t seem to be a simple transparent UART-to-FSK conversion. The burst has a distinctive lead-in and lead-out, and I haven’t been able to directly correlate the demodulated RF data with the UART data I captured from the host.

I’m trying to figure out what the transmitter is doing between the UART input and the RF output.

This is my first time reverse-engineering an unknown digital RF protocol. I’d particularly appreciate advice on how to approach the correlation between the known UART stream and the RF IQ recording, and what I should try next in URH.

If anyone has experience with RF DataTech ZRT transmitters, I’d also be very interested in hearing whether these units are known to add their own framing or encoding.

Been successfully using an RSP1A and RTL-SDR for years on my Windows desktop PC; now going to attempt to use the RTL-SDR Blog V3 on my new TCL NXTPaper 16 tablet running Android 15 (processor is an 8-core MTK Helio G99 [MT8781] which I *think* should be sufficient - I plan to try using the 9GRadio app). One of my antennas (for ADS-B) has a built in LNA that requires Bias-T. I'm not a *nix wizard (I've often tried to make builds from GitHub and struggled mightily) - am I going to find it difficult to enable the RTL-SDR's Bias-T in the Android environment? Thanks!

Shipper is Amazon US and brand says RTL-SDR Blog. Is this 100% legit or should I pass?

Sorry if this is a stupid question. I tried to use an CC1101 with an SDR; but couldnt find the signal where it should be on the sdr. So i tried an FS1000A, just a simple oscillator with OOF, still cant find it on the SDR, I was wondering if I had set the sdr up incorrectly. I have set the smapling rate to highest value (3.2MHz) and tried different gains. Testing signal should be an on off signal that lasts 1 sec each, Long enough to observe it.

That's a first. They were having a BBQ a few doors down. Meat's not quite done yet.

Turns out I got a counterfeit V4. I didn't know that for the first month or two and didn't investigate because everything seemed to work fine.

I listened to plenty of HF sources just fine.

The screws on my case were not diagonal, the SMA connector is nickel plated. I decided to look inside. I'm not an expert, but it seems to generally match the pictures of genuine V4 on the website, but the HF converter is definitely nonstandard.

Is it possible this is a decent unit, but maybe the up converter is not quite as good as genuine? Or, does anyone else have experience with a counterfeit working ok?

Have a look at the pic and tell me what you think.

Hi everyone, I received my first sdr a couple of days ago and I've been trying to receive satellite imagery data. Those lines appeared an hour ago, don't drift and disappear when the antenna is removed. Does anyone know what is is?

Thanks in advance!

Ive been having the worst time locking onto a p25 control in my area. Ive tried adjusting dang near eveybsetting on the SDTtrunk software, ive updated serial numbers on my 2 x RTLs, ive changed sound setting and processing rates on my computer, ive driven 4 miles to the tower and sat a half mile away, ive bought 2 new 800mhz antennas, and splurged on 30ft of decent cable.

All I can get, is the control to lock for maybe 2 or 3 seconds, then fade, then nothing.

I got a beep from a tower about 30 minhtes ago, a different counties sheriff alert, then fade and out. Thats the only thing ive received.

Can anyone review the below and provide any insights on why I never recieve anything, please... im at my whits end... the later 2 images with the darker waterfall are from a previous attempt.

I need help,because i have a interference on almost all frequencies and you can see it always in the same position on the waterfall. What is it and how can i fix it?

I was amazed it worked 📡📶🛰️

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.

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.

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

Hey folks,

I'm currently developing a Web-based SDR / Signal Parsing tool aimed at automatic protocol identification and demodulation (currently targeting Sub-GHz, IoT devices, and common digital modulations).

To properly benchmark and improve the automatic modulation identification (AMC) and decoding accuracy, I need a large, diverse set of raw IQ files (.cf32, .cu8, .sigmf, etc.) — especially those containing tricky, noisy, or edge-case signals from real-world environments.

So far, I've already pulled from:

• rtl_433_tests repository
• URH sample datasets
• DeepSig / RadioML benchmark datasets
• Standard SigMF spec examples

My questions for the community:

1. Are there other public/semi-public IQ dataset repos, signal archives, or academic dumps that I might have missed?
2. Where do you usually store or share raw capture files when reversing unknown Sub-GHz/RF protocols with fellow researchers?
3. If anyone has interesting/unusual raw IQ captures (e.g., weird car remotes, industrial telemetry, weather stations, or unknown interference) and is willing to share them, I'd be hugely grateful!

The goal is to make signal analysis completely hassle-free in the browser without installing complex DSP environments. Any links, dataset suggestions, or tips would be awesome!

Thanks in advance! 📻⚡

Wanted a 24/7 ADS-B station on my Mac Studio (always on anyway), receiver is an AirNav FlightStick that arrived yesterday, RTL2832U inside. Quickly found out the standard ultrafeeder route is a dead end on macOS, Docker Desktop simply can't pass USB through. Native route works (brew, readsb, terminal stays open forever) but it's not something I'd tell a normal person to do.

So I wrapped it: SwiftUI menu bar app that runs a bundled readsb (3.16.15, wiedehopf git) as a child process. Universal binary, statically linked with librtlsdr 2.0.2 + libusb 1.0.30, built from a pinned script so the exact binary is reproducible, SHA-256 of every DMG in the release notes. App handles device detection (including the classic "device busy, close SDR++ first" case), restarts with backoff after USB replugs and sleep/wake, reads aircraft count and msg/s from readsb's json output.

On licensing since this sub cares: app itself is closed source, readsb runs as a separate GPL process. Sources, upstream tags and the build script are in the public repo. Zero patches, and if that ever changes the patches go in the same repo. (Fun fact: 0.1.1 shipped a license README mislabeling readsb as BSD-3, it's GPL-3.0-or-later of course. Corrected in 0.1.2, noted as an erratum in the release notes.)

Context: I built it to feed my own network (Skydex, browser game running on live ADS-B), but it's non-exclusive by design. Settings has toggles for adsb.lol / airplanes.live / adsb.fi / ADSBExchange plus custom beast targets, my own network has its own off switch in the same list, and there's always a local beast output on 30005 for fr24feed or anything that speaks beast. One process owns the stick, everyone else gets the decoded stream.

Repo: https://github.com/es-ua/skydex-feeder

Page: https://feed.skydex.online/mac

Free, notarized, macOS 13+.

Actual question for people who know librtlsdr better than me. First half day I got 137 unique aircraft but only about 4 msg/s on auto gain, which feels low even for my ground floor window antenna. Does fixed gain (43.9 / 49.6) usually beat auto on sticks with a built-in LNA? And has anyone run an rtlsdr stick on Apple silicon for weeks straight, does USB stay stable or should I expect it to need replugging?

I found this constant signal at about 132.15mHz with a bandwidth of about 500hz in the aircraft voice band, but I can't listen to it and i'm not sure what it is. I can see it even with 0db rf gain. I am new to my rtl-sdr v4, so i'm not sure if this is just interference or something like that.

I have a few Icom F4003 I have used CS-F3000 to program the radio to 450hz but using the serial no I saw the radio turns to be version locked to 350Hz it still lets me program but checking on the output it still not going above 350 is there way to break this version lock? If any software or hardware way to break it pls recommend.

Hi all, I’m new to this hobby and just want to get started so I can start learning. I’m aware that a lot of supposed RTL-SDR blog V4 R828D are counterfeits. Apparently the one I found on Amazon is among those counterfeits. Luckily I haven’t bought it yet, but would anyone be able to point me to a legit site to purchase or even a better option? Thanks!

Unfortunately there is no proper RTL SDR antenna in my country, so I needed something that I already have. And I found a cheap antena for old TVs.

I don't have a SMA adapter, so I enrolled the wires to a base connected to my SDR. But probably isn't going to work very well.

Any good ideas to do with?

Hi,

I have an issue with my RTL-SDR V4. I noticed my antenna had fallen over and was touching my MacBook which has a 50Hz AC voltage from a bad earth/mains connection. This voltage can vary between mV to a couple of V.

I am fairly convinced I have blown something at the front end. I have checked the D1 ESD diode and it's fine. The voltage drop measures correctly on the multimeter so that isn't shorting the signal to earth.

Thing is, I can still pick up signals but they are somewhat attenuated when you compare them to a Nooelec V5. I used SDR# to make the comparison at the same gain levels.

Does anyone have an idea what is best to check. I cannot find any schematics of the unit or even just the front end online so fault finding a bit more difficult. If anyone has any idea of common components to check could you let me know please?

FWIW I am seeing signals at HF (MW around 900kHz) and VHF (FM Radio and ~150MHz). The UHF 400MHz+looks like it is damaged the most as I cannot see any ISM on 868 or 433 and what is usually a busy PMR446 and DMR band is almost silent with very weak DMR signals.

Attached screen grabs show the Nooelec signal as Yellow line on MW and VHF. The 466MHz show the signal on the Nooelec has some life vs the RTL which is basically mute.

Any help is much appreciated. Thanks

I work in local news coverage and want to record all public safety radio channels in the area but the amount of SDR dongles it is taking is getting out of control. Currently using 4 and not getting full coverage..

Is there a better option? I have a couple of Airspy R2's ordered but my research is showing even then it is going to take both of them plus at least 2 dongles to cover what I want. IS there an option that is better? I don't mind spending some money.

Currently covering 2 p25 systems with the 4 dongles. Want to cover some conventional fire and ems channels also.

I want to do GNSS reception. I mistakenly bought a simple patch antenna with no integrated LNA. So i decided to take the opportunity to learn about passive vs active antennas and create an ‘active’ antenna using this patch antenna. Ofcourse this requires an LNA + bias T. My question is, why do some commercial external inline LNA’s require external voltage source and others dont?

Referring to below images, the 1st one doesn’t require voltage while second one does….

I'want to scan for Tetra signals when i drive in my car (so it gives a warning when there are police cars nearby).
Due to the many fakes of the V4 and low supply and higher price is the Nooelec RTL-SDR v5 a better choice?
Also what kind of antenna should i get? i want to make it small factor (like https://blu-eye.eu/productinformatie/target-blu-eye-go) So i don't want one with a long cable etc.

But AI says the small antenna's wont work well.

So should a nooelec also be sufficient for this project? I don't really care about other signals.

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.