Serial Logging with Timestamps for Long Capture Sessions

A raw capture is only half the job; without timestamps you cannot correlate device output with what happened in the field.

When a serial link is the only window into a device, logging the session to a file turns a transient screen into evidence. For field faults that happen once an hour, or overnight, a timestamped log is what lets you find the moment something went wrong.

This article covers what makes a useful serial log, why timestamps belong on the capturing side, and how to keep long captures manageable.

Why log on the capturing side

Timestamps should be added by the terminal, not inferred from when you happened to read the screen. A capture that records the arrival time of each line lets you correlate device output with external events, shift changes, or power events long after the session ends.

Device output rarely carries its own clock, and even when it does, the device clock may be wrong or unset. A terminal-side timestamp is independent of the device and therefore trustworthy for ordering.

Choosing a log format

A plain text log with one timestamped line per received line is the most portable: it opens in any editor and diffs cleanly between sessions. A hex or mixed log preserves binary content for protocol work but is harder to read by eye.

For protocol debugging you may want both: a readable text log for the human and a hex capture for the bytes. Keep them as separate files so the readable one stays grep-friendly.

• Text log. Timestamped lines, easy to search and diff.
• Hex log. Preserves binary for frame analysis.
• Separate files. Keep readable and raw captures apart.

Handling long-running captures

An overnight or multi-day capture grows large. Rotating the log when it reaches a size, or at a time boundary, keeps any single file manageable and ensures a crash or disconnect loses only the most recent chunk rather than everything.

Also write the log to durable storage, not a temp directory that gets cleared. A capture lost to a cleanup script is worse than no capture, because it creates false confidence that the event was recorded.

Capturing both directions

For a request/response protocol the useful record includes what you sent, not just what the device returned. Logging the transmitted side as well lets you see whether a bad reply followed a malformed command or a correct one.

Mark the two directions distinctly, for example by prefixing sent lines, so a later reader can tell cause from effect without guessing which side spoke.

From log to finding

Once captured, the workflow is to narrow by time: find the anomaly, then read the minutes around it rather than the whole file. Timestamps make this search possible; without them you are scrolling blindly.

Pair the log with a short note of what changed in the field at each interval, power cycles, cable swaps, firmware loads, so the timestamped device output can be matched to real events during the post-mortem.

Naming logs so they survive

A log file named after the device, the date, and the session type stays useful months later. 'cabinet3-controller-2026-11-05-boot.log' tells the story without being opened; 'log3.txt' tells nothing and gets overwritten by the next incident.

Keep the capture directory flat and dated rather than nested by whim. When a fault report arrives quoting a date and a device, a dated filename is found in seconds, which is the entire reason for capturing in the first place. The log that cannot be found might as well not exist.

If the same device is captured repeatedly, append a short reason to the filename: '-after-fw-load' or '-intermittent'. The suffix is the context that turns a raw stream into a document someone else can act on without sitting through the whole session.

Capture from the board console, keep a hex view alongside the text log, and use the timestamps to locate Modbus frame errors after the fact.

Common questions

Should timestamps come from the device or the terminal?

From the terminal. Device clocks are often unset or wrong, and the device may not timestamp at all. A capture-side timestamp is independent and reliable for ordering events.

What log format is best for serial capture?

A plain text log with one timestamped line per received line is the most portable and searchable. Keep a separate hex capture when you need the raw bytes for protocol analysis.

How do I keep an overnight capture from getting huge?

Rotate the log by size or time so no single file grows unbounded, and write to durable storage rather than a temp directory that may be cleared.

Should I log what I send, not just replies?

Yes, for request/response work. Logging the transmitted side lets you see whether a bad reply followed a malformed command, which a receive-only log cannot show.

Why did my log file disappear?

Likely it was written to a temporary location that a cleanup process removed, or the capture crashed without flushing. Write logs to durable storage and verify the file after the session.

Keep reading