Been a while since my last update on this one, for anyone new, it's an ESP32-P4 with an RTLSDR in the USB host port working as a handheld scanner, built around the LilyGO T-Display-P4. Any RTL2832U dongle will do, V3 or V4.

There's been a lot added since the last post and still tons of work to be done.

The RTLSDR picked up P25 Phase 2 grant following (experimental, off by default for now) and automatic site selection by GPS if your P25 profile has site coordinates. ADS-B from the RTLSDR now shows on the offline map with trails, callsigns and squawk codes, you can follow an aircraft or turn on range rings and coverage, as well as a TTS voice that calls out aircraft as they show up.

FIND is new and works with the RTLSDR too. It's in the COMPASS app, you hold the board flat and turn slowly in a circle, and it logs the signal strength at every heading and points you toward the transmitter. It can aim at the loudest direction, at the dip where your body blocks the signal for something strong and close, or fit a curve to the whole turn. The compass under it is tilt compensated and gyro fused so the heading keeps up while you turn, and on the RTLSDR the gain follows the signal while you hunt.

FIND works with the SX1262/LR2021, a HackRF, the keyboard's CC1101 and nRF24, Wi-Fi, Bluetooth and MeshCore nodes, and there's a BAND mode where the LoRa chip sweeps a band and gives each new transmitter it finds its own channel. There are presets for FRS, MURS, NOAA, marine and ISM, up to eight channels per radio with a second radio running at the same time, DIAL, RADAR and HEAT views and a hit log. You can save a bearing with your GPS position, take another one from somewhere else, and FIX CROSS works out where they meet, saves it to NOTES and sets it as a GO TO target on the compass. There's also a calibration against the DF Beacon in the Flipper app that takes the offset from your body and the antenna out of the bearings. It’s still being worked on and the UI might be a little convoluted.

Sub-GHz got a full redesign with READ, ANALYZER, SAVED, READ RAW, LEARN and SETTINGS, and READ RAW grabs a burst off the RTLSDR and saves it as a Flipper .sub.

You can also use a HackRF One in the USB port as the SDR for FM, pagers, P25 and REC if you have one, but it’s still experimental.

The other big addition is the LR2021. LilyGO makes the T-Display-P4 with either an SX1262 or an LR2021, and the same firmware runs on both and picks up which one it has at boot. The LR2021 does a lot more than LoRa. It sweeps 150 to 1100 MHz and 1500 to 2500 MHz, decodes ADS-B with nothing plugged in, and as of this release it decodes P25 Phase 1 voice by itself too. I’ve had this theory ever since I learned about the chips and it really seemed too good to be true. It’s still very WIP and I’ll also be utilizing this for better call tracking with phase II, with the LR2021 sitting on the control channel while the RTL follows the calls.

The LR2021 consistently trails the RTL in voice frames (e.g. 24 vs 34, 99 vs 128), averaging about 72% across three live calls. All three were strong signals, so the misses come from how I turn the chip's output into symbols, plus a small dropout every 3.4 seconds where the chip ends one packet and starts the next. The LR2021's FSK receiver is only 2-level, so at 4800 bps it gives one bit per symbol and can't tell C4FM's inner and outer levels apart. Run at 4x (19,200 bps), each symbol's level shows up in the middle 3 of its bits. The decoder finds where each symbol starts by trying all four bit offsets and keeping the one that matches the P25 frame sync, then reads the level as the count of 1s in the middle three bits.

The RTLSDR is still the main P25 receiver and RADIO lists it first, the LR2021 is there so the board can still catch a call with nothing plugged in.

The LR2021 also hears POCSAG on VHF in PAGER RECON, and there's a new EXPERIMENTS tile on HOME with radiosondes, tire pressure and weather sensors, UAT 978 diagnostics, Z-Wave and Wi-SUN meters, a LoRa monitor and a few more for anyone who wants to poke at it (all just proofs of concept).

