My DT80 Series 2 (Firmware 9.2) has been chugging away logging local weather and other farm data for the best part of 2 decades. No complaints about the durability!
I am now tring to add a Modbus Chinese soil moisture probe, and doing initial command line tests to work past the lack of functional documentation...
My first mystery is that the DT80 doesn't appear to care if the probe is connected to the SERSEN_PORT or not!
I have set P56=4 to show extended dialogue and the following setup executed from the command line in DeTransfer:
PROFILE “SERSEN_PORT” “MODE”=”RS485”
PROFILE “SERSEN_PORT” “BPS”=”4800”
PROFILE “SERSEN_PORT” “DATA_BITS”=”8”
PROFILE “SERSEN_PORT” “STOP_BITS”=”1”
PROFILE “SERSEN_PORT” “PARITY”=”NONE”
PROFILE “SERSEN_PORT” “FLOW”=”NONE”
PROFILE “SERSEN_PORT” “FUNCTION”=”MODBUS_MASTER”
`Suspect not relevant for master
PROFILE MODBUS_SERVER SERSEN_ADDRESS=0

I get the following with the sensor wired as RS485:
DT80> 1MODBUS(AD0,R4:00001,=87..88cv)
Modbus TX >SS: 00 0300000002c5da (8)
1MODBUS 2

If I disconnect the RS485 A & B wires, I get the same result - I was expecting a time-out error.

If I change the address to 1, I get an error:
DT80> 1MODBUS(AD1,R4:00001,=87..88cv)
Modbus TX >SS: 01 0300000002c40b (8)
Modbus timeout
dataTaker 80 E124 - Modbus transaction failed
1MODBUS NotYetSet

The reply "1MODBUS 2" is must be generated by the DT80, but I don't know what it means.

My next step is to test the probe elsewhere, and if necessary look at the RS485 traffic. i'd welcome any debugging suggestions!

Further to my last post, I have tested the sensor manually using a RS485 interface and RealTerm, and it is working as expected. I can request the 2 registers and get a response with valid data. My tests with the DT80 last week were with the sensor directly connected to the screw terminals, so there was no risk of faulty cabling.
I'm definatly looking at an issue in the DT80 or me not configuring it correctly.

Wow, the amount of spam being placed on this noticeboard is dissapointing.

My issue continues... And so far it's all quiet and zero replies from DT80 land. (If you've retired Roger, thanks for all the support over your carreer!)

I've spent quite a bit of time with a RS485 monitor watching the communication between the DT80 and soil probe. The DT80 does not appear to be sending the correct command code 0X03 to request a read from the stored analogue values in Modbus mode.

I then tried a different approach, using the serial port to talk directly to my sensor. It's the same request code inc CRC every time. I cannot get it to send a simple sequence of binary codes! I just want to send 0x01 0x03 0x00 0x00 0x00 0x02 ( and CRC) 0xC4 0x0B, but I cannot work out a how to stop the DT80 converting the data to ASCII in a wide variety of unwanted formats!

It should be simple. I send the above packet, and then recieve back a short (binary) packet with the wanted information in known byte positions. Some simple maths, and I can log the data.

For a system that is this well established, I assume these issues have been well and truly covered, but I'm stuck and have not been able to find soloutions.

Any advice greatfully received!
james@tecsol.com.au

Hi James,

You need to send a copy of the probe manual, specifically the section about the MODBUS register list. We will need that information to check the correctness of the syntax for reading the parameters.

Your examples show that the sensor either responded with an error or did not respond. The one that gives a response indicates the correct wiring but still has an incorrect syntax.

Best regards,
dataTaker Expert

For anyone else's assistance, I've posted the last reply from The Support Team below. I've tested the reccomended syntax, and I can't explain why it works this time! (I did have the RS485 A/B connections reversed early on, but spotted that due to the reversed/mirrored values showing up with my monitor.)

Thank you for the great support.

Hi James,

We can start with the command package and try to replicate it for the logger.
0x01 0x03 0x00 0x00 0x00 0x02 (+CRC) 0xC4 0x0B

The first hexadecimal is sensor address 0x01 = address 1
The second is MODBUS register type 0x03 = holding register
The third and fourth are the start address 0x00 0x00 = 0
The fifth and sixth are the amount of byte to be read 0x00 0x02 = 2

We can ignore the last two since the logger automatically calculates the CRC.

Based on the response 01 03 04 00 00 00 EC FB BE

The first and second hexadecimal is a follow-up echo from the sensor address and MODBUS register type 0x01 0x0
The third indicates four bytes response 0x04
The fourth and fifth are the first parameter 0x00 0x00, which is 0; we are unsure if this reading represents moisture.
The sixth and seventh are the second parameter 0x00 0xEC, which is 236 in decimal. We assume that if this is temperature data, a factor of 0.1 makes the value 23.6. It is likely the correct value.

The response indicates that the reading has an integer 16-bit (2-bytes) as the value type.

The correct syntax in dataTaker would be
1MODBUS(AD1,R4:1,=1..2CV)
1CV("Humidity~%")
2CV"Temp~degC")

AD1 represents sensor address 1
R4 represents the holding register 03
1 represents the starting address of 0; there is a shift of 1 between the dataTaker and MODBUS register due to the implementation of CV bound to the MODBUS register. We do not have 0CV and start with 1CV, meaning the dataTaker starting register is 0. However, it only occurs on the declaration; in the backend, we negate the number by 1.
=1..2CV indicates that you want to get two parameters at once, or you can declare it as two syntax

1MODBUS(AD1,R4:1,"Humidity~%")
1MODBUS(AD1,R4:2,"Temp~degC")

Your second syntax posted in the forum seems correct; if it does not give you the reading, you can try to swap between RS485+ and RS485-. Please ensure you are using the Tx Z pin and RTS Y pin.

Best regards,

The Support Team
Technical Support and Application Specialist
dataTaker( and Odalog( Product