多传感器融合时的时间同步问题解决方案——PPS校准STM32内部RTC

      关于STM32的RTC校准问题，网上讨论很多。个人认为可以分为外部校准和内部校准，外部校准一般采用的是GPS的PPS信号（主要是PPS信号基于原子钟，太准了），但是PPS信号如何对RTC进行校准，网上并没有相关的一些校准流程。结合查阅的一些论文，我设计了两套PPS校准流程以及源码，都是基于STM32的，源代码较为简单，希望各位大佬不要嘲笑。这些将会在下一章进行介绍。在进行校准之前，我们首先需要知道GPS的PPS信号和GPRMC信号之间的关系，PPS是脉冲信号，GPRMC是世界时间，两个信号会相继传给STM32。那么这两个信号差多久呢？这里需要我们拿示波器测一下。一般应该是PPS早于GPRMC信号几十毫秒。下图是示波器波形

   
       

      GPS传感器最出色的功能除了有基于原子钟的精准时钟源PPS信号外，还拥有包含了网络时间的GPRMC信号，在校准RTC之前，对GPRMC时间信号的解析也变得尤为重要，对于GPRMC的解析网上有很多参考例程。GPRMC信号通过232芯片转换成TTL信号之后在电脑上的显示就是一行字符串，因为只需要提取年月日时分秒即可，所以我在最开始的时候打算偷个懒，直接从字符串数组中按索引依次提取时分秒，年月日的值，再通过计算转换成北京时间。然后就操蛋了，时分秒一直没有问题，到了年月日，一会儿是25年，一会儿是21年，一会儿是12月一会儿是24月。这个小bug我排查了三天，先是怀疑GPS发出的GPRMC有问题（可能是没有看到向往的蓝天，他理解错了时间）,排查！没问题，再怀疑232芯片转换有问题，排查，没问题！再开始怀疑测试环境的风水……哎~~~

     最后发现问题所在，就是————不能按照数组下标提取时间！！！！因为GPRMC的长度不是固定的，它的方位角等参数是一直变的，一会儿是三位，一会儿是四位，操蛋了啊！！！

  所以可采用的方法就是，找GPRMC的字段标识符，也就是“，”，利用锁定字符串中指定字符位置的小算法得到标识符的位置，然后根据这个来锁定年月日时分秒的位置。

HAL库环境下可参考我的部分代码如下，pch为自定义指针，USART_RX_BUF为单片机接收的GPRMC信号。

pch = strchr(USART_RX_BUF, ',');
	while (pch != NULL) {
		for(i=0;i<12;i++)
			{
			comma[i]=pch-USART_RX_BUF;
			pch = strchr(pch + 1, ',');
			}
                             }

    PPS由于它独有的准确性能，可以作为时间同步的辅助时间参考，那么，如果要利用PPS来校准32内部时钟，该怎么做呢？首先我们要清楚PPS和GPRMC的时间关系。PPS和GPRMC的波形图大概如下所示：

这个波形图蓝色应该就是PPS，黄色就是GPRMC信号，由于年代比较久远，我记得二者相差大概几十ms。

既然有了时间差，那我们就设定这个时间差为time。PPS是每秒一次，每秒来一发，那么我们就要好好利用这个特性，校准流程图如下所示：

      流程解释：首先检测每次过来的PPS信号，在检测到PPS信号之后的time毫秒内，GPRMC时间信号会被接收到，解析这个GPRMC时间信号，并赋值给A。再次检测PPS信号，并接收下一时刻的GPRMC信号，解析并赋值给B。对于PPS信号的检测，为了减少程序对时间的损耗，建议采取硬件中断的方式来读取PPS信号。将A-time和B-time的值进行求差，看绝对值是否为1（A-time即为PPS的时间，pps每秒一次），如果是1，将B的值赋值给单片机内部RTC，如果不是，重复进行检测。因为RTC时间很容易跑一段时间就出现时间差，所以需要经常性的进行校准。这套流程可以用STM32系列复现出来，建议用F7+HAL库。

     这套校准方法是我去年在解决一个时间同步问题时设计的，肯定会存在很多问题，欢迎讨论。由于工作原因，相关源码不能公布出来，有问题可以私信。