UPDATE: The radiosonde data feeds have almost completely been moved to sondehub.org and the APRS-IS is no longer involved or affected by it. Thank you!
I have today started to filter out radiosonde traffic coming to aprs.fi, because it's consuming quite a lot of resources, and the incoming data is quite a mess, and my log files are full of warnings about inconsistent balloon positions, just because the gateways all work differently, and they create a lot of duplicate data, at a very high rate.
The packet rates are also wild - many gateways forward packets from a single balloon every few seconds, which is much more often than any well-behaving APRS stations do. Because different gateways customize the packets by using unique destination callsigns, inserting advertisement URLs and custom comment texts, I'm getting a whole lot of packets here, many of them modified duplicates of the same original frequent packets. It's quite silly indeed.
Please note that it has also been said and written many times that the APRS-IS is designed and built to only carry amateur radio traffic, and sonde data clearly are not amateur radio traffic. I might personally be ready to make an exception, but I can't speak for others, there might be strong opposition elsewhere. One perfectly good option that all of this traffic only goes to sondehub.org and/or radiosondy.info in the future - but the improvements listed here should help that service just as well.
I can re-enable intake of this data at aprs.fi (perhaps via a different set of APRS-IS-like servers, or the sondehub.org websocket feed), but I have two simple conditions that must be fulfilled first.
1. Receivers must forward data consistently, and maintain data integrity, so that APRS duplicate packet suppression works
All gateways forwarding a single packet received from a sonde must all output the exact same APRS packet: Same source callsign, same destination callsign, and same packet contents. Similarly to APRS, the path may differ and the receiver callsign after the Q construct is naturally different.
The packet must only contain data that was received from the sonde - it must not contain identifiers, text or data that is configured on the gateway, or is somehow dependent on the receiver software version, local time, signal level at receiver, or such.
This ensures that the APRS-IS duplicate packet filtering methods work. When all the gateways emit the same packet, duplicates can be removed and a single copy will land at aprs.fi.
Yes, this requires a little co-operation and coordination by the gateway software authors. Once you sort it out, and document what the format is, and which gateways support the consistent format, let me know and I'll open it up!
The gateways may announce their own software and custom comment strings in the beacon comment text sent to indicate the position of the gateway itself. It must not go to the comment string of the balloon; the packet of the balloon must be standardised and harmonised.
2. The packet rate must be sane, and in line with APRS operations
Typical APRS stations beacon once every 30 seconds, or much less often, when they're not making tight turns. Once per 10 or 20 minutes when they're not moving. It's not acceptable for balloons to transmit on the APRS-IS once every 3 seconds, even if their data rate on RF would allow such an interval.
If you need a higher rate for the recovery / location, make it dynamic - every 20 seconds when the balloon is at low altitude and just about to fall down. When flying really high - every 40 or 60 seconds should do, it's plenty. When they're high up, the packets will be heard by many receivers, which also brings the packet rate up greatly.
The discussion on fixing this for radiosonde_auto_rx is ongoing in these two tickets, but the point is that all gateways need to work the same way.
73, and happy hacking!
No comments:
Post a Comment