Serial to Ethernet Converters: A Byte’s Journey from RS232 to RJ45

You have a temperature sensor and it sends a byte: 0x7F. This byte needs to get to your computer that’s 200 meters away.

A serial to Ethernet converter is what makes this happen. You plug the temperature sensor into one side of the converter and an Ethernet cable into the side and somehow the byte arrives at your computer.

What is really going on inside that little box? Where does the byte go when it is sent? What gets added to the byte? What gets taken away from the byte?

Let us follow one byte on its journey. The byte starts at the temperature sensors RS485 port then it goes through the converter across the network and into your software.

The Starting Point: One Byte, One Serial Port

The byte in question is 0x7F. In binary: 01111111. It comes from a Modbus RTU temperature sensor configured for 9600 baud, 8 data bits, no parity, 1 stop bit (8N1).

The physical layer is RS485, though the same principles apply to RS232. The sensor’s UART converts the byte into a sequence of voltage transitions on two wires (A and B). A logic 0 creates a voltage difference where A is higher than B; a logic 1 does the opposite.

The byte travels a short distance—one or two meters—to the converter’s serial port. At this stage, it’s purely electrical. No addressing, no error checking, just voltage levels changing at 9600 times per second.

Stage 1: Leaving the Temperature Sensor

The temperature sensors UART takes the byte. Turns it into electrical signals.

For RS485 the UART creates a voltage difference between two wires, wire A and wire B. When the byte has a logic 0 wire A is higher than wire B. When the byte has a logic 1, wire B is higher, than wire A.

The byte travels down the wire. It’s only a meter or two to the converter—short enough that signal degradation isn’t an issue.

The physical layer follows the TIA/EIA-485 standard , which defines the voltage levels and timing for RS485 communication.

Stage 2: Entering the Converter

The converter has a chip that looks at the voltage on the A and B lines of the RS485. It checks to see what the voltage is. Says “okay that is a 0” or “that is a 1”. Then it uses this information to figure out the bits.

The converter has to do this at the right time. The converter is set to check the line at a speed, which is 9600 times, per second. This means it looks at the line every 104.17 microseconds. If the converter checks soon or too late it gets the wrong bit from the RS485. The RS485 is very sensitive so the converter has to be careful when it is checking the bits.

This is why the baud rate of the device and the converter need to be the same. If the sensor is sending information at 9600 baud rate but the converter is expecting 19200 baud rate the converter is going to check for information as often as it should. This means the converter will read a lot of nonsense information.

The converter gets all eight bits of the information puts them to form the byte 0x7F. Then it saves this byte in a small memory buffer. The converter has to do this with the baud rate of the device and the baud rate of the converter being the same so it can get the information, from the sensor and the device.

Stage 3: Waiting in the Buffer

Now the byte is inside the converters memory. The byte is joined by bytes from the same sensor, maybe the rest of the Modbus query.

The converter does not send every byte away over Ethernet. This would not be a way to do things. Each Ethernet packet has a lot of information like MAC addresses and so on, which takes up 18 bytes, plus 20 bytes for the IP header and 20 bytes, for the TCP header. So that is 58 bytes. If the converter sent one byte at a time it would waste a lot of bandwidth. The converter and Ethernet and the Modbus query would not work well together if it did that. The converter and the Ethernet and the Modbus query need to work in a better way.

Instead, the converter waits. It uses one of three rules to decide when to send:

• Packet timeout: If no new bytes arrive for X milliseconds, send whatever’s in the buffer.
• Packet length: When the buffer reaches Y bytes, send immediately.
• Character trigger: When a specific byte arrives (like a carriage return), send.

For our byte lets say it has to wait for 10 milliseconds. So it waits. Then more bytes, from the message show up. After 10 milliseconds have passed and no new bytes have arrived the converter thinks that the message is complete. The converter decides this about the message.

Now it has a block of data ready to send.

Stage 4: Wrapping for the Network

The converter wraps the data in layers of headers. Each layer has a specific job.

First: TCP header

The TCP header contains:

• Source port (configured for this serial port)
• Destination port (the port your software listens on)
• Sequence number (to track order)
• Checksum (to detect errors)

The Transmission Control Protocol is a way of connecting that makes sure everything gets through. It guarantees that every single byte of information arrives and it does so in the order without sending anything twice. If for some reason a packet of information gets lost the Transmission Control Protocol will send it again.

Second: IP header

The IP header contains:

• Source IP (the converter’s address)
• Destination IP (your computer’s address)
• Protocol number (6 for TCP)

Third: Ethernet header

The Ethernet header contains:

• Source MAC (converter’s hardware address)
• Destination MAC (next switch or your computer)
• Ethertype (0x0800 for IP)

The complete packet now looks like:

[Ethernet header][IP header][TCP header][YOUR DATA]

Our byte 0x7F is deep inside, unchanged.

Stage 5: Out the RJ45 Port

The complete Ethernet frame comes out of the converters RJ45 jack. This is really a bunch of voltage changes that happen on the twisted pairs inside the Ethernet cable. The way it works is different from RS485. The basic idea is the same: the voltage changes are what represent the bits in the Ethernet frame.

The Ethernet frame then goes through switches. Each switch takes a look at the destination MAC address of the Ethernet frame. Sends the Ethernet frame on its way to your computer. If the destination of the Ethernet frame is, on a network the routers remove the Ethernet header from the Ethernet frame and then send it on its way based on the IP address of the Ethernet frame.

At every hop, our byte is just cargo. Nobody looks at it. Nobody changes it.

Stage 6: Arriving at the Computer

Your computers network card gets the frame. It looks at the destination MAC address.. It matches mine. The network card removes the Ethernet header. Then it sends the IP packet to the operating system.

