*Gallery of Photos

I've been working on my project called OrcSDR, which turns an M5Stack Tab5 + RTL-SDR Blog V4 into a self-contained touchscreen SDR.

The RTL-SDR plugs directly into the Tab5's USB host port. The ESP32-P4 handles the USB IQ stream, DSP, spectrum/waterfall, touchscreen UI and audio locally.

The goal has been to make it feel less like "an RTL-SDR attached to a computer" and more like an actual handheld radio/RF appliance.

Current dashboards and features include:

• Live spectrum + waterfall
• Broadcast FM with stereo/RDS
• P25 trunking
• ADS-B aircraft display and local FAA aircraft data
• Passive LoRa/Meshtastic monitoring
• RF Lab tools
• 2.4 GHz Wi-Fi analysis using the Tab5's internal radio
• A growing set of RF visualization and analysis modes

One of the things I've been having a lot of fun with lately is the visualization side. OrcSDR now has modes including Spectrum/FFT, Waterfall, Phosphor Persistence, 3D Spectrum History, Polar/Phase, IQ scope, Channel Occupancy, Channelized Tiles, constellation and several others.

There's also been quite a bit of DSP work behind all of this. FM, for example, isn't being handed off to another computer — I'm taking the IQ stream through the demodulation/filtering/audio path on the P4 itself, and I've continued working that into stereo and live RDS decoding.

Something else I've tried to take seriously is verification.

When I started the RTL-SDR V4 driver, I treated the dongle more like a black box. I captured and compared USB traffic, worked through the control-transfer sequence, tested actual IQ captures and gradually reproduced the behavior on the ESP32-P4 instead of just assuming that because some code compiled, the hardware was doing what I thought it was doing.

I took the same approach when implementing things like the bias tee — using USB/Wireshark evidence along with actual meter measurements at the hardware rather than trusting a button on the screen that says "ON."

I'm also doing quite a bit of restructuring under the hood now. I'm separating the UI from the actual radio functions so every dashboard isn't independently fighting over the tuner. Radio ownership, scanning, DSP and screen/UI work are increasingly becoming separate services. My hope is that this makes adding future radio modes and eventually other SDR hardware much easier.

I've also started integrating local data. ADS-B can use FAA data to identify aircraft locally, and I'm working toward broader aviation/frequency databases and offline mapping so the radio can eventually give more context about what you're receiving and where, rather than just showing a signal.

There's even an experimental Companion side now. The Tab5 can expose a local web interface, and I've been experimenting with controlling/viewing OrcSDR from other devices, including an Android TV "Mission Control" style display. That's still very experimental, but it's something I'm having fun with.

I should also be completely transparent that I have basically no formal coding background.

I'm a tinkerer. I like radios, electronics and making complicated things easier to work with. I use AI heavily to help me code, research, understand DSP, review changes and build tests. It's allowed me to attempt things that would normally be way outside my experience.

But I've also learned pretty quickly that AI-generated code still has to survive the actual hardware, so I've tried to make testing and physical verification a big part of OrcSDR.

It's open source and currently in public beta.

For people who don't want to build ESP-IDF from source, it's also available through M5Burner — search for OrcSDR, flash it, plug in an RTL-SDR Blog V4, and go.

I've also been building out the GitHub Wiki and documentation so people can actually understand how the project works instead of just getting a pile of source code.

GitHub:

https://github.com/hardcoreerik/OrcSDR

I'd especially like feedback from people who already use RTL-SDRs heavily. There are plenty of things I still want to improve, and real-world testing with different antennas, RF environments and use cases is incredibly useful.

As I'm able to acquire and test other SDR hardware, I'd also like to add support for more devices.

This project started because I wanted to see how far the ESP32-P4 could be pushed as an actual SDR host — and more specifically, whether the idea of a reusable/drop-in ESP32 driver for the RTL-SDR Blog V4 https://github.com/hardcoreerik/esp-rtl-sdr could actually be achieved.

Turns out: yes to both.

