Real-Time-Clock
This page documents the real-time-clock configuration
Table of Contents
Warning
An accurate time is required when communicating with a S3 server
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 |
2 |
Retain current time: |
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, synchronized via CAN-bus or synchronized via network.
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:
Select the manual
sync
method and set the current UTC timePower on the device and wait a few seconds to allow the device to read the manually set time
Power off the device
Change the
sync
method to retain the current timePower on the device again
Verify that the new absolute time is now correctly retained across power cycles
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
.
Network
The RTC can be synchronized using the WiFi connection and an external time (NTP) server. When enabled, the device periodically polls an updated time.
Warning
Make sure firewalls etc. allow NTP (port 123) traffic.
The difference between the RTC time and the network time is compared to the configured tolerance
. For more information on the tolerance see the synchronization via CAN-bus section.
- 1
Continues tracking requires that an updated external time is available at least once each hour