RTKLIB专题学习(十三)—关于RTKLIB的PPP模式不能有效解算北斗数据原因的探索(一)
RTKLIB专题学习(十三)—关于RTKLIB不能有效解算北斗数据的探索(一)
文章目录
- 系统使用发现问题
-
- 精密星历读取
- 信号类型选取
系统使用发现问题
从上图的调试结果可以看到，当处理北斗数据时(sat=106是对应的北斗)，其计算的接收机到卫星的距离为-1；也就是计算出错，原因是，在geodist函数中，当卫星距离地心的距离小于地球半长轴时，返回值-1。
/* geometric distance ----------------------------------------------------------
* compute geometric distance and receiver-to-satellite unit vector
* args : double *rs I satellilte position (ecef at transmission) (m)
* double *rr I receiver position (ecef at reception) (m)
* double *e O line-of-sight vector (ecef)
* return : geometric distance (m) (0>:error/no satellite position)
* notes : distance includes sagnac effect correction
*-----------------------------------------------------------------------------*/
extern double geodist(const double *rs, const double *rr, double *e)
{
double r;
int i;
if (norm(rs,3)<RE_WGS84) return -1.0;
for (i=0;i<3;i++) e[i]=rs[i]-rr[i];
r=norm(e,3);
for (i=0;i<3;i++) e[i]/=r;
return r+OMGE*(rs[0]*rr[1]-rs[1]*rr[0])/CLIGHT;
}
在这里调试到rs的时候，看到rs为0，因此，应该是卫星位置出现问题，而考虑到卫星位置可能和广播以及精密星历的读取有关，因此要进一步分析这两个可能性。
精密星历读取
这里有一点乌龙了，由于igs的最终星历里面没有北斗卫星的数据，导致了卫星位置计算参数的缺失，所以才引发了上述结果！
使用武汉大学的精密星历数据，就能解算北斗数据了！因为此时可以得到必要的卫星位置信息了
信号类型选取
但此时还是有问题，由于RTKLIB默认使用L1+L2进行无电离层组合并且进行定位解算，但是在观测值文件里，每一历元平均只有五颗有效卫星，也就是只有少数卫星同时存在2I和7I对应的观测值，所以，在剔除有异常的观测数据后，该历元的有效卫星数可能就小于4，这样该历元就无法解算(要想计算出接收机位置，必须同时观测四颗卫星以上)
因此我打算利用2I+6I对应观测值进行解算，目前在调试代码，可以看到，修改对应的频率位置如上图所示；但是实际上这样修改也并没有实际作用，根本还是要修改RTKLIB对于解算北斗时的信号类型的选取：
static char *obscodes[]={ /* observation code strings */
"" ,"1C","1P","1W","1Y", "1M","1N","1S","1L","1E", /* 0- 9 */
"1A","1B","1X","1Z","2C", "2D","2S","2L","2X","2P", /* 10-19 */
"2W","2Y","2M","2N","5I", "5Q","5X","7I","7Q","7X", /* 20-29 */
"6A","6B","6C","6X","6Z", "6S","6L","8L","8Q","8X", /* 30-39 */
"2I","2Q","6I","6Q","3I", "3Q","3X","1I","1Q","5A", /* 40-49 */
"5B","5C","9A","9B","9C", "9X","1D","5D","5P","5Z", /* 50-59 */
"6E","7D","7P","7Z","8D", "8P","4A","4B","4X","" /* 60-69 */
};
观测码字符串如上所示，可以知道，在修改代码时，要能指定北斗数据使用哪种信号类型的观测值，这是一个重要思路，接下来会继续往下摸索的。