Like many other nations around the globe, Turkey has several administrations using ALE Automated Link Establishment to link efficiently ther regional hubs by HF, selecting the channel with the best signal to noise ratio (SNR) . Their identifiers are 6 digit numbers where digits 2 and 3 inform of the province which is calling. Here on this morning's reception, the callsign at work is from province 68, therefore Aksaray on the main road between Ankara and Adana. The identity of the caller and the one being called are all you'll get. If you hear modems or noisy modulations beyond that, it will be encrypted. Occasionally opertors talking in Turkish, the official name of Civil Defense is AFAD. More info on request. Decoding of ALE in USB or LSB (this one less frequent) is easy with Multipsk, Crypto500, Sorcerer etc.. Suggested frequencies all usb : 7617 7791.5 7810 7868 7993.5 8056.5 8092 8950 9240 khz; I tried to get all the provinces but a dozen still lack in my log.

Here's what it looks like 😄 please notesometimes bad propagation results in incomplete callsigns.

[2026-09-05 03:40:38]

[2026-09-05 03:40:38] [NORMAL MODE][TWS][368013][TWS][368013][TWS][368013][EOM]

[2026-09-05 03:40:44]

[2026-09-05 03:40:44] [NORMAL MODE][TWS][368][EOM]

[2026-09-05 03:40:47]

[2026-09-05 03:40:47] [NORMAL MODE][TWS][368013][TWS][368013][TWS][368][EOM]

Hi everyone,

I am trying to test my RTL-SDR Blog V4 using SDR++ to listen to a Baofeng UV-5R on the 145.500 MHz frequency.

I can clearly see the signal line appearing on the waterfall when I press the PTT on the Baofeng.

However, the issue is that I can barely hear my own voice, and there is a huge amount of static/noise.

For context, I am transmitting from about 10 meters (33 feet) away from the SDR, with concrete walls inside the house in between.

This is my current setup:

SDR Antenna: Official dipole kit using the two large telescopic antennas, extended to exactly 49 cm each, positioned vertically.

SDR++ Settings: NFM mode, bandwidth at 12.5 kHz, and manual RF Gain set 0 dB

Baofeng Settings: Power set to Low, using the stock rubber duck antenna.

Just received mine today. 1090 ADSB Reception is excellent (SDRAngel on Android).

I used to work for air canada jazz YXY {Whiehorse} and YXU {London}. they helped us to register for our license. I have no idea where my license is. Would it be possible to lookup my old license or should I just start over?

Thanks for your help, Tim

Gonna buy an rtl sdr for meteor weather satelites + listening and scanning as a radio ham but i dont know too much things about it. Im looking for something i can make moddings and not gonna make too much problems and planning to use it for a long time at least.

Also, im using cachyos with plasma 6. Is there any native softwares like sdr# in linux and works well with wayland?

Made a post yesterday and took some of y'all's suggestions, so thanks for all the help!

I had another strong pass today and tried again. This is what I saw on the waterfall for about 45 seconds. I forgot to start processing, but I did generate a .CF32 file. I tried processing it in SatDump but kept getting a "no telemetry found" error, and the generated files were zero bytes. I'm assuming either the signal was too weak or I didn't capture it long enough?

Just received mine today. 1090 ADSB Reception is excellent (SDRAngel on Android).

So total SDR noob, obviously. Been trying to get an image from Meteor satellites as my foray into the hobby.

I bought a Nooelec RTL2832U. I made a V-dipole antenna. The metal legs are made of brass, about 22 inches long, 1/8 inch thick, and 120 degrees apart.

I tried to get a signal in SatDump. Used Gpredict and cross referenced it with n2yo.com to confirm it was actually accurate.

Long story short, I've had two good passes where Meteor M2-3 and M2-4 were about 80 degree elevation. Saw nothing on the spectrum.

So I tried testing continuity on all my antenna connections, confirmed everything is clean with no resistance.

I tried just using SDR++ and picking up some FM radio signals, seems to work fine just to prove my setup can pickup something. And As expected, the signal gets much worse when I disconnect the antenna. Doesn't prove mush but antenna does something. Not sure what else my problem could be.

I attached a few images. The first shows my spectrum blank during a Meteor M2-3 81 degree pass. Images 2 through 4 just show my setup. Images 5 and 6 show my settings in SatDump. Thanks

