大软件编码及动态库静态库理解
一、 大软件解码、编码接口部分
卫星发射的信号有载波、测距码和导航电文三部分组成。测距码和导航电文信息调制在高频的载波上,将其播发出去。接收机接收到发射下来的信号,不同的接收机板卡根据不同的规则将这些有用信息排列成一定的数据格式,如RT27格式、RTCM格式等,这些信息是以一系列由“0”和“1”组成的二进制数据组成, 通过格式文档可将该段电文解析出时间信息,观测值信息等。
- 解码模块为何使用静态链接库?
EarthNet 3.0中BaseStation从数据库中读取基站数据,通过静态链接库送入解码模块。静态链接库可以使进程可以调用不属于其得可执行代码的函数,使用静态链接库可以使解码部分得更新更容易的应用于各个模块,而不会影响该程序的其他部分,但是静态链接库文件自身是不可执行的二进制文件,所以每次在解码部分有更改是,解码人员不能自行测试,需要将其更新到大软件中,有大软件的测试结果来验证解码的正确有否,编码情形类似。
此外,在解码处有更改后只要重新编译解码相关代码,将生成的Decoderd.lib替换至EarthNet_BaseStation->lib->Debug下原来的Decoderd.lib,在将EarthNet_BaseStation重新编译一下即可。
- 在何处调用解码模块?
主要函数调用过程如下:
Start()->RecvDataThread->RecvData()->Decoder((unsigned char*)szBuff,iRet);此函数将数据转发给数据总线,送入解码模块
在解码模块中,调用解码动态连接库,通过调用入口函数
m_pDecoder->parse(szData[i],m_pBaseStation->m_iStationType,&pData,datatype)
其中szData[i]为待解析的数据流,m_iStationType为选择的基站类型,pdata为输出指针,datatype为输出数据类型。
- 如何更换Decoderd.lib?
在修改解码模块后,生成的Decoderd.lib,拷贝至大软件basestation中debug下,重新运行即可。如果解码部分和basestation(即为BS)部分公用的头文件,如myheader.h,需保证头文件一致。此时需要注意BS下对该头文件的使用是否受到影响。保证头文件一致是重点!
- 编码部分说明
(1) 动态链接库,替换debug下CoEncode.dll和CoEncode.lib,两者同时生成,其实只要替换前者即可。将其替换至debug下,动态保证接口一致!
二、其他信息
- 解码接口部分及支持的解码数据类型
在DecodeInterface.h中定义了类DecodeInterface,如下
class __declspec(dllexport) DecodeInterface
{
private:
CRTCM31_Decoder m_rtcm31; //目前支持一下几种数据类型, CRTCM23_Decoder m_rtcm23; //如有新类型,再此添加
CRTCM32_Decoder m_rtcm32;
CNavComParser m_navcomparser;
COEM4 m_oem4;
CBinex m_binex;
CSouth_Decoder south;
private:
int GLO_FreQuence[26];
public:
int parse(unsigned char v_c, int v_StationType,IData** v_pData, eDataType& v_iResult);
};
成员函数DecodeInterface::parse(unsigned char v_c, int v_StationType,IData** v_pData, eDataType& v_iResult)
v_StationType |
数据格式 |
备注 |
-1 |
Navcom |
未知 |
0 |
RTCM2.3 |
|
1 |
OEM4 |
包括UB380、K508板卡,有观测值及导航电文 |
2 |
RTCM31 |
只添加观测值,导航数据部分被注释,可恢复 |
3 |
Binex |
|
4 |
RTCM31+OEM4 |
RTCM观测值+OEM4导航数据 |
5 |
RTCM31+RT27 |
RTCM观测值+RT27导航数据 |
7 |
South |
观测电文及导航电文 |
8 |
RTCM32+RT27 |
RTCM提供观测值,使用RT27的导航电文 |
9 |
RTCM32+ OEM4 |
RTCM提供观测值,使用OEM4的导航电文 |
10 |
RTCM32+RTCM31 |
32格式提供观测值(MSM4),31格式提供导航电文(1019,1020,1047北斗自定义导航电文) |
其中,szData[i]为数据流,
m_iStationType为基站类型,目前大软件定义的基站类型对应的数据格式如下:
eDataType为数据类型,
E_NONE = 0, //无类型 0
E_FORVRS, //基站VRS数据 1
E_NAVDATA,//导航数据 2
E_GLONAV,//Glo导航数据 3
IData是个纯虚数据接口,在basestation下被DataForVRS继承,变成一些观测值的结构体。
通常,组合不同格式的电文发送是因为单一格式的电文无法同时提供观测电文及导航电文,如RTCM32格式只能出观测电文的MSM信息,故配合RT27电文发送,从而获取导航信息。
- 编码部分挂载点信息:
挂载点 |
具体信息 |
备注 |
|
SRTK or RTCM1819 |
18,19观测值伪距载波差分改正数 |
18,19,03号电文 |
|
RTCM0103 or SRTD |
RTCM2.3中1,3 |
1:GPS伪距改正;3:GPS参考站参数 |
|
RTCM31 |
1004,1012,1013,1006,1008 |
1:GPS+GLONASS 2:单GPS |
|
RTCM31-CGR |
1004,1012,1104 1013,1006,1008 |
BD+GPS+GLONASS系统顺序不同 |
|
RTCM-GRC |
1004,1012,1104 1013,1006,1008 |
GRC三系统 |
|
RTCM31-CG || SRTK-CG |
1104,1004 1013,1006,1008 |
CG双系统 |
|
RTCM31-test |
1104,1004 1005 |
CG双系统 |
|
RTCM-GC |
1104,1004 1013,1006,1008,1033 |
支持GC双系统或者C单系统 |
|
RTCM32 |
MSM7:1077,1087,1127 1013,1006,1005,1008 |
三系统 |
|
RTCM32-GC |
1077,1127 1013,1006,1005,1008 |
GC双系统 |
|
RTCM-1819||RTCM32-G |
|
单G |
RTCM-1819是假挂载点,应及时去掉 |
RTCM32-C |
|
单C |
|
RTCM32-4 |
MSM4:1074,1124 |
G+C |
54所测试需求 |
RTCM32-4G |
1074 |
单G |
54所测试需求 |
RTCM32-4C |
1124 |
单C |
54所测试需求 |
- 各系统时间之间的转换
在2015年6月底跳秒变为17s.
2017年12月31号变为18s.
三、 不同格式电文简介
事后解码软件分为2版,一种是朱静然及之前的几位师姐编写及维护的解码软件(简称朱版),其中采用大量的移位和取位操作,以及对int和uint的取值,代码量大,不易理解且易出错,但是解码内容基本不会出错,不包括一直未解决的小问题,不影响使用,但是要注意,不同格式的数据文档有更新,可能用此版软件解不出数据。这时需要及时维护。
另外一版是丁艺伟在朱版的基础上,将部分格式移植过来,主要有2点改进。第一点,用getbitu及getbits读取数据,简化了代码量,易于后面理解;第二点,将不同频段上的码上观测值加以区别,完善了RINEX3.02版输出。另外还添加了RT27的GALILEO观测值解析、将RTCM 3.2格式与RTCM 3.1格式的代码集成等。
1、 RTCM V2.3格式
2、 RTCMV3.1
仅支持单GPS、单GLONASS或者GPS/GLONASS混合系统等差分信息。
RTK消息类型:
观测值 |
GPS L1 |
1001、1002 |
|
|
GPS L1/L2 |
1003、1004 |
|
|
GLONASS L1 |
1009、1010 |
|
|
GLONASS L1/L2 |
1011、1012 |
|
基站坐标 |
|
1005、1006 |
|
天线描述 |
|
1007、1008 |
|
接收机和天线描述 |
|
1033 |
|
网络RTK改正数 |
网络辅站数据 |
1014 |
|
GPS电离层差分改正 |
1015 |
|
|
GPS几何差分改正数 |
1016 |
|
|
组合的GPS电离层与几何差分改正 |
1017 |
|
|
GPS网络RTK残差 |
1030 |
|
|
GLONASS网络RTK残差 |
1034 |
|
|
···详见数据格式 |
|
|
|
辅助操作信息 |
系统参数 |
1013 |
|
|
GPS卫星星历 |
1019 |
GPS星历 |
|
GLONASS星历 |
1020 |
|
2.2为移动站和参考站提供服务的消息组请参考RTCM v3.1格式 Table 3.1-2。
1004、1012只有C/A和P码,不支持三频。
1104有B1B2双频或B1B2B3三频。
该格式尚不支持RINEX3.02输出,在解到的观测值,没有赋值C1C/L1C,C1W/L1W等值。后续若需要,该格式解码部分需添加该类值。
L1上的P码不常见,故P1暂时不写入RINEX2.0格式的输出,P1这里代表C1P。
3、 RTCM V3.2
RTCM V3.2格式新增加的多系统消息(Multiple signal messages,简称MSM)旨在以统一的形式生成GNSS接收机观测值以应对越来越多的GNSS系统和信号。其取代原RTCM V3.1的观测消息(1001—1004,1009—1012),以统一的格式传输尽量多的基本信息,包括新的信号和GNSS系统。其中各系统对应的电文号如下表:
系统 |
消息号 |
GPS |
1071~1077(MSM1~MSM7) |
GLONASS |
1081~1087(MSM1~MSM7) |
BDS |
1121~1127(MSM1~MSM7) |
基站出的原始数据为GPS/GLONASS/BDS的MSM4(1074、1084和1124电文)信息。GPS和BDS采用码分多址的方式,载波频率是相同的,
GPS:
L1=1575.42 MHZ
L2=1227.60 MHZ
L5=1176.45 MHz
BDS:
B1=1561.098 MHz
B2=1207.14 MHz
B3=1268.52 MHz
由于GLONASS采用频分多址方式,每颗卫星播发的两种频率L1和L2的计算公式为:
L1=1,602+0.5625*K (MHZ)
L2=1,246+0.4375*K (MHZ)
其中,K为每颗卫星的频率编号,范围为-7~13。一般在电文中该值为加7后的值,范围(0~20),所以在解到该值后带入公式需减7.
在事后软件中,单解MSM4得GLONASS,要输入正确的glo_num值,否则载波值解不对。
在MSM4中不含有GLONASS系统的频率号,故需配合其他电文来获取该值。
MSM电文头部分含有32位的GNSS信号数据表,每一位的位置对应特定系统相应的信号类型,如GPS系统下,该字段第二位置“1”表示含有L1频段上的C/A码。若L1频段上同时含有C/A及Z-tracking orsimilar 码,优先选择C/A码上的伪距观测值为C1,相位观测值为L1,如无C/A码,则选择Z-tracking orsimilar码上的伪距载波相位观测值作为C1、L1。
目前,该软件中对观测值C1、L1、P2、L2的取值优先级方法如下;
系统 |
常见码(从左到右优先级依次降低) |
|
GPS |
L1:C/A、z-tracking or similar L2:Z-tracking or similar、L2C(M+L) |
|
GLONASS |
G1:C/A、P G2:C/A、P |
|
BDS |
B1:I B2:I B3:I |
目前软件采用双频(B1\B3) |
经论文中提到的,RINEX2.01格式中GPS数据时间均以GPST计,与UTC时差一个整数的跳秒数。
4、 TEQC的使用
GPS观测文件和星历文件必须和TEQC程序放在同一个目录下面。在对GPS观测数据进行质量检查时,TEQC只接受RINEX格式的数据,2.01版本是其期望的版本。
运行teqc +qc+config,可列出质量检查模式下的teqc所有的命令选项及缺省状态。
5、 导航电文
时间系统:
系统 |
GPS |
GLONASS |
GALILEO (GST) |
QZSS (QZS) |
BDS (BDT) |
起始时间 |
1980-1-6 00:00:00 |
|
|
|
2006-1-1 00:00:00 (比GPS起算时间晚1356周) |
Week transmitted |
10 bits |
|
12 bits |
|
13 bits |
计周方式 |
0-1023,翻转 |
|
0-4095,翻转 |
|
0-8191,翻转 |
标记时刻 |
1999-8-22 00:00:00第一次翻转 |
|
GST week start at 1999-8-22 00:00:00 |
|
还未发生翻转 |
跳秒 |
1980-2012年间:16秒 |
|
|
|
|
Week reported in RINEX |
连续周计数 |
|
连续周计数 |
|
连续周计数 |
摘自RINEX3.02版说明中的图,各个翻转时段,对应的各系统的周数:
GSPT,GLONASS,UTC,TAI(国际原子时)时之间的联系:
TAI:一种更可靠、更精确、更权威的,能被世界各国所共同接受的统一的时间系统。现在由国际计量院(BIPM)的时间部门在维持。是一种均匀的时间系统。
稳定性和复现性都很好的原子时能满足高精度时间间隔测量的要求,因此被很多部门所采用,但是在天文导航等地球自转有密切关系的有需要世界时。由于原子时是一种均匀的时间系统,而地球自转存在不断变慢的长期趋势,这就意味着世界时的秒长将变得越来越差,所有原子时和世界时直接的差异越来越明显,后来国际无线电科学协会与20世纪60年代简历了协调时间时UTC时。
UTC时:秒长严格等于原子时的秒长,为在保证UTC时与世界时UT间的时刻规定需保持在0.9s以内,采用闰秒的方法进行调节,增加1s称正闰秒,减少1s成为负闰秒。闰秒一般发生在6月30号及12月31号。
最近一次闰秒发生在2016年12月31号到2017年1月1号,已从17秒跳变到到18秒。
局部UTC系统:由各自实验室内的多台原子钟建立和维护的,共本国或本地区使用。如UTC(USNO)。
GPS时;GPS使用的一种时间系统,室友GPS地面监控系统和GPS卫星中的原子钟建立和维持的一种原子时,起算点1980年1月6日0h00mm00s。GPS开始与UTC对其,但是GPS是连续的,UTC存在跳秒,在GPS起算点时,UTC已经与TAI差19s,
RTCM一般都有钟差修复,所以解到的伪距一样很正常,像OEM格式,就没有修复,解到的伪距相差几万到几十万都很正常
6、 其他信息
天宝BD970 多模GNSS接收机,参考信息输出格式有:CMR,CMR+,RTCM 2.1,2.2,2.3,3.0,3.1
四.编解码程序实现中常见的错误:
在添加CTime时,包含头文件afx.h时,出现了以下错误:
\afx.h(24): fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
解决方法:对着你的项目点击右键,依次选择:属性、配置属性、常规,然后右边有个“项目默认值”,下面有个MFC的使用,选择“在共享 DLL 中使用 MFC”
EXCEL:
1.如何隔行选中数据?
解:(1)在需要选择的一行数据最后,输入 =A?:G? (A,G分别是选取行的开始和结束的范围)
(2)注意上/下空白的行(隔一行,选一行空白;隔两行,选两行空白,看需要),然后选中 =A?:G?的单元格和空白单元格,一直往下拉.
选中这样的一列,Ctrl+g,定位条件,选择引用单元格
这样就可以选中大量部分隔行的数据了。