The OS checks the IP header. Destination IP matches. It strips off the IP header and looks at the protocol field: TCP. It passes the TCP segment to the TCP/IP stack.

The TCP stack checks the destination port. Is any program listening on that port?

Two possibilities:

If a program has a socket on that port the TCP stack sends the data right to it. The program gets the byte stream like the sensor sent it. Our byte 0x7F shows up along, with the rest in the order.

If no program is listening, the TCP stack sends a “connection refused” response. The data never reaches an application.

Stage 7: Through Virtual COM Port (Optional)

Many factories still use software that only works with a real serial port. This software can’t connect to a socket.

That’s where virtual COM ports come in. They help by creating serial ports like COM5 or COM6 on Windows computers. When an application tries to use COM5 the virtual COM software takes over. It then opens a connection, to the IP address and port of the converter.

For our byte’s return journey:

1. Application writes to COM5
2. Virtual COM driver catches the write
3. Driver sends the data over TCP to the converter
4. Converter receives it and sends out the serial port

The application never knows the device is 200 meters away. It thinks COM5 is plugged directly into the computer.

The Return Journey: Same Path, Opposite Direction

When your software sends data back to the device, the process reverses:

1. Application sends bytes (via socket or virtual COM)
2. Computer wraps them in TCP/IP/Ethernet headers
3. Packet travels across network
4. Converter receives it
5. Converter strips off all headers
6. Converter sends raw bytes out the serial port at the configured baud rate
7. Device receives them

What About Different Modes?

Our journey assumed TCP connection. But converters support other modes too.

TCP Server mode (what we just followed): Converter listens, computer connects. Most common.

TCP Client mode: Converter initiates the connection. It reaches out to a specific IP and port. Useful when the converter is behind a firewall or has a dynamic IP.

UDP mode: No connection is established. The converter simply sends data packets to an IP address and port number. It does not check if anyone is listening. This method is faster. Has less overhead. However there is no guarantee that the data will be delivered. It is suitable, for sending broadcast data. This is also okay if occasional data loss is acceptable.

What the Converter Doesn’t Do

It’s worth understanding what the converter doesn’t do:

It doesn’t interpret your data. Our byte 0x7F could be temperature, pressure, or part of a Modbus query. The converter doesn’t know and doesn’t care. It just moves bytes.

It doesn’t change baud rate mid-stream. Whatever you configure is what it uses. If your device changes baud rate, the converter won’t follow.

It doesn’t store data long-term. The buffer holds data temporarily, but if power fails, everything in the buffer is lost.

It doesn’t have a display. You configure it through a web page or utility, then mount it and forget it.

Real Converter, Real Journey

Let’s trace this with an actual device, the 1CH-RS232/485/422-ETH from Valtoris:

1. Sensor sends 0x7F at 9600 baud, 8N1
2. Converter’s RS485 chip captures it
3. Processor stores it in 512-byte buffer
4. After 10ms timeout, wraps it in TCP header (port 4001) and IP header (192.168.1.100)
5. Ethernet interface sends frame to switch
6. PC receives, OS delivers to application on port 4001

The whole journey is really fast. It takes milliseconds. The sensor has no idea that there was a network involved. The application is also unaware that there was an RS485 connection.

Why Industrial Converters Are Different

Our journey works with any converter.. In factories the equipment really matters:

• Temperature: -40°C to 85°C means the electronics keep working in frozen warehouses and sun-baked cabinets.
• Surge protection: 2KV on Ethernet means lightning nearby won’t kill it.
• Wide power input: 9-24V DC means it runs on whatever power is in the panel.
• Metal enclosure: Acts as a heatsink and blocks electrical noise from motors and drives.

Common Questions About the Journey

“Does the converter add delay?”

Yes, a little bit. Buffering takes a milliseconds. The network also takes a milliseconds. For most monitoring applications you won’t even notice it. For high-speed control loops it could be a problem.

“What if the buffer overflows?”

When data comes in from the port really fast it can be too much for the network to handle. If the network is slow the buffer gets full. When the buffer is full it starts to lose information. You should pick a converter that has a buffer that’s the right size, for the amount of data you are working with.

“Can I see what’s in the buffer?”

No. The buffer is inside the system. Some of these converters have lights that flash really fast when they are dealing with a lot of data but you cannot look at what is actually, in the buffer.

“What happens if the network goes down?”

When we use TCP modes the connection breaks. The converter will try to reconnect if it’s a client or it will wait for a new connection if it is a server. If data arrives during the time the connection is broken it may get lost. This depends on how big the buffer’s. The TCP connection is very important here the converter tries to fix the TCP connection by reconnecting or waiting for a new TCP connection.

“Does the converter have its own IP address?”

Yes. This is a network device. You give the network device an internet protocol address just like you do with any device that is on your network. The network device gets an internet protocol address so it can work with devices, on the network.

Summary: The Byte’s Journey in Five Steps

1. Serial in: Byte arrives at converter’s serial port, reconstructed from voltage changes
2. Buffer: Waits with friends until it’s time to send
3. Wrap: Gets wrapped in TCP, IP, and Ethernet headers
4. Network: Travels across switches and routers to destination
5. Unwrap: Headers stripped off, raw byte delivered to application

The converter helps translate data. It makes slow serial connections fast for networks. It also helps equipment work with modern systems. It even makes things that’re close, by work remotely.

But if you really think about it the converter is just moving data bits from one spot to another one bit at a time, it does this over and over.

REQUEST A QUOTE

Name *

Product(s) in Name

Email *

Company *

Product(s) interested in *

SKU/Part No.

Estimated annual order quantity *

Additional Comments *

Submit Inquiry