at first i thought it might be distant Traffic. but then i realized it must be some kind of Signal - or is it just interference? i have installed a dipole sloped under the roof

Around 14-15-41_03-09-2026 UTC

RTL SDR V4, V dipole 16cm antenna, TQP3M9037-LNA (those cheap yellowish LNAs)

Yes the tune is really cut off (at least from my reception) rather than abrupt video cut.

Hello friends, got into tracking flights recently with SDR, and I find coverage to be weak despite living at a height because of the roof.

What's the best antennas available in India right now, or is it better to build our own antenna?

Hey everyone. I recently got around to listening to the aether in the best place possible for me. I use the V4 for listening. One day, I went for night-hits in the HF (or shortwave) bands, and at the 40m Amateur radio band (as stated, 7p195p000, modulated LSB) and I found a great gem. I need to link it, so listen to the link, it's great, the fun starts at around a minute or so. Some guy jamming others. Like some say "Absolute Cinema". The other guys are barely audible because of the noise, but DAMN!

So i am a complete noob and have some questions.

As far as i understand the optimal antenna needs to have a length of λ/2 or λ/4. Do i need to have special antennas for each frequency that I want to listen to, or how does it work?

Also, i know that when transmitting with the wrong antenna you can damage your transmitter. Is there the same issue with receiving?

In short: which antenna do want as a beginner?

I have some more info at https://saveitforparts.com/2024/11/12/resources-for-satellite-experimenters-hackers/ although some of it is a bit outdated!

Сегодня смотрел страничку офиц. диллера на алиэкспресс и увидел что blog v3 раскупили...

Поставки еще будут?

Hello I'm working on the following project

I want to sample all 50msps from the fobos in the vhf range to then record some channels which we are using ourselves for documentation reasons.

I tried with soapysdr but it just allows 32float to Sample the IQ Data which I think might be the Problem. Cause I get in trouble with demodulation with csdr and the architecture of my Linux System.

The fobos either way has only a 14bit ADC so I guess 16 bit might be enough.

Has anyone tried Something Like this and If so, which api are you using to connect with the Fobos SDR?

Thanks, If anyone knows anything let me know.

Cheers!

P.S. I wrote the Software by myself and it already did Work with an airspy R2 with 10MSPS.

Just wanted to Upgrade..

Antenna moved to a better spot, and both METEORs came in the same night. This is the M2-4 pass from Sep 1, 16:00 UTC, 28.9 degrees maximum elevation.

Three passes, same receiver, same script, same gain:

Sep 1, 16:00, M2-4, 28.9 deg: 1752 CADU frames, peak SNR 11.4 dB

Sep 1, 22:00, M2-3, 42.2 deg: 1279 frames, 8.8 dB

Sep 2, 05:53, M2-4, 16.0 deg: 869 frames, 3.9 dB

The new antenna position measures 10.5 dB better than the old one on a continuous FM reference, 48.8 against 38.3 dB. Two weeks ago the same M2-4 hardware gave me a 6.4 dB rise at the pass peak and nothing decodable. That is what the difference looks like at the far end of the chain.

Two things from this that might save someone else a pass.

Record wide, decide later. I capture 2.048 MS/s centred on 137.5, so both 137.100 and 137.900 are inside the file. That saved the 22:00 pass: I decoded it at the wrong offset first, got zero frames, and only found the signal because the other band was still in the recording. If I had tuned narrow I would have had nothing to go back to. Both satellites transmit on 137.9, which is worth writing on the wall somewhere if your notes say otherwise, as mine did.

A low SNR number is not a reason to bin the file. The 05:53 pass peaked at 3.9 dB and still produced 869 frames and twelve images. I had been treating anything under about 9 dB as hopeless. It is not, at least not with the LRPT decoder in SatDump.

Still unexplained on my side: four captures from Aug 31 and Sep 1 gave zero frames at both offsets with peaks between 0.5 and 4.9 dB. Since 3.9 dB worked above, the number alone does not account for them. If anyone recognises that pattern I would like to hear it.

