October 19, 2026
Posted by: editor
Category: RECD & Emission Control Devices

The DG controller’s log says the generator started at 14:02. The Retrofit Emission Control Device’s log shows exhaust temperature rising at 14:09. The cloud dashboard records the first RECD reading at 08:32. And the BMS alarm history shows a high back-pressure alarm at a time when, according to the DG log, the engine wasn’t running at all.

Nothing is broken. The clocks disagree.

Misaligned timestamps are one of the most common and least noticed problems in RECD monitoring. They make it impossible to say what happened first, to calculate how long the RECD was monitored while the DG ran, or to match readings to load. This guide explains where timestamp differences come from, how to measure and correct them using events that both logs can see, and how to prevent the problem from the start.

Why Alignment Matters

You need RECD data and generator data on the same timeline to:

Interpret RECD readings in context. ΔP and back-pressure only mean something at a known load and running state. See why generator load must be matched in RECD comparison tests.
Sequence events correctly. Did the back-pressure alarm come before or after the load step? Before or after the regeneration failed?
Calculate data availability, meaning the share of DG running time covered by valid RECD data. See detecting missing data in RECD monitoring records.
Estimate PM avoided, which depends on running hours and load. See estimating kilograms of PM avoided after an RECD retrofit.
Support investigations, warranty claims and inspections, where a clear, believable timeline matters.

Where Timestamp Differences Come From

1. Clock drift

Every controller has an internal clock. Cheap real-time clocks drift by seconds per day, and the drift varies with temperature, which matters in hot DG rooms. Over months without correction, a clock can be minutes out.

2. Clocks never set correctly

Controllers often leave the factory, or come back from repair, with a default or roughly set time. If nobody sets it at commissioning, it can be hours or even days out.

3. Clock reset after power loss

If the controller’s clock backup battery is flat or missing, a power interruption can reset the clock to a default date. All subsequent data is then stamped wrongly. See RECD monitoring during a power failure: what should stay available.

4. Time zones

Many cloud platforms and some controllers store time in UTC (Coordinated Universal Time). Indian Standard Time is UTC+05:30. A reading taken at 14:02 IST is stored as 08:32 UTC. If one system shows UTC and another shows IST, they will be exactly 5 hours 30 minutes apart.

India doesn’t use daylight saving time, but some supplier platforms or servers abroad do. If a platform converts time using a time zone that has daylight saving, displayed times can shift by an hour for part of the year.

5. Date format ambiguity

Is 03/04/2026 the 3rd of April or the 4th of March? Different software and regions use different conventions. Exported CSV files are especially prone to this. The international ISO 8601 format (for example 2026-04-03T14:02:10+05:30) removes the ambiguity.

6. Measurement time vs recording time vs upload time

A gateway may read a value at 14:02:10, store it, and upload it to the cloud at 14:15:00 when the mobile network recovers. If the platform stamps data with the arrival time instead of the measurement time, buffered data appears late. See how to set up remote RECD alerts for an unattended site.

7. Interval labelling

If a system logs one-minute averages, is the value stamped 14:03 the average of 14:02–14:03 (labelled at the end of the interval) or 14:03–14:04 (labelled at the start)? Two systems with different conventions are offset by one interval, even with perfect clocks.

8. Different logging intervals

The DG controller may log every 10 seconds, the RECD controller every minute and the BMS on change only. Combining them needs care, because a “value at 14:02:30” may not exist in every log.

The Alignment Method: Anchor Events

You can’t usually go back and fix the clocks for old data. But you can measure the offset between two logs using events that leave a clear mark in both, which we’ll call anchor events, and then correct the data.

Good anchor events for RECD and DG logs

Anchor event	Mark in DG log	Mark in RECD log	Expected physical delay
DG start	Start time; running status	Inlet temperature begins rising; ΔP rises from zero	A few seconds to tens of seconds
DG stop	Stop time	ΔP falls towards zero; inlet temperature starts falling	A few seconds
Large load step	kW step	Step in ΔP and back-pressure	Seconds
Load transfer (ATS)	Transfer event	Step in ΔP if load changes	Seconds
Alarm raised by both systems	Alarm timestamp	Alarm timestamp	Should be near-simultaneous

DG starts and stops are usually the best anchors: they happen often, they’re unambiguous, and the physical delay is short. Temperature reacts a little slower than pressure, so ΔP is often the sharper marker.

Step-by-step

Choose a reference clock. Usually the system most likely to be accurate, such as a DG controller or BMS that is time-synchronised. Everything else is aligned to it.
List several anchor events over the period you’re analysing, ideally at least three, spread out in time.
For each anchor, note the time in the reference log and the time of the corresponding change in the RECD log.
Subtract to get the apparent offset. Allow for any known physical delay.
Check consistency. If offsets from different anchors agree, the clock was simply offset. If they increase over time, the clock is drifting.
Correct the data, by a constant offset or a time-varying one (see drift below).
Document the offset, method and anchors used, so the correction can be repeated or checked.

