How can I continuously log serial port data directly to a file?

Serial Communication
1

I need to capture and save all data coming over a serial port directly into a file for later analysis and debugging. I’m not sure what tools, commands, or scripts are best for this on my system, or how to set it up so the logging is reliable and doesn’t miss any data over long periods. Looking for practical steps, recommended software, or example configurations that will let me monitor the serial port and write everything to a file automatically.

2

If you just want your serial traffic logged 24/7 without babysitting it, you can totally script that with a serial port sniffer that accepts command-line arguments.

One option:
Serial Port Monitor from Electronic Team. Not shilling, just what I ended up using because it actually lets you control the basics from the command line: which COM port, where to save the log, and how big the log is allowed to get before it rotates/stops.

Basic command-line setup

Once it is installed, you can kick off logging from a shortcut, a batch file, or Task Scheduler. General idea looks like:

SerialPortMonitor.exe /port COM3 /log ‘C:\path\to\logfile.txt’ /maxsize 1048576

Where:

  • /port COM3 is the serial port you want to sniff
  • /log 'C:\path\to\logfile.txt' is your output file
  • /maxsize 1048576 is the max log size in bytes (that example is 1 MB)

Tweak the COM port and path for your setup.

Making it run automatically at boot

Two simple routes on Windows:

  1. Startup folder method

    • Create a shortcut with that command as the target.
    • Drop the shortcut into your startup folder:
      C:\Users\<your_user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
    • Next reboot, it launches on its own and starts logging.

  2. Task Scheduler method

    • Open Task Scheduler
    • Create a new task
    • Trigger: “At startup” (or “At log on” if you prefer)
    • Action: “Start a program”
    • Program/script: SerialPortMonitor.exe
    • Arguments: /port COM3 /log 'C:\path\to\logfile.txt' /maxsize 1048576

I usually go with Task Scheduler because you can get fancier with triggers and recovery options.

Restarting it daily so it does not bloat

If you are worried about memory leaks or just want a clean log per day, you can:

  • Create a scheduled task that runs at system startup (as above)
  • Add another trigger to the same task or a separate one that runs at, say, 00:00 every day and restarts the task/program

In Task Scheduler you can also:

  • Set the task to stop after X hours and then run again
  • Or have a second task that kills the process at midnight and relaunches it with the same command line

End result: once you set this up, you do not have to click anything. Windows boots, the serial monitor starts, it watches your chosen COM port, and it keeps appending to your log file up to the size limit you picked, all hands-off.

8 Likes
3

If you want continuous logging, @mikeappsreviewer’s approach with Serial Port Monitor from Task Scheduler is solid, but I’d set it up a bit differently and also keep a “plan B” that doesn’t depend on any GUI config.

1. Use Serial Port Monitor, but rotate logs cleanly

Since you’re already looking at Serial Port Monitor, I’d lean into its strengths and keep the config portable:

  • Create one small batch file, something like:
@echo off
set PORT=COM3
set LOGDIR=C:\serial_logs
set DATESTAMP=%DATE:~10,4%-%DATE:~4,2%-%DATE:~7,2%

if not exist '%LOGDIR%' mkdir '%LOGDIR%'

rem daily log file, not one giant blob
SerialPortMonitor.exe ^
  /port %PORT% ^
  /log '%LOGDIR%\serial_%DATESTAMP%.log' ^
  /maxsize 52428800 ^
  /append

Differences from what @mikeappsreviewer suggested:

  • I prefer a new log per day (serial_YYYY-MM-DD.log) instead of one file that keeps growing.
  • The \append behavior keeps the file for that day instead of nuking it if the process restarts.
  • You can stick this batch in version control so your logging setup is documented.

Then in Task Scheduler:

  • Trigger: “At system startup”
  • Program: C:\path\to\start_serial_logging.bat
  • In Settings, check “Restart the task if it fails” to avoid silent stops.

If you want a simple description to drop in your docs:
The Serial Port Monitor app is a Windows tool for capturing, analyzing, and saving serial port traffic in real time, with support for automated logging, COM port selection, and detailed data views for debugging embedded devices, industrial controllers, and serial-based equipment.

More info here:
serial port data logging and analysis tool

2. Plain script solution (no GUI, more control)

