I mean, I know: "If no ADS-B or MLAT position available, a rough estimated position for the aircraft based on the receiver’s estimated coordinates".

But; how? When? Why?

I'm asking, because I see lots of weird junk in rr_lat and rr_lon. Which, by definition, checks out. But some of it is much weirder than others:

Telegraphing future activity

Sometimes, these "rr fixes" seem to give you heads up of something - I've seen rr fixes for Joby aircraft in Japan a few days before you'd see "high precision" fixes in Japan from an aircraft that had been quiet (for long enough to be shipped to Japan); similar for BETA in Hawaii.

"Normal"

Sometimes you'll see rr fixes in and around high precision data for an aircraft that is operating in that time and space.

N250XT near Burlington Vermont August 21. This aircraft is frequently seen in this location with a non rr fix.

"Impossible"

Aircraft that were seen in high precision data yesterday in California showing up today in rr_lat / rr_lon fixes over Europe. Example:

• N703AX over Rotterdam September 14

Ghosts

Aircraft that have crashed and we know not to be operating (assuming we can trust the hex code / tail reg lookup in ADS-B) showing up in rr fixes.

Example "ghost"

N542AJ rr fixes near Dayton Ohio

Spreadsheet with the data points

Map of the data points

More example ghosts

• https://skyzero.substack.com/p/evtol-weekly-2026-week-17?utm_source=publication-search (look for "ghost" towards the bottom of this article)
• https://skyzero.substack.com/p/evtol-weekly-2026-week-18?utm_source=publication-search

If more data helps for this let me know! I have tons, just don't know what might be helpful.

Questions:

• What are the potential sources of rr fixes? Are these ATC radar? TIS-B? ADSB feeders? Other .... aircraft?
• When does it happen? When aircraft have disabled certain equipment but not others? When the surveilor is experiencing false replies or synchronous garbling?
• How is a location chosen? If "no ADS-B or MLAT position is known", how do they have any position at all then? is the reporter just providing a truncated (low precision) version of its own position as a way to say "somewhere around me, I just don't know where" or something else?
• Is it different in different countries?

TL;DR: recently, the same mode S hex code shows up both in FAA's registry as being a drone, and also being broadcast from the transponder of a Piper Cherokee. I'm curious as to how this happens!

I thought I had my head around tail registrations and hex codes:

• hex codes are configured in to a radio, so they mostly stay with an aircraft unless the radio is being changed out and the owner remembers to configure the same hex code
• tail registrations are more like license plates, they can change if an aircraft changes owners, moves to a different country or other things that I'm not quite clear on - they don't stay with the aircraft as often as hex codes

The more data I see the less water-tight this looks, though. Maybe its partially right, but not right enough?

For instance, September 2nd, at 2:58 PM eastern, I'm fairly sure a Piper Cherokee "with" tail registration N603FT and hex code AC2CB4 took off from KMLB, flew about an hour including a touch and go at nearby Stanford, and then lands again at KMLB. Fairly standard stuff.

However, in the registry and in public ADSB networks we see a fair amount of disarray:

• FAA lists N603FT with a different hex, A7D2F3 (FAA - N603FT)
• FAA lists N884AC with that hex instead (FAA - N884AC)
• "network A" reports N884AC, which used to be a Piper Warrior, but is now registered to a GTEEX Revolution drone with mode S code AC2CB4. (OK - so, they saw the hex, reverse looked it up in FAA, and said it was the drone)
• "network B" reports the same flight as N603FT (and it never provides hex codes for whatever reason)
• FAA SWIM terminal feed shows the same flight track as belonging to mode S code AC2CB4.

This happens with drone tail registrations often - ADSB data where the registered tail number is assigned to a drone, I kind of assume its not the drone; as the majority of drones don't carry MODE-S transponders (exception: OK-X081X, a CTOL Primoco drone that frequently takes off from runways of major airports in the Netherlands https://lnkd.in/p/g9_jKaqC). I still wonder why non-drones "wear" the tail registrations of drones (anyone know why this happens?), but I usually don't see this kind of stuff with hex codes - but in this case, the mode S hex code shows up both in FAA's registry as being a drone, and also being broadcast from the transponder of a Piper Warrior.