Worked Example: A Seven-Minute Offset and Slow Drift

The figures are illustrative. A site’s DG controller is synchronised to a network time source, so it is used as the reference. The RECD controller isn’t synchronised.

First, the offset

Anchor	DG log (reference)	RECD log	Marker used	Apparent offset
DG start, 3 Oct	14:02:10	14:09:22	ΔP starts rising	+7 min 12 s
DG stop, 3 Oct	17:45:00	17:52:12	ΔP falls to near zero	+7 min 12 s
Load step, 3 Oct	15:30:40	15:37:51	ΔP step	+7 min 11 s

The three anchors agree within a second: the RECD clock was about 7 minutes 12 seconds fast on 3 October.

Then, the drift

A month later, the same method gives:

Anchor	DG log	RECD log	Apparent offset
DG start, 2 Nov	09:15:00	09:22:51	+7 min 51 s
DG stop, 2 Nov	11:02:30	11:10:21	+7 min 51 s

The offset has grown by 39 seconds in 30 days, a drift of about 1.3 seconds per day.

Correcting the data

For data between 3 October and 2 November, subtract an offset that grows linearly from 7 min 12 s to 7 min 51 s. For example, for a reading in the RECD log on 18 October (15 days after the first anchor):

Offset ≈ 7 min 12 s + (15 × 1.3 s) ≈ 7 min 12 s + 19.5 s ≈ 7 min 31.5 s

Subtract that from the RECD timestamp to put the reading on the DG timeline.

For most RECD analysis, accuracy to within a minute is plenty, so a single average offset may be good enough. For detailed incident investigations, the drift correction is worth doing.

The time zone giveaway

If an offset comes out at almost exactly 5 h 30 min, one log is almost certainly in UTC and the other in IST. Correct the time zone first, then look for any remaining clock offset.

Avoiding the Problem: Synchronise at the Source

Correcting misaligned data is possible but tedious. Preventing it is far better.

Use network time synchronisation

Where the RECD controller, DG controller, BMS and gateways are on a network, synchronise them all to a common time source using the Network Time Protocol (NTP), specified in RFC 5905. On isolated operational networks, a local time server, itself synchronised periodically or to GPS, can serve all devices without internet access. See does an RECD need internet access to operate.

If network sync isn’t possible

Set the controller clock carefully at commissioning, against a reliable reference
Check and correct it at every maintenance visit, and log the correction. See what should an RECD event log record
Some gateways can push their own synchronised time to the controller. Ask the supplier.

Make sure clocks survive power loss

Confirm the controller’s clock has a working backup battery, or resynchronises automatically on start-up. Check it during blackout tests.

Store time unambiguously

Store timestamps in UTC, or with an explicit offset, in ISO 8601 format, for example 2026-10-14T08:32:10Z or 2026-10-14T14:02:10+05:30
Display them in IST for local users, clearly labelled
Export CSV files with ISO 8601 timestamps and a header stating the time zone

Record measurement time, not arrival time

Gateways and platforms should stamp each reading with the time it was measured, and keep that timestamp through buffering and upload. If they also record arrival time, keep both, in clearly named fields.

Agree interval labelling

For averaged data, document whether timestamps mark the start or end of each interval, and use the same convention across systems where possible.

A Spreadsheet Method for Finding the Offset

You don’t need specialist software to measure an offset. A simple spreadsheet approach:

Export the DG controller’s event log (start and stop times) and the RECD’s one-minute data (timestamp, ΔP, inlet temperature) for the same period.
Convert all timestamps to the same format and time zone. Make sure the spreadsheet treats them as date-times, not text.
In the RECD data, add a column that flags the first row of each run, where ΔP rises above a small threshold (say 5 mbar) after being below it.
Add a column that flags the last row of each run, where ΔP falls below the threshold after being above it.
List the flagged start and end times next to the matching DG start and stop times.
Subtract to get the offset for each pair, and format the result as minutes and seconds.
Plot the offsets against date. A flat line means a constant offset. A sloping line means drift, and the slope is the drift rate.
Apply the correction in a new column. Keep the original timestamps unchanged.

With one-minute RECD data, each offset is only accurate to about a minute. Using several anchors and averaging improves this. For finer accuracy, use higher-resolution data around the anchor events if the controller provides it.

Aligning Laboratory Test Records

Formal emission tests add another set of timestamps: the lab’s sampling start and end times. These must be aligned with the DG load log and the RECD’s own data to confirm that each sample was taken at the agreed load, with the device stable and not regenerating. See RECD testing during regeneration: what should be recorded.

Before a test:

