// ModbusManager Pro — Logging Settings

Modbus Logging Interval
and Deadband

Two settings decide whether a logging run is useful or useless, and both are easy to get wrong in the same direction: too fast, too much, too big to work with. This page has the arithmetic for choosing an interval, what a deadband actually saves, and the one thing a deadband quietly hides.

Download Pro trial — free 14 days All logging features

Modbus RTU, ASCII and TCP · Windows 10/11 · One-time license

// what an interval costs

Rows add up faster than people expect

Before choosing an interval, it is worth seeing what each one produces. These are rows per single logged signal, with no deadband.

Interval Per day Per month Per year
100 ms864 00025 920 000315 360 000
1 s86 4002 592 00031 536 000
5 s17 280518 4006 307 200
30 s2 88086 4001 051 200
1 min1 44043 200525 600
5 min2888 640105 120

Multiply by the number of signals. Twenty signals at one second for a month is 51.8 million rows. The same twenty at five seconds is 10.4 million. Nothing about the data changed — only whether you can open it afterwards.

// choosing an interval

Sample the event, not the clock

The right interval comes from the question you are trying to answer, not from what the software allows.

The rule of thumb worth remembering: sample at least five times faster than the fastest change you need to see. If a pump start takes two seconds to complete, a 400 ms interval captures its shape; a two-second interval may catch the start and the end and nothing between them.

Applied to the work people actually do:

100–500 ms
Debugging a sequence

Control word handshakes, drive ramps, a fault you are trying to reproduce. Run it for minutes, not days — this rate is for catching an event, not for record keeping.

1–5 s
Commissioning a plant

Enough resolution to see a load step or a string dropping out, and small enough to keep a week of data workable. This is the default most jobs should start from.

30 s – 5 min
Energy and trending

Consumption, temperatures, anything you will look at as a daily or monthly curve. A year fits comfortably and the export opens in a spreadsheet without complaint.

Two constraints sit on top of this. On a shared RS-485 line, the interval you can actually achieve is limited by the line itself — twenty devices at 9600 baud need about a second for one full pass, so asking for one second leaves no margin. See Modbus RTU data logger over RS-485 for the timing. And devices do not have to share an interval: each poll window keeps its own, so a meter read every 30 seconds can sit beside a drive read every second.

// deadband

Store the change, not the clock tick

A deadband writes a value only when it has moved by more than a set amount since the last stored value. On steady signals this is the difference between a database that stays small and one that fills a disk with identical readings.

The saving depends entirely on how much the signal actually moves. A tank temperature that changes twice an hour, sampled every second, produces 86 400 rows a day of which perhaps 50 carry information. A deadband removes the rest without losing the shape.

Choosing the amount is a measurement question, not a storage one. Set it slightly larger than the noise floor of the signal and smaller than the smallest change you would act on:

Signal Typical noise Reasonable deadband
Line voltage±0.2 V flicker0.5–1 V
Active powerlast digit dithering1–2% of rated load
Temperature±0.1 °C0.2–0.5 °C
Energy counternone, monotonicsmall or none — every increment matters
Status / state wordnone, discretenone — every transition is the point
What a deadband hides

A deadband records movement. It cannot record the absence of movement — and those two look identical in the data. If a signal sits perfectly still for six hours, so does the log. If the device stopped answering for six hours, the log also sits still.

So a deadband on its own is not proof that the link was alive. When the question you need to answer later is “was it running?” rather than “what was the value?”, log that signal without a deadband, or keep one plain time-based series alongside as a heartbeat.

// putting it together

A setup that survives a month unattended

  1. Split signals by purpose, not by device. Fast diagnostics, plant trending and energy counters want different intervals. Give each its own poll window.
  2. Set the interval from the event, then check the line can carry it. If the RS-485 arithmetic says no, raise the baud rate before lowering your ambition.
  3. Apply a deadband only to analogue signals with noise. Leave counters and status words alone.
  4. Keep one heartbeat series. One plain time-based signal with no deadband, so a gap in the record means a gap in reality.
  5. Estimate the row count before you leave. Interval, signal count and days — the table above. If the answer is tens of millions, change something now rather than at export time.
  6. Export a sample after an hour. Verify the format and the numbers while you are still on site. See logging Modbus data to CSV for the export traps.
// frequently asked questions

Interval and deadband — FAQ

What logging interval should I use for Modbus data?+
Sample at least five times faster than the fastest change you need to see. For debugging a control sequence that means 100–500 ms for a short run; for commissioning a plant, 1–5 s; for energy and long-term trending, 30 s to 5 min. One second per signal produces 86 400 rows a day, so twenty signals for a month is about 51.8 million rows — worth estimating before you start rather than at export time.
What does a deadband do?+
It stores a value only when the value has moved by more than a set amount since the last stored one. On a steady signal sampled every second, most rows are identical and carry no information; a deadband removes them while keeping the shape of any real change. Set it slightly above the signal’s noise floor and below the smallest change you would act on.
Should I put a deadband on every signal?+
No. Energy counters increase monotonically and every increment matters. Status and state words are discrete, and each transition is the reason you are logging them. Deadband belongs on analogue measurements that dither — voltages, temperatures, power readings.
How do I tell a flat signal from a dead connection?+
With a deadband you cannot, because both look like an absence of rows. Keep at least one series logged on a plain time interval with no deadband. If that series has a gap, the link was down; if it has rows and the others do not, the process really was steady.
Can different devices use different intervals?+
Yes. Each poll window has its own interval, so an energy meter read every 30 seconds can share a connection with a drive read every second. On a serial line the scheduler serialises the requests onto the one bus and always runs whichever window is due first.
// try it on your own devices

Set up a logging run free for 14 days

Full Pro edition, no credit card. Set an interval, add a deadband, let it run for an hour and export the result.

Download Pro trial — free 14 days

Windows 10/11 · 14-day trial · Pro from $119 one-time