Struggling with RS-485 adapter - should be simple - 2 way serial communication


Firstly, I am a newbie to Digi, but have a Computer Engineering background.

I am trying to communicate with some soil moisture sensors that have a custom RS-485 protocol.

My desired config would be to use Realport to allow for “Hyperterm” to send commands to the sensors, eg. “23M/r/n” would request a moisture measurement from soil sensor 23. Sensor 23 would respond with something like: “01,1,67.333”.

I need this to run at 1200 baud, with 8N1N settings.

My setup is as follows:

PC (running Realport) <–ETHERNET–> ConnectPort X4 <–ZIGBEE–> RS-485 Adapter <–DIRECT WIRED–> Moisture Sensor

I have installed and tried the udp_zig_tunneling python script and the console seems to show that the packets are getting to the CPX4 from the PC, and going out the ZIGBEE interface, but I cant see any return packets from the sensor.

Does anyone have any suggestions? I’m thinking clear 2 way serial communication should not be this hard on the Digi platform.

Cheers, Tom

My own past experience with RS-485 says your RS-485 wiring may likely be wrong. Are you sure the wiring is correct, given the common misuse of terms where + might mean + or at times it means - or A or B.

Are the jumpers correct? The AT settings (like D7) correct in the XBee 485 adapter? Is there anyway you can confirm if the sensor is actually seeing the request, and sending a response? Sometimes, a voltage meter can be used to see the lines ‘wiggle’.

Hi Lynnl,

Some further news on this issue. I have connected a PC to the RS-485 interface (using an RS-485 to RS-232 converter). The PC has no issues locally communicating with the soil sensor. I can not however see any communication over the zigbee network in either direction. To me, it seems as though the issue with the data not going through the RS-485 adapter ZIGBEE<–>SERIAL.

I can confirm D7 = 7 and the jumpers are set correctly (factory default for the Digi RS-485 adapter).

Any further suggestions? If you would like to see screenshot / python files, please let me know and I will attach.

PS. I have tried both the udp_zig_tunneling default script and the iDigi Dia serial channel_get and channel_set approaches. Neither are working for me.

Ok, some progress. It would appear that running my iDigi DIA program was resetting D7=0. Changing that to D7=7 is now getting text from Hyperterm (through Realport) to the sensor and i can locally see the sensor is responding to the request.

So the problem now is that the data is not coming back through the zigbee network. It must be some setting like RTS/CTS. I’ll keep playing, but any suggestions/tips from you clever folks would be greatly appreciated.

I have used the driver with customer code and RS-485 adapters several times (with both Modbus and thermostat device). But looking through the core code seems xbee_serial is forcing D7 to 1 or 0, which is wrong for the RS-485 adapter. I have been ‘accidently’ over-riding this in own code.

The setting for ‘hardwareflowcontrol’ should be NOTA (none-of-the-above) since it is neither true nor false.

All I can suggest for now is try the again, but comment out the lines these lines in
xbee_ddo_cfg.add_parameter(‘D6’, rtsflow)
xbee_ddo_cfg.add_parameter(‘D7’, ctsflow)
Since these lines inver-ably force D7 to either 0 or 1. You really just want them to remain as-is/unchanged.

I’ll have to force a failure on this feature & see that it gets fixed (in the future)

hi lynnl,

i have applied your suggested fix and it solves the issue of D6/7 being changed upon build, but i still cannot get any data back from the xbee adapter to the connectport.



Telnet to the X4, enter the command “set trace state=on mask=xbee:*”

This gives you a trace of all XBee messages coming or going. When you send a message, expect to see a small RECV response which is the hand-off message - not a response.

It may be that a response is being received by the X4, but not being properly returned to your callback. There could be some end-point problem. Under ZigBee, the send has no relationshiop to the receive (unlike TCP or UDP).

Make sure your SE/DE are still 0xE8.

Ok, so I worked out what it was.

Went back to basics and checked the DIP switches on the adapter.

It turns out that by default the unit ships in RS-422 mode. I simply flicked all dip switches on and hey presto. Great success.

Thanks Lynn for your tips, I certainly think there was also the issue of D7 being set to 0 by the script in the ESP platform.

all the best.