Lose RS485 wire A in one direction, not the other

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heres one thats got me stumped

 

I have an RS485 link from my head end controller to my pool's RTU  19.2k speed, cable length is about 50 feet.

 

Here's the cable:

https://www.markertek.com/produc...

 

This link has been running 24/7 for several years without a problem up until the other day where I no longer get readings displayed on the touchpanel.

 

The RTU is indicating that it is getting valid packets from the head end, and is responding to them with TX, and RX led's that are connected to the AVR so if they are not lit, it means the AVR is not getting something it recognises.

 

At the Head end I left out the LEDs - Stoopid me, but a scope and Logic Analyser shows that I am not seeing return data from the RTU on the "A" wire.  Hmm Driver chip died?  Ok, I'll replace it even though the RTU says all is good.

 

I replaced the Driver in the RTU and things are still the same, no data on "A" wire.  I metered the lines and the data lines show 60 ohms, which is correct as I have 120 ohm resistors across the A and B lines.  The 18 gauge lines are to provide power to the RTU and they meter out good too.  I do not see a short from either data line to the shield either.

 

Next I replace the Driver at the Head End, but still, NO DATA ON THE "A" wire at the head end.  I see data leaving the Driver at the Head end, but I only see a reply on wire "B"....WTF?

 

So, I take the Laptop and the Logic Analyser and go to the RTU at the pool.  Put the Analyser on the "A" and "B" lines and I see Data coming FROM the Head End on BOTH "A" and "B" and I see data LEAVING the RTU on both the "A" and "B" lines.

 

How the hell is that possible?  I get data on both lines in one direction, but on the reverse only one line?

 

I yank the termination resistors and no change.  Same thing.  No data on the "A" line in the reverse direction.  The RTU is Sending the data, but it's not showing up on the "A" line.

 

A cursory check of the wire shows nothing, but I will look again in a little while.  I do not expect to see any damage as the lines are all metering out ok, but who knows.

 

My question is, Has anyone ever seen this before?  Data from the head end goes through to the remote, remote responds, but data only comes through on one of the lines?

 

I have confirmed that the RTU driver is operating by connecting the logic analyser at the connectors pins and I see data on both "A" and "B" lines.

 

As a last ditch effort I can change the line out, but I would like to see if I can determine why this is happening first.

 

JIm

 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a somewhat similar situation, might have even been the A side... I kept swapping parts and finally tracked it down a failed leg of a TVS diode. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the feedback!

 

I have two issues against your suggestion....

 

1) I am getting data out of the driver on both A and B from the RTU at the RTU.  I do not have data at teh Head end A line.

 

2) I do not have any TVS/suppression diodes on this link!  OOPS!  The RTU was made with spare parts I had lying around, and the Head End not having any was a brain fart

 

I pulled the RTU from the pool area, and pulled back the communications line.  Cursory inspection checks out ok, now to put it in the test bench and see whats going on.

 

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hairline break in the A line, acting like a cat's whisker, or a 'fox hole radio'?  Long shot, I know ;-) ... but if so, and if the break was disturbed when you pulled back the line, then the behaviour may cease.  Either it may not work at all, or it may work fine.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Mon. Sep 25, 2017 - 02:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you ever sort this out?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, as I have been dealing with some other pressing issues that were/are more important.

 

I did move the cable in question, and the RTU to the lab and set it up right next to the head end, and it still does it.  I also noticed that the same thing is happening on a 3 metre long piece of cable as well.  THere is also a small hiccup at the end of both the poll and response that dos not seem to affect the RTU, but might be causing the Head end to take issue.  I will try and get to this in the next few weeks and report back. 

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user