Transfer Serial Data to the Cloud

Yes, but with a real caveat you need to design around. A physical COM port is exclusive-open — one process at a time — so a local application and the cloud can't both hold the same real port directly. The workable pattern is a virtual-port pair on the local machine: the local app talks to a virtual port, SEC bridges it to the real port, and the cloud connection shares that same bridged data.

The honest warning: once both a local app and a cloud app are attached to one device, their traffic can mix. Inbound data from the device fans to both consumers (fine for read-only), but if both sides send commands, those commands interleave on the single physical UART and corrupt each other. So "local and cloud at once" is safe for shared reading; for commanding the device, make sure only one side writes at a time.

Answered by Nikolai Svarachevsky · Lead Developer

Yes — this is a fan-in topology and it works well. On the cloud machine you create one virtual COM port per source, each fed by a client connection dialing in from its respective site (or by servers at each site that the cloud connects out to — the connection types are interchangeable). Your cloud application then sees a separate, clean COM port for each remote device.

The design rule that keeps this sane: give each source its own virtual port rather than merging several devices into one port. If you funnel multiple devices into a single port, their bytes arrive interleaved with no way to tell which came from which. One port per remote device — and remember each site's link carries its own internet latency, so size timeouts per source, not on a single assumption.

Answered by Nikolai Svarachevsky · Lead Developer

Throughput is almost never affected in any way you'd notice, because serial data rates are minuscule compared with network bandwidth — even a fast serial link is a trickle next to a normal internet connection, so SEC isn't bandwidth-bound. What SEC and the network add is latency, not a throughput ceiling: a small software overhead plus the round-trip time of the path to the cloud.

For continuous or bulk transfer that latency is a one-time pipeline delay and effective throughput stays high. Where it shows up is chatty request/response traffic, where every exchange pays the round-trip and the effective rate drops even though raw bandwidth is ample. If that's your pattern over a long cloud path, reduce the number of round-trips (batch requests, keep a poller local to the device) rather than expecting SEC to speed up the link.

Answered by Bohdan Miniv · QA Engineering

The signal-line state is carried when you use Telnet (RFC 2217) mode: the remote application's RTS/DTR changes are transmitted and applied at the physical port, and line states like CTS/DSR/DCD are reported back. In Raw mode none of this is carried — Raw moves data only. So for signal control, use Telnet mode.

The honest limit is timing, not capability. RFC 2217 carries control-line changes in-band and loosely synchronized with the data stream, so over a cloud link with buffering and internet latency, the exact moment a line changes relative to the data is not deterministic. For status signals and setup that's fine. For real-time uses — software-driven half-duplex RS-485 direction switching, or precisely-timed BREAK — don't drive the line remotely over the internet; handle that timing locally at the device and use the cloud link only for data.

Answered by Nikolai Svarachevsky · Lead Developer

Yes. In Raw mode SEC has a Signal Lines tab where you can configure which signal lines are raised or lowered on connection — so you can have a line asserted when a network client attaches and dropped when it disconnects. That's exactly the "a remote client is now attached" indicator you're describing, and it's a supported setting rather than something you have to improvise.

Worth understanding the distinction from Telnet mode: there, SEC reflects the actual hardware line states between the two ends, so the lines follow the device rather than the connection. The configurable connect/disconnect line behavior is the Raw-mode feature. Set the specific lines and their on-connect / on-disconnect states in that tab; if your target line or polarity isn't among the options, describe the exact goal to support and we'll confirm what the current build allows.

Answered by Bohdan Miniv · QA Engineering

SEC has a keep-alive setting that handles exactly this. It periodically checks that the link is still live, so a connection that has silently dropped is detected and torn down rather than sitting there looking alive. By adjusting the keep-alive timing you control how closely SEC watches the link — shorter intervals detect a drop faster, longer ones are more relaxed.

The reason this matters is that a silently dropped network path — a "half-open" TCP connection where one side vanished without a proper close — can otherwise appear connected until something actually tries to send data. The keep-alive check is what surfaces that quickly and lets the connection re-establish cleanly. Tune the timing to your needs: tight enough to catch a real drop promptly, loose enough that a naturally quiet device isn't flagged during normal idle periods.

Answered by Bohdan Miniv · QA Engineering