Servo Mode

Servo mode (enabled by passing a negative Timeout to NetworkTimeProtocol) is a “clock discipline” mode where the datalogger continuously fine-tunes the RTC rate instead of frequently doing hard time steps (explicit clock sets).

What servo mode does

In normal operation, NTP sync often means: measure the offset → if it’s big enough, set the clock. A hard set is effective, but it’s also a relatively disruptive operation (can cause skipped scans, abrupt time jumps, etc.).

In servo mode, the datalogger takes the time offset measurements coming back from the NTP server and feeds them into a PID-style control loop. That loop:

  • Smooths/judges incoming offsets over time

  • Rejects or de-weights outliers (for example, if the NTP server is unstable or the network introduces jitter)

  • Produces small corrections that nudge the RTC frequency up/down so the logger gradually “steers” back into sync

The end result is a clock that stays aligned by slewing (rate adjustment) rather than stepping (sudden set), which is typically gentler on scan timing and time continuity.

Recommended frequency of calls to NetworkTimeProtocol in servo mode

When using servo mode, it is recommended that the NetworkTimeProtocol instruction be executed every 2 to 5 minutes. This provides regular NTP measurements that allow the data logger to continually refine its clock adjustment (RTC “nudging”) and maintain the best accuracy.

In some applications, calling NetworkTimeProtocol this often may not be practical (for example, when using a cellular modem that is only powered periodically). In these cases, the instruction may be called less frequently. Less frequent updates can reduce timekeeping accuracy between NTP contacts because the servo has fewer opportunities to refine the clock adjustment. However, depending on the application and the interval between NTP contacts, the resulting time error may still be acceptable.

Clock adjustment refinement only occurs when the datalogger successfully contacts the NTP server and the reported time difference is less than NTPMaxMSec. If the NTP server reports a time difference greater than NTPMaxMSec, the datalogger will perform a hard clock set (step the time), even when servo mode is enabled.

Using servo mode with infrequent NTP contact is supported, but it is outside the recommended operating pattern. Users should validate that the resulting behavior and time accuracy meet their application requirements.

Interaction with NTPMaxMSec (important)

Even in servo mode, the data logger still has a safety mechanism: if the reported time difference exceeds NTPMaxMSec, it will perform a hard clock set.

Because servo mode is specifically intended to handle small-to-moderate offsets through gradual nudging, NTPMaxMSec should typically be set higher than in non-servo use—often around 1000 ms (1 second)—so that normal jitter/offset does not trigger stepping. With a higher threshold, the logger will:

  • Use nudging for everyday corrections

  • Reserve hard sets for rare “something is really wrong” situations (large drift, long outage, bad starting time, etc.)

Practical expectation / limitations

Servo mode is designed to make hard clock sets rare, because the clock is being continuously disciplined. That said, the quality of results depends on the NTP server and network path: if responses are noisy or incorrect, the control loop will do its best to filter them, but large errors can still force a hard set (via NTPMaxMSec) or reduce overall stability.