Siemens LOGO! RTC Drift: DCF77, GPS and NTP Time Synchronization Methods

The Siemens LOGO! logic module family (0BA3 through 0BA8 and the current 0BA8 FS4 release) is widely deployed in lighting control, astronomical-clock applications, tower clocks, irrigation, and public-building HVAC. Many of these applications require the internal real-time clock (RTC) to remain accurate to within one minute per year, but the on-board RTC drifts at a typical rate of ±2 seconds per day at 25 °C – equivalent to roughly ±12 minutes per year. This article documents every documented method to bring LOGO! timekeeping within tolerance, compares their cost, and provides working FBD and Modbus TCP examples.

1. LOGO! Real-Time Clock Hardware Specifications

The RTC block in every LOGO! from 0BA3 onward is implemented as a 32.768 kHz quartz-crystal counter with battery-backed RAM. Published specifications from the LOGO! 8 (0BA8) System Manual are summarized below.

The drift is dominated by the tuning-fork crystal's parabolic temperature characteristic; it also exhibits aging drift of roughly 1 ppm per year (≈0.086 s/day) that adds to the temperature term.

2. Quantifying Drift in Tower-Clock and Lighting Applications

For a tower-clock movement driven by a LOGO! weekly timer, the relevant figure is the long-term accumulated error. Using the worst-case 5 s/day drift over one year:

E_year = 5 s/day × 365 days = 1825 s ≈ 30 minutes/year

The astronomical-clock feature (sunrise/sunset) published in LOGO! 8 Manual, Section 4.4.8 tolerates a few minutes without audible consequences, but bell-tower controllers and tariff-switch applications generally require < 60 s/year.

3. Hardware Option A — LOGO! CMR2020 GPS Receiver Module

The LOGO! CMR2020 (Siemens part number 6BK1700-0BA20-0AA0) and the equivalent successor CMR2020 V2 (6BK1700-0HA00-0AA0) plug onto the left side of any LOGO! 8 base module. The CMR receives a GPS signal through a passive or active antenna and forwards UTC time to the LOGO! master via the internal backplane. The relevant spec sheet is the LOGO! CMR2020 Operating Instructions.

Configuration steps:

1. Mount CMR2020 to the left of the LOGO! base. Power-down first.
2. Connect the GPS antenna; mount with sky visibility (≥ 120° elevation mask recommended).
3. Power the LOGO!; the CMR obtains the address 192.168.0.10 by default.
4. From a PC on the same subnet, browse to the CMR and enable Time Synchronization → LOGO!.
5. Select Sync interval = 1 h; the CMR pushes UTC plus the LOGO!'s configured time-zone offset.

4. Hardware Option B — LOGO! CMR2040 with NTP over GSM/GPRS

The LOGO! CMR2040 (6BK1700-0BA40-0AA0) adds a quad-band GSM/GPRS modem to the CMR2020 feature set. The relevant manual is the LOGO! CMR2040 Operating Instructions. It supports two operating modes:

• GPS mode: Identical to CMR2020. The cellular modem is idle.
• NTP mode: The modem dials a PPP connection to an APN and queries a configurable NTP server (default pool.ntp.org) on UDP/123.

NTP mode allows remote installations where roof antenna mounting is impractical but a cellular signal is present. It requires:

• Mini-SIM card with GPRS data (1 – 5 MB/month is sufficient)
• Public APN of the operator (e.g., internet, web.vodafone.de)
• An NTP server reachable from the public internet

Typical NTP round-trip synchronization yields < 50 ms accuracy; combined with LOGO!'s 1-second resolution, the resulting time is correct within the same second on every poll.

5. Why DCF77 Cannot Be Connected Directly

DCF77 is a 77.5 kHz amplitude-modulated time-signal transmitter in Mainflingen, Germany (PTB), with a published range of roughly 2000 km. Decoding the time-of-day and date requires sampling the carrier at ≥ 1 kHz with a band-pass filter, envelope detector, and bit decoder – functionality that no LOGO! input provides. Siemens has confirmed in the CMR2020 manual's FAQ section that DCF77 synchronization is not supported on any current LOGO! generation.

An alternative is to use a DCF77 receiver with a serial or Ethernet output, such as the ELV DCF77-2 module, and forward a minute-boundary pulse through a LOGO! digital input. This requires a hardware interface between the receiver's UART output and a LOGO! input, which most users find more expensive than the CMR2020.

6. Low-Cost DCF77 Workaround — Alarm-Clock Edge Detection

A field-proven technique uses any consumer DCF77 alarm clock (e.g., TFA 98.1080, Technoline WT 745) set to emit one daily audible alarm. The speaker's piezo transducer produces a 2 – 4 kHz burst every 24 hours, which is then rectified and routed into a LOGO! digital input through an optocoupler. This delivers a discrete edge at a known wall-clock time (e.g., 04:00 local) every day.

Hardware schematic (ASCII topology):

+5V ──┬── 4.7 kΩ ──┬── Opto-LED anode
      │            │
  Piezo           Cathode ── GND
speaker  (+)──────┘

Opto-transistor collector ── LOGO! I1
Opto-transistor emitter   ── LOGO! M

