Serial Port Utility Help Center

Quick start

Use this path when you only want to confirm that the software, driver, cable and target device can talk to each other.

Download the latest build from the Downloads page and install it.
Install the USB-to-serial driver required by your adapter or development board.
Plug in the target device and confirm the COM port appears in Device Manager.
Select the port and match the device parameters. A common first try is 115200 / 8 / 1 / None.
Choose Text mode for readable commands or logs. Choose Hex mode for binary frames and byte-level checks.
Send a short known command, then watch the connection state plus Rx and Tx counters.

If the first test fails, do not change many settings at once. Check the port, driver, cable, serial parameters and line ending in that order.

Connection and serial parameters

Serial communication only works when both sides agree on the same link settings.

Port: the COM port assigned by the operating system. Re-plugging a device can change it.
Baud rate: must match the target device. Common values include 9600, 115200, 460800 and 921600.
Data bits: usually 8.
Stop bits: usually 1.
Parity: usually None, but industrial devices may use Even or Odd.
Flow control: keep it disabled unless the device documentation explicitly requires RTS/CTS or XON/XOFF.
Line ending: AT-style devices often require CRLF; some older devices require only CR or LF.

Custom baud rates are available, but stable high-speed communication still depends on the serial chip, driver, cable quality and target firmware.

Quick Settings panel

Quick Settings is the column of frequently used options on the left of every connection: Connection Settings, Control Lines, Receive Settings and Send Settings.

The Quick Settings toolbar button only shows or hides the panel; it never changes the configuration.
To choose what the panel contains, open Settings and switch to the Quick Settings page. The application remembers the layout.

The page lists the four groups as a tree with a short description next to every entry:

Check or clear a group to show or hide it as a whole; keep at least one group checked.
Expand a group to check or clear its individual fields, so the panel only contains what you actually use.
Use Up and Down to reorder the groups, or the fields inside a group.

What the groups contain:

Connection Settings: the connection parameters. The port and mode selectors are always shown; baud rate, data bits, parity, stop bits and flow control can be hidden or reordered individually.
Control Lines: the DTR and RTS outputs and the Break button; serial connections only.
Receive Settings: receive format (Text or Hex), idle-interval line wrap and receive timestamps.
Send Settings: send format, loop send, line ending, checksum, sent-data echo and line-by-line send.

Display Send and Line by Line start hidden to keep the panel compact; enable them on the Quick Settings page when needed.

DTR, RTS and Break

DTR and RTS are serial control outputs. They are separate from the data bytes shown in Text or Hex mode and are available only for serial ports, not TCP or UDP connections.

Control Lines is a separate quick-settings group and appears only for serial connections; see Quick Settings panel for how to show, hide and arrange the groups.

DTR: check or clear Data Terminal Ready. The checked state is the requested output level for the current port panel.
RTS: check or clear Request To Send when flow control is None or XON/XOFF.
Break: press and hold the button to transmit a continuous break condition; release it to stop. Break is not a newline character and does not append CR or LF.

You can choose DTR and RTS before opening the port. The application applies those choices whenever it opens the port, including automatic reconnect and send-time reopen, and clears the physical outputs before a normal close. The requested levels can also be set on the settings dialog's Control Lines tab; they default to checked and are remembered across sessions, so boards that must not see DTR asserted on open only need to be configured once.

When RTS/CTS flow control is selected, the serial driver owns RTS and the manual RTS checkbox is disabled. Do not use manual RTS as RS485 transmit-direction control unless the adapter and driver explicitly require it; most USB-to-RS485 adapters handle direction automatically.

Checked means logically asserted. The voltage seen at a connector may be inverted by an RS232 transceiver or USB adapter. DTR also resets or enters the bootloader on many MCU boards, so clear it before opening when the target must not be reset. For bootloader or recovery sequences, follow the device vendor's required DTR/RTS order and Break duration.

Text and Hex workflows

Use Text mode when the protocol is readable: AT commands, startup logs, console output or line-based messages.

Use Hex mode when the protocol is binary: Modbus RTU, private UART frames, sensor packets, bootloader frames or data that contains non-printable bytes.

Practical checks:

If text looks garbled, confirm the baud rate first, then check encoding and display mode.
If a binary command does not work, compare the exact bytes in Hex mode.
If a command needs a line ending, configure the automatic suffix instead of typing invisible characters manually.
Keep sample frames with spaces, for example 01 03 00 00 00 02 C4 0B, so they are easier to review.

Automatic send and command lists

Automatic send is useful for polling, burn-in tests and repeated protocol checks.

Loop send: repeatedly sends the current command at a fixed interval.
Line-by-line send: sends multiple commands in sequence, one line at a time.
Send history: helps reuse common commands during repeated debugging.
Pause and Stop: use these states to inspect data or release the port before switching firmware or tools.

For device initialization scripts, put one command per line and test the sequence slowly before lowering the interval.

Logs and long-running capture

Turn on logging when a problem is intermittent or when you need to hand evidence to another engineer.

Recommended logging habits:

Enable timestamps for each received and sent line.
Use a filename template that includes the port, project or date.
Rotate logs by size or time for long tests.
Open the current log immediately after the issue appears and keep the original file.
Include a small sample frame in support requests so the symptom is reproducible.

For 24-hour tests or production benches, confirm the log location and rotation rule before starting the run.

CRC and Modbus checks

CRC failures are usually caused by one of four things: wrong payload bytes, wrong byte order, wrong CRC algorithm parameters, or missing line/frame boundaries.

Recommended workflow:

