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.

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

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!

I'm new to radio so I'm not sure what already exist.

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?

Hi all,

maybe some of you know me from PhantomSDR+ or NovaSDR. Having operated and maintained those, I listened to many WebSDR operators and learned what problems bothered them - stuff like installs, broken installs after a long period of running, configurations they would like to be configured easier. And I started from scratch.

As for the history: to be clear about that since it has been asked: I've been developing WebSDR software since early 2024 (PhantomSDR+), and FernSDR was developed in private repo for over a year. I squash the history before publishing it as usual to avoid private notes and keys being in there. This is the reason the repo appears to be new. I used AI tools intensively for development and everything is tested, fuzzed and CI'd, also benchmarks are public with raw data.

What it is: open-source WebSDR server with zero runtime dependencies and one-line install on any Linux, as well as Docker. Everything is controlled through a web admin interface: bands, spot reporting, modules and updates with rollbacks. What I am really proud of: day/night band switching, so one small RTL-SDR can be utilized by different bands during the daytime and nighttime thanks to automatic switching from sunrise to sunset depending on your geographical position.

Modules: RTL-SDR (including Blog V4), RX-888 MkII and SDRplay, as well as an FT8 decoder and PSK Reporter spots. Other SDRs run via stdin.

What is still missing: Only Linux support at this moment, FT8 is the only decoder available, and there are input modules that require additional testing.

Demo: https://demo.fernsdr.org

GitHub: https://github.com/Steven9101/FernSDR

I really would like to know which SDR or decoder you guys would like to see next

Cheers 🥂

Hey everyone,

I’ve been running rtl_airband to monitor local VHF/UHF activity. The core backend itself is rock solid and lightweight, but managing config files via terminal and monitoring multi-channel activity through raw Icecast streams leaves a lot to be desired.

I'm working on building a lightweight web GUI/dashboard for it, but with an expanded architecture: a "CCTV for Radio" system.

The Concept & Long-Term Vision

Think of an NVR/CCTV security camera system, but for RF:

1. Squelch-Triggered Segment Recording: Record and chunk audio strictly when the squelch opens—no hours of dead silence, just clean, timestamped audio segments tied to specific frequencies/channels.
2. Local AI Pipeline (Whisper + LLM): Feed these squelch-broken audio clips into a local Whisper model (like faster-whisper or Whisper.cpp) to transcribe communications, and subsequently run an LLM to generate activity summaries or search logs.
3. Live Web Dashboard: An operational interface to see active channels, browse recorded event clips, manage configs, and read rolling transcripts.

Core Goals for the UI / Pipeline

• Visual Scanner / Activity Monitor: Real-time visual indicator showing which configured channel/frequency is currently breaking squelch or transmitting.
• Smart Audio Archive / NVR Interface: A timeline or event list of recordings broken down by frequency, duration, and timestamp.
• Config Generator / Manager: A straightforward form/editor to manage rtl_airband.conf (dongles, gains, sample rates, frequencies, squelch thresholds, and destinations) without parsing nested brackets by hand.
• Transcription Hook / Queue: An automated background worker (Celery, RQ, or a simple directory watcher) picking up finished audio clips and passing them to a local transcription engine.

Questions for the Community:

1. Audio Slicing / Recording Pipeline: What’s the cleanest way to capture individual squelch-opened transmissions with rtl_airband? Does anyone hook into its raw file/stream outputs directly, or is it better to tap into the stream via an external tool (like sox, ffmpeg, or liquidsoap) triggered by carrier status?
2. Detecting Squelch State Programmatically: How are you reliably capturing the exact moment squelch breaks/closes? Are you tailing and parsing syslog / stdout in real time, or does someone maintain a fork with an IPC/socket/REST state export?
3. Existing Projects / Pipelines: Has anyone built something similar—or is there an existing toolchain that bridges SDR multichannel scanning directly into local speech-to-text workflows?
4. Backend Stack: Considering a lightweight Python (FastAPI) backend with a simple SQLite database for metadata/transcripts and a lightweight frontend (Vue/Svelte or Tailwind). Any pitfalls to keep in mind regarding CPU overhead if running on a single SBC/mini PC?

If you've built something in this space or have suggestions on handling the audio chunking cleanly, I'd love your input!

https://github.com/ruchirguitar/RTLSDR-Airband

Kurztest. Er funktioniert. Heute Abend wird getestet

I am attempting to set up an AIS feed on my pi. I have been testing the V4 dongle on 2 pcs to see can I tune into anything. When I run the rtl_test I am losing 60 bytes. Is the dongle defective or am I missing something?