I've just installed my new bad GPS fix detection algorithm. It should detect bad fixes about as well as before, but produce less false positives. The new algorithm looks at the previously received packets instead of the previously accepted packets, and is also slightly adaptive, taking into account more history than just the previous single accepted position.
It should work better for jets (traveling close to 1000 km/h), although during the takeoff acceleration some points might be dropped. After some initial test flights we'll be fixing that. :)
It should also better handle the case where the initial transmission happens to be somewhere far off. It seems like there are a bunch of stations which always wake up in Tokyo and then start transmitting their correct position in the US or Europe. Probably the GPS manufacturer has decided to show it's office location instead of the standard 0/0 lat/lon, and either does not indicate the bad fix in the NMEA sentence, or the tracker ignores that bit of information and transmits the bad position. These should now jump to the correct position after just a couple of packets.
The algorithm also ignores positions which were sent more than 2 hours ago, so if you take an intercontinental flight and start transmitting your new position immediately, it should just work!
Feedback is more than welcome!
The news of https://aprs.fi/ - new features and interesting attractions found in the APRS and AIS worlds.
The new algorithm found duplicate objects reporting positions 1200 mi apart. N0PBA in Minnesota and SHWBTE-2 in Arizona, USA, had the same object to report and aprs.fi started rejecting them as moving too fast. Renamed the SHWBTE-2 one and all is well.
ReplyDeleteMany thanks for your efforts. We all love aprs.fi and use it all the time.
Cole Cunningham, AA7RD
email: aa7rd@cox.net
I just started using APRS in my aircraft. Most of my reports say my speed is 16-34MPH instead of 300+ MPH. The course and altitude are correct. About 1 in 10 reports show a correct speed. Any suggestions?
ReplyDeleteJim WB5SYO
Cole: Ok, good, thanks. It's working much like it should.
ReplyDeleteJim: (raw packets) There are a few different possibilities. Either the tracker is truncating the speed and wrapping around, or it is encoding it wrong, or my mic-e parser is not decoding the speed correctly. We could maybe narrow it down by switching to plaintext/uncompressed APRS packets (by disabling mic-e). They're a little bigger, but it's easy to read the raw packets. Could you try that please?
There are also a big number of duplicate and delayed packets arriving here (as seen in the raw packets). This is because of the WIDE1-1,WIDE2-1 path which is generally very good for cars. It's a bit excess for airplanes. A single WIDE1-1 would probably do. If your tracker supports profile switching (using a different configuration based on, say, altitude), you could maybe configure it to use an empty path (nothing of the WIDE* things) when airborne (altitude > 500 feet or something).
i beaconed using an app on my iphone (was not carrying a radio on my trip), that send data directly over TCP to APRS server.
ReplyDeletei did this prior to take off --and my first update on landing registered the error "Location changes too fast (>500 km/h)"
oh, my flight was about 960km and 1.5 hours long
ReplyDeleteso this was under the '2 hour' window you mention.
maybe you should trim that down to minutes not hours for the detection issue??