Using the Real Time Clock (RTC) on Zymkey

ZYMKEY4
1

Standard Zymkey’s are supplied with a Real Time Clock (RTC). This capability can be useful for platforms which do not have a built-in RTC, such as Raspberry Pi, but rather depend on NTP for time-keeping.

Dependence on NTP may cause problems due to unscheduled power outages or unreliable WiFi connections. For example, if a deployed application that periodically collects sensor data experiences a power outage and is not able to restore a connection to any available networks upon boot up, the timestamps associated with any collected data would be incorrect. On Raspberry Pi, this will be approximate to the last valid timestamp when things were last running normally.

We can simulate this by disabling ntp.service comparing the system date to the time.nist.gov server. After only 12 hours, the system clock has drifted nearly 40 minutes!

Zymkey’s Real Time Clock is battery backed for reliable operation, which could be very valuable for significant power or network outages. Prior to starting NTP in the boot sequence, the zymkey provides the current UTC timestamp to the host computer (e.g. Raspberry Pi). This means that, if access to a reliable network isn’t available, a reliable timestamp will be available for use by any running applications.

With a bound Zymkey installed and running zkbootrtc.service on the same system as above (ntp disabled), we can see the clock restored based on the Zymkey RTC. You will notice this message at boot:

Feb 8 19:22:26 raspberrypi systemd[1]: Starting Restore System Clock from Zymkey…
Feb 9 18:58:48 raspberrypi systemd[1]: Started Restore System Clock from Zymkey.

And we can validate using the same test as above.

Zymkey’s time value is not settable directly by applications that are running on Pi. Instead RTC accuracy is monitored and maintained by the Zymkey software suite.

In order for the RTC feature to be activated, the Zymkey needs to have it’s clock checked and set occasionally, which is done by the Zymkey software, but this means that NTP must be running so that the Pi time is synchronized to an accurate clock source. To make sure that NTP is active, on later raspbian distributions, you’ll need to run sudo timedatectl set-ntp true and then reboot. In the case where a new coin cell has been installed, it may take a few minutes after the reboot for the Zymkey time to be synchronized.

Accuracy of RTC

Zymkeys with integrated RTC are supplied with Standard Accuracy calibration. This is generally suitable for commercial applications that are not exposed to extreme temperature ranges and not disconnected from NTP for months on end. (see specs below)

An optional High Accuracy RTC are available, providing additional stability over extended temperature ranges.

1 Like
6

Hi Zymbit and Community!