If you’d rather keep it script-only and not rely fully on Serial Port Monitor:

PowerShell on Windows

param(
    [string]$Port = 'COM3',
    [int]$Baud = 115200,
    [string]$LogDir = 'C:\serial_logs'
)

if (-not (Test-Path $LogDir)) { New-Item -ItemType Directory -Path $LogDir | Out-Null }

while ($true) {
    $date = Get-Date -Format 'yyyy-MM-dd'
    $logFile = Join-Path $LogDir 'serial_$date.log'

    $portObj = New-Object System.IO.Ports.SerialPort $Port, $Baud, 'None', 8, 'One'
    $portObj.ReadTimeout = 500
    $portObj.Open()

    try {
        while ($true) {
            $line = $portObj.ReadExisting()
            if ($line.Length -gt 0) {
                Add-Content -Path $logFile -Value $line
            } else {
                Start-Sleep -Milliseconds 50
            }
        }
    } catch {
        Start-Sleep -Seconds 2
    } finally {
        $portObj.Close()
    }
}

Run that as a scheduled task “At startup.”
Pros over a GUI logger:

  • Easier to customize (timestamp every line, rotate by size, compress old logs, etc.).
  • You can add sanity checks, like auto-reopening the port if another program briefly grabs it.

3. If you’re on Linux or WSL

If you’re not strictly on native Windows, a terminal-based solution can be nice:

Using screen:

screen -L -Logfile /var/log/serial_$(date +%F).log /dev/ttyUSB0 115200

Then put that in a systemd service and it auto-restarts and logs 24/7.

Using pyserial in Python for precise control:

import serial, time, os, datetime

PORT = '/dev/ttyUSB0'
BAUD = 115200
LOGDIR = '/var/log/serial_logs'
os.makedirs(LOGDIR, exist_ok=True)

while True:
    date = datetime.date.today().isoformat()
    logfile = os.path.join(LOGDIR, f'serial_{date}.log')
    with serial.Serial(PORT, BAUD, timeout=0.5) as ser, open(logfile, 'a', buffering=1) as f:
        while True:
            data = ser.read(1024)
            if data:
                f.write(data.decode(errors='replace'))
            else:
                time.sleep(0.05)

4. Things people forget until it bites them

  • Baud / framing mismatch = garbage log. Double-check baud, parity, stop bits.
  • If you need timestamps, don’t rely on the tool’s default; explicitly log them in your script or use Serial Port Monitor’s timestamp view.
  • Watch for disk usage if you log binary data at high speed. Rotate logs and optionally zip old ones.
  • If the same COM port is used by another app, you may want Serial Port Monitor’s sniffing mode rather than direct reading, but that’s more advanced.

Bottom line:

4

If you just need all serial data dumped to disk forever, you’ve already got two decent roads from @mikeappsreviewer and @shizuka. I’ll poke at their ideas a bit and then add some alternatives so you’re not locked into a single tool or OS.

1. When using Serial Port Monitor actually makes sense

They’re right that Serial Port Monitor is a solid choice if you’re on Windows and want something you can set once and forget. Where I’d tweak things:

  • Use it when:

    • You need to sniff a port that another app is using.
    • You want higher level views (hex, parsed, etc.) in addition to raw logging.
    • You want an “it just works” solution instead of maintaining your own script.

  • Be careful when:

    • Your machine is headless or super locked down. GUI tools can be annoying over RDP or on servers.
    • You need very specific timestamp formats or custom log rotation rules. Scripts win there.

If you decide to go that route, grab the installer from here:
get Serial Port Monitor on your system
Then combine it with Task Scheduler like they described, and you’re basically done.

I don’t totally agree with having one huge log by size limit like @mikeappsreviewer showed. Big single logs suck to open and search. Daily or hourly rotated logs, like @shizuka suggested in the batch file, are much safer in real life debugging.

2. “Pure CLI” on Windows without relying on a specific app

If you want to avoid any external tools and just use standard stuff:

Using mode + PowerShell minimalism

You can set up the serial port with mode and then pipe with PowerShell:

@echo off
rem Configure serial port
mode COM3: BAUD=115200 PARITY=N DATA=8 STOP=1