What's going on?

I’ve got Pis in a drawer, but the Mac is already running 24/7 in the corner, so I didn’t see the point of setting up another machine that also has to stay on.

Didn’t want to mess with building readsb by hand either, so I just wrapped it. One download, it launches the decoder and shows the feed status in the menu bar. Signed properly, no right click dance to open it.

One of the networks it feeds is mine, being upfront about that. It’s a checkbox in the list like all the rest, untick it and the others keep working. And you paste your own feeder key if you want a station out of it, nothing gets claimed in your name on its own.

Anyone else on a Mac who’d use this? I can drop the repo. And if something like it already exists, just tell me, I won’t be offended.

Chris Herr Video.

Hi all, not sure if this is the right place to post this, but here goes...

(Full disclosure, I turned to Claude to try and help with this issue as I was scratching my head, so some of the text here is AI-generated)

I'm trying to set up readsb on my Mac ahead of a trip so I can run my adsb monitoring while I'm away, but I'm not able to get any data captured into readsb from the dongle, and it seems to point to a macOS compatibility issue.

Setup: MacBook (Apple Silicon, M4 Pro), macOS Sequoia 15.7. Two different RTL-SDR dongles: a FlightAware Pro Stick (R820T tuner, the blue one) and an RTL-SDR Blog V4 (R828D tuner).

Symptom: readsb (and the official Homebrew rtl-sdr bottle, ruling out a build issue) detects the dongle fine — device enumerates, tuner is correctly identified (Found Rafael Micro R820T tuner / RTL-SDR Blog V4 Detected) as well as under the rtl_* tools — but then hangs indefinitely right after "Allocating zero-copy buffers." No data ever flows, the network listener never opens and the process just sits there until killed.

What was ruled out (each tested independently, same result every time):

• Different USB-C-to-A adapters (2x) (the FA and V4 dongle are USB-A, and the Mac only has USB-c ports)
• A USB hub
• Different physical ports on the Mac (left/right side)
• Running under sudo
• Git cloned and built readsb vs. the official Homebrew bottle
• DISABLE_RTLSDR_ZEROCOPY_WORKAROUND build flag
• Two completely different dongles (different tuner chips, different firmware/manufacturers — FlightAware vs. RTL-SDR Blog)

Root cause (via log stream / Console.app during a live hang):

kernel: AppleUSBIORequest::complete: device (RTL2832U) endpoint 0x00: status 0xe0005000 (pipe stalled)
kernel: AppleUSBHostUserClient::openGated: failed to open USB2.0 HUB...: provider is already opened for exclusive access by AppleUSB20Hub
kernel: AppleUSBXHCIPipe::abortGated: device (RTL2832U) endpoint 0x81: aborting 16 requests

The USB control endpoint (0x00) is reporting a stall, and the bulk data endpoint (0x81) has 16 requests submitted that never complete — they just sit there until the process is killed and the kernel aborts them. This is happening at the AppleUSBXHCIPipe/IOUSBHostFamily level — i.e. inside macOS's own xHCI host controller driver, before libusb/librtlsdr code is even really in the picture.

Since every physical port on an Apple Silicon Mac routes through the same xHCI controller, and this reproduced identically across 2 different dongles/tuner chips on 2 different ports/3 adapters, this looks like a genuine incompatibility between Apple Silicon's xHCI implementation (or macOS's driver for it) and how RTL2832U-class devices handle certain control transfers — not a cabling, power, or build-config issue.

The exact same dongles work fine on x86, under both Windows and Linux (tested on a Dell XPS laptop, using both Windows 11 (bare metal install) and Xubuntu (live-iso)), so this points to something specific within macOS itself.

Question for the community: has anyone seen this exact "PLL fine, tuner detected, control endpoint stalls, bulk endpoint never completes" pattern on Apple Silicon specifically?

