RTKLIB专题学习(十三)—信号ID与观测类型在精密定位中的优先级优化策略

1. 信号ID与观测类型：精密定位的“食材”与“菜谱”

搞RTK精密定位，尤其是用RTKLIB，你肯定遇到过这种情况：明明数据收得好好的，卫星数也够，可解算出来的坐标就是飘，固定率死活上不去。我以前也总被这个问题困扰，后来花了很长时间才琢磨明白，很多时候问题不是出在算法本身，而是出在“源头”——RTKLIB到底用了哪些卫星信号来算？它更“偏爱”哪种信号？这就像做一道菜，食材（信号）选得不对，或者处理食材的优先级（菜谱）有问题，再好的厨师（算法）也做不出美味佳肴。

这里说的“食材”，就是信号ID和观测类型。信号ID，比如GPS的L1C/A、L2P，北斗的B1I、B2I、B3I，伽利略的E1B、E5a，它指明了你接收到的具体是哪个频率、哪种调制方式的无线电波。而观测类型，主要就是四大类：伪距（C）、载波相位（L）、多普勒（D）和信噪比（S）。伪距好比是粗略的尺子，能快速知道大概距离；载波相位则是高精度的游标卡尺，虽然存在整周模糊度这个“起点”未知的问题，但一旦确定，精度极高，是厘米级定位的基石。

RTKLIB在读取RINEX或实时数据流时，面对一个卫星的多个频率信号（比如北斗三频C2I, C7I, C6I），它不会一股脑全用上。它会根据一套内置的默认优先级，像点菜一样，从菜单里挑出它认为“最好”的那一道。这套默认规则，就是上一篇文章里提到的那个优先级表格。比如对于北斗，在单频模式下，它会优先使用C2I（对应B1I）信号；在双频模式下，则优先组合C2I和C7I（B1I和B2I）。这个默认设置对大多数通用场景是合理的，但它绝非金科玉律。

为什么优先级这么重要？我打个比方：假设你在一个嘈杂的菜市场（复杂电磁环境），想听清一个朋友说话。他可能同时用正常音量、大声喊和用喇叭三种方式（三种信号）叫你。默认优先级就像让你只听“正常音量”。但如果现场“正常音量”的通道干扰很大，而“喇叭”通道反而更清晰，你还固执地只听“正常音量”，那肯定听不清。定位同理，在某些特定场景下（城市峡谷、树下、存在多径干扰），默认的最高优先级信号质量可能并不是最好的。盲目遵循默认设置，就等于放弃了其他可能更优质的观测数据，定位精度和固定成功率自然大打折扣。

所以，信号ID与观测类型的优先级优化，其核心思想就是从“被动接受默认菜单”转变为“主动定制最佳食谱”。我们需要根据实际的数据质量、定位场景和接收机特性，告诉RTKLIB：“嘿，今天这道‘精密定位’的菜，我们不用默认的C2I做主料了，试试用C6I，可能更香。” 这就是本篇文章要深入探讨的策略。

2. 深入源码：优先级是如何被决定的？

要优化，先得知道机制是怎么运行的。我们不能当黑盒用户，得打开RTKLIB的“厨房”看看。从上一篇文章的源码追踪中，我们已经看到了数据读取的完整链条：readobsnav -> readrnxt -> readrnxfile/readrnxfp -> readrnxh & readrnxobs。其中，决定信号选择的关键函数是 set_index 和 decode_obsdata。

2.1 set_index函数：优先级表的加载与赋值

在 readrnxobsb 函数中，会为每个导航系统（GPS、北斗、伽利略等）调用 set_index 函数。这个函数干了几件关键事：

1. 建立信号索引表：根据RINEX文件头中的观测类型标识（tobs，如 “C1C”, “L2W”），将其转换为RTKLIB内部使用的信号代码(code)和类型(type)。
2. 获取优先级：核心的一步，调用 getcodepri(sys, ind->code[i], opt)。这个函数会查询内部优先级表，返回该信号在当前系统下的默认优先级数值。数值越大，优先级越高。
3. 处理用户选项：解析输入选项 opt 字符串（就是我们在RTKCONV或RTKNAVI中输入的-GL1C -CL2I这类命令），如果用户指定了某个信号及其相位偏移，会