Cloud instability and setTime problem

Cloud
#1

I’m using this code to manually set the time on a Core using pub/sub.

I’ve found two things:

  1. Having the Core in question publish its time every 15 seconds to the cloud seems to create instability with all the other particle devices linked to that account. I have even have a Photon or two in another physical location a mile away (but linked to the same account) and they are now going offline/online frequently in a way that they weren’t before, before I introduced the every 15s publish.
    I have noticed this before on other occasions with other similar code but wasn’t convinced of the link.
    Whilst I’m not 100% sure even this time, it does look likely there’s a link. Does anyone have any theories? Surely sending a repeating 15 second PUBLISH isn’t too much cloud traffic?

  2. When I set the time via the unixtimestamp, no matter how hard I try to click ‘send’ the very second the timestamp I’m wishing to set matches the epoch timestamp, it still seems there’s a 7 second mismatch when I get the 15second publish from the device. Is this about the computational power of the Core?!

(I am hoping to use this facility to test whether the Core ever corrects its time using the particle cloud - I have never found that it does so, despite running with SYSTEM_THREAD(ENABLED); and not in any kind of manual mode. I find it just continues to drift, getting more and more out of sync as the days and weeks roll by.)

cheers!

#2

It does not unless the connection is completely lost, then it will resync on next connect.
Or use Partile.syncTime()

With your 7 second delay I’d assume your actual running code and the cloud round trip time has much more effect than the relatively slow clock frequency of the Core (compared to Photon or Argon).

#3

ah thanks Scruff that’s so helpful to know it only does it the once under normal circumstances and explains an awful lot.
It looks like I’m not alone in finding that the device time isn’t very accurate even when it has been recently set, either.

I previously had problems running a scheduled sync but I’m a bit older and a bit wiser now so happy to give it another go! :slight_smile:

#4

Well hallelujah - and thanks Scruff - it looks like my years old problem of not being able to sync time on my Core is over. It is now tested working!!

adventureswithtime

oo - AND - seems to have the added unlooked for but very welcome benefit of actually setting the Core with the accurate time if it’s not done as part of the startup process!

1 Like
#5

DSADSADASD
Further findings… it looks like there is some built in logic either server side or client side to not correct the time if it’s within a defined tolerance…
If I’m right, that’s annoying, as that tolerance allows for (at least) a 20 second drift!
Explain a lot of my frustrations over the years - I believed my daily time sync call wasn’t working - but it probably was, just that the logic rendered it useless.
It’s only now that I’ve been given the code to trick the Core into taking on a totally wildly ‘out’ time, that I’ve been able to test what’s going on.
@jvanier @marekparticle - am I right in what I think I’ve found ?