2
\$\begingroup\$

I have an issue where a certain controller which uses a RS-485 tranceiver (unknown, due to third party device in epoxy resin) sends data on a bus so that signal levels won't cross.

The signal looks like this (yes, I know, measured on oscilloscope with grounded leads connected to device's GND, each channel on bus's A and B).

First data packet is sent from my tranceivers SN65HVD1781A-Q1, second is sent from a third party tranceivers (which chip I can't know due to epoxy resin fill)

enter image description here

It looks like, my receiver end won't see the signals 'low enough' to register them correctly. Without this TI tranceiver, I can read the third party controller from a dongle easily.

  • This picture was generated using a 150 Ohm termination on my tranceiver side. Although third party insisted using no termination resistor - not sure why.
  • Interesting is that

schematic

simulate this circuit – Schematic created using CircuitLab

a) Third party with rs485 USB dongle (no TI's tranceiver) - receive and send works works.

b) SN65HVD1781A tranceiver with Dongle works (no third party)

c) SN65HVD1781A tranceiver with third party (with or w/o dongle) - has this issue.

So either me or the third party might somehow drives the bus at the same time...

How Could I mitigate this anomaly?


Not a direct solution

On test setup I can't access the DE or nRE pins :/, but yes, seems there's some firmware issues. Started to rewrite the send and receive parts, just to confirm, single send or receive parts are working. Currently everything seems to go positively.

\$\endgroup\$
  • \$\begingroup\$ Is the termination correct? The devices drive against the termination resistors, so if the resistance is too low, the sender might not have enough drive strength. \$\endgroup\$ – Simon Richter Nov 29 '17 at 10:40
  • 3
    \$\begingroup\$ Does your bus transceiver release (stop driving) the bus? The scope trace looks like usual bus contention where 2 drivers are driving the bus at the same time. \$\endgroup\$ – Steve G Nov 29 '17 at 11:16
  • 2
    \$\begingroup\$ Try scoping the DE (driver enable) pin at the same time as capturing the bus waveform. \$\endgroup\$ – Steve G Nov 29 '17 at 11:54
  • 1
    \$\begingroup\$ What Steve G said ... This will serve to not only verify that the code is working as intended, but will also verify that DE is not somehow shorted. Also, if possible connect the probe to DE at the transceiver in case the DE connection to your controller is open. \$\endgroup\$ – Tut Nov 29 '17 at 11:57
  • 1
    \$\begingroup\$ @SamGibson Ok, thanks, could've been better indeed. Added a simple setup diagram. Although already figured out that there was smth wrong with the code. Not sure exactly what, just started to rewrite it, only recieving part - check if it works, and then move on. So most probably the communication mechanicsm was flaky indeed. \$\endgroup\$ – crypton Nov 29 '17 at 13:55
3
\$\begingroup\$

This is a quick guess, but it smells like your transceiver is not releasing the bus. The other transceiver is then fighting against yours when trying to drive the lines to their opposite states. Yours appears to work fine since it doesn't have to fight with anything else on the bus.

Look carefully at your code and see if you properly release the line when done transmitting. Or, sometimes this is done in hardware. Either way, take a close look at this mechanism. It is likely faulty.

Have your device send a message with nothing else connected to the bus. Then afterwards measure the current it takes to short the high line low and the low line high. I suspect you'll find that current is a lot more than it should be according to just the passive bus pullups and pulldowns.

\$\endgroup\$
  • \$\begingroup\$ In some other serial protocol I had a similar issue with I introduced some resistances, forming voltage divider with the existing setup, and by measuring on either sides I could see that something was pulling up where not expected. I guess this should be possible here too. \$\endgroup\$ – PlasmaHH Nov 29 '17 at 12:12
  • \$\begingroup\$ This would not explain why it is unique to one device. They state that both devices can communicate with a third party device. \$\endgroup\$ – StainlessSteelRat Nov 29 '17 at 12:32
  • \$\begingroup\$ @Stain: I took it to mean the other device can communicate with a off the shelf dongle when the OP's device is not connected to the bus. Note the "without this TI transceiver", meaning without the OPs (faulty) device. \$\endgroup\$ – Olin Lathrop Nov 29 '17 at 12:36
  • \$\begingroup\$ Indeed, as others also suggested, the mechanism seemed to be faulty. Rewriting the code and checking in between if the communication works. Hardware seems fine. So marking this as a solution, although (whover reads this later) Do check the comments as these give good insights on debugging possibilities! \$\endgroup\$ – crypton Nov 29 '17 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.