Thanks for the reply, my previous particle time sync attempt is at the bottom of this post. this code was based on example code from the forums or the documentation.
On occasion it doesn’t sync, and my customer has noticed the drift, as per the attached picture, additionally I have seen the time sync jump 30secs forwards in time. which messes up the timestamped data that I’m sending. In all it is too much black magic that I can’t rely on.
Secondly, and the reason for the post, is that at times, the devices will not perform a handshake, and therefore will not get the OTA that I need. I thought that I would stuff the handshake code in my NTP sync function as it only needs to happen once a day or once an hour. but this doesn’t work either - I simply can’t get it force a handshake reliably unless I reboot the modem / device.
Actually to moan a little bit… The cloud service seems a bit flaky. I have another product(s), that misses publishing the regular 10min “keep_alive” that I send with the battery health embedded in it. as it gets a “device_came_online” message in the middle of the events, I don’t really mind the device_came_online message. its annoying but documented that the particle keepalive time is too long, but you would think that doing a publish itself should perform all the necessary functions to make sure that the device reconnects and sends, as the device is non critical I haven’t bothered fixing it.
for my critical products.I have put in a ton of code and modded the boards with external WDT’s to try and keep these devices online and overcome all the “nuances” of the system.
I have yet another product that I have had to switch to MQTT altogether as I can’t rely on the service (and I wanted to send messages to groups of devices). - Although this meant I wasn’t affected by the recent outage experienced at particle.
I’m really dependent on Particle, as I have PCBs designed and built, and have just got contracts for several hundred devices, so I really appreciate the support - sorry for the moan, and apologies if it is a little unspecific.
Regards
Marshall
Here is the particle time sync code.
#define ONE_DAY_MILLIS (24 * 60 * 60 * 1000)
//#define ONE_DAY_MILLIS (10 * 1000)
void cloud_sync_time (bool sync_right_now){
time_t lastSyncTimestamp;
char cpyoftnow[32];
unsigned long lastSync;
if (sync_right_now == false){
lastSync = Particle.timeSyncedLast(lastSyncTimestamp);
}
else { //to sync immediately
lastSync = ONE_DAY_MILLIS + 1;
}
if (millis() - lastSync > ONE_DAY_MILLIS) {
unsigned long cur = millis();
//OPITO_DEBUG("Time was last synchronized %lu milliseconds ago", millis() - lastSync);
//snprintf(cpyoftnow, sizeof(cpyoftnow), "%s", (const char*)Time.timeStr(lastSyncTimestamp));
//OPITO_DEBUG("Last Time Sync received from Particle Cloud was @: %s", cpyoftnow);
// Request time synchronization from Particle Cloud
snprintf(cpyoftnow, sizeof(cpyoftnow), "%s", (const char*)Time.timeStr());
OPITO_DEBUG("Time prior to Sync is %s",cpyoftnow);
Particle.syncTime();
// Wait until Electron receives time from Particle Cloud (or connection to Particle Cloud is lost)
waitUntil(Particle.syncTimeDone);
// Check if synchronized successfully
if (Particle.timeSyncedLast() >= cur) {
// Print current time
snprintf(cpyoftnow, sizeof(cpyoftnow), "%s", (const char*)Time.timeStr());
OPITO_DEBUG("Time after Sync is %s",cpyoftnow);
}
}
}
Here is a picture of customer noticing the drift. it’s the trend that is of interest.
engineer tests this and responds here in January. (cc: device team lead 
