Real-Time-Clock

This page documents the real-time-clock configuration

Configuration file fields

This section is autogenerated from the Rule Schema file.

---

Real-Time Clock (RTC) rtc

Time synchronization method rtc.sync

Internal real-time-clock synchronization method. The real-time-clock is maintained when the device is off.

Type	Default	Options
integer	0	Retain current time: 0 Manual update: 1 CAN-bus: 3

Time zone (UTC-12 to UTC+14) rtc.timezone

Adjustment in full hours to the UTC time. Includes daylight savings time if applicable.

Type	Default	Minimum	Maximum
integer	0	-12	14

Adjustment (-129600 to 129600 seconds) rtc.adjustment

Adjustment in seconds to the UTC time. Can be used for fine tuning the internal time.

Type	Default	Minimum	Maximum
integer	0	-129600	129600

---

Configuration explained

This section contains additional information and examples.

The CANedge uses a real-time clock (RTC) with battery backup, which allows it to retain the absolute date & time when the device is not powered. The RTC enables the CANedge to add absolute timestamps to recorded messages.

Time-zone changes and minor adjustments can be done via the timezone and adjustment fields.

Synchronization methods (sync)

The RTC time can either be retained, manually set or synchronized via CAN-bus.

Note

When using an external synchronization source, the TimeExternal signals can be used to confirm that the device correctly receives and understands the time synchronization information.

Manual update

Manually changing the RTC is only needed if the RTC time has been completely reset (e.g. after a battery replacement). The following sequence explains how the RTC can be manually set:

1. Select the manual sync method and set the current UTC time

2. Power on the device and wait a few seconds to allow the device to read the manually set time

3. Power off the device

4. Change the sync method to retain the current time

5. Power on the device again

6. Verify that the new absolute time is now correctly retained across power cycles

7. Set timezone (timezone) and do minor adjustments (adjustment) if needed

Note

The internally stored session counter is lost when the battery is removed. See Setting session counter for information on how to set the session counter.

CAN-bus

The RTC can be synchronized based on a CAN-bus message. The interpretation of message data signals is configurable.

Time information can be provided via either physical CAN-bus channel or using the internal GnssTime signals. See Sync using internal GNSS time for an example on how to use the internal GNSS time signal.

The synchronization method depends on the time difference between the RTC time and the external time provided via CAN-bus:

• Time difference exceeds tolerance: The RTC time is directly set to the external time (discrete jump in time)

• Time difference within tolerance: The RTC time slowly tracks the external time (continuous time)1

The synchronization message data is assumed to include the external time and optionally a valid flag indicating if the external time should be applied or not:

• Valid signal (optional): 1: Time signal is valid, else: Time signal is invalid

• Time signal (mandatory): The current UTC time as Epoch (floating-point number of seconds since 01/01/1970 00:00:00 UTC)

Warning

Avoid using a high-frequency CAN-bus message for time synchronization. If the frequency of the time message is high, consider using pre-scalers to reduce the period to e.g. 1 minute.

The configuration of the signals uses a concept similar to that used by .DBC files. In case a .DBC file is available (describing the interpretation of the synchronization message), the information from the file can be used directly for configuration. For more information see Section Signal.

Example 1: Using both the valid signal and time signal (time message generated by a CANmod.GPS device).

• The valid signal is 1 bit starting at index 0. The factor and offset are chosen such that the decoded signal becomes 1 when the time signal is valid.

• The time signal is 40 bit starting at index 8. After applying factor and offset the result becomes Epoch in seconds.

Signal	Type	Byteorder	Bitpos	Length	Factor	Offset
Valid	Unsigned	Intel	0	1	1	0
Time	Unsigned	Intel	8	40	0.001	1577840400

Example 2: Same as Example 1 but without using the valid signal.

• The valid signal length is set to 0. With a factor of 0 and offset of 1, the result always becomes 1 (valid)

Signal	Type	Byteorder	Bitpos	Length	Factor	Offset
Valid	Unsigned	Intel	0	0	0	1
Time	Unsigned	Intel	8	40	0.001	1577840400

Note

If a valid signal is not included in the data, a constant valid signal can be enforced by setting the factor to 0 and offset to 1.

---

1

Continues tracking requires that an updated external time is available at least once each hour