1. 项目概述：Multi-GNSS并发定位到底在解决什么问题
先聊点实际的。做过车载定位、无人机导航或者手持测绘设备的朋友，大概率遇到过这种场景：车开进城市高楼密集区，GPS信号被遮挡了一半，定位点开始乱跳，明明在直行，轨迹却画出了蛇形；无人机在树林边悬停，位置漂移从米级跳到十几米；甚至在某些遮挡严重的路段，接收机直接罢工，屏幕上显示"无定位"。
早期GNSS接收机只支持GPS单星座，遇到这些问题只能认命。后来GLONASS恢复组网、Galileo逐步建成、BDS也完成了全球组网，多星座接收开始普及，但市面上很多所谓"多系统"产品，其实只是按优先级做星座切换——GPS信号弱了切到GLONASS，结果切换瞬间定位中断，照样掉链子。真正能解决问题的，是标题里这个关键字：Concurrent Positioning，并发定位。
并发定位不是"用哪个系统"的问题，而是"同时用所有系统"的问题：接收机同时跟踪GPS、GLONASS、Galileo、BDS、QZSS多个星座的信号，在一个解算周期内把所有观测值融合起来，输出一个统一的位置结果。这个项目的核心就是搭建一个支持并发定位的Multi-GNSS平台，让终端在任何环境下都有足够多的卫星可用，从根上解决遮挡场景下的定位失效问题。
这篇文章不打算写教科书式的原理堆砌。我会从方案选型、硬件平台、实操配置、实测对比、踩坑记录这几个角度，把这个"多系统并发定位平台"从头到尾拆一遍。适合正在做GNSS方案选型的工程师、无人机和车载定位方向的开发者、以及想自己搭一套高可靠定位系统的爱好者参考。内容里涉及的硬件和软件都是我实际用过的，踩过的坑也会一并列出来。
2. 整体设计思路：为什么一定要做"并发架构"
2.1 并发定位和"多系统支持"是两码事
先把概念掰清楚。市面上很多接收机模组标称"GPS+GLONASS+Galileo+BDS"，看起来支持四星座，但内部实现可能是时分复用的：一个射频通道在不同时间片切换跟踪不同星座，或者虽然有多个通道，但某个星座信号质量稍差就被调度器踢出去。这种方案的直接后果是：可见卫星数统计表上很好看，但真正参与定位解算的卫星可能只有七八颗，而且一旦某个星座信号波动，参与解算的卫星数就剧烈变化，位置输出跟着跳。
并发定位的架构是完全不同的思路。接收机的射频前端用足够宽的带宽，把L1、L2、L5等频段的所有GNSS信号一并采下来，基带部分给每个星座分配独立的硬件相关器通道，同一个时刻并行跟踪几十颗卫星。以我常用的u-blox ZED-F9P为例，它宣称支持184个通道，也就是同时可以跟踪184颗卫星信号，GPS、GLONASS、Galileo、BDS、QZSS全在并发工作，而不是轮询切换。
打个比方：单系统定位就像公司只有一个员工，生病了就停工；多系统切换就像有几个员工但只能轮流上班，换人的时候产线要停；并发定位则是全员同时上班，谁状态好谁多干活，产线永远不断。这个比喻虽然粗，但能很直观地解释为什么并发架构在恶劣环境下的优势是碾压级的。
2.2 并发带来的收益不是"多几颗星"这么简单
并发定位最直接的收益是可见卫星数大幅上升。在城市峡谷、山谷、矿区、集装箱堆场这类对空视野受限的场景，任何一个星座的信号都很难覆盖完整的天穹，但四个星座的信号叠加后，总能拼出一个相对完整的天空覆盖。我实测过，在上海某个高楼密集的路口，单GPS接收机只能看到5到6颗星，定位精度直接崩坏；换成多系统并发平台后，可见卫星数稳定在25颗以上，PDOP值从6.8降到1.2左右。
第二个收益是定位精度的提升。定位精度和参与解算卫星的几何分布密切相关，DOP值是衡量这个几何分布的关键指标。卫星都在头顶时DOP值大，精度差；卫星分布在各个方向时DOP值小，精度高。多系统并发后，卫星在天空的分布不再依赖单一星座的轨道设计，而是四个星座的轨道面互相补充，几何构型更接近理想状态。再加上卫星数量多，参与最小二乘解算的冗余观测值增加，定位结果的噪声也明显下降。
第三个收益是可靠性。单系统在遮挡场景下出现周跳或者失锁，往往直接导致定位中断；并发架构下，某个星座的几颗卫星失锁，其他星座的几十颗卫星还在正常工作，解算结果只是稍微变差，不会中断。这对高速运动的载体尤其重要。我做过一个实验：用单系统接收机沿高架桥下方行驶，平均每两分钟就出现一次定位中断；换成四星座并发平台后，全程没断过，最差情况下HDOP也控制在2.5以内。
2.3 平台架构的选型逻辑：从硬件到软件的通盘考虑
这个项目命名里的"Platform"容易让人联想到软件平台，但GNSS领域里说的平台，通常是硬件接收机、解算软件和外围系统的组合体。我选择的方案是：高并发通道数的GNSS接收机模组作为信号采集主体，通过串口或USB输出原始观测数据和解算结果，上位机运行RTKLIB或者厂商SDK做深度处理。这套架构的好处是模块化程度高，信号采集和定位解算解耦，出了问题可以分别定位是硬件还是软件的原因。
硬件端我主要对比过三类方案：消费级模组（u-blox NEO-M9N、ZED-F9P）、国产高精度板卡（和芯星通UM980、华测CGI-410）、以及软件接收机方案（GNSS-SDR搭配RTL-SDR）。消费级模组胜在便宜、功耗低、上手快，但并发通道数和载波相位观测值质量不一定能满足高精度需求；高精度板卡性能强，支持RTK和PPP，但价格贵一个数量级；软件接收机方案最灵活，可以自己写信号处理算法，但实时性很难保证。综合成本和项目需求，ZED-F9P是性价比最高的选择，而如果项目对精度有更高要求，UM980这类板卡是更合适的方向。
3. 并发定位的核心环节：从信号捕获到位置解算
3.1 射频前端：并发定位的第一道关口
并发定位的物理基础是射频前端能把多个频段的信号同时接收下来。GNSS信号分布在L1（1575.42 MHz）、L2（1227.60 MHz）、L5（1176.45 MHz）等频段，每个系统的信号中心频率略有差异。传统单频接收机只接收L1频段，并发平台则要求射频前端有足够宽的带宽，至少覆盖1160到1610 MHz的范围，同时把L1、L2、L5都收下来。
这里面有个容易被忽略的坑：射频前端带宽太窄，会让边带信号失真，影响相关器对码相位的测量精度；带宽太宽又会引入更多带外噪声，降低信噪比。所以射频前端的SAW滤波器选型和LNA（低噪声放大器）的增益配置非常关键。实际项目中，我倾向于选择集成度更高的模组，因为独立搭建射频前端对PCB布线和阻抗匹配的要求很高，稍不注意就出现镜像频率干扰，排查起来相当痛苦。
信号进入射频前端后，经过放大、下变频、模数转换，变成数字中频信号，然后交给基带处理。基带部分的核心是相关器阵列，每个相关器负责对某颗卫星的某个频点信号进行捕获和跟踪。并发定位要求相关器数量足够多，也就是前面说的184通道、1400+通道这些参数。通道数不够的话，就算射频端收下了信号，基带也没法同时处理，并发也就无从谈起。
3.2 基带调度与时钟同步：并发架构的隐形战场
大多数人不关心基带调度器的实现，但这恰恰是并发平台能否真正"并发"的关键。接收机基带芯片内部，每个通道独立跟踪一个卫星信号，但通道之间的调度、卫星信号的锁定状态切换、以及观测值的生成时间戳对齐，都需要统一的时钟基准和调度策略。
GNSS系统的时间基准各不相同：GPS使用GPST，GLONASS使用GLONASST，Galileo使用GST，BDS使用BDT。接收机必须先把各个系统的时间统一换算到同一个时间框架（通常是GPST或者接收机本地时间），才能把不同系统的观测值放到同一个定位方程里解算。时间基准没对齐的话，误差会以光速传播，1微秒的时间偏差就是300米的位置误差，这种量级的错误一眼就能看出来。
在我实测过程中，ZED-F9P这类专业模组已经把时间同步做在了芯片内部，用户不需要手动处理。但如果用软件接收机方案自研，时间同步就是必须仔细处理的模块。我的建议是，刚起步的项目不要碰软件接收机。先用手持模组把并发定位的应用逻辑跑通，再考虑底层的时钟同步问题，这样能把风险控制在一个可控范围内。
3.3 观测值质量检查与定位解算：并发之后的数据怎么融合
多系统并发跟踪的卫星数一旦超过20颗，定位解算策略就需要调整。最简单的位置解算方式是加权最小二乘，把所有卫星的伪距观测值放到一起，根据卫星仰角和信噪比分配权重，解算出位置和接收机钟差。由于不同系统间存在系统间偏差（ISB），解算时每个系统还需要额外估计一个钟差参数，这会让方程组的未知数增多。
我用的RTKLIB在处理多系统融合时，默认会给每个星座分配一个独立的接收机钟差参数，这是最稳妥的做法，因为不同系统之间的时间偏差不像理论上那样是固定值，它随温度和硬件状态会有缓慢漂移。如果为了减少未知数而强制共用同一个钟差，必须实时估计系统间偏差，不然定位结果在高动态场景下会出现间歇性跳变。
此外，并发解算还面临一个浮点运算量和实时性的矛盾。卫星数越多，矩阵维度越大，解算耗时越长。对每秒10 Hz甚至20 Hz的定位输出要求来说，解算必须在几十毫秒内完成。好在现在的ARM处理器性能足够强，我在树莓派上跑RTKLIB，四系统并发25颗星的RTK解算，单次解算耗时大约8毫秒，完全够用。
3.4 天线选型：并发平台最容易翻车的环节
很多人把注意力放在接收机模组上，对天线不太上心，这是并发定位项目里最常见的错误。多系统并发意味着天线必须能同时接收L1、L2、L5频段的信号，如果天线只支持单频段，模组再怎么并发也是白搭。
市面上常见的多频有源天线，比如测量级天线常见的"三频"设计，能覆盖GPS L1/L2/L5、GLONASS G1/G2/G3、Galileo E1/E5a/E5b、BDS B1/B2/B3，增益一般在40 dB左右，噪声系数在2 dB以内。这类天线适合固定站、车载和测绘场景。手持设备上用的贴片陶瓷天线虽然体积小、价格便宜，但通常是单频或双频设计，多系统并发时会损失大量L5频段的信号，不建议在需要高可靠性的项目里用。
有源天线的供电问题也要注意。模组通过RF线缆给天线馈电，电压通常是3.3 V或者5 V，电流在10到50 mA之间。如果RF线缆过长或者线损太大，天线上得到的电压不足，内部的LNA就会停止工作，接收机表现为"能搜到星但信号极弱，定位成功率低"。我踩过一次这个坑：用10米长的RG174线缆连接外置天线，结果定位时卫星数只有正常情况的三分之一。后来换成了RG58线缆，并在模组端把天线供电电压调到5 V，问题立即消失。所以，天线选型一定不能拍脑袋，要把线缆损耗、供电能力、安装环境放在一起算。
4. 实操记录：从零搭一个四系统并发定位平台
4.1 硬件准备与连接：5分钟变成一套完整定位终端
我用的硬件清单如下：
- u-blox ZED-F9P模组（RTK高精度版）或者NEO-M9N（导航级），两者都支持四系统并发，区别是F9P支持载波相位和RTK
- 多频有源天线（我用的是陶特信TAU-1000，支持GPS/GLONASS/Galileo/BDS全频段）
- USB转串口模块（FT232或者CP2102均可）
- 树莓派4B（作为上位机运行解算软件）
- 5 V供电线和RF线缆
连接方式很简单：天线通过SMA接口接到模组的RF_IN引脚，模组的UART1通过USB转串口接到树莓派USB口。如果使用的模组直接带USB接口（比如ZED-F9P的USB口），可以省掉USB转串口模块，直接连电脑或者树莓派。上电后用串口工具检查输出，如果能看到NMEA语句，说明硬件链路已经通了。
我建议第一次调试时先拿到开阔的楼顶或者操场去测，不要在室内或者窗边，因为多系统并发定位对卫星信号的依赖非常强，室内环境连单系统都难定位，更别说验证并发了。
4.2 参数配置：开启四星座并发和原始观测值输出
ZED-F9P模组默认只输出NMEA协议，定位模式和星座选择也需要先通过U-Center软件配置。U-Center是u-blox官方提供的上位机软件，连接模组后进入Configuration视图，重点设置以下参数：
- PRT（端口配置）：把UART1波特率设为460800或者更高，因为四系统并发后观测数据量很大，19200波特率根本传不完
- GNSS配置：在GNSS页面勾选GPS、GLONASS、Galileo、BDS，并确认每个星座的启用状态是1（enable）而不是0
- RATE（定位频率）：根据应用需求设成1 Hz、5 Hz或者10 Hz。并发解算建议从5 Hz开始测试，10 Hz对接收机硬件和上位机的处理能力要求更高
- UBX-OUT配置：建议输出UBX-NAV-PVT、UBX-NAV-SAT、UBX-RXM-RAWX这几类消息。UBX-NAV-SAT能看到当前参与解算的卫星列表和信噪比，UBX-RXM-RAWX是原始观测值，做RTK或者PPP后处理必需
配置完成后保存到模组的flash，重启后模组就会按配置输出数据。
4.3 上位机解算验证：用RTKLIB确认并发是否生效
我用RTKLIB的STRSVR接收串口数据流，RTKNAVI做实时解算和显示。真正验证并发定位是否生效，有三个信号特征可以作为判断依据：
第一，可见卫星数。在开阔环境下，并发平台应该同时看到30颗以上的卫星。如果只看到10颗左右，说明某些星座没有启用，或者天线不支持相应频段。这个现象在RTKLIB的skyplot窗口里一目了然，四星座的卫星会在天空图上按轨道分布画出四组明显的卫星轨迹。
第二，参与解算的卫星数和PDOP值。ZED-F9P的UBX-NAV-SAT消息里会直接给出每颗卫星是否参与解算（flags.svUsed字段）。如果配置正确，参与解算的卫星通常达到20颗以上，PDOP值在1.0到2.0之间。如果PDOP大于5，说明卫星几何分布很差，移动下位置或者换更开阔的场地再试。
第三，定位结果的稳定性。在静置状态下，并发平台的定位点抖动应该在1米以内（码伪距解算）甚至厘米级（RTK模式下）。如果定位点以米级幅度漂移，大概率是某些卫星的信噪比太低，或者天线安装位置有问题。
4.4 实测对比：单系统与三系统并发到底差多少
我挑了一个典型的半遮挡场景来做对比实验：一条南北向道路，东侧有连续的高层建筑，西侧是空地，模拟城市峡谷的卫星信号遮挡环境。
先关闭模组的GPS以外的所有星座，只开GPS。测试结果惨不忍睹：可见卫星数在4到8颗之间波动，HDOP经常大于5，定位轨迹有明显的锯齿状跳变，每隔30秒左右就会出现一次位置跳变超过10米的情况，这种输出在车辆导航上是不可用的。
随后开启GPS+GLONASS+Galileo三系统并发，同样的测试路线，可见卫星数升到18到22颗，HDOP稳定在1.5到2.2之间，定位轨迹平滑了很多，锯齿跳变基本消失，偶尔还有小幅度漂移，但整体可用性大幅提升。
最后开启BDS，实现四系统并发，可见卫星数稳定在28颗以上，HDOP降到1.0到1.5，定位轨迹几乎没有跳变，静置状态下定位点离散度明显小于三系统模式。在靠近高楼的区域，四系统模式的定位结果依然可用，而单GPS模式已经完全无法锁定位置。
这个实验直接验证了一个结论：多系统并发不是锦上添花，而是遮挡环境下能否定位的分水岭。做车载导航或者城市巡检项目时，不要纠结单系统精度高还是多系统精度高的问题，直接上并发方案，省得后面反复改版。
5. 常见问题与排查技巧实录
5.1 卫星数上不去或者一直搜不到某个星座
这种情况最常见的原因有三个：一是模组的卫星星座配置里没有启用该星座，去U-Center的GNSS配置页检查；二是天线频段不支持该星座的信号，换成多频全星座天线；三是当前环境的遮挡太严重，该星座的卫星恰好全部在地平线以下。如果是第三个原因，可以把接收机搬到开阔环境验证，不要在室内纠结。
另外一个隐藏原因在ZED-F9P这类模组上比较常见：如果同时开启了太多星座，但基带通道数分配不合理，部分星座分配的通道数过少，在信号质量稍差的时候会出现无法捕获或失锁。解决办法是把通道数分配给重点星座，以及调整信号捕获的信噪比阈值。在U-Center的Advanced Configuration里可以逐星座调整通道分配参数，但这个操作对大部分用户来说太底层，建议默认配置就行，除非你有明确的调试需求。
5.2 定位结果在并发模式下反而变差
有时候开启多系统后，定位结果还不如单系统稳定。我遇到过这种情况，排查下来是系统间偏差在作祟。RTKLIB默认对每个星座独立估计接收机钟差，这能有效处理ISB问题。但如果用的是某些简化版的解算库，它们把所有系统的卫星放在一起解算，却只估计一个接收机钟差，不同系统之间的时间偏差就会被映射到定位残差里，导致定位结果出现系统性偏移。
处理办法有两个：一个是改用支持多钟差估计的解算软件；另一个是只使用同一个系统的时间基准做解算，其它系统的观测值先做时间同步偏差修正再加入方程。后者实现难度更高，不建议从零自己实现，优先用成熟的RTKLIB和商业SDK。
5.3 并发模式下CPU负载过高，实时性保不住
卫星数量从10颗翻倍到30颗，最小二乘矩阵的维度也翻倍，解算耗时成倍增长。如果还开着RTK解算和写日志，嵌入式设备很容易出现处理不过来、定位频率下降的问题。
我做压力测试时遇到的情况是：ZED-F9P输出10 Hz并发数据，树莓派4B上RTKLIB的CPU占用达到80%左右，偶发丢包。解决办法包括：把定位频率降到5 Hz；关闭不必要的日志记录；在RTKLIB里启用RTCM3输出而不是同时输出多种格式；用更高效的数据结构减小接收机状态更新的开销。如果是MCU级别的平台，建议把定位解算放到Linux主机上做，MCU只负责信号采集和转发，否则很难同时满足并发和高频率输出。
5.4 多系统并发下的时间基准问题
GNSS授时是很多项目的核心场景。多系统并发时，接收机输出的时间标签（time tag）是基于GPST还是本地时间的，直接决定了后续的数据融合精度。我在做多传感器融合时发现，把GNSS时间戳和IMU时间戳对齐，必须在采用并发定位模式后重新做一次时间同步校准，因为多系统并发的观测数据量增大后，串口传输延迟和系统处理延迟都会变化，原来单系统时测得的固定延迟值不再适用。
实践中的做法是：通过PPS（秒脉冲）信号和GNSS的UTC时间输出做硬件级时间同步，配合软时间戳校准，把时间误差控制在毫秒级以内。如果项目对时间同步精度要求到达微秒级，需要用支持PPS输出的接收机和具有硬件时间戳捕获功能的处理器，这属于时间同步系统的范畴，这里提一句提醒大家注意即可。
5.5 常见问题速查表
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 卫星数始终不超过10颗 | 星座未启用或天线不支持 | 检查GNSS配置和天线频段 |
| 某星座一直无信号 | 遮挡严重或通道分配不足 | 去开阔环境复测 |
| 并发后定位反而漂移 | 系统间偏差未正确处理 | 改用多钟差解算 |
| CPU占用过高、定位频率下降 | 数据量过大或处理能力不足 | 降低频率、精简输出 |
| 定位中断频繁 | 遮挡严重但并发数仍不足 | 加天线增益或更换安装位置 |
| 天线已接但信号极弱 | 馈线损耗大或供电不足 | 换低损耗线缆、提高馈电电压 |
6. 应用场景延展：并发定位可以往哪些方向落地
6.1 城市峡谷环境下的车载导航与自动驾驶
城市道路两侧高楼遮挡是GNSS定位最常见的挑战。单系统GPS在城市峡谷里的可用率通常只有60%到80%，根本无法作为自动驾驶的可靠定位输入。多系统并发配合IMU和轮速计做组合导航，可以把可用率提升到99%以上，这是L2+级辅助驾驶和自动泊车方案里的常见架构。这个项目里的并发平台可以直接作为组合导航系统的GNSS数据源，输出原始观测值给融合算法使用。
6.2 无人机巡检与精准农业
无人机在山区、峡谷和树林边作业时，卫星遮挡和信号多路径效应是定位误差的主要来源。多系统并发能显著提高固定翼和多旋翼在复杂地形下的定位稳定性，配合RTK甚至可以实现厘米级航线精度。精准农业的拖拉机导航和变量作业也依赖高可靠定位，大片开阔农田场景下并发平台的性能优势不明显，但在林缘、果园这类半遮挡场景下，多系统并发能明显减少定位跳变导致的作业重叠或漏行。
6.3 测绘与工程测量
测绘级应用对定位精度要求极高，必须使用载波相位观测值。并发平台的原始观测数据（UBX-RXM-RAWX）经过PPK或者RTK解算后，可以在城市环境下实现厘米级精度。传统单频接收机在楼宇间经常出现整周模糊度无法固定的问题，多系统并发让参与解算的卫星和频率组合大幅增加，模糊度固定成功率显著提升。我测试过，在建筑密集区域，单系统RTK的固定率可能只有50%，四系统并发RTK的固定率可以达到95%以上。
6.4 时间同步与科研应用
GNSS本身是免费的高精度授时源。多系统并发授时最大的优势是冗余性，某一个系统的卫星出现问题后，其它系统可以无缝接管，保证时间输出不中断。科研项目中，多系统并发GNSS接收机也经常作为水汽探测、电离层监测等研究的数据源，提供更密集的观测数据。
7. 写在最后的几点体会
做这个项目最深的感受是：并发定位的技术难点并不在定位算法本身，而是在"信号链路的完整性"和"数据链路的稳定性"这两个容易被忽略的环节。天线选型、馈线损耗、供电电压、输出协议格式、时间基准对齐，每一环都是系统工程的一部分，任何一环掉链子，最终定位结果都会以一种难以排查的方式恶化。
另外，多系统并发带来的数据量膨胀是很多从单系统切换过来的人没有心理准备的。从串口波特率到上位机处理能力，都要预留足够的余量。我用默认的38400波特率跑过一次四系统数据流，结果输出被截断，定位结果完全不可用，排查了半天才发现是波特率不够。这类基础配置问题，最容易浪费大量调试时间。
最后一个建议是：验证并发定位效果时，一定要选一个有真实遮挡的环境测试，而不是在开阔操场。开阔环境下单系统和多系统的差异可能只有20%，但在城市峡谷这种极端场景下，差异是"能不能用"级别的。真实环境的测试数据，才能支撑你在方案评审或者论文写作中拿出有说服力的对比结论。
如果你正打算把定位方案从单系统升级到多系统并发，或者想在高遮挡环境下提高定位可靠性，这套平台搭起来之后，会对GNSS的"并发"有一个非常直观的认知。拿着数据回头再看上面的技术点，很多概念会清晰很多。
 配置速查)
