`card.location` time in UTC?

1

I need time in UTC as accurately as possible, is the time from card.location always UTC as retrieved from the GPS?

2

Yes, it’s “always UTC” in the sense that it’s a UNIX timestamp (specifically elapsed seconds since Jan 1st 1970 00:00 UTC). The Notecard will always update its internal clock to maintain the most accurate time whenever it connects to a cell tower.

3

Ok, thanks. So it is based on cellular and not GPS? From the docs I can see that card Requests - API Reference - Blues Wireless Developers is based on cellular, but that one is also not UTC.

4

The Notecard uses the cellular network time the first time it connects after initial power-up. Upon syncing with Notehub, it uses the time provided from Notehub. We do trust the GPS and the Notehub-provided times equally. All of the times are UNIX timestamps, which are based on UTC.

1 Like
5

So, what happens in Y2038? I’ve have begun hearing a lot of chatter about Unix Datestamps and the 2038-pocolypse.

6

Valid question, even though we are a few years away :slight_smile:

In a nutshell:

  • Notehub should have few, to no, issues.
  • Notecard will have some issues but nothing involving more than several days of work
  • The integrated cjson portion of the C API libraries, which are currently focused on being optimal for MCUs with very small amounts of SRAM, will need to be enhanced to default to 64-bit, and we will likely do this through a compilation flag.
7

OK. Just asking. I was around for and quite active in fixing Y2K for a company back then and that was 22 years ago now. 22 years from NOW will be 2044.

8

Yes, that is surreal (and mildly depressing :slight_smile:)

9

Does that mean that GPS time is never used, but only cellular time? So if the notecard connects to a tower, gets the time, and is then without service for a long time it is only using its internal clock? Not the time from GPS?

10

@gauteh The notecard can set its time from 3 sources

  • Notehub - each time it connects to Notehub. I’m afraid I don’t know the guaranteed accuracy of the Notehub clock, but I can check if this is particularly important.
  • From the cellular network
  • From the GPS receiver (RMC NMEA sentence when the fix is valid).
    While the Notecard has power the time is maintained by the Notecard’s CPU’s RTC which uses a precision 32.768kHz crystal oscillator which has better than 250ppm over -40C to +85C.
    GPS is extremely power hungry, so the Notecard will never autonomously enable GPS in order to update the RTC.
1 Like
11

Thank you. Does the accuracy of the time from the Notehub depend on connection latency? What is the overall accuracy of the system (maximum deviation). Do you use PPS from GPS? Maybe using time from a less accurate source after a recent fix + RTC deteriorate the quality of the time. I’ve seen a discrepancy of about 1 second over 4-5 hours, but I’ve so far attributed that to GPS getting a fix (which doesn’t quite make sense when I think about it, compared to an IMU sampling so there could be issues there as well).

12

The current accuracy of the Notecard is around +/- 2 seconds. We do not use PPS- only the RMC sentence time. I would expect the drift of the time to be low due to the high accuracy / stability crystal we use for the CPU RTC, but the absolute accuracy is certainly not sub-second.
I will review both our GPS receiver and the firmware to see if this could be improved in future firmware releases, but for the time being if your application requires 1s or better accuracy the quickest solution may be to use an external GPS receiver.

1 Like
13

Thanks. Better timing would be very useful for me, especially when the GPS is working I would expect the time to be quite accurate. As you say the RTC drift between each fix is probably much less than the inaccuracy in the different timing sources. If GPS is active regularly it would maybe be best to just use the GPS time + RTC.