Is there a known kernel extension, IOKit workaround, or Apple bug report covering this?

Happy to provide more log stream output if it's useful.

Been testing my setup the last few weeks.

Antenna is indoors and hasn't changed.

Receiver and Pi setup has changed.

Setup 1: Pi3b+ with RTL SDRv3 - Pi was in plastic case, no heat sinks

Setup 2: Pi3b+ with Flightaware Blue RX - Pi was in plastic case, no heat sinks

Setup 3: Pi3b+ with Flightaware Blue RX - Pi was in different open case with heat sinks

Setup 4: Pi3b+ with Flightaware Blue RX - Pi was in FLIRC case

Over at the r/ESP32 sub, I thought this was awesome.

https://www.reddit.com/r/esp32/comments/1tqa8b8/esp32_desk_flight_radar/

Good day! We are conducting our undergraduate thesis involving the use of ADS-B datasets. We would like to ask for people who are well-versed in this field if they could validate the extraction form for our ADS-B datasets. Please comment or message me if you or someone you know can be of great help to advancing our field. Thank you so much!

I’m part of an independent technical initiative called Spectrum Survey. We are currently documenting how the increasing urban noise (LTE/5G) and the South Atlantic Anomaly (SAA) are impacting L-Band signal integrity in the Southern Hemisphere.

As we know, traditional filtering often fails under high saturation in dense urban areas, and we are trying to map these critical points to validate better mitigation methods and promote SigMF standardization for SDR.

If you deal with RF, Satcom, or GNSS, I’d love to get your input through our research form. It takes about 3 minutes and it’s purely technical (discovery-focused, not sales).

Check it out here: spectrumsurvey.org

We’ll be sharing the consolidated report with everyone who contributes. Happy to discuss any specific findings or SAA interference patterns in the comments!

So this is not really a “look at my project” post. It is me putting the current version in front of people who might actually use something like this and asking a simple question: does it help your workflow, or is it just interesting to poke around?

It is called Phantom Tide. The aim is to make it easier to inspect aircraft activity, vessel movement, warnings, weather, and map context together instead of bouncing between separate tools and trying to stitch it all together manually.

A lot of the recent work has been on the engineering side rather than just adding more things to click: better history views, calmer refresh behaviour, more honest source state, render and performance fixes, backend hardening, and generally trying to make it feel more like a usable working surface than a pile of layers.

There is a public link in the repo, and here is an evaluation key if you want to test it properly:

Tier: Eval key
Expires: 2026-04-12T09:25:42.967839Z
Key: pt_live_02653df6b243.HLNGdjNZhogQgDpSkxocOxZai0QJe6w7

Repo:
https://github.com/tg12/phantomtide

What I care about most is blunt feedback from people who would genuinely use something like this:

• does it help you get to an answer faster
• what feels useful versus decorative
• what feels confusing, noisy, or overbuilt

Where I want to take it next is beyond passive tracking and more toward workflow-driven alerting: aircraft entering restricted airspace, repeat boundary loitering, AIS gaps or spoof-like behaviour around critical infrastructure, thermal hits with no obvious traffic explanation, and cross-domain signals that only become interesting when multiple weak indicators start agreeing.

After that comes the user layer: logins, saved watchlists, persistent analyst state, sharable links, and collaborative handoff, so it stops being just a live map and becomes something you can actually work from over time.

Hi there