Installation went perfectly well thanks to your [Getting Started Guide] (https://community.zymbit.com/t/getting-started-with-zymkey-3i/142/14) (blue led blinking once every 3s)

I will have to encrypt my SD so that proprietary software sources are protected. I will follow your guide about this and let you know :wink:

But before going further, I wanted to test my Node.js web app. As it needs session, it needs a proper system time set. Now that I’ve replaced my DS3231 RTC with the key, I can’t manage to get a correct time configured while/after booting. What would be the procedure to get correct time setup?
With the DS3231, after first installation, it was needed to set system time from ntpdate-debian, then to save this to DS3231 using sudo hwclock -w.
/sbin/hwclock -s command in /etc/rc.local script would then correctly reset system time after any reboot.
(following this guide)

How do I get a similar behaviour now that I’ve installed zymkey 3?

Thanks for your answers
Cheers

7

Hi again, Will!

Thanks for the question.

The time in the RTC in the Zymkey is set at the factory and is meant as a safeguard during system boot to insure that a “sane” time is in place before NTP runs or in the case where network connectivity is impaired and NTP doesn’t run. Given that Raspbian and friends are a moving target, we elected to not develop any kernel modules for the RTC and, therefore, the stock Linux components (e.g. hwclock) won’t work with Zymkey’s RTC.

Instead, our approach was to keep everything in user space and in systemd. During boot, we currently have a systemd script that checks zymkey for a more recent time than the last one that RPi captured and stored on disk during the last proper shutdown.

This means that, if everything is properly configured and running, the system time (GMT) should be initially set to zymkey’s time before NTP has had a chance to run. You should be able to see this in the console.

Also, we understand that RTCs drift with time and temperature, so we have a feature planned for a future release which will update the Zymkey’s time periodically if needed during normal operation.

Hope this answers your question.

8

Hi Scott,

Good to hear from you…
OK, I get the design choices made for the Zymkey.

In my case, main usage for the PI is to boot offline (no network connection available), it emits its own WIFI (access point mode) without password. PI is configured to share its internet connection whenever connected to a router using ethernet.
The PI is usually plugged out after usage (a few hours)… so no proper shutdown scripts are currently called :frowning: is that a problem regarding the zymkey way of doing things?

I understand that as NTP can not be run successfully while booting offline, Zymkey should set the system time, even if last shutdown wasn’t properly done.

Currently, once booted (either ethernet connected or not) , I log in via ssh, and I get

Last login: Fri Jan 2 02:12:09 1970.

Once logged in:

pi@xxx:~ $ date
vendredi 2 janvier 1970, 02:26:39 (UTC+0100)

(friday Jan, 2nd, 1970 …)

Now how can I ensure that the systemd boot scripts are correctly run?
When you say:

You should be able to see this in the console.

Where do you refer I should check?
How can I check the time currently stored in the Zymkey?

I’ve done nothing more than the installation scripts on an existing system, so would a previous DS3231 RTC configuration be in conflict with Zymkey?
Is it possible that my previous config has somehow made the date overwritten in the Zymkey?

Sorry to have so many questions for such trivial things, I’m more into devs than in Linux :wink:

EDIT
4 last lines of
#cat /var/log/syslog | grep Zymkey:

Jan  1 01:00:07 ____ systemd[1]: Starting Restore System Clock from Zymkey...
Jan  2 09:17:58 ____ systemd[1]: Started Restore System Clock from Zymkey.
Jan  2 09:17:58 ____ systemd[1]: Starting Zymkey Interface Connector...
Jan  2 09:17:58 ____ systemd[1]: Started Zymkey Interface Connector.

EDIT 2
In python, trying to get time form zymkey
print('get_time(): ' + str(zymkey.client.get_time()))

get_time(): 178283

It appears factory set time on the zymkey has been overwritten by some operations of mine…
For the DS3231 I had to update /boot/config.txt, and forgot to remove before starting the software installation procedure

dtoverlay=i2c-rtc,ds3231

Might this have something to do with a possible rewriting the key?

9

Hi, I dont want to hijack from Wiill but out of interest what is the protocol and DNS/IP ranges needed for the RTC module to get its time from your cloud system?

Is it possible to not use the Zymbit RTC module on the Pi and use another external module to do the job? Strange question but we have another board that has a builtin RTC module and would rather use that but still use your product for the encryption.

10

Hi @wiill,
Sorry for the delay in responding. If you enter sudo systemctl status zkbootrtc and a line which says something like
Jun 12 21:17:04 raspberrypi zkbootrtc[388]: /sbin/zkbootrtc: using system time
is displayed, then the Zymkey has lost it’s time reference. This issue could have been caused by the removal of the coin cell battery at some point.

Based on your attempt to get the time from a Python script, it looks to me like the Zymkey has indeed lost its time reference. We will be issuing an update to the Zymkey software that will automatically keep the RTC up to date to compensate for drift while the host is running. In your case, the time should be restored with this feature as long as the coin cell is not dead and if the host is able to get a stable fix on time via NTP over internet.

Also, the dtoverlay that you mentioned should have no bearing on the Zymkey time.

I’ll keep you posted on the Zymkey software update. It should be ready by Tuesday next week.

1 Like
11

@chunkychicken,
No problem with the hijacking. It’s not really that, it’s about answering questions and helping out :slight_smile:

To answer your first question, we don’t use any cloud components to keep Zymkey time up to date…
the post has to be cleaned up
:grimacing:. As I mentioned in my response to wiill, we will be issuing a release that will just update the Zymkey time per latest system time on the Pi. In the usual use case, the Pi will have internet connectivity and will have NTP running, so this should be sufficient for keeping the time in bounds.

As for your second question, it is easy to disable the Zymkey boot time update. Simply disable the zkbootrtc service with:
sudo systemctl disable zkbootrtc
This will stop the service from running for all subsequent reboots.

12

Hi @Scott,

Thanks for your feedback, no problem!
Can’t wait for next tuesday :wink:

In the meantime, here is the output for the sudo systemctl status zkbootrtc

pi@____:~ $ sudo systemctl status zkbootrtc
● zkbootrtc.service - Restore System Clock from Zymkey
   Loaded: loaded (/etc/systemd/system/zkbootrtc.service; enabled)
   Active: inactive (dead) since jeu. 1970-01-01 23:50:18 CET; 49s ago
  Process: 422 ExecStart=/sbin/zkbootrtc (code=exited, status=0/SUCCESS)
 Main PID: 422 (code=exited, status=0/SUCCESS)

janv. 01 23:50:18 ____ zkbootrtc[422]: /sbin/zkbootrtc: system time was initially 9.000219131. Time is now 82218
janv. 01 23:50:18 ____ systemd[1]: Started Restore System Clock from Zymkey.

pi@____:~ $ date
jeudi 1 janvier 1970, 23:52:08 (UTC+0100)

Hope the coin cell is allright…

13

@wiill,

Just wanted to let you know that the RTC update is now available. However, the URL for the apt repo has changed. Please see the notice Zymkey apt repo url has changed.

This change will now set a correct Zymkey time when the Zymkey time goes bad for any reason (coin cell goes flat or is removed). Also this post (Using the Real Time Clock (RTC) on Zymkey) has been updated with the relevant notes at the bottom.

1 Like
14

Hi @Scott_of_Zymbit,

Thanks for all the updates, worked like a charm, now I will closely look after the offline usage of my Pi to check if there are any issue left with the coin cell… But resync has been made and my web app sessions are all OK.

Now proceeding with the encryption… see you :wink:

Cheers

15

Please forgive me if this is a silly question but will your product work if a coin battery isn’t inserted if an RTC module is already installed on the Pi?

Our product will be offline for possibly up to a week so NTP isnt available to keep the Zymbit in check. The current RTC module we use has a very low drift and highly accurate so want to keep this. Ideally we’re trying to keep costs down and avoid installing 2 coin batteries in each product.

We will be using your product for partition encryption

16

@chunkychicken
In the current products, the coin cell is only needed for RTC. You can safely remove it if you don’t need the RTC functionality.

1 Like
17

Hi @chunkychicken,

Out of curiosity, how would you manage to do so? I mean about the reconfiguration of which pins your RTC module would be plugged on, since the Zymkey takes the 10 firsts… This could be an option on my side as well, to keep a separate RTC module and use the Zymkey for encryption (my primary need for the Zymkey was for encryption, but I had to remove my DS3231 and rely on the Zymkey RTC)

Cheers

18

To be honest Ive never tried to do this before so i was wondering whether i could solder the RTC onto the same pins and disable the Zymkey own RTC. My knowledge on this sort of stuff is very limited, i tend to learn by playing around. Obviously it may not be work, no idea!

Maybe the guys at Zymbit could answer this better than myself?

1 Like
19

@chunkychicken @wiill

We thought it might be helpful to your discussion if we published the specification of our RTC, compared to the DS3231 and compared to what you might reasonably need in a typical commercial application. Under most circumstances the standard RTC onboard Zymkey should be good enough, which saves you time and money on integrating additional hardware and interface code.

(Post is in the main body, copied here for convenience).

##Accuracy of RTC
Zymkeys with integrated RTC are supplied with Standard Accuracy calibration. This is generally suitable for commercial applications that are not exposed to extreme temperature ranges and not disconnected from NTP for months on end. (see specs below)

An optional High Accuracy RTC are available, providing additional stability over extended temperature ranges.

1 Like
20

Hi,
I’m new with zymkey. For my project, I need a RTC to maintain time as my device won’t be powered up all the time and won’t have any network connection (RJ45 or Wifi).
Is it possible to use the zymkey as main clock source? If the time drifts, will it be possible to adjust it manually, without ntp?
Thanks in advance,