Lose RS485 wire A in one direction, not the other

Go To Last Post
10 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

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

Been a while since I reported back on this issue. 

 

I have the RTU and the suspect cable connected to the head end controller and things were still not right with the A line.  I started poking around some more and could not find anything wrong with the RS485 line.  EVERYTHTHING meters out as OK.  All connections are where they belong, and are solidly made.

 

What I DID find is the ground/shield line for the RS232 line to the Crestron system was loose.  I re-terminated the two data lines and the ground/shield and...........things are back to working again!

 

 

For the life of me I cannot understand why the ground/shield for the RS232 affected the RS485, and ONLY the A wire, and in ONLY one direction.  The ground/shield for both the 485 and the 232 are connected together on the PCB and to the power supply ground.  Both Driver chips are +5vdc powered and both are powered from the same supply.

 

If time allows I will look into this some more as I cannot come up with a viable reason for the cause/effect on this.

 

Cannot mark SOLVED just yet

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

  

David (aka frog_jr)

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

Are the RS-232 and RS-485 cables running together?  I've had cases where the RS-232 was spiking other signals in the same cable.

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

No. Separate lines.

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