RS485 turbidity sensor not responding
Hi all. I wanted to connect an RS485 turbidity sensor I got off ebay to a Raspberry Pi to collect readings for a project of mine. This is the link to the item (https://www.ebay.co.uk/itm/286164251961), but the one that was sent has slightly different dimensions, a lot like this item (https://www.amazon.co.uk/Turbidity-Stai ... B0FF4C7LBK). I know that it uses the RS485 communication standard, but I am not sure whether it is the modbus protocol. It also didn't come with any manual so the only info I have is what I gathered from the url. I used an RS485 transceiver from Pihut (https://thepihut.com/products/rs485-board) to communicate with the device. The wiring is shown below
Pi-----------------------------------RS485 transceiver
GPIO 14 (TX)----------------- DI
GPIO 15 (RX)-----------------RO
GPIO 18-------------------------RSE
3.3V------------------------------VCC
GND------------------------------VCC
The turbidity sensor's A and B pins are connected to the A and B pins in the transceiver and the device is powered up using a DC supply (it operates in the range of 12 - 24 V). There is an image of the setup below.
Image
I was following the steps in the tutorial in this link (https://38-3d.co.uk/blogs/blog/using-th ... UCkEwVshIW), but I can't seem to get any reading at all from the device. I disabled the serial console and enabled the hardware and rebooted before running the code. Is there a standard text that I should send in order to get a response from the device? Or is the device supposed to send some reading. I am not sure what steps I can take to get the device up and running because there is no response from it at all. I would be grateful for any help.
Pi-----------------------------------RS485 transceiver
GPIO 14 (TX)----------------- DI
GPIO 15 (RX)-----------------RO
GPIO 18-------------------------RSE
3.3V------------------------------VCC
GND------------------------------VCC
The turbidity sensor's A and B pins are connected to the A and B pins in the transceiver and the device is powered up using a DC supply (it operates in the range of 12 - 24 V). There is an image of the setup below.
Image
I was following the steps in the tutorial in this link (https://38-3d.co.uk/blogs/blog/using-th ... UCkEwVshIW), but I can't seem to get any reading at all from the device. I disabled the serial console and enabled the hardware and rebooted before running the code. Is there a standard text that I should send in order to get a response from the device? Or is the device supposed to send some reading. I am not sure what steps I can take to get the device up and running because there is no response from it at all. I would be grateful for any help.
Re: RS485 turbidity sensor not responding
One thing you could do is to disconnect the hardware from the Pi, then connect the serial port Tx and Rx together (i.e. a wire between GPIO 14 & 15). Then, without any other software running, use a terminal emulator to open the serial port. Type a few characters and verify that they are received. You can disconnect the wire to verify that they are stop being received, and reconnect it to verify that they start again.
This short test shows you that you have identified the pins on the GPIO header correctly, and that the serial port device exists, and you have opened the correct device name.
If any of these steps don't work then your final project won't work.
This short test shows you that you have identified the pins on the GPIO header correctly, and that the serial port device exists, and you have opened the correct device name.
If any of these steps don't work then your final project won't work.
Oh no, not again.
Re: RS485 turbidity sensor not responding
Personally, I think this is a valuable lesson in buying items from less reputable sources.
If something doesn't have a basic datasheet with it, why would you buy it?
The product listing seems to indicate that multiple devices can be connected to a single RS485 bus. This suggests that this will require some type of command sent from the controlling device to get the device to respond.
Your best bet is to google any part numbers you can find on the device and hope that someone out there has provided a datasheet. The "JOT-250624-06" part number on the amazon listing, results in nothing helpful
If something doesn't have a basic datasheet with it, why would you buy it?
The product listing seems to indicate that multiple devices can be connected to a single RS485 bus. This suggests that this will require some type of command sent from the controlling device to get the device to respond.
Your best bet is to google any part numbers you can find on the device and hope that someone out there has provided a datasheet. The "JOT-250624-06" part number on the amazon listing, results in nothing helpful
Electronic and Computer Engineer
Pi Interests: Home Automation, IOT, Python and Tkinter
Pi Interests: Home Automation, IOT, Python and Tkinter
Re: RS485 turbidity sensor not responding
Thanks. I tried this just now and I am getting responses as expected with no problems at all. So the serial communication is not an issue.ame wrote: ↑Fri Aug 29, 2025 7:06 amOne thing you could do is to disconnect the hardware from the Pi, then connect the serial port Tx and Rx together (i.e. a wire between GPIO 14 & 15). Then, without any other software running, use a terminal emulator to open the serial port. Type a few characters and verify that they are received. You can disconnect the wire to verify that they are stop being received, and reconnect it to verify that they start again.
This short test shows you that you have identified the pins on the GPIO header correctly, and that the serial port device exists, and you have opened the correct device name.
If any of these steps don't work then your final project won't work.
Afterwards, I also hooked up pin A from the sensor to an oscilloscope and I am seeing a response.
Image
The timing of the response matches the time the data is sent from the Pi so that would mean that there is a signal being sent to the device. I am not sure why I am not getting a response back.
Re: RS485 turbidity sensor not responding
The cheaper sensors sold by DFRobot (https://shorturl.at/qAxI8) didn't have a decent IP rating so I wanted something a bit more waterproof and wanted to test this device out. Agreed on this not being the best option to go for. Since there seemed to be a lot of similar products online, I assumed that it would be easy to use and there might be data coming out of the device as soon as it is powered up. The product has a sticker with the label 'soonsall xm8518b' on it. But searching for that doesn't really return any results.scotty101 wrote: ↑Fri Aug 29, 2025 7:36 amPersonally, I think this is a valuable lesson in buying items from less reputable sources.
If something doesn't have a basic datasheet with it, why would you buy it?
The product listing seems to indicate that multiple devices can be connected to a single RS485 bus. This suggests that this will require some type of command sent from the controlling device to get the device to respond.
Your best bet is to google any part numbers you can find on the device and hope that someone out there has provided a datasheet. The "JOT-250624-06" part number on the amazon listing, results in nothing helpful
Re: RS485 turbidity sensor not responding
Some google minutes later, there is
http://www.xunchip.com/english/products/XM8518.html
which possibly matches this sensor.
Some remark on the connections
RS485 connections must include also GND connection. For true isolated adapters, this can be omitted.
Look for python minimalmodbus library.
http://www.xunchip.com/english/products/XM8518.html
which possibly matches this sensor.
Some remark on the connections
Code: Select all
Pi-----------------------------------RS485 transceiver
GPIO 14 (TX)----------------- DI
GPIO 15 (RX)-----------------RO
GPIO 18-------------------------RSE
3.3V------------------------------VCC
GND------------------------------GND (was VCC, possibly a typo)Look for python minimalmodbus library.
Re: RS485 turbidity sensor not responding
Thanks for this. The GND connection was connected to the ground. There was a typo earlier. I also connected the GND from the 14V power supply that was connected to the sensor to the Pi's GND for a common ground. The read signal, according to the datasheet, should be as follows.ghp wrote: ↑Fri Aug 29, 2025 8:39 amSome google minutes later, there is
http://www.xunchip.com/english/products/XM8518.html
which possibly matches this sensor.
Some remark on the connectionsRS485 connections must include also GND connection. For true isolated adapters, this can be omitted.Code: Select all
Pi-----------------------------------RS485 transceiver GPIO 14 (TX)----------------- DI GPIO 15 (RX)-----------------RO GPIO 18-------------------------RSE 3.3V------------------------------VCC GND------------------------------GND (was VCC, possibly a typo)
Look for python minimalmodbus library.
Image
The code I used is given below.
Code: Select all
import serial
import time
from pymodbus.client import ModbusSerialClient
client = ModbusSerialClient(port='/dev/serial0', baudrate=9600, timeout=1)
if client.connect():
print("Connection successful.")
try:
response = client.read_holding_registers(address=0, count=1, device_id=1)
if not response.isError():
raw_value = response.registers[0]
turbidity_value = raw_value / 100.0
print(f"Turbidity value: {turbidity_value} UNT")
else:
print(f"MODBUS Error: {response}")
except Exception as e:
print(f"An error occurred: {e}")
finally:
client.close()
print("Connection closed.")
else:
print("Failed to connect to the MODBUS device.")I keep getting this error
Code: Select all
Connection successful.
No response received after 3 retries, continue with next request
An error occurred: Modbus Error: [Input/Output] No response received after 3 retries, continue with next request
Connection closed.Re: RS485 turbidity sensor not responding
Maybe try setting address=1 rather than 0.
You could also try using a for loop to increment the device number to see if any of them respond.
You could also try using a for loop to increment the device number to see if any of them respond.
Electronic and Computer Engineer
Pi Interests: Home Automation, IOT, Python and Tkinter
Pi Interests: Home Automation, IOT, Python and Tkinter
Re: RS485 turbidity sensor not responding
Perhaps
- use device_id=0 which is a broadcast number. Perhaps someone has changed device_id (somehow)
- A, B are swapped
- look for response timeout value. Perhaps the device is a bit slower than expected.
- how is data direction line of modbus adapter RSE controlled, see https://pyserial.readthedocs.io/en/late ... 85-support
See viewtopic.php?t=257816 or viewtopic.php?t=318466
Or create a low level workaround. Use pyserial, send out a request, toggle RSE and read response.
My approach would be to use a RPi pico with micropython plus your rs485 adapter board and evaluate the value retrieval. If this works, then go back to RPi and work on the data direction line.
- use device_id=0 which is a broadcast number. Perhaps someone has changed device_id (somehow)
- A, B are swapped
- look for response timeout value. Perhaps the device is a bit slower than expected.
- how is data direction line of modbus adapter RSE controlled, see https://pyserial.readthedocs.io/en/late ... 85-support
See viewtopic.php?t=257816 or viewtopic.php?t=318466
Or create a low level workaround. Use pyserial, send out a request, toggle RSE and read response.
My approach would be to use a RPi pico with micropython plus your rs485 adapter board and evaluate the value retrieval. If this works, then go back to RPi and work on the data direction line.
Re: RS485 turbidity sensor not responding
This isn't really a solution to the problem, but I got hold of a RS485 to USB converter https://shorturl.at/pS5Rm and connected the turbidity sensor to the converter, which I then connected to one of the Raspberry Pi's USB ports. I then ran a scan of all available channels using the code below.
I got a response for ID 1 at baud rate 9600.
And so I tried the code below, and got readings from the device. I didn't try it in a liquid but I put a piece of paper between the transmitting and receiving ends of the turbidity sensor and the NTU value shot up.
This tried running a similar scan with the RS485 module I have, but the same turbidity sensor that worked with the USB device does not get detected using the module. I feel like it has something to do with my code.
Code: Select all
from pymodbus.client import ModbusSerialClient
baudrates = [9600, 19200, 38400, 115200]
slave_ids = list(range(1, 11)) + [250]
for baud in baudrates:
print(f"\n=== Testing baudrate {baud} ===")
client = ModbusSerialClient(
port="/dev/ttyUSB0",
baudrate=baud,
parity="N",
stopbits=1,
bytesize=8,
timeout=1
)
if not client.connect():
print(f"Could not open port at {baud}")
continue
for sid in slave_ids:
try:
print(f" -> Trying device_id {sid}...")
# Turbidity register is at 0x0000
resp = client.read_holding_registers(address=0, count=1, device_id=sid)
if resp and not resp.isError():
raw = resp.registers[0]
turbidity = raw / 100.0
print(f"Found device at baud {baud}, ID {sid}: raw={raw}, turbidity={turbidity:.2f} NTU")
except Exception as e:
print(f" [ID {sid}] Error: {e}")
client.close()I got a response for ID 1 at baud rate 9600.
Code: Select all
Found device at baud 9600, ID 1: raw=0, turbidity=0.00 NTUCode: Select all
from pymodbus.client import ModbusSerialClient
import time
client = ModbusSerialClient(
port="/dev/ttyUSB0",
baudrate=9600,
parity="N",
stopbits=1,
bytesize=8,
timeout=1
)
if client.connect():
try:
while True:
resp = client.read_holding_registers(address=0, count=1, device_id=1)
if resp and not resp.isError():
raw = resp.registers[0]
turbidity = raw / 100.0
print(f"Turbidity: {turbidity:.2f} NTU (raw={raw})")
else:
print("Read error:", resp)
time.sleep(0.5)
except KeyboardInterrupt:
print("Stopped.")
finally:
client.close()
else:
print("Failed to connect to sensor")Code: Select all
import RPi.GPIO as GPIO
from pymodbus.client import ModbusSerialClient
RS485_RSE_PIN = 18
GPIO.setmode(GPIO.BCM)
GPIO.setup(RS485_RSE_PIN, GPIO.OUT)
GPIO.output(RS485_RSE_PIN, GPIO.LOW) # Set to LOW for receive mode by default
def set_rse_transmit():
GPIO.output(RS485_RSE_PIN, GPIO.HIGH)
def set_rse_receive():
GPIO.output(RS485_RSE_PIN, GPIO.LOW)
class CustomModbusClient(ModbusSerialClient):
def connect(self):
result = super().connect()
# Attach the callback functions to the client
self.rse_callbacks = {
'before_send': set_rse_transmit,
'after_send': set_rse_receive
}
return result
baudrates = [9600, 19200, 38400, 115200]
slave_ids = list(range(1, 11)) + [250]
try:
for baud in baudrates:
print(f"\n=== Testing baudrate {baud} ===")
client = CustomModbusClient(
port="/dev/serial0",
baudrate=baud,
parity="N",
stopbits=1,
bytesize=8,
timeout=1
)
if not client.connect():
print(f"Could not open port at {baud}")
continue
for sid in slave_ids:
try:
print(f" -> Trying device_id {sid}...")
resp = client.read_holding_registers(address=0, count=1, device_id=sid)
if resp and not resp.isError():
raw = resp.registers[0]
turbidity = raw / 100.0
print(f"Found device at baud {baud}, ID {sid}: raw={raw}, turbidity={turbidity:.2f} NTU")
except Exception as e:
print(f" [ID {sid}] Error: {e}")
client.close()
finally:
GPIO.cleanup() # Clean up GPIO settings on exitRe: RS485 turbidity sensor not responding
I would hazard a guess that either your Python software isn't "turning round" the bus fast enough or the RTS control isn't working as you expect.
On a 2-wire RS-485 bus you need to be confident that the bus is in receive mode before the sensor starts transmitting a reply. Even if Python is fast enough most of the time (which it may well be - having started life with 8-bit processors, I probably fret too much about response times nowadays) there may sometimes be occasions when normal multitasking on the Pi delays things a bit too much.
RS-485 operations are supported at the kernel level (https://www.kernel.org/doc/html/latest/ ... rs485.html) which is always going to be much faster and more reliable than userland code. Unfortunately I have no idea how to leverage the capability in Python.
Maybe you can monitor signals to get a better idea of what's going on. Pulse an output pin on the Pi every time you start a transaction, and use that to trigger a scope (ideal) or logic analyser (there are some really cheap ones around!).
You can also add progress messages in your code, but make sure they don't introduce delays in unhelpful places.
On a 2-wire RS-485 bus you need to be confident that the bus is in receive mode before the sensor starts transmitting a reply. Even if Python is fast enough most of the time (which it may well be - having started life with 8-bit processors, I probably fret too much about response times nowadays) there may sometimes be occasions when normal multitasking on the Pi delays things a bit too much.
RS-485 operations are supported at the kernel level (https://www.kernel.org/doc/html/latest/ ... rs485.html) which is always going to be much faster and more reliable than userland code. Unfortunately I have no idea how to leverage the capability in Python.
Maybe you can monitor signals to get a better idea of what's going on. Pulse an output pin on the Pi every time you start a transaction, and use that to trigger a scope (ideal) or logic analyser (there are some really cheap ones around!).
You can also add progress messages in your code, but make sure they don't introduce delays in unhelpful places.
Re: RS485 turbidity sensor not responding
Browsed the modbus pymodbus repo and could not find something like the "rse_callbacks" definition. Add print statement to the callback methods to see whether these are called in your code. Did you find documentation about this feature somewhere?
There are "Auto Data Direction Control" RS485 modules available, see for example https://www.circuitstate.com/pinouts/ma ... reference/ .
There are "Auto Data Direction Control" RS485 modules available, see for example https://www.circuitstate.com/pinouts/ma ... reference/ .
Re: RS485 turbidity sensor not responding
Many of the lower cost modules operate that way. And in a benign environment, they do seem to work OK. But I wouldn't like to trust them as much in the real world; they must work by detecting edges on data lines, so could pick up noise. And, especially at high baud rates, timings could become a bit marginal.ghp wrote: ↑Thu Sep 04, 2025 1:53 pmThere are "Auto Data Direction Control" RS485 modules available, see for example https://www.circuitstate.com/pinouts/ma ... reference/ .
Re: RS485 turbidity sensor not responding
I tried a very low level approach and it appears to work. I sent a raw modbus frame over.
01 03 00 00 00 01 84 0A
Code:
Which comes from what appears to be this device's datasheet (http://www.sonbus.com/upload/pdf/XM8518.pdf pg 3).
Results come out like this
I guess manually toggling the GPIO18 each time and sending the modbus query frame helps. Wiring had been correct all along.
01 03 00 00 00 01 84 0A
Code:
Code: Select all
import serial
import RPi.GPIO as GPIO, time
import struct
RSE_PIN = 18
GPIO.setmode(GPIO.BCM)
GPIO.setup(RSE_PIN, GPIO.OUT)
GPIO.output(RSE_PIN, 0) # start in receive mode
def tx():
GPIO.output(RSE_PIN, 1)
time.sleep(0.002)
def rx():
time.sleep(0.002)
GPIO.output(RSE_PIN, 0)
# Precomputed Modbus RTU frame: device 1, read holding register 0x0000, count=1
QUERY_FRAME = bytes.fromhex("01 03 00 00 00 01 84 0A")
ser = serial.Serial(
port="/dev/serial0",
baudrate=9600,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=1
)
print("Connected to XM8518 sensor on /dev/serial0")
try:
while True:
tx()
ser.write(QUERY_FRAME)
ser.flush()
rx()
resp = ser.read(7)
print(f"Raw response: {resp}")
if len(resp) == 7 and resp[0] == 1 and resp[1] == 3:
raw = struct.unpack(">H", resp[3:5])[0]
turbidity = raw / 100.0
print(f"Turbidity: {turbidity:.2f} NTU (raw={raw})")
else:
print("No response:", resp.hex(" "))
time.sleep(2)
except KeyboardInterrupt:
print("\nStopped by user.")
finally:
ser.close()
GPIO.cleanup()Which comes from what appears to be this device's datasheet (http://www.sonbus.com/upload/pdf/XM8518.pdf pg 3).
Results come out like this
Code: Select all
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x00\x00\xb8D'
Turbidity: 0.00 NTU (raw=0)
Raw response: b'\x01\x03\x02\x0329a'
Turbidity: 8.18 NTU (raw=818)
Raw response: b'\x01\x03\x02\x03\xd9y.'
Turbidity: 9.85 NTU (raw=985)
Raw response: b'\x01\x03\x02\x03\xe8\xb8\xfa'
Turbidity: 10.00 NTU (raw=1000)
Raw response: b'\x01\x03\x02\x03\xe8\xb8\xfa'
Turbidity: 10.00 NTU (raw=1000)Return to "Automation, sensing and robotics"
Jump to
- Community
- General discussion
- Announcements
- Other languages
- Deutsch
- Español
- Français
- Italiano
- Nederlands
- 日本語
- Polski
- Português
- Русский
- Türkçe
- User groups and events
- Raspberry Pi Official Magazine
- Using the Raspberry Pi
- Beginners
- Troubleshooting
- Advanced users
- Assistive technology and accessibility
- Education
- Picademy
- Teaching and learning resources
- Staffroom, classroom and projects
- Astro Pi
- Mathematica
- High Altitude Balloon
- Weather station
- Programming
- C/C++
- Java
- Python
- Scratch
- Other programming languages
- Windows 10 for IoT
- Wolfram Language
- Bare metal, Assembly language
- Graphics programming
- OpenGLES
- OpenVG
- OpenMAX
- General programming discussion
- Projects
- Networking and servers
- Automation, sensing and robotics
- Graphics, sound and multimedia
- Other projects
- Media centres
- Gaming
- AIY Projects
- Hardware and peripherals
- Camera board
- Compute Module
- Official Display
- HATs and other add-ons
- Device Tree
- Interfacing (DSI, CSI, I2C, etc.)
- Keyboard computers (400, 500, 500+)
- Raspberry Pi Pico
- General
- SDK
- MicroPython
- Other RP2040 boards
- Zephyr
- Rust
- AI Accelerator
- AI Camera - IMX500
- Hailo
- Software
- Raspberry Pi OS
- Raspberry Pi Connect
- Raspberry Pi Desktop for PC and Mac
- Beta testing
- Other
- Android
- Debian
- FreeBSD
- Gentoo
- Linux Kernel
- NetBSD
- openSUSE
- Plan 9
- Puppy
- Arch
- Pidora / Fedora
- RISCOS
- Ubuntu
- Ye Olde Pi Shoppe
- For sale
- Wanted
- Off topic
- Off topic discussion