GNSS时间转换程序设计

i-17

已于 2023-12-11 17:35:22 修改

阅读量1.9k

点赞数 15

分类专栏： GNSS 文章标签： matlab 算法经验分享

于 2023-12-11 13:52:45 首次发布

本文链接：https://blog.csdn.net/m0_58307078/article/details/134887690

版权

GNSS 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

GNSS中常见的时间类型：UTC、GPST、BDST、儒略日、年积日 doy（day of year）

本文主要围绕UTC、GPST、BDST、儒略日之间的相互转换，内容包括程序设计思路、预期功能、算例及结果分析的阐述，以及笔者对编程过程中一些常见问题和注意事项的总结。

代码详见：

https://download.csdn.net/download/m0_58307078/88614986?spm=1001.2014.3001.5503https://download.csdn.net/download/m0_58307078/88614986?spm=1001.2014.3001.5503

1 实验任务及目的

了解常用的时间系统的定义；
掌握UTC时间、GPS时、北斗时三者之间相互转换的方法；
了解并掌握通过儒略日与GPS时、UTC时间之间的转换关系，并将其作为中间桥梁，建立GPS时与UTC时间的相互转换。

2 数据来源及编程测试环境

1．算例数据来源：PPP精密单点定位原理实验平台

2．编程环境：MATLAB 2016a

3．测试环境：MATLAB 2016a及PPP精密单点定位原理实验平台

3 实验内容及成果

3.1 GPS时与UTC的相互转换

3.1.1 GPS时转UTC——gps2utc(t_gps)

1．程序设计

预期功能：将输入参数GPS周和周内秒（week,sec ）转换为UTC时（年月日时分秒）并输出。

设计思路：按UTC与GPS时的换算关系编写函数，程序计算流程及步骤如图3-1所示：

图3-1 GPS时转UTC计算流程示意

2．遇到的问题及解决过程

（1）月份计算较为复杂

问题描述：依次计算年于日时分秒（图3-1中step4）中月份计算较为复杂，各种问题层出不穷：1）起初计算思路不明确；2）月份与分钟同用m字母表示导致后期计算错误；3）没有考虑循环遍历时进行的操作会会覆盖原有正确结果。

解决过程：

1）由于月份天数不同，导致判断月份较为复杂，但特定的月份内含有的天数固定，因此可通过判断累计天数判断月份，即：若为一月，累计天数不超过31天，若为二月，累计天数在区间[32，59]内，以此类推，设置for循环和if条件判断语句即可确定月份；

2）检查代码逻辑错误的过程中即可发现该错误（细小但致命）；

3）排除并修正上述错误后发现依然没有得到正确结果，与其他同学的计算结果比对，定位出错点为月份计算，再次审视月份计算相关代码，发现理论上可以得到正确答案，但由于循环的设置，计算出正确结果后进行下一次循环时的计算结果会覆盖正确结果，因此通过合理使用break语句，在得到正确答案后及时跳出循环，即可保留正确结果。

月份计算代码部分如下图所示：

图3-2 月份计算部分代码截图

（2）有关闰秒调整和GPS周翻转的细节

编写代码时需要注意两个细节：1）闰秒调整要在计算年月日时分秒之前，否则调整后可能会因为进位问题导致结果错误；2）导航电文的GPS周数存储格式导致GPS周数最大为1023，当来到1023周的下一周时，GPS周溢出自动翻转为0周，即：大概每20年发生一次GPS周翻转。目前共发生过两次，第二次也是最近的一次GPS周翻转发生在2019年4月7日0时，因此在原有GPS周的基础上+2048周即为正确的GPS周。

对应代码如图3-3所示：

图3-3 闰秒调整及GPS周翻转代码截图

3．算例结果

GPS时转UTC的算例结果如下表所示：

表3-1 GPS时转UTC算例结果

GPS时	Y	M	D	H	Min	S
[55,321011]	2020	4	29	17	9	53
[43,132253]	2020	2	3	12	43	55
[42,479749]	2020	1	31	13	15	31
[8,301098]	2019	6	5	11	38	0
[37,306588]	2019	12	25	13	9	30

4．用儒略日计算

上述GPS时转UTC的算法转换较为复杂，后期发现用儒略日转换更为简单。

算法流程如下图所示：

图3-4 儒略日计算GPS时转UTC流程示意

遇到的问题：日的计算公式中FRAC小数部分计算错误导致没有及时发现该小数部分对应以天为单位的时分秒。

解决方法：通过在程序中合适的位置添加断点，分步排除错误，找出错因。最终发现问题出在FRAC小数部分的计算：编程时打错了一个符号，非常致命的细节错误。

具体实现代码截图见图3-5：

图3-5 儒略日计算GPS时转UTC对应代码截图

3.1.2 UTC转GPS时——utc2gps(t_utc)

1．程序设计

预期功能：将输入参数UTC时（年月日时分秒）转换为GPS周和周内秒（week,sec ）并输出。

设计思路：按UTC与GPS时的换算关系编写函数，程序计算流程及步骤如图3-6所示：

图3-6 UTC转GPS时计算流程示意

2．遇到的问题及解决过程

问题描述：对儒略日转GPS时的原理理解不透彻导致编程效率低下。

解决过程：查阅资料+仔细思考，转换时的几点主要理解如下：

计算GPS周时，由于GPS时的起算时间为1980年1月6日（区分起始时间：1980.1.1），此时的儒略日为2444244.5，因此需要将UTC转换成的儒略日减去2444244.5（如图3-7中第一行代码）；
由于前面的转换都是基于UTC进行的，因此需要对转换后的GPS周内秒进行闰秒调整并进行进位判断（图3-7第三行至最后的代码）。

图3-7 儒略日转GPS时代码截图

3．算例结果

UTC转GPS时的一些算例结果如下表所示：

表3-2 UTC转GPS时算例结果

Y	M	D	H	Min	S	GPS时
2019	12	25	13	9	30	9周 177044.00秒
2021	6	30	2	51	26	116周 269504.00秒
2021	10	10	0	29	58	131周 1816.00秒
2019	6	16	20	1	51	10周 72129.00秒
2020	1	12	20	38	9	40周 74307.00秒

3.2 北斗时与UTC的相互转换

1．程序设计

预期功能：基于输入的时间参数，转换为指定时间类型。值得注意的是，输入输出形式均为年月日时分秒。

设计思路：UTC与北斗时之间只相差4秒，即：BDT=UTC+4。如果直接按照两者之间的转换关系编写函数，则需要多次判断进、退位，且日、月之间的进退位情况多种多样，整个算法要逻辑严密、情况复杂，不易编写。基于上述分析，我们可以基于UTC与GPS时两者之间的转换函数进行间接转换：先利用utc2gps(),将UTC与北斗时转换为周和周内秒，通过适当的闰秒调整后，再利用gps2utc()将其转换为年月日时分秒的形式输出。

程序计算流程及步骤如图3-8所示：