Recieving this on my system. Wonder if its an ooops or what
RPN9007 A33263 Squawking: Aircraft Hijacking [FR24] [FlightStats] [FlightAware]
Altitude: 21975 ft / 6694 m Squawk: 7500
Speed: n/a RSSI: -23.8 dBFS
Track: n/a Last seen: now
Position: n/a
Distance from Site: n/a
Do these “emergency” squawks show up as a different color by default?
LitterBug
I had this happen on Monday. I run two RPIs, one with regular Dump1090 and the other with Dump1090-mutability. The mutability RPI was reporting an aircraft with a squawk of 7700 and my other RPI was reporting the same aircraft with a squawk of 7754. I checked FR24, Planefinder and a friend’s RPI and those also report a normal squawk of 7754.
Are you using Dump1090-mutability? I wonder if there is something odd with it?
Marty
I run two Pi’s with dump1090-mutability. They are both configured identically. One reports 7X00 squawks all the time. The other almost never does.
I attribute most of these to decoding errors, with bits that are right on the edge – I see this as well, with two SDRs running off the same RF chain, and one getting a better decode than the other (or at least a different decode than the other).
bob k6rtm
I just started playing around with mutability a day ago. I had a FDX plane going 3275 mph on my Mutability box, but my stock PiAware box was showing a normal speed. I also am getting 50 malformed frames in VRS from the mutability box a day compared to 0.
Cheers,
LitterBug
Yes I run Muta
It’s mostly a numbers game - dump1090-mutability picks up a lot more candidate frames, most of which are discarded because they don’t pass validation.
Given enough candidates, some errors are going to slip past error detection.
The message error correction coverage in the Mode S message format isn’t great either - it gets worse as you have more aircraft with bitwise-similar ICAO codes - which can cause odd effects (squawk/altitude getting attributed to the wrong aircraft is the most common case; undetected errors are another possible result)
Any idea what VRS consider a malformed frame? The message framing should always be OK.
If you are running with --oversample and getting the errors, would removing --oversample lose more data relatively than errors?
Try it and see, I don’t have hard numbers. You could experiment with dropping --fix too.
You’re never going to entirely remove bogus messages (not only from reception errors - there are plenty of transponders out there that just generate garbage data) so even if you are quite conservative in the receiver settings it makes sense to take all the data you see with a large grain of salt 