I am trying to communicate with a PM810 power meter using Modbus-RTU protocol with the RS-485 standard over 175 meters of CAT5e STP cable. It's less than ideal, but it's the situation I'm working with.

To facilitate testing, I have installed two laptops at either end of the transmission cable. The idea is that one is setup as a Modbus client, the other runs a server to emulate communication with the PM810. I wanted to post a block diagram for clarity here, but I'm only allowed two links.

Laptop -> USB to RS-485 Converter -> 175m of CAT5e STP -> USB to RS-485 Converter -> Laptop

The problem I am facing and can't wrap my head around is as follows:

  1. Laptop_PuTTY -> 175m CAT5e -> Laptop_PuTTY serial communication (9600 Baud, 8bits, no parity, 1 stop) is fine. It works in both directions without any issues.
  2. Modbus Client-> 175m CAT5e -> Modbus Server (9600 Baud, 8bits, even parity, 1 stop) fails.
  3. Modbus Client-> 1m CAT5e -> Modbus Server (9600 Baud, 8bits, even parity, 1 stop) works fine.

What is the difference between PuTTY's serial communication protocol and Modbus protocol that could be causing Modbus to fail and PuTTY to work fine over the 175 meter length? They both work over the shorter distance, the physical medium is the same for both over the longer distance, in yet only PuTTY serial works. I tried googling information about what exactly PuTTY's serial communication protocol is, but I couldn't find any satisfying answers. This is from the PuTTY manual, but I don't really understand what it means.

In this mode [serial], text typed into the PuTTY window will be sent straight out of your computer's serial port, and data received through that port will be displayed in the PuTTY window.

Any advice on how to address this problem, or is Modbus communication out of the question?

  • \$\begingroup\$ You should probably state whether you are using Modbus-ASCII or Modbus-RTU protocol. The packets for Modbus-RTU have timing constraints. \$\endgroup\$
    – Tut
    May 8, 2017 at 18:59
  • \$\begingroup\$ How did you determine that your PuTTY serial test 'worked'? Did you send a big chunk of data over and do a binary compare? \$\endgroup\$
    – brhans
    May 8, 2017 at 19:00
  • \$\begingroup\$ If Modbus-RTU, packet timing could fail if the entire Modbus packet does not transfer in a single USB packet (on both ends). Of course that does not explain why it would work with a short cable. (I have not used USB/RS485 adapters ... I use RS232/RS485 adapters which are easier to control timing) \$\endgroup\$
    – Tut
    May 8, 2017 at 19:10
  • \$\begingroup\$ Try sending over a file of 1K random content using RealTerm. Which is functionally equivalent to PuTTY. Does this work? If not, how many bytes have failed? Also, you do have copper cable, not copper clad aluminium? \$\endgroup\$
    – Jeroen3
    May 8, 2017 at 19:26
  • \$\begingroup\$ @Tut Good point, forgot to mention that. Updated the answer to show that it's Modbus-RTU \$\endgroup\$
    – Otto
    May 8, 2017 at 20:41

2 Answers 2


Have you checked your termination and grounding? Theoretically at 9600 baud it should not matter. If you use putty you probably type letter-by-letter. If there is no termination there will be ringing at the receiver. It may be just that one character/second gets received correctly, but a longer Modbus frame does not because it "collides with its reflection".

Some useful resources:

  • \$\begingroup\$ I'm suspecting this is probably it. Would you be willing to elaborate or link a good resource on proper termination and grounding so that we have a point for discussion? \$\endgroup\$
    – Otto
    May 8, 2017 at 20:59
  • \$\begingroup\$ I think this has a strong possibility of being the problem. If the cable is not terminated properly, a glitch might possibly be seen as a false character at the end of a packet. Modbus-RTU packet termination is ended by a short quiet-time so a false character as the end would probably be included with the packet causing it to be thrown out, even if the actual packet characters received ok. \$\endgroup\$
    – Tut
    May 9, 2017 at 10:57
  • 1
    \$\begingroup\$ Termination and biasing was the issue. I chose your answer as correct because of you explaining that a PuTTY serial character is only a few bits where as a Modbus frame is longer. To make the answer better I would add that since Modbus communication will fire off a whole bunch of frames in very rapid succession, there's no time for the reflections to dissipate (unlike my relatively super slow key stroked into the PuTTY terminal). Oh, and because of the design guide you linked, that was great. \$\endgroup\$
    – Otto
    May 10, 2017 at 23:28

PUTTY is just a user interface. It applies the settings (baud rate etc) to the physical interface, and then just sends each character you type to this interface for transmission.

The MODBus programs do exactly the same, except they send a hole message at once, as fast as possible.

I would recommend you to test HTerm which is a by far better program for serial communication than PUTTY. (The site is german, but the tool is english, also see the screenshots there). This program not only allows to display and write data in hex, decimal, ascii and binary simultaneously, it also takes a whole line of input to send at once. You can also easily assemble a MODBus message with HTerm, which is difficult with PUTTY. This would also allow you to request something from the MODBus client by hand, and check the received message.

If you get transmission errors with HTerm, too, you for sure have a signal integrity problem. For example, without proper termination, signals are reflected on the other end of the cable and interfere with new sent signals.

  • \$\begingroup\$ When you say as fast as possible, how does that line up with baud rate? Wouldn't the chosen rate of 9600 be the same for both PuTTY serial and Modbus? Or is it that my character-by-character key strokes (like @filo suggests) are slow enough that reflections on the line dissipate fast enough to communicate. On the other hand, a Modbus protocol script is sending each character as fast as possible and the reflections build up, thus ruining the line? \$\endgroup\$
    – Otto
    May 8, 2017 at 21:12
  • \$\begingroup\$ @Otto: "As fast as possible" means without any delay between the bytes. At 9600baud, about 1000 bytes can be sent per second, but you can't type so fast. So the interface sends a byte, and waits ages for your next key press. \$\endgroup\$
    – sweber
    May 9, 2017 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.