1

Setup: I have a number of biometric devices, each of which records 24hr-48hr chunks of data that need to be correctly time-stamped with start date of each recording. Each device needs to be connected to a PC from time to time, at which point they function as removable storage media, allowing collected data to be downloaded. I have design control over the software (.NET) on the PC and some limited design control over the firmware on the device.

Problem: Each device keeps an internal date/time, and a clock battery keeps this clock working even when unpowered, but they are not intelligent to know anything about daylight saving time or time zones. As a result, this device sometimes gets out of sync and has to be manually reset. The physical design of the device prevents anything other than using the removable storage (an SD card) while it's connected to the PC—I cannot directly send commands to the device's main processor. Resolution down to the minute is good enough.

Possible Solution: While it's connected to a PC, the software could write the PC's local date/time to a file on the device's SD card, and the next time the device starts up, it could read that file and use that to set it's internal date/time. However, if the device isn't immediately powered back on by a user (and there's no way to enforce that) the date/time that was written to the card will be off by minutes to days. What I really need to know is the current internal date/time on the device at the instant it starts up in USB mode as well as the local date/time on the PC when the device was connected (let's assume these happen within a minute of each other). The software can then write out the delta to the SD card, and the device can use that delta to adjust the internal date/time to the device. This would also address the situations when the device is left unpowered for days.

Question: Has anyone else had to deal with this kind of situation, and if so, am I going about this in the right way? Does anyone have any alternative suggestions or are there any pitfalls I need to watch out for with the proposed implementation?

1

Here are some possibly contrarian thoughts...

Use UTC On The Device

I assume you actually need local time on the device, or you would not ask this. Otherwise the simplest way to avoid getting out of sync on time zones is to always use UTC on the device and only translate to local time on the pc or other UI.

Communicate Only The UTC Offset From The PC

Assuming the device needs local time, e.g. to display to a user....you could...

  • Run the device always in UTC.
  • Transfer only the UTC Offset from the PC.
  • Let the device apply the UTC Offset when displaying time to the user, if time is ever displayed.

This addresses the issue of passing a time reset through slow medium. You pass only a UTC Offset which is usually accurate until the next seasonal time adjustment.

Consider User Expectations

But you are left with a device that doesn't meet typical consumer expectations.

  • It does not automatically do seasonal adjustments.
  • It does not automatically pick up time corrections when connected to a pc or network.

And you have no way to address a case where the device's time is grossly out of sync due to loss of battery power, for example.

Build In A Clock That Does Not Need Reset

It should be possible to design or buy a device that has sufficiently accurate clock and sufficient clock battery to work for many years without a reset. Hardware MFA ID Tokens, for example. That would be my first choice, design in a clock battery that eliminates the need to reset time. Only reset UTC Offset if needed.

Use The TZ Database And Your Dev Tools To Automate Seasonal Changes

If you have some control over the firmware and you're using a development toolset that has decent time libraries, you can include data from the timezone database in the device and let it do its own seasonal changes. This would need only the portion of the TZ database relevant to your currently selected timezone, and could be transferred from the PC. But I imagine you know this, and would have thought of it if it were practical. The TZ database is available in many formats. It does occasionally need an update.

This has been my friend, when dealing with time zones. IANA TZ Database It's the db behind many dev tools handling of time zones. So you may not actually have to tinker with it yourself if your toolset already uses it.

Otherwise Build In A Better Communication Channel

Otherwise I suggest that for most consumer applications, if you can't provide the clock and battery to keep the device on accurate enough UTC time for its effective life then you need a better communication method. Whether it's USB cable, bluetooth, wifi, whatever is appropriate.

That's what comes to mind. Thanks for giving me the opportunity to window shop for a micro sized atomic clock. Found one for $1500, 30g weight. Very Rube Goldberg, unless you need it. On a really small low power device an RFID chip could probably handle this communication. But that's probably silly, and outside your scope.

  • Thanks for the response. 1) I need to display the local time to the user, but yes, I could use UTC and local offset on the device.2) The device has very limited memory and fully implementing the TZ database may not be practical in firmware (if the db needs to be updated that requires a firmware update), but I could possibly store it on SD card. 3) The hardware on the device is fixed; I can only make firmware changes. 4) This doesn't actually solve the synchronization issue; all devices need to be synced at least once (probably by my method), but after that, they would be easier to maintain. – p.s.w.g Nov 10 '16 at 16:13
  • @p.s.w.g Regarding TZ database. I would think only the entries for the selected timezone would be needed, and could be transferred from the pc when configuring or updating the device. That should be small enough data. When 'syncing' the device, latest tz data for the zone in question could be sent. – joshp Nov 10 '16 at 17:52
  • That's a good point. – p.s.w.g Nov 10 '16 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.