Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Comms bus immune to EMI

Status
Not open for further replies.

strantor

Active Member
I need to communicate with a device through a 200m multiconductor cable. Some of the cable conductors are used to power motors via a VFD. There will be A LOT of EMI in the cable. Assume worst case, there will be no shielding on the comms bus conductors (although there probably will be).

Is there ANY comms bus hardware protocols that are guaranteed (or highly likely) to tolerate this crazy high EMI environment? Please do not suggest fiber optics. I already know that is the best solution but I am trying to find a simpler and cheaper alternative. Please do not suggest wireless. That is not an option for this application.

Here's what I'm considering so far (in order of what I think will work best):
  • Ruggedized industrial comms busses such as Power rail boosted Profibus and Dupline.
    • Assumption: If it's designed to operate out to 10km, over slip rings and bus bars adjacent to power bus bars, and if it makes claims of "exceptional noise immunity" or "immune to noise" then maybe it lives up to its claims and maybe it has a chance.
  • Point-to-point pair of "ethernet extender" DSL modems ranging from this to this.
    • Assumption: if it's designed to operate over a 20,000m aerial antenna (suspended phone line) adjacent to power lines, then it should be able to operate through only 200m of exceptionally noisy cable.
  • EoP (ethernet over powerline)/BPL(broadband over powerline) with solutions ranging from this to this.
    • Assumption: if it's already designed to communicate ON noisy power lines, it should be able to handle comms over a clean isolated sine wave NEXT to noisy power lines.
  • A homebrew amplified serial connection involving optically isolated transceivers and high current, low impedence I/O.
    • Assumption: If serial clock and data lines are optically isolated (responding to current flow instead of voltage fluctuations) with very low impedance (requiring a relatively very high current, tens or hundreds of mA) to change state, then EMI would not be enough to cause inadvertent state change or prevent intended state change.
  • Multiplexed 4-20mA analog signals or HART modem
    • Assumption: same as above, current instead of voltage driven signal, should be more EMI tolerant.
  • Typical industrial protocols (CAN Bus, MODBUS, RS-485/422 variants - devicenet, profibus, etc.), via Isolated repeater or not.
    • Assumption: these protocols are differential signals with high common mode rejection. Any EMI that affects one wire affect the other as well. They are proven tech in industrial settings and may be sufficient.
You'll notice that everything above has an "assumption" under it. According to what I've uncovered in researched, not one of these technologies is guaranteed to work, and in fact the manufacturer recommends not doing what I'm trying to do. Hopefully I find something guaranteed to work, but if not, I would appreciate if anybody would like to weigh in on what I've proposed so far or make suggestions on anything I have missed. Is my list out of order? I am open to any option that would/should/might work. I would prefer an ethernet-based solution but that is a matter of convenience, not a requirement.

Thank you
Chuck
 
This is a simple one. Based on the information you've given, 42 amp pulses of 271.8 Vdc at a 1 Hz rate will come through with excellent signal integrity.

ak
 
Last edited:
This is a simple one. Based on the information you've given, 42 amp pulses of 271.8 Vdc at a 1 Hz rate will come through with excellent signal integrity.

ak

LOL ok point taken.

I have (8) analog sensors that I need to read, assume 16bit resolution, that's 128bits for a complete transmission. My baud rate requirement is very low; I could handle getting these 128 bits every half second. So 256bps, and I'll quadruple that to account for addressing/error re-transmission/checksums/handshaking/whatever the protocol demands, and say that 1kbps is the absolute minimum requirement, but preferably at least 10X that, 10kbps.

Conductors will be 14-8AWG unshielded or 20AWG shielded. Your hyperbolic 42A pulses could actually be permissible by conductor gauge.
 
That's because 42 is the answer to life, the universe, and everything.

Separate from that (and 100e and the loneliest number), knowing the S-parameters of the signal path would help. Something simple like frequency shift keying might be all it takes. Or FSK sent differentially through RS-422 chips.

IIWM I'd start by using straight RS-422 to characterize the path at 1 and 10 kHz, and then decide if more is needed.

ak
 
Last edited:
I used RS-485 in a same kind of environment.... I chose to run at 4800 baud.... Use the proper cables.. I used shielded twisted pairs then all pairs were also shielded... We got it working ( eventually ) Shielding the PCB's was the hardest part!
 
I used RS-485 in a same kind of environment.... I chose to run at 4800 baud.... Use the proper cables.. I used shielded twisted pairs then all pairs were also shielded... We got it working ( eventually ) Shielding the PCB's was the hardest part!

Excellent! Thanks for the input! How long was your cable and what flavor of RS-485 did you use?
 
RS-485 hardware was sp485 8 pin dips I use my own little hybrid protocol... Cables were 10M to 100M... They had to run down the same cable run as every cable on the ship bow to stern... Ships are notoriously noisy so it was the only way!! These were flood/search lights .... They were controlled remotely...
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top