The LOGO! FBD program then uses a rising-edge trigger on I1 to capture the date/time at the moment of the alarm (the LOGO! has just incremented to the alarm minute) and stores it as the daily reference. Because the alarm clock is itself DCF77-disciplined, its drift is bounded to a few hundred milliseconds per day, and the alignment between the alarm minute boundary and the LOGO! RTC is < 1 second in normal temperature conditions.

7. Software Drift-Compensation Method (No External Module)

For applications that cannot justify the cost of a CMR2020 or 4G module, a deterministic drift-correction logic can be programmed directly in LOGO! Soft Comfort. The method uses the LOGO!'s own on-board RTC to measure elapsed seconds against an external reference that is checked once per week, then applies a correction offset.

7.1 Measuring Drift

Connect any DCF77/GPS-disciplined NTP-synced reference to a PC, and use the LOGO!'s Modbus TCP server (port 102) to read its current time. Compare with a known-good wall clock once per week. The drift in seconds per week is calculated as:

Drift_week = (T_LOGO – T_ref) [seconds]

7.2 Correcting the Drift

LOGO! 8 supports Modbus TCP write to a holding register that maps to the RTC second offset. From the LOGO! 8 System Manual, Appendix C:

A Python script can therefore perform a weekly correction:

import socket, struct, datetime
HOST, PORT = '192.168.0.5', 102
sock = socket.create_connection((HOST, PORT))
# Apply weekly correction: -28 seconds
target = datetime.datetime.now() - datetime.timedelta(seconds=28)
payload = struct.pack('>BBBBBB',
    target.year - 2000, target.month, target.day,
    target.hour, target.minute, target.second)
# MBAP + FC 0x10 (write multiple), start addr 0, qty 3
pdu = b'\x10\x00\x00\x00\x03\x06' + payload
sock.send(b'\x00\x01\x00\x00\x00\x09' + pdu)
print(sock.recv(64).hex())
sock.close()

8. Temperature Stabilization to Reduce Crystal Drift

Because the RTC's worst-case drift is driven by the parabolic curve of the 32.768 kHz crystal, holding the LOGO! at a stable 25 ± 2 °C drops the drift from ±5 s/day to ±2 s/day. Practical techniques:

• Install the LOGO! inside an IP65 enclosure with a 5 W silicone heater pad (e.g., DBK H5), thermostated to 25 °C.
• Mount away from contactors, VFDs, and direct sunlight.
• Avoid placing near the CMR2020 if not used, since unused modules can self-heat.

This is the cheapest single intervention and typically halves the required correction interval from weekly to fortnightly.

9. Decision Matrix — Which Method to Choose

10. Implementation Example — Weekly Drift Correction in LOGO! Soft Comfort

The following FBD logic uses a weekly timer (B3) to trigger a one-shot correction every Sunday at 03:00:00. The correction magnitude is parameterized in a flag byte set via the LOGO! display.

[Weekly Timer B3]
   Sun 03:00 ── enable ──> [Edge detector] ── Q → M30 (pulse)
                                          │
                                          └──> [Counter C1 +1]
                                                  │
                                                  └──> compare C1 = 7 days ──> reset C1

To apply the correction, the LOGO! sends a Modbus TCP write to its own RTC offset via the user program: open the Ethernet connection block NB with peer 192.168.0.5:102, then trigger a VM mapping write to address 0x0004 (second byte) when M30 fires. The offset value is taken from variable memory VW10, set during commissioning.

11. Verification Procedure

After deploying any synchronization method, verify the result over at least four weeks using the following procedure:

1. Set the LOGO! time to a known NTP-synchronized PC using the LOGO! web server (Diagnostics → Set Time).
2. Log daily drift to a CSV file by polling Modbus register 0x0004 every 24 h from a separate PC.
3. Plot drift vs. time; the slope should be ≤ 0.5 s/day for an acceptable installation.
4. For CMR-based systems, verify in the CMR web UI under Events that no > 24 h sync gaps occurred.
5. For the alarm-clock workaround, listen daily for the alarm and confirm I1 toggles exactly once.

12. Compatibility Table Across LOGO! Generations

13. Field-Proven Caveats and Common Faults

• Symptom: Time is off by exactly one hour. Cause: DST flag not set, or UTC pushed by CMR without time-zone offset. Fix: In LOGO! display menu → Setup → Time Zone → Auto DST = Yes.
• Symptom: CMR loses GPS lock every night. Cause: Antenna mounted under metal canopy; ionospheric delay not the cause. Fix: Move antenna to clear sky; add a 30 dB gain LNA if cable > 10 m.
• Symptom: Modbus TCP write returns 0x90 0x02. Cause: Illegal data address – the LOGO! does not accept writes to the seconds register without first unlocking VM. Fix: Issue an FC 0x06 write to register 0x0000 (control word) with value 0x0001 before writing the RTC.
• Symptom: RTC drifts faster than 5 s/day. Cause: Failing CR2032 cell; voltage < 2.7 V. Fix: Replace the cell – the LOGO! 8 manual recommends replacement every 8 years.
• Symptom: Alarm-clock edge not detected. Cause: Piezo signal too short for LOGO!'s 5 ms input filter. Fix: Add a 100 µF capacitor at the opto output to stretch the pulse to 50 ms.

14. SVG Topology — Recommended Reference Architecture

15. Frequently Asked Questions