Different 485 modul = different received bytes?

Hardware
,
1

Hello,
I use the following setup:

uart:
  id: uart_bus
  baud_rate: 2400
  tx_pin: GPIO3 #4
  rx_pin: GPIO1 #5
  parity: NONE
  stop_bits: 1
  debug:  
    direction: BOTH
    

modbus:
  id: modbus1  
  send_wait_time: 500ms
  uart_id: uart_bus
  
modbus_controller:
- id: modbus_device
  address: 0x1 
  modbus_id: modbus1
  update_interval: 5s
  setup_priority: -10

to read out a solar controller.

i have that two 485 moduls:

image
image735×1271 79.4 KB

If I use that upper modul:

I get that:

[uart_debug:114]: >>> 01:03:00:00:00:14:45:C5
[uart_debug:114]: <<< 01:03:28:00:01:00:01:00:00:80:00:00:00:00:00:00:02:02:48:02:48:01:C8:01:90:00:00:01:7C:00:00:01:77:00:00:00:1B:00:00:00:07:19:3D:26:FE

when I use bottom one:

[uart_debug:114]: >>> 01:03:00:00:00:14:45:C5
[uart_debug:114]: <<< 40:20:09:01:00:01:00:00:80:00:00:00:00:00:00:02:02:48:02:48:01:C8:01:90:00:00:01:93:00:00:01:8B:00:00:00:1C:00:00:00:07:19:3D:C3:21

the first one is correct, the first 3 bytes come, like expected back:
01:03:28:00:01:00:01:00:00:80:00:00:00:00:00:00:02:02:48:02:48:01:C8:01:90:00:00:01:7C:00:00:01:77:00:00:00:1B:00:00:00:07:19:3D:26:FE

the second one is missing a byte and ‘unexpected’ bytes are returned:
40:20:09:01:00:01:00:00:80:00:00:00:00:00:00:02:02:48:02:48:01:C8:01:90:00:00:01:93:00:00:01:8B:00:00:00:1C:00:00:00:07:19:3D:C3:21

instead of ‘40:20:09’ there must be ‘01:03:28:00’

Now the question is, how can that be? I just changed the 485 module, the code and ESP are the same.

2

Why not, they are different modules. If you try third module, you might get no response at all…

The second one has one ic that could be voltage regulator. You should find some specs for that module. Also look at the chips they have, are they same in both?

3

but that shouldn’t matter, or shouldn’t play a role?

A 485 module only converts the signals.

and if I send a certain byte sequence to my solar controller, it sends one back.

that’s all specified in the Modbus protocol.

a 485 module can’t just leave out a few bytes at the beginning.

and the first 3 bytes in the response are defined in the Modbus RTU:

1 = DEVICE ADDRESS
2 = Function Code
3 = Byte Counts

the first module receives:

01
03
28

the second

40
20
09

and the requested function code was 03. so something is wrong with the second 485 module. I just wanted to know if anyone knows why that is?

4

The beginning looks corrupted. 40,20 is not any modbus exception response.
Might be that the second module has voltage regulator and needs 5V to operate correctly for example. Or the automatic flow control is misbehaving or… You could try to make two request in a row and see if you get two equal responses.

Ps. I controlled CRC for the “bad” response:
40:20:09:01:00:01:00:00:80:00:00:00:00:00:00:02:02:48:02:48:01:C8:01:90:00:00:01:93:00:00:01:8B:00:00:00:1C:00:00:00:07:19:3D
and correct CRC should be 33:94 instead of C3:21.
So the data is 100% sure corrupted.

5

that are the feature of the second ‘wrong’ 485 modul:

image
image840×1000 141 KB

yes I did a lot of request in a row, always the response start with:
40:20:09:

if I change 40:20:09: with 01.03.01.00 the checksum always is ok.

the rest of the response is also ok and not corrupt.

6

Maybe your device is replying so quickly that the converter is not ready yet to receive.
Kind of strange that the corruption is always identic.
If you have common Usb-serial converter, you could wire that to Rs485 module and try with PC-software. That takes Esphome out of the trial.
There are many freeware available online.

There is no logic for the corruption even if I look at the bits:
00000001 00000011 00101000 00000000 (01:03:28:00)
00100000 01000000 00001001