Phones have no serial port and cannot speak RS-232, so something must sit in between: a microcontroller bridging to Bluetooth for a nearby phone, a Wi-Fi or cellular gateway for fixed and remote installations, or a service on a PC already cabled to the device. Choose by where the device physically lives.
There is an enormous amount of equipment in the world that works perfectly and cannot talk to anything made after about 2005. Engine management systems, industrial controllers, laboratory instruments, medical devices, weighing systems, machine tools. They speak RS-232, RS-485, or a proprietary framing over a serial line, and they will outlive several more generations of phone.
The instinct is to replace them. That is usually the wrong call: the hardware is expensive, frequently certified for its role, and often more robust than whatever would replace it. Bridging is nearly always cheaper than replacing, and nobody has to re-certify anything.
Why the phone cannot just do it
Worth being precise, because the gap is bigger than it looks. RS-232 is not merely an old connector. It is a different electrical standard — voltage levels swinging positive and negative, well outside anything a phone's hardware handles — carrying an asynchronous byte stream with no addressing, no framing guarantees, and no error recovery beyond whatever the device's own protocol invented.
Phones have no serial port and no driver model for one. So the question is never "how do I connect the phone to the device." It is "what sits in the middle, and where does it live?"
The four bridge architectures
| Bridge | Use when | Trade-off |
|---|---|---|
| Microcontroller → BLE ESP32 or nRF52 wired to the serial port, speaking Bluetooth to a phone | The device is mobile or the operator stands next to it | Only works in range; BLE has real throughput limits |
| Wi-Fi / Ethernet gateway Same idea, publishing onto the local network | Fixed installation with existing network | Needs power and network; someone must own the credentials |
| Cellular gateway Bridge with its own modem | Remote sites, no usable network | Ongoing SIM cost; power budget matters |
| PC-side service A small program on a machine already cabled to the device | A computer is already attached and stays on | Inherits that machine's reliability and its Windows updates |
Choose by asking where the device physically lives and who needs the data, not by which technology is most interesting. The most common mistake is reaching for cloud connectivity when the actual requirement was one engineer standing beside the machine with a phone.
Reverse engineering a protocol nobody documented
Sometimes the manual exists. Frequently it does not, or it describes a firmware revision from 1998 that does not match the unit in front of you. The method that works is capture first, theorise later:
- Tap the line passively. Do not transmit yet. Record what flows while the device is operated normally. Writing to a device you do not understand is how you brick it.
- Log physical reality alongside the bytes. Note what the machine was doing, and what its own display read, at each moment. This correlation is the entire key; without it you have a pile of hex.
- Look for structure. Most protocols reveal themselves quickly: a repeating start byte, fixed-length records, a length field, a trailing checksum. If a byte increments once per message, that is a counter. If the last byte changes when any other does, that is a checksum.
- Change one thing. Alter a single physical variable — raise a temperature, move a lever — and watch which bytes move. This maps fields to meanings faster than any amount of staring.
- Only then transmit, starting with a command you can observe and reverse safely.
Two practical notes. Checksums are usually simple — a sum of the payload truncated to a byte, or a small XOR — and worth solving early, because you cannot send valid commands without one. And byte order will be wrong on your first guess about half the time; try the other one before concluding the field is not what you thought.
The parts that surprise people
Latency is a design constraint, not a detail. "Live" means different things: a dashboard refreshing every few seconds is easy, and half-second updates over BLE require thinking about polling rate, packet size and connection interval together. Decide the number early, because it shapes the architecture.
The device is not a database. Many serial devices answer only when asked, hold no history, and will happily be overwhelmed if polled too aggressively. Whatever stores history is something you are building, not something you are reading.
Reconnection is most of the reliability work. The device power-cycles, the phone sleeps, someone unplugs the cable. Recovering cleanly from each — without duplicating or losing readings — is where the real engineering hours go. As with any companion app, the demo is easy and the edge cases are the product.
What it costs, honestly
The integration itself is ordinary work. The risk sits entirely in one question: is the protocol documented?
If yes, this is a normal project — we quote embedded and IoT work from $4,500, scoped per project. If no, the honest approach is a short paid discovery phase to capture and decode the protocol, then a fixed quote against what was actually found. Anyone giving you a firm number for decoding a protocol they have never seen is either padding heavily or about to be unpleasantly surprised, and both end up costing you.
We have done exactly this shape of work: a decades-old engine management system wired to a native iOS app and a web dashboard with half-second refresh over BLE, for a motorsport equipment maker in Monza — the build log is here.
Book a free 30-minute discovery call. We do firmware, apps and the bridge between them — including the unglamorous protocol archaeology.
Book a free discovery call