Getting a bit off topic but last time I read the spec Ethernet and PoE have distance limits.
S
For sure, but there are always solutions for that problem as long as the cost does not matter. Normally that’s what repeaters are for.
The guy wires might be a problem with neighbours.
I was thinking more like this 
Freestanding, 330.4 metres and we have already have experience of building in the UK.
1 Like
Back in the mid 1980s, when I was last up that tower, the BBC were rather worried about the rusty water that seeps through the concrete.
4 Likes
I’ve just checked the location of a communication tower where i look at every morning from the bath room. I thought already “wow, that would be a good location”.
Checked the max range via heywhatsthat.com
Having a device on that tower would give me a range up to north sea and south to almost Milan (Italy). The tower is only 300 feet tall, but built on top of a mountain.
Still dreamin’…
I like when a thread goes off-topic 
So I see in this topic that for Airspy users, gain experimentation is less important? I’ve done some anyway, wrote a wrapper script that restarts airspy_adsb every ten minutes with different settings. Then I have a separate script that fetches stats from Prometheus for each 10m period to see which settings perform most strongly.
It’s all pretty close and in the noise but for my setup right now 20 appears to get me slightly better results than the 21 max:
event rate, gain 17-21, mean then mesian
902.9236606005733 1040.6
937.2180315535028 1015.2666666666667
909.0329757399759 1006.0666666666667
969.3911419019122 1091.6333333333332
936.0530182543393 1025.0333333333333
num planes, gain 17-21, mean then mesian
68.36978233034571 75.0
68.65535071942446 69.0
68.13038933890776 75.0
73.67412302999492 84.0
71.01815431164901 75.0
This is over 5d of data, so on average that’s 720 10m periods, which I would think should be statistically significant. I’ll keep collecting for a few more days. (And also start doing this same experiment with other flags of course.)
2 Likes
How are you keeping the same number of planes in the air and the same number of transmissions to have a consistent sample?
1 Like
Isn’t it all about collecting enough data to compensate for that unpredictability?
I’ve picked the 10m change interval to be as fast as changes in air traffic can be, have Prometheus collect metrics every I think 15 seconds, throw away the first 90s of every 10m interval to avoid contamination (the number of planes is counted over preceding 60s of data after all).
I’ve been experimenting for over 2w by now and I’ve gotten the same results over different 2-3d and longer periods so far. I’ve been trying hard to prove myself wrong and have not been able. And will of course keep running this because it’s fun and interesting.
But if you have advice on how I can ask aircraft around me to cooperate with my research, sure I am all ears.
1 Like
Are you using an LNA?
Which other command line parameters?
I’d be interested in the details of this, it’s something I’d like to experiment with at the MTG site, that’s using a Pi3B+ and an Airspy Mini. I’ve never really spent much time tweaking the gain there.
I’m interested in testing this out as well. I’ve spent the last year tweaking my Pi4 and airspy mini-setup by manually adding a lot of data to excel and it’s quite tedious to do this on a daily basis.
This could be a nice way of doing it and getting additional data into the mix.
The “true” message rate fluctuates at pretty much every timescale from seconds through to years, so averaging is not everything. Ideally you’d use a reference system to provide a baseline.
2 Likes
Yup, it’s clear that a splitter and a control setup is ideal but not everyone has the dedication and time to setup an additional RasPi + Airspy of course.
To me this seems like the next best equivalent. 
I can’t just rely on other people with a splitter and double Airspy since their setup and therefore test results may otherwise be very different.
(And yes I’ve already noticed that mean and median tend to tell me very different things over short measurement periods, and most of all that nighttime data is so noisy I could consider always discarding it (or at least separating it out as I also wonder whether for nighttime traffic levels, different flags could be optimal!))
I have an LNA, yes. This is the DPD antenna (peaks at 10m AGL) then the RTL-SDR LNA, then 7m of coax (Aircell 7), then the Airspy Mini. (Planning to insert an external bias-tee injector when I have it.)
My flags at the time were:
/home/adsb/airspy/airspy_adsb -v -b [listens and connects] -p -f 1 -x -g [gain_value]
I forgot when the -x snuck in, I think I’ve read here that its results are questionnable so I’ll just have to test it on and off separately. The fun of this script is you can have it experiment with anything, for example I’m hoping to do a binary search on what to pass to -e now (but AFAIK I’ll need to be more careful as it can just result in more garbage packets getting through?)
bive, keithma: I’ll clean up the sources and share later, yes! Note that the runner script is easy to share but I don’t know whether Prometheus has been fully integrated with the standard PiAware image yet? (I’ve been using Prom with my own dump1090 metrics exporter since 2015… )
2 Likes
No -e probably won’t give you garbage.
With 12 MHz you don’t need -p for packing, and even with 20 MHz … if you’re not using other USB devices, without usually is more reliable.
You can add -w 5
The -w 5 will increase the whitelist threshold, if you use that my experience is that you won’t get anything bogus. Well at least not bogus extra aircraft.
Can’t really be sure about extra bogus messages but it’s unlikely given the numbers.
What RPi is that?
On an RPi3 try: -e 9 -m 12 (the -m 12 is the default anyhow, just being verbose)
On an RPi4 … you can easily do -e 9 -m 20 … the higher sample rate can be quite useful but it depends on how crowded 1090 MHz is.
Sounds great!
I’m running Prometheus on a separate RPi3, using the fa-grafana-docker-installation on Github (https://github.com/flightaware/fa-grafana) so it should work without too many hiccups. If not, I’m sure that I can tweak it enough to work.
Have always used raspbian lite for my RPi’s (and Debian for my other Linux systems) and are doing that for my FA-feeder as well.
Back to the original thread subject i have a question.
It was mentioned several times in the thread that targetting the 5% max for messages > -3dBFS
Is this also valid from the opposite?
So let’s say i am reducing the gain to a level where this value is at 1-2%
Should i then increase gain to get closer to that 5%?
Or is a lower value always better (as long as the range and received aircraft remain the same)?
You should be able to answer this yourself.
As in what’s the drawback of high gain?
If i would be able ot answer correctly, i would not ask
My thought is that a lower value is better as long as it does not impact the overall
performance.
Any message > 3dB is (too high) noise overloading the receiver, therefore not counted properly, correct?
But that’s what i am not sure about.
Listening to… Running my Jetvision antenna on gain 49.6 - ~3% of messages are under 5 dB. Running the Airnav on gain 44.5, and getting ~10% of messages under 5 dB - But it does not seem to overload the reciever, overhead planes does not disappear on the map. Max. range are approx the same.