dump1090-mutability accepting out-of-range locations


I’ve configured both my instances of dump-mut to limit aircraft locations to 250 nm (MAX_RANGE=“250”), yet one of my Pi’s (but not the other) is showing aircraft over 250 miles away. Shouldn’t these positions be discarded? (Range rings are 50 nm)


Here’s my latest log entry:

Statistics: Tue Apr 14 20:30:26 2015 UTC - Tue Apr 14 21:30:26 2015 UTC
Local receiver:
  65922 sample blocks processed
  0 sample blocks dropped
  0 Mode A/C messages received
  83045157 Mode-S message preambles received
    52519106 with bad message format or invalid CRC
    28689693 with unrecognized ICAO address
    1705177 accepted with correct CRC
    131181 accepted with 1-bit error repaired
  -6.5 dBFS mean signal power
  -0.6 dBFS peak signal power
  266636 messages with signal power above -3dBFS
Messages from network clients:
  0 Mode A/C messages received
  0 Mode S messages received
    0 with bad message format or invalid CRC
    0 with unrecognized ICAO address
    0 accepted with correct CRC
    0 accepted with 1-bit error repaired
1836358 total usable messages
9 surface position messages received
51987 airborne position messages received
47682 global CPR attempts with valid positions
1 global CPR attempts with bad data
  0 global CPR attempts that failed the range check
  1 global CPR attempts that failed the speed check
79 global CPR attempts with insufficient data
3912 local CPR attempts with valid positions
  3846 aircraft-relative positions
  66 receiver-relative positions
401 local CPR attempts that did not produce useful positions
  391 local CPR attempts that failed the range check
  1 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
466 unique aircraft tracks
131 aircraft tracks where only one message was seen
CPU load: 38.4%
  1211851 ms for demodulation
  133605 ms for reading from USB
  36970 ms for network input and background tasks


what logfile do you get that info in , and where do I find it


It will indeed apply that range limit and not use those out of range positions for those things that use dump1090’s interpretation of the messages - the dump1090 webmap and Basestation output on port 30003.

However it does not affect “raw” output at all - the undecoded packets are still forwarded. I assume you are feeding the raw output to VRS, which will then do its own position decoding with its own set of rules.

If you want to rely on dump1090’s position decoding, you can connect VRS to the Basestation output on port 30003 (though there are obviously tradeoffs to be made there)


/var/log/dump1090-mutability.log by default.


You’re absolutely right. It was raw data fed to VRS. Sorry I didn’t think of that. What tradeoffs?


Sorry for the confusion on my part @obj. I just reconfigured VRS to use BaseStation and port 30003.


Well, the Basestation format output is a processed format that only provides specific things e.g. position, speed, heading, callsign, squawk.
So VRS is limited to showing just those things and can’t extract some of the data it usually would extract from the raw messages (e.g. transponder type, whether the speed is airspeed or ground speed, etc)


Aha. I see. I can live without those details. I’m more interested in having VRS display accurate locations.

Can you tell me what I need to change in your dump-tools graph scripts to show the output in miles, not kilometers? Thanks.


I don’t think that one is one of mine (I collect the max range data but I don’t graph it). But assuming you’re using “rrdtool graph” to plot it, you can use a CDEF to convert the data before plotting (see the CPU graphs for some examples e.g. the calculation of “all” - it has a RPN-like expression syntax).

Something like this: “CDEF:range_miles=0.62137,range_km,*”