hello wiedehopf and others, are there any issues feeding FR24 when using Airspy Mini (currently running piaware 6.0 on SD card, 2.2 RC30 on buster)? i can’t remember if there were any warnings/comments re this and i’m getting old and forgetful!
when i ssh into my pi and run the fr24 install i get
E: Repository 'http://flightaware.com/mirror/raspberrypi/debian buster InRelease ’ changed its ‘Suite’ value from ‘testing’ to ‘oldstable’
N: This must be accepted explicitly before updates for this repository can be ap plied. See apt-secure(8) manpage for details.
The weekend brought increased air traffic thanks to the first nice weather in maybe 8 months. I noticed what looked like a DF4 messages burst for a little while on Sunday. I don’t think this happens too often here. Traffic was much denser than usual for this region at the time. Tons of GA aircraft. Interesting (to me).
My suspicion is also that ATC radars will start reducing interrogation rates as the message rate ramps up.
Then you have more overlaps as the number of messages increases.
Do some math (i’m not sure exactly how to even approach that haha).
But you have some message rate and a message is a certain duration: Radartutorial
Note that there are short and long messages depending on DF type. (64 and 120 us i believe)
For 120 us long messages the absolute maximum theoretical rate is 8333 but the probability to get some overlap is obviously present at lower rates.
I have no stats on how many ModeAC messages are present which are on the same frequency.
Thank you for taking the time to respond.
I wanted to avoid studying the math background like any typically lazy guy, hoping you’re past the calculations and have a ready answer.
ATC can actually reduce the query rate over a given amount of traffic, as this is for security, but beyond this phenomenon, the tendency is that the number of decoded DF17 packets may increase further, but the number of positions per second peaks at a certain value. Typically, a value of around 150-160 (RHS) can be read during the day.
The simplified model you have outlined is perfectly sufficient for me to associate an illustration with it in an easy imagination.
lol It’s better to save on expensive paper
Indeed, the chance of finding the preamble is proportional to the sampling rate - and the high number of overlaps and the imperfect signal-to-noise ratio have the opposite effect. … in addition, as traffic increases, the number of ACAS (DF0 and DF16) increases, further increasing the number of overlaps.
I think, we can simply enjoy the fact of having a working decoder - thanks for the great dev work behind.
For some reason, I am always tempted to complicate my otherwise quiet work day.
The current math is heavily optimized. The small tweaks in the internal parameters (filters) can have different effects depending on the receive conditions. We have a good average, I would say. To get better results, we will need a completely different approach, from the hardware to the DSP. As of today, I don’t think it’s economical.
If we skip the economic factor, what kind of improvement do you think is possible? And would there be different solutions for a busy site close to Heathrow compared to a site in a less aircraft-dense area?