Read only RS485

Projects Networking, Protocols, and Devices
1

I'm in the midst of a quick and dirty little project to monitor an RS485 network that controls my pool. I was surprised that just by reading I seemed to be having an effect on the network as a whole... somehow just by "read only" polling for traffic I could start causing timeouts on the RS485 network. I worked around this by slowing down my polling, but I was kinda scratching my head with regards to what was going on. How does simply reading the RS485 network affect the network as a whole?

My hardware is an ESP32 S2 mini whose serial port is wired to a TTL/RS485 board with "automatic flow control" ( Amazon.com: HiLetgo 5pcs TTL to RS485 485 to Serial UART Level Reciprocal Hardware Automatic Flow Control UART to RS485 Converter RS485 to TTL : Electronics? ), though I've also observed the same effect with a Waveshare ESP32 board that has built-in RS485 (also automatic flow control I believe).

Super simple serial port code:

#include <Arduino.h>

#define RS485 Serial1
#define RS485_RX_PIN  17 // 17 for s2 mini... 15 for s3 touch
#define RS485_TX_PIN  18 // 18 for s2 mini... 16 for s3 touch
unsigned long sTime = 0;

void setup() {
  Serial.begin(9600);   // Serial Monitor
  delay(2000);
  Serial.print("setup starting..");
  RS485.begin(9600, SERIAL_8N1, RS485_RX_PIN, RS485_TX_PIN);  // RS485
  while (!RS485) {
    delay(10); // Wait for initialization to succeed
  }
}

void loop() {
if (millis() > (sTime + 100)) // only check the rs586 bus 10 times per second
{ 
  sTime = millis();
  int av = RS485.available(); 
  byte b = RS485.read();
  Serial.print("0x");
  Serial.print(b>>4,  HEX);
  Serial.print(b&0x0F,HEX);
  Serial.print(",");
  Serial.println("");
}
}

Anybody want to attempt an explanation for why a "read only" activity bogs things down?

Thanks!

2

In principle, reading should not have an effect, except that by placing a receiver on the bus you are adding a load. Typically these chips support 64 or more nodes on a bus, I assume you are within that limit.

I am assuming that you never see the TX light come on?

However, that board you have also has pullups, a termination resistor and some other stuff that may disturb the bus.

3

What seemed odd to me was that the effect had to do with how many times per second I was reading the bus. At 10x per second, I don't really notice any different. But if that goes to 50 or 60 times per second, I start having trouble using the network with other devices. So must be something related to what's happening during an access attempt.

4

Strange. My first thought would also be related to pull up/down resistors and terminating resistor on your RS485 module affecting the bus.

Whether or not you read data from your RS485 module and at what rate should have no bearing on the bus activity as your module should always be in receive mode.

I'm not familiar with the ins and outs of an ESP32, but can you set the TX pin parameter to NULL or -1 to effectively stop any accidental transmissions the ESP32 may do? As @bobcousins says - hopefully your TX LED never flashes.

Depending on the data rate on your RS485 bus, I think you may also end up with a situation where the ESP32 serial receive buffer fills up and data is lost. If I understand your code correctly, it will only read 1 byte every 1/10th second assuming there's a byte to read. If you ESP32 receives more than 1 byte between each 1/10th second check then eventually your ESP32 serial receive buffer will fill up, unless of course the RS485 activity is very infrequent.

For a simple RS485 monitor like this, you should be ok simply tearing round the loop function and fetching a byte the moment it's received.

1 Like
5

Whether or not you read data from your RS485 module and at what rate should have no bearing on the bus activity as your module should always be in receive mode.

... yup, my thoughts exactly...

And, oops, sorry, I posted an older version... the actual read loop drains the buffer 5 times per second. Here's the correct inner loop:

while (RS485.available())
      {
        byte b = RS485.read();
        Serial.print("0x");
        Serial.print(b>>4,  HEX);
        Serial.print(b&0x0F,HEX);
        Serial.print(",");
      }

In one run, I put in some stats on the amount accumulating in the buffer between reads and convinced myself it's not overflowing (e.g. I'm reading all traffic). And actually looking at the traffic it seems it's all there and there aren't any half or invalid packets.

I will look more carefully on the TX light next time - I don't think I looked for that directly.

I'm also going to experiment with termination resistor in place or not and see if that has any affect.

6

Some of those auto flow control devices do some unusual things on the bus in order to determine if it is in use by another device. If you had a normal RS485/TTL converter with direction control and set to receive only I don't think there would be a problem

7

Why you have tx even connected...

8

Paid attention to latest test, and the TX light on the TTL/RS485 board doesn't light at all, for what it's worth.

Interesting idea on disconnecting TX and see what happens. Easy enough to try, other than it seeming kinda wrong to keep crashing the network on my working pool. It seems the control panel or the devices will shut off if they sense something is amiss.

I do want to transmit occasional packets eventually, so will want TX functional at some point.

I put a terminating resistor in place and it didn't seem to hurt anything - haven't tried the unlimited read rate yet to see if it still crashes things.

9

That doesn't sound right to me. Your RS485 bus should already be setup / configured correctly with the appropriate terminating resistors and biasing resistors.

Adding a further terminating resistor doesn't make sense to me, unless of course you are extending the bus so that the RS485 monitoring board is at the end of the bus. In which case an existing terminating resistor would be removed.

10

Well, some progress... I got "the other" ttl/485 arduino board... the one with breakouts for RE and DE ( Amazon.com ), and I was able to poll the line non-stop with no adverse effects (pulling RE/DE low in my code). I'm going to circle back and try it again with the "auto" board and see if it still fails with my new code base (I'm continuing to work on my app while I'm sorting out this comms issue).

The bus is more active that I thought - 40 packets a second.

I do think I'll need a terminating resistor - where this is going is to replace a control panel that was at the end of a 60 foot "telephone style" cord that links back to the RS485 master, and that'll constitute a new leg to the master. I'm replacing and old system that wasn't using RS485 (old system was simply continuity based switches). I plan to scope it with and without in any case. I'll post the scope if I can figure out how to log it.

11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.