Copy the exact Hex payload without the CRC bytes.
Select the expected CRC algorithm, such as CRC-16/MODBUS when the device uses Modbus RTU.
Compare width, polynomial, initial value, xorout and reflection settings if the supplier document lists them.
Append the calculated CRC in the byte order required by the protocol.
Send the frame and compare the raw response bytes.

If a device returns nothing, first confirm the physical link and serial parameters. CRC debugging only helps after the device can actually receive the frame.

TCP and UDP debugging

Serial-to-network modules and gateways often need both sides checked together.

TCP Client: connect to a device, gateway or test server.
TCP Server: listen locally and observe incoming clients.
UDP: test datagram-based protocols, broadcast-like discovery or gateway forwarding.
Hex mode: use it for binary payloads over TCP or UDP, not only for serial ports.
Logs: save network-side traffic when comparing it with serial-side traffic.

When TCP or UDP fails, check IP address, port, firewall rules, subnet, gateway mode and whether another process already holds the same local port.

Cloud Console: a live web console

Cloud Console lets you view and operate a running Serial Port Utility from the browser: watch the port list and live TX/RX traffic, send data to a specific port, and open, close or reconfigure ports remotely.

Enable and use

Enable it on the desktop (all three switches are off by default):

Sign in inside the application (Cloud menu → Sign In); the device is bound to your account.
Check Cloud → Cloud Console. The device keeps a heartbeat with the cloud and shows as online in the web device list.
Check Allow Remote Send only if you want to send data from the web; without it the console is view-only.
Check Allow Remote Port Control only if you want to open/close ports or change parameters from the web; it is independent of Allow Remote Send.

Use it on the web:

Sign in at alithon.com, open "Cloud Sync" in the top navigation and pick "Cloud Console" in the sidebar.
The device list shows each bound device and its online state; click "Open Console" to enter the device page.
Port tabs match the desktop names, for example COM3 or TCP Client 192.168.1.10:5000. Select a port to watch its live RX/TX log.
In the send area choose Text or HEX (for example AA55010203) plus a line ending, then send to the selected port. Open/close and parameter changes live in the status panel.
"Recent Remote Commands" shows each command's state and failure reason.

Good to know

A live window, not a recorder: nothing is uploaded while nobody is watching, the page only shows traffic from the moment you open it, and the cloud keeps no history. Use desktop log files for complete records.
Waking up can take up to about 30 seconds after you open the page: the device learns about the viewer on its next heartbeat, then starts uploading the port list and events.
The live buffer is small: under heavy traffic the oldest lines are dropped and the log shows a "some log lines were dropped" notice.
A succeeded command only means the desktop wrote every byte to the port. It does not mean the target device received, understood or answered — judge that from the RX log that follows.
Common failure reasons: permission_denied (the matching desktop switch is off), port_closed (the target port is not open), commands are rejected while the device is offline, and unanswered commands are marked timeout.

Traffic and quota

Console event uploads (up) and remote commands (down) are metered as cloud traffic. Each direction has a monthly free allowance; overflow draws from your top-up balance, which is shared across both directions and does not expire.
Usage, ledger and top-ups live on the web "Cloud Traffic" page. With quota enforcement enabled, a direction is refused once the allowance and balance are exhausted, and the desktop switches Cloud Console off with a top-up prompt.

Security and privacy

Every remote capability is off by default and must be granted on the desktop machine itself; the web console cannot bypass the desktop switches.
Signing out stops all cloud features. These data flows are fully disclosed in the Privacy Policy — review it before enabling.

Troubleshooting checklist

Port does not appear:

Re-plug the USB device and try another cable or USB port.
Check Device Manager and install the correct CH340, CP210x, FTDI or vendor driver.
Confirm the device is powered and not in firmware-update-only mode.

Port cannot open:

Close other serial tools, IDE monitors and firmware flashing tools.
Re-check the COM number after device reboot.
Try unplugging and plugging the adapter again.

Device resets or enters the bootloader when the port opens:

Clear DTR and, if the board uses it, RTS before opening the port.
Confirm the board's boot strap sequence and remember that USB adapters may invert the logical signal.
If RTS/CTS flow control is enabled, RTS is driver-managed; disable hardware flow control before attempting a manual sequence.

No data received:

Confirm baud rate, parity, data bits and stop bits.
Confirm the target device actually sends data or replies to the command.
Check TX/RX wiring and RS485 A/B wiring.
Try a known-good command and a slower send interval.

Garbled data:

Start with baud rate and parity.
Switch between Text and Hex to decide whether the raw bytes are correct.
Check whether the device uses a different text encoding or binary protocol.

RS485 device does not respond:

Confirm A/B wiring, termination and common ground.
Make sure only one master is sending.
Verify device address, function code and CRC.

High baud rate is unstable:

Shorten the cable and use a better adapter.
Reduce the display load and enable logging.
Validate the exact rate before relying on it in long tests.

Orders, activation and Cloud Sync

The public website separates the desktop debugging workflow from account and service workflows.

Downloads: get the current Windows or macOS build and review release notes.
Service: purchase, order lookup and offline activation live in the service area.
Offline activation: prepare the CID shown by the application and the license information from your order.
Cloud Sync: account-based workflows cover device binding, licenses and settings sync; remote viewing and control live in the Cloud Console section above.
Privacy: review what data is collected before enabling online workflows.

If you only need local serial debugging, start with Downloads and the quick-start steps above.

Before contacting support

Please include as much of this information as possible:

Operating system and Serial Port Utility version.
Device model, adapter model and driver name.
Serial parameters: port, baud rate, data bits, stop bits, parity and flow control.
Text or Hex mode, line ending and the exact command you sent.
Screenshot of the connection state and Rx/Tx counters.
A short log file or sample frames showing both request and response.
For orders or activation: order number, checkout email, CID and license type.