PPS to UBX-NAV-TIMEUTC latency

GPS/GNSS Development Boards
1

Hi, I am using a NEO-M9N - mostly because of the breakout board available. What I need to do is a time server. I wait until the PPS occurs, receive the UTC time, and then send the UTC time to a client over RS-232. I have enabled the UBX-NAV-TIMEUTC message on UART1 at 115200baud to send the UTC time every second. What I am finding is that there is about 12.15mS delay from the PPS TOS until the beginning of the UBX message - this is very repeatable

I need to find a way to reduce this delay so that the time I am forwarding is more accurate. Would a different module spec help? Is there a configuration I can use (not user delay) that would speed up the time solution? I do not need position.

Thanks, Bill

PPS_to_UBX.jpg
PPS_to_UBX.jpg1024×768 160 KB
. Would a timing specific module allow this - or just provide a more accurate PPS signal?

2

Hi Bill,

There is more information on this in section 3.10 of the integration manual. I suggest using the UBX-TIM-TP message, which will tell you what the time will be (time-of-week in milliseconds) at the next pulse.

https://cdn.sparkfun.com/assets/5/d/7/8 … 14286_.pdf

Best wishes,

Paul

3

Thank You Paul. I have looked at the TIM-TP message and spent some time figuring out how to convert TOW into UTC and I am not sure (yet) if I really want to go there. I guess I am just surprised that there is no way to get U-BLOX to supply UTC time for the next pulse or UTC time closely following the time pulse.

Thank You again,

Bill

4

Hi Paul, I decided to go for decoding the weeks/seconds TIM-TP time into calendar time/date. It was mildly painful but now it is working great and does exactly what I need. Thanks again, Bill

5

Hi Bill,

You’re very welcome.

I’ve been kicking this around in the back of my mind. The following ideas may help?

You could use the UBX-NAV-PVT message to help convert the Time-Of-Week into regular date and time. PVT contains both the iTOW and year, month, …, sec. So long as you keep clear of the minute boundary, the TOW in UBX-TIM-TP should only ever be one second ahead. Add one to the sec field from PVT and you’re in business. (But do keep clear of the minute boundary. And there may be leap seconds to think about too.)

The SparkFun u-blox GNSS library does not support UBX-TIM-TP directly, but you can access it through a custom packet. Have a look at Example20 or Example21:

https://github.com/sparkfun/SparkFun_u- … ommand.ino

Replace:

customCfg.cls = UBX_CLASS_CFG; // This is the message Class

customCfg.id = UBX_CFG_RATE; // This is the message ID

with:

customCfg.cls = UBX_CLASS_TIM; // This is the message Class

customCfg.id = UBX_TIM_TP; // This is the message ID

and you’re good to go. You will need to extract the TOW manually from the first four bytes of the payload, but I guess you’re already doing that.

Very best wishes,

Paul