0

I am currently testing a circuit that I've put together on a carrier board for a Raspberry Pi CM4. It connects RS485 to USB via SP3485CN and CH340E.

I've set up a PC with the software Modbus Slave and connected to it using a standard RS485 to USB adapter.

On the raspberry Pi I'm currently using minimalmodbus.

My issue is an additional 0x00 byte being added to the beginning of the response message. This means that it cuts off the final byte of data because it has a set length it's expecting in response. The last byte is unfortunately the second half of the checksum meaning the software believes the data to be a failed transmission.

The debugging mode in minimalmodbus returns the following messages when I run the code:

MinimalModbus debug mode. Will write to instrument (expecting 9 bytes back): 01 04 00 00 00 02 71 CB (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 104832.80 ms, minimum silent period: 4.01 ms
MinimalModbus debug mode. Closing port /dev/ttyUSB0
MinimalModbus debug mode. Response from instrument: 00 01 04 04 01 BD 01 BC 6A (9 bytes), roundtrip time: 0.1 ms. Timeout for reading: 500.0 ms.
...
minimalmodbus. InvalidResponseError: Checksum error in rte mode: '1/4j' instead of '\x0bq' . The response is: '\x00\x01\x04\x04\x011/2\x011/4j' (plain response: '\x00\x01\x04\x04\x011/2\x011/4j')

So far I've double checked all the data sheets of the components and I'm confident I've integrated each part correctly (but always appreciate corrections)

RS485 Schematic

When doing some research I've come across lines bias that can cause the issue and I've tested it but without success or change.

The part I'm very confused about is the readings I'm getting from the oscilloscope. When connected to RO pin of the SP3485CN, I'm getting the results shown in the image. As you can see - the oscilloscope is able to interpret the response perfectly. The response "01 04 04 01 BD 01 BC 6A 7D" is exactly what is expected. Unfortunately - as shown in the debugging messages above, I'm getting "00 01 04 04 01 BD 01 BC 6A"

Oscilloscope Capture

As far as I understand, the beginning of the message waveform is correct with a single low bit to indicate the message start, followed by the LSB of the first byte.

I'm at a complete loss as to why this is happening and would love any additional suggestions besides lines bias.

import random
  • 3,054
  • 1
  • 17
  • 22
Oliver Munro
  • 1
  • 2
  • Wild guess: there is an off-by-one in the pointer-arithmetic somewhere, causing a pointer to the first byte *before* the start of your data-buffer to be returned, rather than a pointer to the first byte of the data buffer (and that spurious location just happens to contain a zero) – Jeremy Friesner Jul 06 '23 at 04:41
  • In all honesty I haven't dived too deeply into minimalmodbus. That does make a lot of sense to me. I began searching for other minimalmodbus users having this issue and most forums seemed to say that minimalmodbus was reliable and it's more likely a user error. Until alternative recommendations are made - I'll probably continue my search in that direction. – Oliver Munro Jul 06 '23 at 04:47
  • "*I am currently testing a circuit ...*" -- This site is for programming questions, rather than hardware questions; suggest you read the [Help pages](https://stackoverflow.com/help). Your post is not composed as a software question at all. You haven't tagged your post with `linux`, but you need to be aware that termios can (depending on the configuration of the serial terminal by your program) can insert or replace a char/byte with a null byte to indicate a break and receive-error condition. Study the termios man page for the details. – sawdust Jul 06 '23 at 05:41
  • I would look into multi-peer configuration. If it's possibly with the modbus it can be the address of the peer. Can you send 8 bytes? – 0andriy Jul 09 '23 at 09:47

0 Answers0