RS485 debugging

[aaronik19]

Dear All,

I would like to start experimenting on RS485 to start my project. I am going to start using 1 master and 1 slave. My goal is to have multiple Masters such as 2-3 masters and multiple slaves (such as 8).

Just to start, hardware side, How I can "monitor"the RS485 message on hyperterminal? I was going to use the RS485.c driver to display characters on hyperterminal.

Looking forward for your suggestions and ideas. I will post and improvements that I notice on this forum

[temtronic]

super simple if it's just a 'monitor'. Just add an RS485 transceiver that interfaces to your PC,select correct baudrate, etc. and it'll show all the 'traffic' on the Rs-485 bus. No magic, just easy hardware. What you don't say it what your PC comport is configured. RS-232 ? USB? RS-485?

need to know that...


jay

[aaronik19]

thanks for your reply. what do you mean by comport configuration? from the PIC Side or from PC side. I am intending to use Serial to usb for this test. is that fine? sorry if i dod not understand your question.

[Mike Walne]

Translation:-

Comport = communications port.

I've only used RS232.
With RS232 to USB converters/adapters your PC can monitor several channels at once.
I would expect to be able to do the same with RS485.

Mike

[aaronik19]

Dear All,

Attached please find the circuit that I am going to use to monitor RS485 messages. any ideas where I can improve? I removed the LEDs and Cyrstal for this diagram to keep it simple.

http://postimg.org/image/fqq78j3dj/

[Ttelmah]

I think you are slightly 'missing the point'.

The monitor, wants to just _monitor_ (receive). You show the PC transmit connected, but not the receive....

What it needs is an RS485 buffer, hardware set to receive, wired to the receive pin on the PC comm port. Easiest way actually is to get one of the little USB to TTL transceiver blocks, and put this onto a board with the RS485 transceiver. Otherwise a RS232 transceiver is needed as well (as you show).

The PC can then _monitor_ the RS485 (think like a 'wire tap'). Listening to everything that happens, but not sending.

You can then run a terminal program in the PC, connected to this port, and actually 'see' the data transfers as they occur.
Historically, there were little 'black box' monitors that did this for serial busses like this. When designing something, or trying to get something working, you attached them to the bus you were working on, and suddenly could see that odd problem that was causing it not to work, like the bus becoming undriven early, or a clash. With the low price now of PC's, a simple 'monitor' circuit has become the way to go. Since RS485, allows multiple receivers to be on the bus at the same time, this is simple.

Even if it is the PC actually sending data, it is worth having this simple circuit connected at the same time (using a second comm port).

Other things:

You have the receive enable connected to the driver enable, but nothing operating these. On your PIC, this needs to go to a line that the PIC sets high when it wants to send, and low when receiving. On the monitor, this line wants to be pulled low, so that the chip is permanently set to 'receive'.

On the RO pin of the transceiver, there wants to be a pull up resistor. Otherwise when the PIC is sending, and the receiver is turned off, this line is floating, and you can get random 'unwanted' characters received.

You don't actually need a DI connection to the transceiver on the PC side (since this will be set to permanently receive).

I suspect you have taken part of a circuit that uses RTS to control the 485 buffer direction, which is why you have this pin connected to the RS232 transceiver. Going on to the wrong place, and not wanted.