Yes i did, im getting error like this
Hmm,strange, it should work... You have to make this work first and then do the coding part.
I`m out of ideas.
sorry, dinner..
if you have your PC connected to the sensor using your USB adapter, then you should not be receiving anything until you request it..
kind of looks like you are maybe somehow still connected to your UNO??
hook up should be PC USB adapter to Sensor, give the sensor power and you should be able to test comms using the PC..
nothing else connected at this stage..
once you get sensor reading properly then we go back to the uno..
either a bad hook up or bad sensor..
~q
ok, more i think about it..
has to be getting this from the UNO..
kind of tests the UNO comms..
the command 01,03,00,00,00,07,04,08 is the command to send to a modbus slave..
valid response is 01,03,Length of Data,CRC,CRC
so when the Uno send it's request my app see's this as a response, with 0 length of data and yes 00,00 is not a valid checksum should be F0,20..
you get a packet time out because there are 2 more bytes that are still in receive buffer the 04,08..
these get tossed away by a watchdog and we again receive another bad response..
so, Yeah, disconnect the UNO please and hook USB adapter to sensor..
sorry.. ~q
Guess I should state this..
My app doesn't test the UNO but the sensor..
Same with that other app in pic you uploaded, their both meant to communicate to modbus slaves..
Your UNO is a master not a slave..
But like I mentioned, if you did hook up UNO to USB adapter, you won't break anything but you will get the output you posted and this also means the UNO is sending out the proper request..
something is not right with the sensor??
~q
Just reading the latest posts, and I was thinking the same.
@prakashpoojary if you remove power from your UNO, it should not interfere with the comms from the test program. Re-run the PC app that @qubits-us provided with your UNO powered off and see what happens.
Can you please send the connection diagram, I'm quite confused!
With just your PC + the USB RS485 dongle + the 12V battery + the sensor, your connection should look like this:

Unfortunately, the USB to RS485 dongle you have doesn't have a connection point for a GND. That should be OK over such short distances when you are working on a desk.
You should be able to run the software provided by @qubits-us and get a response from your sensor. If you don't get a response, then you may have A & B are swapped over. If that is the case, swap A & B over - it won't damage anything.
Report back how you get on.
That actually looks proper, just got no response..
I see Port Opened, then you clicked send and I can see what was sent out >>
You should receive something like <<$01,$03,$E0,..... the docs shows a valid response..
Try Slave Id 254 (in hex it's 0xFE), per your docs should be broadcast address..
Back on post 42 is the only time I see a somewhat proper response out of your sensor..
Once the port is opened, every time you press send you should get a response..
outgoing data has >>
incoming data has <<
the $ mean the number is displayed in HEX same as 0x##
the slave should respond if Id and checksum is correct, it will either send proper data or an error message..
if the id or checksum is wrong, then the slave should send nothing..
So stick with PC and adapter till you get a response, maybe start with new connection wires between usb adapter and sensor, verify sensor power source..
If you have more than one sensor, try each one in turn..
good luck.. ~q
I'm getting something like this, I have disconnected everything and I followed the pin diagram given by @markd833
success!
and do you see what was killing you?? ![]()
it's address is not 1 but 2, can see it in the response..
now change slave id from 254 to 2 and you should get same result..
its working but the address which should be 1 by default is in fact 2 and that's why you never got a reply..
very strange..
once you verify that slave id 2 works, then it's back to the uno..
good luck.. ~q
looks good too me..
you outgoing command >>02 (slave id),03 (func read holding registers),start 0,qty 8
should give you a 16 byte response 2 bytes for each register, these are combined into words..
the response is slave 2 func 3 data len 10 hex which is 16 in decimal which is deciphered to nice format then raw data in hex, then the crc which passes no more crc failures, looks like a valid response..
now if you're asking me do these values look correct, idk and keep in mind the default address was not correct so it could have been used??
looks like you're getting values in reg 1 and reg 4, check your doc and see what they relate too..
the value in reg 4 changed slightly..
if you have another sensor, be a good time to test it as well and compare results..
first try address 254 and see how it replies..
good luck.. ~q
@prakashpoojary Way back in post #5 one part of the datasheet you posted showed that the first register returned had temperature in it.
Assuming that the datasheet has got that part right, then looking at the data in post #114, that would suggest temperature is 0115 - it's in hexadecimal.
0x0115 is 277 in decimal.
Temperature is usually 10x the actual value. That would mean the actual temperature reading is 27.7 degC.
You can try inducing different temperatures and see if the sensor reports back the appropriate reading.
Congratulations! Try how it looks like with QModbus. Now you can go back to your UNO modbus master coding. Look at the datasheet 7.1 Modification Address. You can change the slave ID if needed.
Reg 1 is soil moisture and Reg 4 is Nitrogen?
No, this is the only sensor i have, i got this for my college project:)
yes, that's usually my room temperature here. but sadly realized now while texting I haven't inserted the sensor probes into the mud. I will insert and try it now and check if there are variations!
looks like pH, per the doc anyways..
did you try sticking it into some soil??
time for some experiments, i think..
good luck.. ~q