powershell -NoProfile -Command ^
  '$port='COM3'; $logDir='C:\serial_logs';' ^
  'if (-not (Test-Path $logDir)) { New-Item -ItemType Directory -Path $logDir | Out-Null }' ^
  'while ($true) {' ^
  '  $date = Get-Date -Format 'yyyy-MM-dd_HH';' ^
  '  $logFile = Join-Path $logDir (`'serial_$date.log`');' ^
  '  $sp = New-Object System.IO.Ports.SerialPort $port,115200,'None',8,'One';' ^
  '  $sp.Open();' ^
  '  try { while ($true) { $d = $sp.ReadExisting(); if ($d.Length -gt 0) { Add-Content -Path $logFile -Value $d } else { Start-Sleep -Milliseconds 50 } } }' ^
  '  catch { Start-Sleep -Seconds 1 }' ^
  '  finally { $sp.Close() }' ^
  '}'

Stick that in a .bat, run it via Task Scheduler “At startup”. You now have hourly logs like serial_2025-11-25_14.log.

Why this over Serial Port Monitor:

  • Full control over:
    • Rotation policy (hourly, daily, by size… whatever)
    • Encoding and timestamps
    • Recovery logic if the port dies
  • No dependency on a 3rd‑party GUI tool.

Downside: you’re now the maintainer. If something breaks, it’s your script.

3. Simple Linux-style approaches (if you ever do this on Linux)

They didn’t go into native Linux much, so here are a couple:

a) screen or minicom just dumping to file

screen -L -Logfile /var/log/serial_$(date +%F).log /dev/ttyUSB0 115200

or with minicom:

  1. sudo minicom -s
  2. Set serial port, speed, etc.
  3. Enable capture file.
  4. Then wrap it with a systemd service so it auto-starts.

Fine for simple stuff, but kind of a pain to automate rotation.

b) Systemd + cat + logrotate

If you just want raw bytes:

Service file /etc/systemd/system/serial-log.service:

[Unit]
Description=Serial port logger
After=network.target

[Service]
ExecStart=/bin/bash -c 'stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb && cat /dev/ttyUSB0 >> /var/log/serial.log'
Restart=always

[Install]
WantedBy=multi-user.target

Then set up /etc/logrotate.d/serial:

/var/log/serial.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

This is dead simple, no GUI, and runs 24/7. The serial config with stty is the only “gotcha.”

4. Practical stuff people only notice once it’s broken

Regardless of tool or script:

  • Get the serial params right
    If baud / parity / stop bits are wrong, your log is useless noise. Triple check: 9600 vs 115200, N81 vs even parity, etc.

  • Decide if you need timestamps

    • If you’re debugging protocol timing, log timestamps with each line or frame.
    • If you’re just capturing content, raw data is fine.
      With Serial Port Monitor this is built in. In scripts you can wrap each line with something like [yyyy-MM-dd HH:mm:ss.fff] data.

  • Think about binary vs text
    If your device sends binary, don’t try to log as plain text. Either:

    • Use a tool like Serial Port Monitor that can dump hex.
    • Or write a script that writes raw bytes to a .bin file.

  • Disk and rotation
    Big logs grow silently until the disk is full, and then everything dies in a very annoying way. Log rotation is not optional if you’re doing 24/7 logging at any nontrivial rate.

5. When I’d personally choose each route

  • Serial Port Monitor

    • Windows only
    • You want to start fast
    • You might also want live analysis views, hex, sniffing another app, etc.
    • You’re ok with a 3rd‑party tool handling the ugly details

  • PowerShell / batch script

    • You want insane flexibility and full control
    • You don’t mind debugging your own script at 2am when it misbehaves
    • You just need raw dumps, maybe with timestamps and custom rotation

  • Linux cat + systemd + logrotate

    • You’re on Linux, headless, and like simple tools
    • You value reliability over fancy UI

So yeah, @mikeappsreviewer and @shizuka are on the right track with Serial Port Monitor for an “install once, schedule, forget it” solution. I’d just lean a bit more on sane log rotation and have at least one no-GUI fallback (script or systemd) so you’re not stuck if the tool changes, breaks, or you move to another box.

5

If you just want another angle instead of repeating what’s already been said:

@shizuka and @andarilhonoturno are basically on the “script it yourself” side (PowerShell, systemd, cat, etc.), while @mikeappsreviewer is on the “let a tool handle it” side with Serial Port Monitor. Both camps work; the real choice is how much control vs. convenience you want.

To complement their ideas, here’s how I’d structure things in practice.

1. When a dedicated tool like Serial Port Monitor is worth it

If you are on Windows and this is a production-ish box, a GUI + CLI hybrid like Serial Port Monitor is not a bad compromise.

Pros:

  • Can spy on ports another program already opened, which is hard to DIY.
  • Command line flags fit nicely in Task Scheduler or a service wrapper.
  • Built-in views: text, hex, mixed, filters, timestamps without writing any code.
  • Easier for coworkers who are not comfortable editing scripts.

Cons:

  • Closed source and you depend on someone else’s update cycle.
  • Less flexible log format and rotation rules compared to your own script.
  • Not ideal on headless or very locked-down servers.
  • Licensing if you need it on several machines.

I slightly disagree with the “just one big file with a size limit” pattern. Huge flat logs are painful to grep and parse. I’d rather have Serial Port Monitor create daily or hourly logs and archive them, even if that means a few more settings up front.

A neat hybrid: use Serial Port Monitor only as a raw binary dumper, then run your own parsing and timestamp injection offline with Python or similar. That splits the problem: stable capture, flexible analysis.

2. Extra approaches that were not really covered

A. Windows service wrapper for a script

If you like the PowerShell examples from @shizuka but dislike babysitting console windows, wrap the script as a Windows service:

  • Write your serial logger in PowerShell or C# using System.IO.Ports.SerialPort.
  • Use a small service host (like nssm or a custom Windows service in C#) to run it in the background.
  • Rotate logs by size, not only by time. For example: start a new file every 50 MB, keep the last N files.

Why I prefer this over pure Task Scheduler for 24/7 capture:

  • Services restart automatically on failure and do not need a user login.
  • You can add dependencies (e.g. wait for specific drives to mount).
  • You can configure recovery actions on repeated crashes.

B. Structured logging instead of raw text

Everyone so far focused on “dump bytes to a txt file.” That is fine for quick checks, but for debugging over weeks, consider a structured log:

  • For ASCII protocols: write JSON lines like
    { 'ts': '...', 'dir': 'rx', 'len': 27, 'data': '...' }
  • For binary: store hex or base64 inside the JSON.

This makes later analysis trivial:

  • Filter by time ranges.
  • Search for specific patterns or frame types.
  • Import into tools like Elasticsearch, Splunk, or a simple SQLite DB.

You can still use Serial Port Monitor as the capture engine and have a secondary process convert its raw log to structured form periodically.

3. About the competitors’ approaches

  • @shizuka leans on built-ins and scripting. Powerful for control freaks, but you must maintain it.
  • @andarilhonoturno adds more Linux-centric and systemd-oriented methods, great if you are on a server or embedded box.
  • @mikeappsreviewer shows the “install once and forget” style with Serial Port Monitor which is probably the fastest path to something running today.

None of these are wrong. The trick is:

  • If you care about repeatability and portability, go with a script / service so you can move it between machines and OSes.
  • If you care about low friction and sniffing another app’s session, a dedicated sniffer like Serial Port Monitor is usually easier.

4. A simple decision path

Ask yourself:

  1. Do I need to monitor a port used by some existing program?

    • Yes → Serial Port Monitor is the straightforward choice.
    • No → Your own script or systemd service is cheaper and more customizable.

  2. Do I need custom timestamps, framing, or protocol decoding now or later?

    • Yes → Script or small custom app, possibly fed from Serial Port Monitor logs.
    • No → Built-in logging in Serial Port Monitor is fine.

  3. Is this going to run unattended for weeks or months?

    • Yes → Whichever route you pick, add:
      • Log rotation by size or time.
      • Auto restart on failure.
      • Disk space monitoring or at least a cap on total log size.

If you follow those points and pick either a script-based path like @shizuka and @andarilhonoturno or the Serial Port Monitor setup from @mikeappsreviewer, you will have continuous, hands-off serial logging that survives reboots and is still usable when you come back to analyze it.