Agree a single reference clock for the day, usually a synchronised DG controller or BMS
Ask the lab to set its instruments and log sheets to that clock, or to record the offset at the start and end of the day
Note the time of a clear anchor event, such as a load step, in every log

Afterwards, these steps make it straightforward to prove, for example, that a particulate sample started 12 minutes after load stabilised and ended before a regeneration began.

A Commissioning Checklist for Time Settings

RECD controller clock set to the correct date, time and time zone
DG controller, BMS, gateway and cloud platform time zones confirmed and documented
Network time synchronisation configured and working, where available
Clock backup battery present and confirmed by a power-off test
Measurement-time stamping confirmed through buffering and upload
Interval labelling convention documented (start or end of interval)
Export format uses ISO 8601 with time zone
Alignment check done: DG start vs RECD ΔP rise within a few seconds
Time settings recorded in the commissioning report

Add this checklist to your handover requirements. See closing the RECD punch list before handover.

Combining Logs With Different Intervals

Even with perfect clocks, logs recorded at different intervals need to be combined carefully:

Resample to a common interval, such as one minute, using averages for continuous values and “last state” for status values
Use events as-is for discrete occurrences like alarms or starts, without forcing them into intervals
Avoid interpolating across gaps. If RECD data is missing for 20 minutes, show it as missing, not as a straight line between the last and next values. See detecting missing data in RECD monitoring records

A Quick Alignment Check for Routine Use

Even with synchronisation in place, check alignment occasionally:

Pick a recent DG start in the DG controller log
Find the ΔP rise in the RECD log
Confirm they’re within a few seconds of each other, allowing for the logging interval
If not, investigate: has synchronisation failed? Did a power cut reset a clock?

This takes two minutes and can be added to the monthly event log review.

When Precision Really Matters: Incident Investigations

For routine trends, a minute either way rarely matters. In an investigation it can. Suppose an engine suffered damage during a long outage, and the question is whether high exhaust back-pressure caused it or followed it. The sequence of events matters:

Did back-pressure rise before the engine’s temperature or oil pressure alarms?
Did an RECD regeneration fail before back-pressure began to climb?
Did an operator shed load before or after the alarm?

With unsynchronised clocks, these questions can’t be answered with confidence. With synchronised clocks, or carefully corrected timestamps backed by documented anchors, the timeline becomes evidence. That evidence matters for insurance, warranty discussions with the RECD supplier or engine maker, and internal learning. See RECD warranty terms: parts, labour and exclusions.

Documenting Corrections

If you do correct timestamps, record:

Which log was corrected, and which was used as the reference
The anchors used, with their times in both logs
The offset and drift calculated
The correction applied (constant or time-varying), and the period it applies to
Who did it, and when

Keep the original data unchanged, and store corrected data separately. Anyone reviewing the analysis later, such as an auditor, supplier or regulator, should be able to see exactly what was done.

Common Misalignment Patterns and Their Causes

Pattern	Likely cause
Offset of exactly 5 h 30 min	UTC vs IST mismatch
Offset of exactly 1 h, appearing part of the year	Platform applying a daylight-saving time zone
Offset of a few minutes, growing slowly	Clock drift without synchronisation
Sudden jump to an old date (e.g. year 2000 or 2020)	Clock reset after power loss; flat backup battery
Offset of exactly one logging interval	Start-of-interval vs end-of-interval labelling
Days and months swapped for dates up to the 12th	Date format ambiguity (DD/MM vs MM/DD)
Data appearing in bursts, later than events	Arrival time used instead of measurement time

Frequently Asked Questions

How accurate do RECD timestamps need to be?

For trends and monthly reporting, within a minute is usually enough. For investigating incidents, such as which came first, an alarm or a load step, a few seconds’ accuracy helps. Network time synchronisation easily achieves that.

Should we store data in IST or UTC?

Either works if the time zone is stored explicitly with every timestamp. Many systems store UTC internally and display IST. The mistakes happen when timestamps are stored or exported with no time zone at all.

Can I correct old data that was logged with the wrong time?

Yes, using anchor events such as DG starts and stops to measure the offset and any drift, then applying a correction. Keep the original data unchanged and document the correction.

What’s the best anchor event?

DG start and stop events. They’re frequent, clearly logged by the DG controller, and produce sharp changes in RECD differential pressure and temperature within seconds.

Our RECD controller has no clock at all. What then?

The gateway, BMS or data logger that reads it should stamp each reading when it’s collected. Make sure that device’s clock is synchronised, and that it records measurement time, not upload time.

One Timeline, Every System

RECD data is only useful when it lines up with what the generator was doing. Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA. We can advise on time settings, synchronisation and data export for your monitoring set-up. See our certifications, or contact our team.

data analysis DG runtime logs NTP RECD monitoring time synchronisation timestamps

How to Align RECD Sensor Timestamps with Generator Runtime Logs