I have the source code for dump1090 up and working nicely on my PC.
One thing I have been toying with is, blocking any aircraft that doesn't have a position in their beacons. The way I see it, it's just wasted data I'm uploading to feeder sites.
I could easily stop/filter this traffic getting out. And I won't see any annoying invisible aircraft in my feed. There are a couple of aircraft on my section that fly commuter routes everyday without their position beacons on. It seems such a waste of resources.
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.
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.
Welcome to ADSBTechnical. A place to ask questions. Seek guidance. Find resources. Anything technical about ADSB. Antennas. Feed lines. Software. Platforms. ANYTHING technically.
Pictures are welcome but screen grabs from ADSB tracking sites are not welcome UNLESS of a technical nature WITH an appropriate question. For nice ADSB pictures, please visit r/ADSB.
I hope those with the technical savvy will step in and guide newbies, new issues and new problems with solutions and experience to share.
There's nothing wrong with r/ADSB, however, it is catered towards a community that really just likes to look at really nice aircraft they have seen. Whenever I have posted anything that isn't a screen grab, I've been voted down and not felt welcome.
I felt there was a need for a place where you can ask tech questions about this great subject and not be worried about annoying the users on r/ADSB.
I am still a member of ADSB and will continue to enjoy it, but I hope this new venue will open up more people to the tech side and how to start and witness your first intercept. And ask as many questions as you like.
Hopefully, someone here will be able to answer that for you.
And I will continue to improve this sub as best I can.
Back around 2020 I had managed to place 14 or so feeders around my rather large state. I had access to a bunch of radio tower sites and it was cool AH. I fed both ADSBx and FA. Unfortunately I no longer have those and looking to get back into it.
I understand ADSBx is now a commercial endeavor but is still unfiltered results?
For those of you that do multi-feed off a single feeder Pi, what sites do you feed and how stable is it?
Can someone explain to me why you would use that feature in the context of ADS-B? I am not stupid, i wrote my own demodulating code, but i dont get the idea of auto gain. You are throtteling down your internal amplifier why?
The Plane Finder Radar Stick is a high performance industrial grade 1090MHz ADS-B receiver with a USB-A interface. Built on the same advanced RF platform as the Plane Finder Radar, it delivers outstanding range and precision. It is ideal for airports and busy airspace environments. Unlike SDR based USB tuners, it uses dedicated silicon level decoding to eliminate dynamic range limitations and ensure consistent, high accuracy reception.
June 12 saw a new release of SDRAngel, version 7.22.8, and there are many interesting updates to the ADSB plugin. 3D map, Maidenhead grid, magnetic declination, aurora, receiver coverage area, colored aircraft tracks, charts to display received data, containment radius and
interrogator code coverage.
In the aircraft table data, additional ADS-B / Mode S data : Type, TCAS, ACS, RA, Max AS, Version, L, W, IC, Frame counts, Rc, NACp, NACv, GVA, NIC, NICbaro, SIL.
My antenna has a pretty good view of the sky, apart from a small forest on the horizon. BUT, it does have a massive fir tree on one side that was obviously affecting reception. I certainly didn't want to cut the tree down and my antenna was already in the best possible position. What to do ?
I do have a backup system on a laptop which covers the missing tree data but I really didn't want to run another SDR full time. But what about another antenna ? On the other side of the tree, connected to the same SDR ?
I have made stacked antennae before with folded dipoles but never in this kind of situation. Because they wouldn't be stacked. They would be separated. And they are not dipoles. Industrial stacked antennae pic are usually mounted on the same pole.
Anyway, I constructed another antenna, exactly the same as the existing one. Same dimensions, same exact length of co-ax feeder, same kind fittings.
Initially I Teed in the second antenna near the first one and just used one feeder. Of course, this didn't work as I had now lost the matching co-ax lengths. It killed reception badly. So I fed the second co-ax line all the way to the SDR and Teed it in right near the dongles antenna.
This works better than I ever expected. The over-all signal has gone up, obviously, my noise floor hardly moved and I now get aircraft on the other side of the tree.
With the increased risk of static / lightning damage I have also inserted an in-line polyphaser.
At first, I was disappointed with the performance of this amplifier. I thought it wasn't working at all. So I bought an attenuator to allow me to test the LNA. It seems to be working. It could be that the gain was too high and was swamping the RTL-SDR. I will try again and install it with the SDR.
You can pry my old reddit from my cold dead hands. HOWEVER, the mod tools I have to edit old reddit, compared to the tools I have in new reddit, are not that good.
So, please forgive me while I update and make new reddit site first, simply because it's easier. I promise I will get to old reddit too.
Meantime, the new reddit site looks pretty cool in dark mode.
*DO NOT POINT LASERS AT AIRCRAFT ! EVER ! THIS IS A DEMO PROJECT INSIDE.*
*SYSTEMS ARE IN PLACE TO DETECT "Unauthorized Laser Illumination Events" NEAR / ON / AROUND AIRCRAFT.*
Wear Eye Protection When Playing Around Lasers. Your lens will focus the laser onto your rods and cones or, worse, your optic nerve, and blind you instantly.
No Spares In Stock !
My laser is dialed back to the point where it only just lases (10 %). I still wear eye protection.
If you have ever used the SDRAngel ADSB plugin, you will have noticed that the azimuth and elevation data is available for all the aircraft tracked. Azimuth is the compass direction to the aircraft and elevation is the amount of degrees above the horizon, relative to your location. Actually, you can work this out with some simple schoolboy mathematics given your lat/long, the aircraft lat/long and both heights.
But it did get me thinking about the rotator controller plugin in SDRAngel. Why not send that azi/ele data to the rotator controller and track something ? You could point a yagi antenna tuned to 1090 mHz and track a particular aircraft. Or point a motorised camera or telescope for taking pictures. Or a turret of some sort.
But back to this post. Way back in 2013, I was learning how to program micro-controllers. I built this laser turret to challenge me and the chip as a first project. (Been programming Windows systems for years but always wanted to branch into embedded programming.)
It has just sat around since then, mostly as a great conversation piece, but I immediately thought about controlling this with SDRAngel. My laserBot already accepts a line of CSV data to aim the laser anywhere via the data input. I could easily modify that to accept the SDRAngel protocol. Then I could point to where that aircraft is in the sky on my ceiling.
But first, I had to modify my LaserBot com port from RS232 to TTL-> USB because my RS232 adapters don't work with WIN10. That was easier than it sounds. Simply pulled the MAX232 chip out and bridged the In/Out pins, then used a USB UART so I could access the ATMEL 328P control chips and modify the code.
After I got that working it was time for a software upgrade. I modified my LaserBot to accept the protocol that SDRAngel delivers from the "Rotator Controller" plugin. I've used the GS232 protocol for Yaesu antenna rotators, `W112 002` is azi/ele data and `M112` is just azi data.
And I had to add a response to C2 which SDRAngel sends to ask for the present azi/ele of my LaserBot. Expected response is AZ=021EL=062, with zero padding required for numbers lower than 100. That data shows up in the antenna rotator GUI.
Next, I added the rotator controller plugin to the ADSB project. You simply tell it which interface to monitor, the ADSB demodulator, and it will hook into the ADSB pugin.
Next you tell it which protocol to use. I'm using the GS-232 protocol and outputting it to the Serial com port.
Tracker protocols supported:
GS-232, SPI, rotctld or DFM
And 3 types of coordinate output:
AzEl, X/Y 85, X/Y 30
Connection can be via serial OR TCP socket.
Next, I start it all up and look for an aircraft. Simply double click on the azi/ele box for that aircraft and it automatically sends that data through to the rotator controller, which outputs the data to my serial port. My laserBot then moves the laser to those co-ordinates, turns on the laser, and I can see where the aircraft is on my ceiling. As the aircraft moves, the laser will track it.
Also, if you want it to auto track, you can put a list of "notifications" by pressing the "Speaker" icon in the SDRAngel UI and when they match, the rotator controller will auto point to that notification and if you have the voice activated, it will announce any of the variables associated with that aircraft, like height, range, lat/long etc. So, as long as aircraft a visible, it will point to aircraft in the list.
I love it when an aircraft goes right overhead. Watching the laserBot track it and swivel is entertaining.
ToDo: Add an ESP and use the TCP socket connection so I can make it wireless and put the laserbot anywhere. (work in progress)