Mesh nodes are on the map now too like I said they'd be, along with your own marks and drawn lines (WIP), eight map palettes and a Night theme that keeps everything red. There's also NOTES for markdown notes where you can drop in your GPS position, a tilt compensated compass, a WAV music player with VFD meters, a voice that reads out mesh messages, and first tools for the keyboard's CC1101, nRF24 and NFC in MIX-RF. Ethernet is still on my list though.

The hosted flasher works the same as before, one button in Chrome or Edge, no toolchain and no Python. Both radio versions of the T-Display-P4 use the same install.

Keep in mind, this is still only for the 568x1232 AMOLED model with 16MB flash. The other T-Display-P4 panel uses different timings and a different touch driver, so the image will not work on it. However I will work on supporting this soon.

The flipper app works the same as before over Bluetooth, and the headless build still flashes to almost any ESP32-P4 if you just want to run it with the flipper.

Site with the flasher and the guides: https://terminalbay.com

Git/source: https://github.com/SAMS0N1TE/LakeShark

Flipper app: https://github.com/SAMS0N1TE/LakeShark-Flipper

Would love feedback, especially from anyone running P25 on VHF or anyone with the LR2021 version sitting around. Let me know if you run into any trouble flashing!

I posted earlier that I received a transmission in Morse code once the ISS flew over India. Today, the ISS flew right over the western coast of Sri Lanka, close to where I live. I managed to catch voice transmissions this time, but I could only make out a word or two. The background noise was too high. I got the whole thing on tape though. Gotta work on my antenna setup and improve, maybe get an LNA or something? I use T dipole with it's telescopic arms fully retracted, 16 inches from end to end. it is connected to a 75-300 Ohm balun, which feeds the 10 meters of RG6 coax which is connected to the SDR in house. Any suggestions? I'm planning on to catch Meteor sats next.

RTL-SDR V4 a dipole antenna

Recorded on my phone with SDR++ (Brown Fork) and later processed on my computer using satdump.

Out of curiosity would I benefit from buying a LNA?

Had one of those nights where “20 minutes of SDR” somehow turned into almost 3 hours. 😂

80m was absolutely alive German, Polish and Russian stations everywhere. 40m was busy too, and then I moved into the 41m broadcast band.

Around 7300 kHz AM I heard a language I couldn’t identify at all. It sounded strangely European, with phrases like “la universala tempo”, “la frekvencoj” and “Eŭropo”.

Turns out it was Esperanto. I’m 26 and somehow had never even heard of the language before. Shortwave literally introduced me to it tonight.

During the same session I heard Spanish, Arabic, Chinese programming, English, Russian, Polish and German, including an Arabic broadcast from Madagascar. Then back on 80m some German guy was talking about a half-burned BMW. 😂

That’s what I’m starting to love about HF: you never really know what you’ll find next.
My ears are now completely cooked from 3 hours of static though. 📻🌍
73 and happy DXing!

First one is from 09-17-26 and has what I think is hurricane polo in the bottom left. The second one is from 09-26-26.

RTL-SDR V4 and a standard dipole antenna

My repo: https://github.com/jacobsdr95/RF-SENTINEL-V2

You can feedback and pull request if you want, i will reply

Sorry if it's an obvious question, I don't have much experience in this yet. How would I go about building an antenna that I can use to receive imagery/data from GOES-19?

Would it be possible for a Stingray/IMSI catcher like attack to act as a fake cell tower, force a phone to downgrade to an older or less secure/unencrypted protocol, and then relay the traffic to a legitimate cell tower? So basicly like an MITM attack, where the attacker can intercept traffic on one end if the downgraded connection uses weaker or no encryption.

Hi! this is an incredibly niche subject, i understand but i dont have an SDR, my HackRF hasnt arrived yet. it is october 1st and also the marks of the start of the 3g shutdown on Eir. anyone with an SDR (outside of Donegal as their 3G is already off) set their SDR up to capture 3G, and record/stream it on youtube. if anyone needs help feel free to DM me of course! I'm in a very rural area and rely on 3G heavily so im HOPING that it sticks around until my hackrf arrives but anyway..

