I have some questions and am hoping to get input on how to maximize my 1090 and 978 feeder setup. I live in the mountains, NW Colorado. There are not many stations up here and zero 978 coverage. We do get a good bit of GA traffic but I suspect its not picked up.
My current setup is a converted pi4 Stratux running piAware. Using a RTL SDR for 1090 and the custom Stratux 978 dongle. I got 978 working after some tinkering. I have 2x Amazon 16in 5.5 DBi antennas mounted on our balcony(Waiting for the HOA to notice) facing west.
High terrain to the east. Airport to the north, more open to the south and west.
I pick up ADSB airline traffic about 50 miles to the west, rarely 100+ miles if I am lucky, only about 15 miles east( Terrain over 10K ). UAT is really hit or miss. Very spotty.
Any suggestions on optimizing? I am considering getting a couple FA dongles or Nooelec to see if I get better coverage. Or is this just terrain limited?
If you ever want to try something on a second sd-card, have a look at https://adsb.im/
Makes it easy to integrate the heywhatsthat panorama into the interface.
Thats a cool option I will definitely be looking into. I am pretty familiar with linux and pi’s, so I have just been using the piaware image and adding the other services as needed.
I had graphs1090 running for a while, but something went wrong with trying to adjust the gain on the RTL SDR and it would intermittently stop receiving messages, then at one point would RX messages but not “track”. I had to reinstall some packages and reconfigure and have not messed with the gain since. And I am wondering if the Stratux RTL SDR and UAT dongles arnt playing as nicely as they should and if that could be effecting performance.
I am looking into tar1090 to get some more analytic data as well.
Be aware that outline is likely for 40k ft and UAT planes usually fly much lower.
Thus you might need a separate outline to judge that.
The rtl-sdr without LNA / filter isn’t all that great for 1090.
Possibly get a blue FA stick or a blue adsbexchange stick.
Then you can repurpose the rtl-sdr you have for 978 which might also improve that.
The 1090 SDR with LNA / filter will most likely be at least a bit of an improvement.
Looking at the range outline and the tracks you get, i’ll assume there is some close in obstacles like other houses / trees in addition to the terrain that heywhatsthat uses to show what is possible.
And in regards to obstacles, no matter what they are, better receiver hardware / antennas is only of limited use.
Thanks for the insight. I am taking into account the 40k for the outline vs the 8-10k that most UAT planes would be flying. The antennas have a clear line of sight to the NW and SW that the outline shows, but the reception is not great. We are on the 3rd floor and have a pretty nice view.
Gain was maxed at 50DBi, so I swapped to the original stratux antennas to see if it is an issue with the inexpensive antennas or coax. But in the process rebooted and am no longer receiving ADSB messages at all.
Gotta trouble shoot that now.
Building materials block a lot of the ADSB signal. Attached to a balcony instead of being on a roof to clear the building will have your building block a lot of the signal to the building side.
What Wiedhopf says is correct, though. Better equipment won’t get you much in the obstructed direction but it can help in the open direction. If you could finagle an antenna on the roof you’ll not only get better range but also see more traffic that’s being blocked now. (Obviously)
There’s a whole following for how to disguise antennas, conceal them as part of a building, etc. Lots of ideas in that group if you want to go that route and the association is willing. You can also explain the value in ADSB. It’s used a lot now to locate lost aircraft, investigate accidents, etc. It’s also just interesting in its own right.
Thanks! I have definitely thought about getting it up on the roof. Unfortunately the HOA will not allow it. The patio is the best option. And I am actually ok with that. The antennas are 30ft above the ground level. We are at 7000ft and terrain rises very quickly over 10,000ft to the east. I would not expect putting the antenna on the roof to give much improvement. We have unobstructed view 180* to the West with the exception of terrain directly west and rising to 8,500ft. The terrain plot is actually a pretty good depiction of the area.
I am trying to get more range in the unobstructed directions if possible. So trying to tweak things to help with that.
Considering terrain, it is probably better to have multiple station in different areas. My hope is to try to place a feeder at the airport 4mi to the north. This would give a different terrain profile. Need to figure out if I can get internet.
Ideally, a station at the top of a mountain would be best, but they are contracted with service providers and littered with radio towers. I don’t think I could get away with that. But I might try at some point.
Update: I ordered a ADSBX Blue SDR for 1090 and a ADSBX Orange for 978. Just plugging in the Blue stick and running it on my laptop at the dinner table with a 6in antenna gives 5x as many aircraft and at least 2x the range. Pretty impressive!
Installing the sticks with in the Pi is a little more of a project. I plan to re-image the Pi and clean up the install so it doesn’t get messed up every reboot. I will probably try the ADSB.im suggested by wiedehopf. Its also getting installed in a proper WX case and more permanent power and networking solutions.
Any suggested are welcomed and
Ill give another update once that is completed.
Update:
Installed ADSB exchange 1090 SDR with amp and filter, and ADSB exchange 978 SDR with amp on my Pi. I also started using ADSB.im and have been really happy.
I am getting much better reception. Both range and consistency. I will have a continuous track rather then a broken breadcrumb trail. I believe I am really only limited by terrain now. But with some thoughtful antenna placement, I can get 1090 and 978 traffic to the threshold at the local airport which is a big improvement.
Just out of curiosity, I will often get a much better track with tar1090 then what gets uploaded to flightaware and that is understandable. I am not sure how many positions get uploaded with respect to how many are received. But flight aware seems to end the flight on base or final and tar1090 follows it all the way to the ground. This then leaves the flight lingering on flightaware.
Is there a way to make sure that the last few positions are uploaded?
If you have cutouts when the aircraft are closest to your antenna which can happen pretty easily, reduce the gain.
Just as a note even if you haven’t mentioned that.
Even at a large airport that is entirely ground covered, the flight ends on the runway.
FA at least in the public data seems to only record a position every 15 seconds.
There are no settings that would change any of that in the feed software.
Not sure if @obj can shed light on that.
Thanks, the gain is currently at 36. It seems to be pretty happy. We are on what would be a 5 mile final and we are above the valley floor, so we do get aircraft that fly rather low and close. But I haven seen a consistent problem with it dropping messages.
I just noticed that flightaware either doesn’t get or use the last few messages and leave the plane hanging on final.
I also noticed this when when looking through some track logs and the tar1090 time-lapse/replay of the flight showed one additional location. But the downloaded XML did not have that point. The time-lapse/replay and downloaded XML also had a much lower resolution,( Which makes sense when it comes to storing that data. ) I think there is a way to increase that resolution if desired, but I haven’t looked into the arguments or config file.
So adsb.im uses the ultrafeeder container which only stores heatmap / replay data which is partial data at an arbitrary 15 second time resolution.
readsb has the capacity to store very nice (at least i think so) trace files for each aircraft and day but that’s not enabled by default.
Probably should make an easy way to switch that on without also changing how the tar1090 user interface behaves. Currently adding --write-json-globe-index --write-globe-history /var/globe_history to the readsb command line will add those, you’d have to do that via READSB_EXTRA_ARGS env var.
But it will change a bit how the webinterface loads. For example pressing T stops working as you might expect it. But /?pTracks will still work.
It’s a bit of a mess in that regard as all the data saving was made with global aggregation in mind.
As such you could use one of the sites that use it and download the KML there.
Seems like most of the aggregators only retain some of the position data as well. They all had the same data as what I could get within the local KML file. It was strange that the timelapse/replay had an additional position report that was not included in the KML and was not on any of the aggregator sites.
As for Flightaware and the other aggregators, It would be interesting to see how they choose what data they include in the track log for position reports. What makes data from feeder A better then feeder B? Is it first come, first server or is it based on some data validity parameters? Do they log more data if certain parameters have a greater rate of change? Flightaware looks like most tracks are at a 30 sec log interval and they do some “predictive” tracking and lots of smoothing.
I will have to dig around in READSB and ADSB.im, may need to throw together a test bench to play around with some of the configuration.
We record at a higher rate, and retain that data, but it’s heavily summarized for display.
We do retain post-landing data (that is, the positions recorded after hyperfeed has decided to arrive the flight), and provide that in some of our data products. I think there’s some work being done on exposing that on the public website but I’m not sure exactly what state that’s in.
Are you feeding those aggregators? Can you link the trace for adsb.lol or one of the other aggregators using readsb/tar1090?
It’s possible the KML export logic has issues, did you check the displayed track in the webinterface and compare that to the KML?
The trace saving logic in readsb is my code and it’s not exactly easy to read or well documented.
There is a maximum configurable interval as well as changes in track or speed or transition to ground that will all trigger more data to be saved.
If you wanted you could save super high resolution data locally.
If you don’t mind changing how the webinterface works a bit … you can put this in env vars on the expert page:
This will ensure all received positions are put into the trace files, ADS-B sends a position every 0.5 seconds. If you don’t need quite that much resolution, you increase the interval to let’s say 2 or 5 seconds.
This is the path in the container, on adsb.im you’ll find the data in /opt/adsb/config/ultrafeeder/globe_history
The directory previously had heatmap data (also used for replay) but with those config changes you’ll also see a traces directory int he subdirectory for each day.
2024/07/11/traces
Note that adsb.im doesn’t support this so it’s gonna be less well tested.
Over time the filesystem might not like the many files being created
That is kinda what I figured. Most dont need precise track information.
So flightaware is probably getting the positions from feeders all the way to the ground. There is just some logic that is not allowing it to display the last few positions and end the flight.
I have seen lots of larger airports have live ground coverage. Which is cool to watch.
I should have looked closer at specific tracks. I feed several and ADSB Exchange does have a higher resolution track and the KML export contains more positions vs the local replay web interface and KML export. I believe it is just an lower logging interval on the local device. But it does seem to be sending more data to aggregators and some aggregators are better at displaying then others.
I may setup remote logging on a local server. That way I can log data without having to worry about the feeder setup and interface or the SD card.
