I'd like to hack together some code to assess the quality and consistency of quality of received data, as opposed to the quantity, and I'm keen for community feedback about how to go about that.
Aside from being useful for evaluating different antennae, this might be of some use to FR24 dev/ops, if they aren't already doing something like this because bad data are sometimes worse than no data.
My receiver is self-assembled. It's a Raspberry Pi 3 running dump1090-mutability, so I get certain data that may or may not be available to other receivers, and I may be missing out on data that others get. I'm currently using a generic SDR with no preamp or bandpass, but a FA + LNA + BP is on its way to replace it. My antenna is a home-brew 8-segment co-lin, which does something like 3× to 5× better in terms of distance and message count than the 1/4w whip it replaced.
Here's what I've got so far as indicators of poor signal quality:
Bad Mode-S messages are, well, bad, probably too many bit errors. Unknown messages might be bad, but there's no way of knowing. My figures for each are about 60% and 39% respectively, so the vast majority of received messages are being thrown away.
Single-point tracks are probably indicative of patchy coverage which, in turn, probably indicates poor quality data. My figure averages around 90% single-point.
Those figures look a bit grim, which is why I want to drill into SQ a bit more. Despite the better antenna, it's mounted in a loft rather than outside but there's no immediate prospect of doing anything about that. The other possible explanation is that there's a cell base station maybe 100 yards away so GSM900 noise and perhaps 4G noise is probably adversely affecting the receiver. Maybe the bandpass filter will help there.
All of the above depend on data provided by dump1090 and thus probably aren't portable.
The idea I have in mind — and I'm interested to know if anybody has any others — is to look at the distribution of elapsed time between position reports for each a/c (ICAO address) on the basis that each a/c probably transmits position messages on a fairly periodic basis (active interrogation aside). A receiver getting good data should show a fairly narrow distribution of timings, where a receiver missing messages because of poor quality data will show a wider distribution. The quality, therefore, is inversely proportional to the standard deviation of that distribution.
An alternative approach would be to look at the distribution of distance travelled between position reports, normalised for reported ground speed. The advantage of this is that the quality of the timestamps becomes irrelevant, a source of error that is probably not insignificant given the latency of rx to decode (where I assume the timestamps get recorded).
A secondary benefit (to FR24) is that only lat/lon/alt/gs are required, not timestamps which means this processing can be done in FR24's infrastructure, if that is desirable.
The disadvantage to this approach is that Vincentian (or even Haversine) computations are much more expensive than a simple timestamp substraction.
What do you think?
If others are interested in trying out this code I'll make it available, as well as the Munin plugins I wrote for dump1090-mutability (and compatible). I'm currently writing it in Python fed by SBS TCP port, so it should run on any platform including Windows. I'd be actively interested in other peoples' quality data for comparison purposes, especially those who get decent ranges or who are known to have good quality installs.
Aside from being useful for evaluating different antennae, this might be of some use to FR24 dev/ops, if they aren't already doing something like this because bad data are sometimes worse than no data.
My receiver is self-assembled. It's a Raspberry Pi 3 running dump1090-mutability, so I get certain data that may or may not be available to other receivers, and I may be missing out on data that others get. I'm currently using a generic SDR with no preamp or bandpass, but a FA + LNA + BP is on its way to replace it. My antenna is a home-brew 8-segment co-lin, which does something like 3× to 5× better in terms of distance and message count than the 1/4w whip it replaced.
Here's what I've got so far as indicators of poor signal quality:
- Bad and unknown Mode-S messages as a proportion of received Mode-S preambles
- Proportion of tracks that are single point
- Signal strength, though I don't see this as being especially useful
Bad Mode-S messages are, well, bad, probably too many bit errors. Unknown messages might be bad, but there's no way of knowing. My figures for each are about 60% and 39% respectively, so the vast majority of received messages are being thrown away.
Single-point tracks are probably indicative of patchy coverage which, in turn, probably indicates poor quality data. My figure averages around 90% single-point.
Those figures look a bit grim, which is why I want to drill into SQ a bit more. Despite the better antenna, it's mounted in a loft rather than outside but there's no immediate prospect of doing anything about that. The other possible explanation is that there's a cell base station maybe 100 yards away so GSM900 noise and perhaps 4G noise is probably adversely affecting the receiver. Maybe the bandpass filter will help there.
All of the above depend on data provided by dump1090 and thus probably aren't portable.
The idea I have in mind — and I'm interested to know if anybody has any others — is to look at the distribution of elapsed time between position reports for each a/c (ICAO address) on the basis that each a/c probably transmits position messages on a fairly periodic basis (active interrogation aside). A receiver getting good data should show a fairly narrow distribution of timings, where a receiver missing messages because of poor quality data will show a wider distribution. The quality, therefore, is inversely proportional to the standard deviation of that distribution.
An alternative approach would be to look at the distribution of distance travelled between position reports, normalised for reported ground speed. The advantage of this is that the quality of the timestamps becomes irrelevant, a source of error that is probably not insignificant given the latency of rx to decode (where I assume the timestamps get recorded).
A secondary benefit (to FR24) is that only lat/lon/alt/gs are required, not timestamps which means this processing can be done in FR24's infrastructure, if that is desirable.
The disadvantage to this approach is that Vincentian (or even Haversine) computations are much more expensive than a simple timestamp substraction.
What do you think?
If others are interested in trying out this code I'll make it available, as well as the Munin plugins I wrote for dump1090-mutability (and compatible). I'm currently writing it in Python fed by SBS TCP port, so it should run on any platform including Windows. I'd be actively interested in other peoples' quality data for comparison purposes, especially those who get decent ranges or who are known to have good quality installs.
Comment