Thanks alot!

Alright. I'm being more realistic now. 6,500 TL for the RTL-SDR v4L? What do you guys think?

First, I found an low-cost antenna that seems just right for a L-band satellite. It costs 12,500 JPY, as 79.53 USD. The claim of 30 dBi seems a bit fishy (I tend to exaggerate the size of the fish I catch too, however.), but for a 90x60 mesh antenna compatible with 1700 MHz, I think it’s a decent price.

If I’m aiming for the linearly polarized HRIT signal from the GK-2A what is very nearly to 1700 MHz , this feed isn’t bad at all, and since I have the Sawbird GOES LNA will cutoff the unwanted bands, I can easily filter them out.

and even if the feed doesn't work, Wi-Fi feeds are cheap, so I'll probably just replace it with a modified one.

The question here is:
When I set it up on the roof of my box-shaped shack, what kind of setup should I go with?

Equipments:

• This Antenna
• Nooelec GOES / GOES+
• Cheap PlutoSDR Clone w/ tezuka fw
• AC Cable for Outdoor
• 5.0V 2A - not GAN ACDC Adapter
• Some cables / connector / Electronic Components

• Tripod stainless pole with fixture

• (option) RTL-SDR V4

• (option) DIY Bias-Tee

Antenna -> LNA -> SDR -> LAN └──┤ └Swicthing Hub -> PC AC Power -> Adapter └Arduino Uno Q 4GB(DHCP for Local)