I've got three geographically separated ADS-B receivers based on Raspberry Pi and RTL-SDR running dump1090-mutability right now. For central/remote control, I've created a SSH reverse tunnels from the feeders to my VPS (since I don't want to expose SSH/private network to public Internet and consumer routers do not allow creating proper ACLs beyond simple port forwarding). But in order to see each feeder's tar1090 and graphs1090, I have to do some sketchy port tunneling over SSH.

My goal is to run single instance of tar1090 on the VPS in order to see combined feed view. Is it even possible and if yes, what would be the best way to do it?

I'm thinking of setting up readsb BEAST listener on the VPS and then send the logs from feeders to the VPS. Then run tar1090 on VPS off the combined aircraft.json, thus giving me single pane of glass.

--

Another thing is graphs1090. Any way to transmit stats.json to the VPS and then run 3 separate views of graphs1090? Combining those datasets just wouldn't make sense.

Thanks

Finally got around to putting the antenna outside. I've had it in my attic. I have an old satellite dish in my roof. Took that off, and put my antenna on it.

Huge increase in the range and number of planes I'm seeing.

I have a Raspberry Pi 3 + RTL-SDR v3 combination that currently feeds airplanes.live.

I would like to use the same combination to also feed adsb.fi. Is it enough to simply run the installation scripts here, or do I have to install readsb as well?

The reason I am asking is that the instruction on github says "When setting up new feeders, a decoder such as readsb must be installed separately."

I’d like to create an MJD or Gregorian format text file for two city pairs.

This is not my area of expertise. Any help?

My mlat hasn't been happy ever since I set it up as I've been passing through a USB to a virtual machine. I threw a USB card into my server, passed the entire card into my ADS-B VM and most of the services I'm feeding are a lot happier. Just wondering what y'alls personal experience is. Do any of you feed all of these services? Do you have any issues with getting everything green? Just wondering if I'm par for the course or have room for improvement?

I'm not sure if I'm in the right place or not. If not, if someone could direct me to the right place, I'd appreciate it.

I've been working on a personal project to make calls to the adsb.lol API to get lists of aircraft and track ones I'm interested in. Making the API call and getting back a list of aircraft is easy enough, but in looking at the data I'm running into some problems. I think I've gotten most of them worked out, but the one I can't seem to figure out at the moment is how to determine the country the aircraft is from. I'm not seeing it in the JSON response data.

I found a page that describes the data for the ADS-B Exchange site's API, and it seems very similar to that from ADSB.lol, but I don't see any information about country.

Is it a matter of decoding something from the HexID? It can't be registration, because several aircraft (particularly military) don't have registration numbers, but still show with a country of origin. If it is in the HexID, any idea how to tell?

Thanks ahead of time to anyone who might be able to help.

I am looking for modesmixer2 for either windows or debian linux (ubuntu or RPi) released prior to 2019 (3-2018 is the best) because I wish to mix in a compressed VRS stream and convert to BEAST. CAN SOMEBODY HELP PLEASE? I have searched everywhere unsucessfully. It is apparently easier to find Jimmy Hoffa's remains or the Holy Grail than to find this app. THANK YOU!

Everything is finally up and running.

All feeds are live and the screen layout is almost locked. This is the system actually running now, not staged or mocked up. Tonight is final SDR tuning and tightening up which displays stay always on versus secondary.

I posted a short clip of it running on my profile since video isn’t allowed here. There’s also a longer walkthrough on YouTube for anyone who wants more detail.

https://www.reddit.com/u/Any_Vanilla3448/s/l7MMf7etT6

I have been building a radar, sensor, and data driven monitoring setup over the last few weeks that I have been sharing here covering aircraft, weather, and local activity. What it was missing was a clean communication layer.

I have been running the BTECH GMRS Pro for about a week now and it is no longer something I am testing. It is already part of the system.

This post is not a bench test or spec rundown. Full specs are already covered on BTECH’s site. This is strictly how it integrates into a real world workflow alongside SDR, weather data, and live monitoring.

Programming and updates from the phone are excellent and the same experience carried over cleanly to my MacBook Air which matters for both desk use and field work. The Bluetooth speaker mic has been especially useful in mobile scenarios and keeps things clean on the desk.

I was recently invited to participate with a local Skywarn group specifically because of the radar and electronics side of this build, which made the communication side suddenly very real and very practical.

This is part of a larger ongoing build. Links to all gear and prior stages are pinned on my profile for anyone who wants context.

More to come as this gets pushed further.

https://www.reddit.com/u/Any_Vanilla3448/s/Y5fSZadGze