请系好安全带，这个故事涉及到一个奶酪占卜师、战争部以及几乎所有其他政府部门。在2017年（我想？）我通过Mark VK5QI认识了气球追踪。当时，澳大利亚的气球追踪社区很小。只有墨尔本和阿德莱德的探空仪（气球上的发射器）在一个叫做Habhub的网站上被跟踪 - 高空气球聚集地。这个网站是为业余气球设计的，而不是气象气球。随着时间的推移，越来越多的探空仪被跟踪在Habhub上，最终Habhub的管理员引入了一个默认过滤器，默认移除气象气球。可以在URL中添加查询参数以移除过滤器，于是2018年5月12日，sondehub.org以单一目的注册 - URL重定向到Habhub，并使用特定于探空仪的过滤器。要明确的是，这更像是个笑话，而不是经营探空仪追踪服务的决定。你访问sondehub.org，它会重定向到habhub.org。就这样。然而，Habhub从未设计为每天承载这么多独特的气球。到7月，我们决定开始通过SondeHub代理探空仪摄取数据。这使我们能够捕捉更多的数据（不再对自己设置速率限制）。这些数据被导入到一个独立的OpenSearch集群中，但在这一阶段我们并没有使用或公开这些数据。我更多的是把它当作一个玩具 - 玩转不同的亚马逊网络服务（AWS）和分析平台。到2019年，Habhub的服务器已经非常吃力 - aprs.fi也是如此。我们意识到我们需要运行自己的服务，最初的计划是构建新的API，最终推出新的前端。随后我们开始收到来自政府机构的关于探空仪数据的信息请求。例如，我们收到关于一个探空仪击中马的保险索赔请求，导致马冲破栅栏。这部分原因是，因为与当时的官方软件不同，我们的系统一路跟踪探空仪到达地面。此外，在2019年，我们检测到探空仪发射数量下降。这与GPS重置日期相吻合 - 我们以为是我们的软件坏了，但结果发现是Vaisala的设备存在问题，导致发射无法进行。搞笑的是，我们的软件处理重置的情况很好。在2020/2021年，我们最终构建了向后兼容的API用于Habhub前端，并开始测试指向我们后端的Habhub前端。它大致上工作得不错。我们开始接收到所有的数据，而不仅仅是部分数据，并通过S3提供开放访问。我们甚至开始运行自己的预测器 - 这是我现在使用的实体。随着我们自己的预测器运行，Mark开发了一个我们称之为反向预测的系统。这是我们利用一个已经启动的探空仪的数据，并使用风模型向后运行预测器，从而粗略确定发射位置预测。这非常有效。我们能够检测到一些记录不良的探空仪发射地点，并开始将气球分配到发射地点。我们第一次体验到与军方打交道。然后在2021年，我们收到了一个关于敏感的/军事的/...设施的电子邮件。因此，我们确实更希望它不会在任何地图上明确标记。然而，风数据不仅用于预测天气。它还用于计算炮兵射程。我们开始不小心绘制炮兵位置的地图。我们决定保留反向预测，但在合理的请求下删除发射地点。反向预测系统还探测到许多海洋军事舰艇。SondeHub还进行了很多开发，增加了像websockets和MQTT等实时数据传输功能。我们断开了Habhub后端与我们的代理的连接，并在ARDC的资助下，我们能够设置一个业余高空气球的SondeHub原型。最终，由于缺乏维护，Habhub停用了，我们匆忙将可以迁移的内容转移到SondeHub。439,000美元导弹与派对气球。一切都很好，直到2023年的“中国间谍气球”事件。SondeHub的流量大幅增加 - 但我们的架构使其相对可管理。然后，在2023年2月11日，美国声称使用AIM-9X侧风导弹击落了一枚业余无线电气球。那天早上，我醒来收到了高使用率警报。SondeHub被《华盛顿邮报》链接到。我们的网站合理处理了额外的流量。从那以后，我们收到了许多来自.mil和.gov地址的支持请求。我们还收到了来自航空业/空中管制塔的请求。在2024年12月，我的收件箱又响起警报。这次是预测的警报。有人决定破坏我们的API。看起来似乎每周都会出现这种情况。全面入侵。我们开启日志记录。请求来自一个单独的IP。我们有一些怀疑，一家私人公司正在使用我们的后端进行地理定位。