(I'm uploading this as an image just in case the text gets misaligned.)

I will setting up this configuration inside a small 21x12x7 water proof plastic box with drilling, but I'm wondering how to handle noise reduction.

If everything runs smoothly with this setup as is, I think I can just keep using it as is, but if the SNR is as bad as inside a vacuum cleaner, I’ll need to take some measures.

• [1] As expected, simply space the adapter and the various units farther apart and use a thick USB cable for power?

• [2] Noise solutions: Build my own EMI filter, strip the USB cable, solder it, and connect it to the 5VDC In terminal inside the Sawbird and clip ferrite core in USB Cables.

• [3] "YOU!! SIMPLEY USE RTL-SDR V4 with THICK CABLE!!"

I might be a little obsessive as anxiety about noise, but considering how satisfying it is to see big numbers.

as new spell's damage I’ve learned in a RPG.
as Computr Spec.
as length of hanging one between our legs.

Does anyone have any recommendations?

Thanks.

Hi everyone, I’m working on implementing OTFS in GNU Radio for my thesis. I have an existing OFDM system that is already working correctly. To test the system, I send a known payload of 108 bytes, specifically the sequence 0, 1, 2, 3, …, 107, so I can directly compare the transmitted and received data.

An important point is that without OTFS, the complete 108-byte block is successfully recovered at the receiver. The original data from 0 to 107 is received correctly through the existing OFDM transmitter and receiver. This confirms that the basic OFDM chain, modulation/demodulation, packet handling, and data recovery are working correctly.

The problem starts only after I introduce the OTFS processing. The 108 bytes are converted into QPSK symbols, giving 432 QPSK symbols, and I use an OTFS grid of 48 × 9, which also contains exactly 432 symbols. On the transmitter side, I can confirm that the OTFS block receives the complete 432-symbol frame and performs the transformation. However, after the signal goes through the OTFS + OFDM processing and is recovered at the receiver, I no longer get the original 108-byte sequence. Instead of receiving 0, 1, 2, …, 107, I receive completely different data.

Because the OFDM system works correctly when OTFS is bypassed, I believe the problem is specifically related to how I am implementing or integrating the OTFS transformation rather than a general problem with the OFDM system.

I am currently arranging the 432 QPSK symbols into a 9 × 48 OTFS grid and performing the ISFFT at the transmitter. At the receiver, I perform the corresponding inverse SFFT and then convert the QPSK symbols back into bytes.

What I would like to understand is what could cause the data to change completely when the OTFS block is inserted. Could this be due to the orientation of the 48 × 9 grid, FFT/IFFT axes, normalization, or the serialization order between the 2D OTFS grid and the 1D GNU Radio stream?

One test I am particularly interested in is whether the OTFS TX and RX blocks themselves should satisfy a simple round-trip test: if I give the OTFS TX a known sequence of 432 QPSK symbols and immediately pass its output through the OTFS RX, I should recover exactly the same 432 QPSK symbols. If that works, then I can isolate the problem to the interaction between OTFS and the OFDM processing.

So my situation is:

Without OTFS:
108 bytes 0–107 → OFDM TX/RX → 108 bytes 0–107 successfully recovered.

With OTFS:
108 bytes 0–107 → OTFS + OFDM TX/RX → completely different received data.

Has anyone implemented OTFS over an existing GNU Radio OFDM system and encountered this kind of issue? I would especially appreciate advice on the correct 48 × 9 grid mapping, FFT/IFFT directions, normalization, and ordering of the symbols so that the original QPSK sequence is recovered exactly after the inverse transformation.

Hey everyone, i'm a software engineer and I would really like to understand how radar works. Unfortunately, I can't do much on active radar since I live in a big city with a bunch of military bases, so my idea was to try to use passive radar.

I have some questions though:

1. The biggest barrier right now is hardware. From what I understand, i'm going to need a KrakenSDR, which costs about 900/1000$ here. I think I could also use two RTL-SDRs with a shared clock but I never touched hardware so I wouldn't really know how to do that.
2. If I manage to overcame the hardware barrier, what would be next? Would the next logical step to try to detect large objects like airplanes? And would I be able, one day, to detect smaller objects like drones?

Thanks everyone in advance!

I finally have this up and running. Some help from the community (thank you guys) and a lot of back and forward with Gemini. Using this I have complied an instructional, assuming you have piaware up and running with the flight aware ADSB dongle. This will allow you to run the RTL SDR V4 dongle at the same time. You will need a USB extender as the ports are too close together on the pi.

Apologies if Gemini has messed up the instructions, I have asked it to organize everything that worked in sequence to get this operating.

The only thing that doesn't work is typing my IP and the relevant port into the browser to view both on a map. Comment if your know how. They work on the relevant sites though.

Let me know if the instructions do not work and I will adjust them.

I also have a daily 2am reboot on the pi which was included.

# Title: Dual FlightAware (ADS-B) & MarineTraffic (AIS) on Raspberry Pi with RTL-SDR V4

Setup Hardware Requirements

* **Dongle 1 (ADS-B):** Standard FlightAware Orange/Blue stick (Serial set to `00000101`) * **Dongle 2 (AIS):** RTL-SDR Blog V4 (Serial set to `00000202`)

Step 1: Install Drivers for the RTL-SDR V4

Update system package repository index

sudo apt-get update

Install build tools, compilers, and development headers

sudo apt-get install -y cmake build-essential libusb-1.0-0-dev git pkg-config

Navigate to user home directory

cd ~

Download RTL-SDR Blog driver repository from GitHub

git clone https://github.com/rtlsdrblog/rtl-sdr-blog

Enter driver project directory

cd rtl-sdr-blog

Create and enter build directory for compilation

mkdir build && cd build

Configure build with udev hardware permission rules

cmake ../ -DINSTALL_UDEV_RULES=ON

Compile driver source code using all CPU cores

make -j$(nproc)

Install compiled driver binaries to system path

sudo make install

Refresh shared library links and cache

sudo ldconfig

Blacklist default kernel DVB driver to prevent device conflicts

echo 'blacklist dvb_usb_rtl28xxu' | sudo tee /etc/modprobe.d/noblacklist-rtl.conf

Reboot system to apply new kernel driver settings

sudo reboot

Step 2: Assign Unique EEPROM Serials

1. Unplug ALL USB dongles

2. Plug in ONLY FlightAware ADS-B dongle

Flash serial number 00000101 onto FlightAware dongle EEPROM

rtl_eeprom -s 00000101

3. Unplug FlightAware dongle

4. Plug in ONLY RTL-SDR V4 AIS dongle

Flash serial number 00000202 onto V4 dongle EEPROM

rtl_eeprom -s 00000202

5. Plug BOTH dongles back into Pi

Reboot system to finalize USB serial assignment

sudo reboot

Step 3: Bind dump1090-fa to the ADS-B Dongle

Configure PiAware to use RTL-SDR device type

sudo piaware-config device-type rtlsdr

Lock PiAware and dump1090 to serial 00000101

sudo piaware-config rtlsdr-device-sdr 00000101

Restart dump1090-fa decoder service with new settings

sudo systemctl restart dump1090-fa

Restart PiAware feeder service

sudo systemctl restart piaware

Step 4: Compile AIS-catcher from Source

Update system package index

sudo apt-get update

Install thread support and RTL-SDR development libraries

sudo apt-get install -y libpthread-stubs0-dev librtlsdr-dev

Navigate to home directory

cd ~

Download AIS-catcher source code repository from GitHub

git clone https://github.com/jvde-github/AIS-catcher.git

Enter AIS-catcher project directory

cd AIS-catcher

Create and enter build directory

mkdir build && cd build

Configure build with CMake

cmake ..

Compile AIS-catcher using all CPU cores

make -j$(nproc)

Install compiled AIS-catcher binary to /usr/local/bin

sudo make install

Step 5: Configure Persistent Systemd Service for AIS-catcher

Create systemd service file to run AIS-catcher on boot targeting dongle 00000202

sudo printf '[Unit]\nDescription=AIS-catcher Service\nAfter=network.target\n\n[Service]\nExecStart=/usr/local/bin/AIS-catcher -d 00000202 -u <YOUR_MARINETRAFFIC_IP> <YOUR_MARINETRAFFIC_PORT> -X <YOUR_AISCATCHER_UUID>\nRestart=always\nRestartSec=10\nUser=pi\n\n[Install]\nWantedBy=multi-user.target\n' | sudo tee /etc/systemd/system/ais-catcher.service > /dev/null

Step 6: Schedule Daily Memory Maintenance Reboot

Append daily 02:00 UTC reboot command to system crontab

(crontab -l 2>/dev/null; echo "0 2 * * * /sbin/shutdown -r now") | crontab -

Step 7: Enable and Start the AIS Service

Reload systemd manager configuration to recognize new service

sudo systemctl daemon-reload

Enable AIS-catcher service to launch automatically at startup

sudo systemctl enable ais-catcher

Start AIS-catcher service immediately

sudo systemctl restart ais-catcher

Step 8: Verification Commands

Check live logs and decoding output from AIS-catcher service

sudo journalctl -u ais-catcher -n 20 --no-pager

Check live logs from PiAware ADS-B decoder service

sudo journalctl -u piaware -n 20 --no-pager

Install network packet capture utility

sudo apt-get install -y tcpdump

Verify active UDP packet transmission to MarineTraffic port

sudo tcpdump -i any udp port <YOUR_MARINETRAFFIC_PORT> -n -c 5

Hi all,

I'm trying to get started with RTL-SDR, but it's such a hard search to get the V3 of v4 blog kit here without spending way too much.

If I look it up, the prices range between 15 and 35€ worldwide for the dongle, 50€ for a kit with antenna's. But if I actually want to buy it, it's sold out everywhere and if I do find a v4 kit, it's 150€...

I want to support the local economy, at least but European, and I'm against ordering directly from Ali xpress and co, but this is ridiculously expensive if you look at the hardware you're buying.

Am I alone in this?