Skip to content

Appendix F Serial over IP

jgyates edited this page Jun 13, 2023 · 11 revisions

Serial communications over TCP/IP

The software communicates with the generator using the Modbus protocol. There are two protocol variants of Modbus: Modbus RTU and Modbus TCP. Modbus RTU is typically used over a serial link and Modbus TCP is over a TCP/IP network. It is possible to transport Modbus RTU over TCP/IP. So this results in three options.

  1. Modbus RTU over serial
  2. Modbus RTU over TCP/IP (serial over TCP/IP. This includes the CRC found in Modbus RTU)
  3. Modbus TCP (additional header is added to Modbus RTU and no Modbus CRC is used since TCP/IP has error checking)

Serial Over TCP/IP

If you want to use the Serial over TCP/IP feature you must have a device that is connected to the serial port that will transfer TCP/IP socket data to and from the serial port. Many companies make these devices. The device use in testing is the USR-W610. This device is inexpensive and does work however the documentation and web based setup is a bit lacking due to the language translation to English from Chinese. These models have been tested and also work : USR-TCP232-410S and a USR-TCP232-306

This Waveshare product has also been used. See this thread.

The entries required for enabling serial over IP are in the /etc/genmon/genmon.conf file or in the web interface.

The following are the requirements for a Serial to IP device needed to be used by the software.

  • The device must support TCP sockets (most support both TCP and UDP)
  • The device must support transparent communications (i.e. just pass the data along, do not do any protocol processing, most do)

In addition, you should consider the following when thinking about using serial over TCP:

  • You should consider how the device is powered. Ideally you would power the device from the 5V supply in the generator controller connector or from the battery. If you use another power source you will need to make sure there is a common ground between the serial IP device and the controller.
  • You should consider networking factors like signal strength and signal quality of WiFi as they will effect the responsiveness of the software.
  • The packet through put is slower. My testing shows 64 packets per second for direct serial vs around 20 packets per second for TCP/IP. This will vary depending on network conditions and quality of the serial IP server device you use (I used and inexpensive one).
  • The serial to IP devices typically offer may configurations options for networking. Please be sure you have the networking knowledge to setup the device before using.
  • The project software does not setup the serial IP device. The data rate, IP address, port number, network bridging options must be setup before using the device with the project software.

The program sockettest.py will perform a simple loopback test over TCP sockets. You can use this test to validate your settings before you use the device with the software.

You will need to configure the software from the web interface or by editing the /etc/genmon.conf file to enable the serial over IP functionality and tell the software the IP address and port number used.

Modbus TCP

The Genmon software also supports Modbus TCP (starting with V1.16.00). This has only been tested with PowerZone controllers. This can be enabled on the settings page in the web interface.

DIY Serial over IP Using and ESP32

User @gregmac used a unique approach to serial over IP with genmon. He used an ESP32 as the serial to IP server over WiFi. His approach is described here.

Troubleshooting

When using serial over TCP, especially over WiFi with a less than perfect signal quality, packet loss can occur. The resulting loss in packets will translate to MODBUS timeout errors while genmon is communication with the controller. Depending on the timeout values and the WiFi packet retry timing, this can cause problems with the modbus communication which can result in invalid data. This occurs when the follow happens:

  1. Genmon attempts to read a given register x
  2. Genmon waits for a response for register x for a fixed timeout period
  3. Genmon times out waiting for register x response from the controller (bad wifi signal causes this not to happen)
  4. After the timeout, Genmon moves on to attempt to read the next register y
  5. Genmon waits for a response for register y
  6. The Controllers response to the read of register x is delayed due to wifi retries so it arrives late
  7. Genmon interprets this response a a value for register y (not x) resulting in invalid data

This problem is exists because the modbus protocol does not have a built in timeout or packet cancelation method and wifi is an inherently noisy medium.

The symptoms of this can be seen in genmon as timeout errors (on the Monitor page), invalid random short outages (only a few seconds long) being reported by genmon and other short lived anomalies. The best solution is to improve your wifi signal quality. If that is not possible you can mitigate this problem with changes to the following settings. On the Advanced Settings Page (double click the gear icon in the upper right for the Advanced Settings Page) and modify these settings:

  • Minimum Outage Duration - outage must be x seconds (put around 10 sec)
  • Additional Modbus Timeout (sec) - Try putting 5 or 10 in this setting
  • Minimum Outage Duration - Set to at least 4 seconds
Clone this wiki locally