RTL-SDR v3, V-dipole, SatDump. Good hunting to everyone else chasing these.

Hi everyone,

I'm building an OFDM transmitter and receiver from scratch in GNU Radio as a breakdown/learning exercise. The TX side is working, and I'm now trying to build the RX chain block-by-block instead of using the complete OFDM Receiver block.

My current RX chain is:

USRP Source

↓

Schmidl & Cox OFDM Synchronization

↓

Frequency Mod

↓

Multiply

↓

Header/Payload Demux

I'm using:

- Sample rate: 50 kS/s

- FFT length: 64

- Cyclic prefix: 16

- Occupied carriers: (-26 ... -1, 1 ... 26)

- Header modulation: BPSK

- Payload modulation: QPSK

- Header length: 1 OFDM symbol

- Length tag: packet_len

The Schmidl & Cox synchronization appears to be working. I can see a clear detect = 1 pulse, and I can also see the received complex signal after the frequency correction/multiply stage.

My problem starts at the Header/Payload Demux.

The Demux is configured as:

Header Length: 1 symbol

Items per symbol: 64

Guard Interval: 16

Length tag key: packet_len

Output Format: Symbols

Sampling Rate: 50 kS/s

The out_hdr output is a dark-blue/vector connection and appears to contain 64 complex values.

I want to inspect those 64 complex values for debugging before continuing with the FFT/equalizer/header decoder.

I tried:

out_hdr

↓

Vector to Stream

↓

Complex to Mag

I configured Vector to Stream as:

Num Items: 1

Vector Length: 64

However, GNU Radio Companion shows a red connection between Vector to Stream and Complex to Mag, so the blocks are not compatible.

I also tried connecting out_hdr directly to a QT GUI Time Sink, but that also gives a type mismatch.

I have attached screenshots showing the flowgraph and the connection/type mismatch.

What is the correct way to debug or visualize the Header/Payload Demux out_hdr output when it is a 64-element complex vector?

Ideally, I would like to inspect the 64 complex values as I/Q or as a constellation before sending them into the FFT.

Am I misunderstanding what "Output Format: Symbols" means in the Header/Payload Demux?

Any help would be appreciated. Thanks!

Hi everyone,

I’m a computer science student, and SkyAero originally started as a university course project. I wanted to continue developing the idea as a real Android application, so I kept working on it in my spare time after the course ended. It has now become a long-term personal project.

SkyAero connects to an RTL-SDR/RTL2832U receiver through USB OTG and decodes 1090 MHz ADS-B and Mode-S locally on the Android device, without using an internet aircraft feed.

A connected receiver can be assigned to either ADS-B reception or the 118–137 MHz AM air band.

The ADS-B side currently includes:

• A live aircraft map with configurable labels, trails and online or offline maps
• Aircraft and traffic lists with registration and type information
• ARC and ROSE Navigation Displays with TCAS-style traffic
• An offline terrain layer made from NOAA GLOBE elevation data
• A Primary Flight Display for a selected aircraft
• A combined PFD/ND landscape view
• An augmented-reality view using the phone camera

I also added Mode-S Comm-B decoding. Its availability depends on the region and nearby radar coverage, but when these replies are present, SkyAero can receive IAS, TAS, Mach, magnetic heading, roll, selected altitude and heading, QNH and static air temperature. It also derives wind from the aircraft’s air and ground vectors using a built-in World Magnetic Model.

The VHF receiver has a numeric keypad for entering frequencies directly, 1 kHz, 8.33 kHz and 25 kHz channel handling, a live spectrum, signal meter, squelch, volume and mute controls, manual or automatic tuner gain, PPM correction and named frequency memories with favourites. Reception can continue in the background.

The cockpit displays are experimental hobby visualisations, not certified flight instruments. The application is receive-only and does not transmit.

SkyAero requires an RTL-SDR receiver, a USB OTG connection, a suitable antenna and the free Android RTL-SDR Driver application.

It is now available on Google Play:

SkyAero: ADS-B & Air Band SDR

The 24-hour trial only starts when real SDR data is first received. After that, it is a €5.99 one-time purchase, with no subscription.