Homepage GitHub

UAVCAN Time master + PPS GPS

(Florian Langlois) #1

I want to precisely synchronize UTC times of some UAVCAN nodes with a time master which has the GPS PPS signal connected to one IO.

Pavel wrote there is a TODO comment for that in the STM32 driver I believe, but this feature is not implemented. Yes, it is perfectly feasible and can be done relatively easily.

But I didn’t find this comment. The idea is to directly sync timer with external input ?

(Pavel Kirienko) #2

The comment happened to be in the Zubax GNSS firmware:

I recommend you either write your own clock driver for your application, or you add support for an optional external signal synchronization to the upstream driver (that would be amazing). If you chose to go with your own driver, you could either reimplement the entire STM32 platform driver from scratch, or you could provide your own implementation of the clock driver only (in that case just leave UAVCAN_STM32_TIMER_NUMBER undefined; see https://github.com/UAVCAN/libuavcan_stm32/blob/8c32fad90025d8466fd8ff0d856bcf9ebb68eab8/driver/src/uc_stm32_clock.cpp#L9).

You could implement the synchronization feature through a simple software phase-locked loop; something similar to what we have in the driver currently, except that the reference signal will be provided in the form of a hardware pulse train rather than periodic time adjustments.

(Florian Langlois) #3

would you use a timer capture interrupt or a simple external trigger interrupt handler ?

my idea was to just add an external input trigger into the existing stm32 driver and then call the also existing adjustutc method in the interrupt handler. you think it is not a good idea ? the only thing you’ll to set is the correct gpio with a define.

not a good idea ?

(Pavel Kirienko) #4

In order to take full advantage of the PPS signal you should account for the IRQ jitter. In order to do that, you should likely use a hardware timer capture input (that is unless you can guarantee a very low jitter, e.g., by using the highest priority IRQ with extremely short to nonexistent critical sections – this is rarely feasible).

(Florian Langlois) #5

Thanks. I’ll give a try with capture input. What do you of directly use the existing adjustUtc ? You’ve already implemented the sync loop. This function can be called from an interrupt handler ?

(Pavel Kirienko) #6

I don’t think this function can be invoked from an interrupt context, but you should be able to fix that easily. You will need a different phase locked loop because the PPS signal contains only rate information but no phase information; i.e., with PPS, you can determine the rate error of your local clock, but not the absolute time.

(Florian Langlois) #7

If I configure PPS from the GPS to 1Hz synchronized with the UTC time and set the UTC time accordingly with gps topic so I can know to which absolute time the pulse refers.

(Florian Langlois) #8


I didn’t have the bandwith to work on that and will try now.

I saw your discussion on PX4 https://github.com/PX4/Firmware/issues/2915 about using hrt timer monotonic instead of tim5. I wonder if using rtc clock with smooth calibration HW of the stm32 is not a good idea for the Utc (or system or realtime) time base ? So like on the linux implementation the used clocs will be the monotonic (in this one the rate can be changed by the way) and realtime.

what do you think ?

(Pavel Kirienko) #9

It’s quite sad that we never got around to fix that problem you linked.

The current libuavcan implementation does just that: it maintains two time bases, monotonic and realtime, using one hardware timer. The existing implementation does not require hardware support for clock stretching, since this feature is implemented in software, but you can easily change that.