第29章 暴雨（1 / 2）
请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。
暴雨衰减是卫星通信领域公认的老大难问题。
原因很简单——雨滴会吸收和散射电磁波，频率越高损耗越大。天穹星座用的是ka波段，恰好是对降雨最敏感的频段之一。一场大暴雨能让星地链路的信號强度衰减十几个分贝，相当於把一条高速公路瞬间变成泥泞小路。
更棘手的是暴雨的空间分布极不均匀。同一片区域里，可能东边暴雨倾盆，西边晴空万里，两个相距不到五公里的地面终端面对的信道状態天差地別。这种空间不一致性让统一的补偿策略几乎失效。
左城翻遍了蓝湾通信的实测资料库，发现暴雨条件下的数据少得可怜——只有十一组，而且全部採集自同一场降雨过程，空间覆盖范围很窄。
数据不够。又是这个问题。
但这次他没有条件像上次一样扛著设备去实地採集——总不能等老天爷下暴雨再去蹲守。他需要换一种思路。
第十二天晚上，左城在宿舍里对著天花板躺了半个小时，突然坐了起来。
气象数据。
暴雨本身是气象现象，而蓝星的气象监测网络已经积累了几十年的歷史数据。如果能把气象部门的降雨强度分布数据和卫星链路的电波传播模型结合起来，就可以用歷史气象数据去“合成“大量的暴雨衰减信道样本。
这和陈浩之前做地下空间数据增强的思路一脉相承，但维度更高——不是模擬一个封闭空间的信號环境，而是用真实的气象观测数据驱动一个物理传播模型，生成的合成数据在统计特性上会比纯模擬数据更接近真实情况。
左城当晚就写了一封邮件给韩哲，申请调用蓝湾通信合作的气象数据接口。韩哲第二天上午就批了——天穹项目的技术资源调配优先级很高。
拿到气象数据后，左城花了两天时间搭建了一套“气象驱动的信道合成器“——输入任意一个时间点和地理位置的降雨强度分布，输出对应条件下的星地链路信道状態。合成器的核心是一组ka波段雨衰经验公式，经过实测数据的標定后，精度控制在可接受的范围內。
有了合成器，他一口气生成了两万组暴雨条件下的信道数据，覆盖了从小雨到特大暴雨、从热带到温带、从平原到山区的各种组合。
然后把这些数据餵给双层预测架构去跑。
结果不太好看。
標准条件下超標百分之四十二的精度优势，在暴雨场景下直接腰斩——只剩百分之十九。原因很明確：暴雨带来的信號衰减太剧烈了，上层的自適应补偿模块来不及跟上变化速度，总是慢半拍。
“问题不在补偿速度。“左城对著仿真数据皱眉皱了一个下午，终於找到了癥结，“问题在底层的確定性预测里根本没有气象因素。“
双层架构的底层是纯轨道力学——它能精確预测卫星的位置和速度，但它不知道地面正在下暴雨。底层预测出来的信道状態是“晴天版本“，上层拿到一个偏差极大的初始值，补偿起来自然吃力。
解决方案很直接：在底层加入气象信息。
把地面气象站的实时降雨数据接入底层预测模块，让轨道预测的同时考虑当前的气象条件，输出的就不再是“晴天版本“，而是“当前天气版本“的信道预测。上层只需要补偿剩余的隨机误差，压力大幅减轻。
但“直接“不等於“简单“。
气象数据的更新频率和卫星信號的处理频率差了好几个数量级——气象站每五分钟更新一次数据，而信道估计需要毫秒级的响应。五分钟对通信系统来说是一个世纪。怎么在两次气象更新之间填补空白
左城又卡了一天。
第十六天下午，他去食堂打饭的路上碰到了唐旭。
唐旭端著一盘红烧茄子和一碗米饭，看见左城主动打了个招呼，犹豫了一下，在他对面坐了下来。
“左城，我有个事想问你。“唐旭挠了挠头，憨厚的表情信道状態信息做输入，但现有的信道估计方案给出来的数据刷新率太低，我想把刷新率提上去又怕增加计算负担。你那边的预测架构有没有可能提供一个高刷新率的信道预测接口给我用“
左城夹菜的手停了。
高刷新率的信道预测接口。
↑返回顶部↑