The existing RT clock on the imp006 is coarse and when it receives updates from the agent, it can skip whole seconds. Is there any plan to either expose the UTC clock source on the BG96 GNSS integration, or to provide a sync to the impOS time() that is preferable to the one is gets from the agent?
The BG96 library only offers lat & long, but the same Quectel call also returns UTC time, I believe.
A transparent implementation of it could inform the date() call on the imp006. Previously, the usec field has always been 0 on the device, but successful integration with the GNSS could populate that field with millisecond precision.
I don’t know whether the inner workings of the impOS time() are receptive to improvement. The GNSS source could also be used as the reference source for real-time that time() could use for synchronisation instead of agent time. Presently, there can be very abrupt adjustments to real-time on the device when a device connects to the cloud after being offline for a period. If the device in informed that it is running slow, it should be instructed to “catch up” n seconds. It could achieve this by stretching the clock over a period of a many seconds. Similarly, time() can slow down by clipping a small amount off each second for a prolonged period.
We hadn’t, I have to say, made a plan to do that, but it’s potentially a good idea. There would still be a certain amount of drift of the imp’s own RTC in-between GNSS time syncs, just as there is in-between server time syncs – but it might take less power to fire up GNSS than it does to fire up the server connection.
The BG96 library does actually return time (the “time” entry in the table in modes 1/2) - that’s not clear from the docs though, and as the library relies on some private APIs to talk to the GPS, you can’t inspect the code to find this out.
Native GPS support including using gpsOneXTRA for faster fixes is being designed right now, and when that ships we’ll be able to return to having a transparent library (or you’ll be able to use the native APIs, obviously).
If you’re seeing significant drift, have you got your crystal load tuned on your board?
I’m not really fussed whether it’s GLONASS, GPS or gpsOneXTRA as long as it has support in some of the more extreme latitudes, like ours.
Our design for the 32kHz on the imp005 and imp006 follow the Electric Imp reference designs.
Drift is one issue. I have only assumed that there is drift, if the server must sometimes adjust the clock by 2 seconds upon reconnection. I also suspect that the larger adjustments are due to variable lag in the device-agent connection, making it hard for the server to confirm just how far ahead/behind the device clock is.
My main gripe is the coarseness. It would be great to timestamp things in the device with something that’s more precise than 1s. I do use hardware.millis(), but it has no comparative relevance outside of the device.
Even if it were hard to do it transparently, I’d be quite happy to call BG96.time() or BG96.date() as an alternative to time() and date().
That’s likely to be your best policy, yes. Get a really good time-of-day from the BG96 as often as you need to, and use hardware.millis() (which is monotonic, except when it wraps of course) to add an offset and work out time-of-day when in-between BG96 sessions.
gpsOneXTRA isn’t a satellite constellation, it’s just preloading satellite path data to get a faster fix.
As noted, you already get time and date from the BG96 library, so Peter’s suggestion of managing this yourself locally with hardware.millis() seems like the best way to go right now?
Umm, I was speaking hypothetically when I mentioned BG96.time(). Are there indeed API calls to get the time and date from the unit? If so, I can’t find them in the documentation.
I’ve spent some time observing the GNSS features. While the Quectel documentation indicates a UTC value from the satellites with the format hh:mm:ss.sss, the millisecond part is always 0 . I tried polling rapidly with BG96_GPS.getLocation() to identify the precise point in time where the second field ticks over, but it’s a bit hit and miss as getLocation() will often return errors if I poll faster than 20Hz. If the GPS clock ticks are accurate, I might be able to get a fix on real-time to a tenth of a second. That’s better than nothing at this stage.
I can believe that the Quectel docs lie here; it’s sort-of a half baked GPS implementation as it comes “for free”
Using AT+CCLK is another option I guess, though again this doesn’t provide sub-second precision but is presumably set from the cell base station clocks (which are accurate). AT+QLTS says it does network sync time but again… only to the second.
. I tried polling rapidly with BG96_GPS.getLocation() to identify the precise point in time where the second field ticks over, but it’s a bit hit and miss as getLocation() will often return errors if I poll faster than 20Hz. If the GPS clock ticks are accurate, I might be able to get a fix on real-time to a tenth of a second. That’s better than nothing at this stage.