UART signal buffering down a long wire

[josechow]

So, I have the need to send a 3.3V TTL UART signal (9600 baud or lower) down a 25 foot noise-y cable. Below is what I intend on doing to mitigate noise concerns and prevent data corruption as the voltage level is too low at 3.3v and may cause problems. I am doing this instead of implementing a RS-232 styled signal because I dont have the power supply requirements on both ends of the sending and receiving UART's. I have no need for bidirectional communication, just one sender is sufficient.

So my thought process was:
1.) send out signal
2.) Buffer it with NPN network to a 0-12 volt level (or w/e I find is low enough to work sufficiently)
3.) voltage divide the signal down to 3.3V and provide diode protection.
4.) Invert the logic on the Receiving UART

Are there any pitfalls in this design that I should know about? It seems to work fine in simulation. I just wanted some pointers before I implement. There are some optimizations like changing the resistor values to reduce power consumption that I will do.

[uncle_bob]

Hi

What you have shown is essentially a re-invention of the Dallas Semiconductor "one wire" communication approach. Like it, you don't get a lot of noise immunity. The thing you gain is the elimination of a power supply at the receiving end. You actually don't eliminate the supply as much as you take one wire out of your cable. (Thus the term "one wire").

If noise really is the issue, putting that wire back into the cable is a much better solution.

Bob

[T3sl4co1l]

RS-232 exists for this purpose, and yeah, you're basically recreating it...

If you don't need a full 232 device at the RX end, just use a schmitt trigger with a threshold around 0-3V.  Don't leave out the noise filtering and ESD protection.  Use a normal 232 transmitter (if it has a free RX or two, who cares?).

You may also be better off with twisted pair, RS-422 or whatever.  Individual transmitters and receivers are available, the common mode range is comparable, and the supply voltage is low (3.3 and 5.0V options).

If you can talk about your noise environment and what kind of grounding and shielding requirements you're expecting for this cable, we could provide more specific ideas.

Tim

[rstofer]

If you have to add bits and pieces anyway, why not just use an RS485 driver chip on each end?

[uncle_bob]

Hi

An RS-485 system could easily give you a couple of miles of range. It adds two wires to your cable bundle. It also would give you a bidirectional line if you eventually needed it.

What about your system rules out a 4 wire cable?

Bob

[josechow]

If you can talk about your noise environment and what kind of grounding and shielding requirements you're expecting for this cable, we could provide more specific ideas.

Tim

So I am kind of doing something a bit strange it seems, as I have been trying to get help on each piece as each problem comes up. But this is what I am looking at and I might have to change my approach or setup.

I am trying to fit the following connections down a 5-wire cable (a 5-din  midi cable)
1.) + audio (balanced pair)
2.) - audio (balanced pair)
3.) 24 V dc power
4.) Ground
5.) RX from one microprocessor to the receiving one

Within those
1.) The ground wire is the shield
2.) Cable resistance of each conductor is 3 ohm, capacitance is 1nF
3.) Audio balanced pair produces fundamentals from 20Hz to 3KHz, with prominent harmonics up to 10KHz
4.) 24 V power is a switching supply with noise in the 64Khz range and associated harmonics above up to 2MHz
5.) The receiving end powers 3 independent PWM led drivers that operate at 600KHz, with current pulses at 500Hz which is seen in the 24V line.




In addition, the setup I had before had single ended audio and instead had a TWI (SCL/SDA) setup for communication between the microprocessors and communication worked fine, except the single ended audio caught all the noise and I couldn't filter it all out sufficiently.

[uncle_bob]

Hi

Ok, so you already *have* power at the far end.

The simple answer is RS-232 with conventional single chip receiver and transmitter IC's. You have a switcher on the supply line so it's already noisy as all get out.

Bob

[josechow]

Hi

What you have shown is essentially a re-invention of the Dallas Semiconductor "one wire" communication approach. Like it, you don't get a lot of noise immunity. The thing you gain is the elimination of a power supply at the receiving end. You actually don't eliminate the supply as much as you take one wire out of your cable. (Thus the term "one wire").

If noise really is the issue, putting that wire back into the cable is a much better solution.

Bob

Thanks! I wasn't sure what the configuration was called.  What do you mean by putting the wire back into the cable? As in a shielded cable? I just posted my requirements above. Hopefully I defined my problem a little better.

[uncle_bob]

Hi

What you have shown is essentially a re-invention of the Dallas Semiconductor "one wire" communication approach. Like it, you don't get a lot of noise immunity. The thing you gain is the elimination of a power supply at the receiving end. You actually don't eliminate the supply as much as you take one wire out of your cable. (Thus the term "one wire").

If noise really is the issue, putting that wire back into the cable is a much better solution.

Bob

Thanks! I wasn't sure what the configuration was called.  What do you mean by putting the wire back into the cable? As in a shielded cable? I just posted my requirements above. Hopefully I defined my problem a little better.

Hi

The wire I was referring to is the wire you already have in the cable. The idea is to put power on one wire and data on a different wire. You have 24V on the cable already. There is no need to move power on the same wire that you have the data on. Having a separate supply lets you use cheap / easy to get chips to solve the problem.

Bob

[Ian.M]

As your power and data grounds are shared, and RS232 receivers will respond to as little as 3V levels, I'd be looking for something more robust with thresholds further from the 0V level.

Consider using LIN bus transceivers (just for the physical layer), as they are designed for single-ended serial comms in an electrically hostile high EMI environment, and have thresholds that will give better noise immunity than RS232.   You'd need a 12V supply at each end for the transceiver, but that should be fairly simple to provide.  Some are rated for 18V operation which further improves the thresholds and thus noise immunity.

If you aren't continuously streaming PWM update data, it may also be worth looking at taking advantage of LIN bus's bidirectional capability so your slave MCU can ACK each data packet with a checksum, and the master MCU resend any that were received corrupted.

[uncle_bob]

As your power and data grounds are shared, and RS232 receivers will respond to as little as 3V levels, I'd be looking for something more robust with thresholds further from the 0V level.

Consider using LIN bus transceivers (just for the physical layer), as they are designed for single-ended serial comms in an electrically hostile high EMI environment, and have thresholds that will give better noise immunity than RS232.   You'd need a 12V supply at each end for the transceiver, but that should be fairly simple to provide.  Some are rated for 18V operation which further improves the thresholds and thus noise immunity.

If you aren't continuously streaming PWM update data, it may also be worth looking at taking advantage of LIN bus's bidirectional capability so your slave MCU can ACK each data packet with a checksum, and the master MCU resend any that were received corrupted.

Hi

A 5V powered MAX232 style chip will be running +/- 10V signaling on the TX end. It will accept +/- 30V on the RX end.  That's pretty robust. More robust other single ended approaches. Indeed that is a very specific RS-232 implementation. There are many ways to do it, some with much less noise immunity. Something like RS-485 with good chips would do better, but the wires are not there to do it.

Bob

[Ian.M]

There's also the possibility of using the balanced audio pair to provide a stable reference for the data signal, which will get most of the ground bounce out of the picture.

[T3sl4co1l]

So I am kind of doing something a bit strange it seems, as I have been trying to get help on each piece as each problem comes up. But this is what I am looking at and I might have to change my approach or setup.

That can be okay, but reductionism doesn't take you far in system design.  You have to consider the whole of the system, including nearby noise sources, radio transmitters, etc.

Not that you can have perfect knowledge about those sorts of things, but you can make SWAGs.  That's really all the regulatory standards are; 3V (conducted) or 3V/m (radiated) susceptibility (typically used for CE marked equipment) is sort of an "average worst" case.  It's expected to get worse than that in some conditions, but those are rare enough not to really care.  Equipment for tougher conditions (industrial, military, lab, special purpose) will need more (for which there are other standards that can be used, as well).

I am trying to fit the following connections down a 5-wire cable (a 5-din  midi cable)
1.) + audio (balanced pair)
2.) - audio (balanced pair)
3.) 24 V dc power
4.) Ground
5.) RX from one microprocessor to the receiving one

Within those
1.) The ground wire is the shield
2.) Cable resistance of each conductor is 3 ohm, capacitance is 1nF
3.) Audio balanced pair produces fundamentals from 20Hz to 3KHz, with prominent harmonics up to 10KHz
4.) 24 V power is a switching supply with noise in the 64Khz range and associated harmonics above up to 2MHz
5.) The receiving end powers 3 independent PWM led drivers that operate at 600KHz, with current pulses at 500Hz which is seen in the 24V line.

Ok, that sounds pretty good.  But, are those the frequencies that you're filtering them at (at either end, ideally both), or merely what you intend to be there?

If the two answers are different, you should probably add the filter to fix that.

In addition, the setup I had before had single ended audio and instead had a TWI (SCL/SDA) setup for communication between the microprocessors and communication worked fine, except the single ended audio caught all the noise and I couldn't filter it all out sufficiently.

You'll still have that problem with the uncontrolled impedances in the cable, unless you've very specifically obtained a cable that has the pair twisted independent from the rest.

Controlling slew rate and filtering the signals will be the biggest help.  If you didn't have any filtering, and the audio signal was high impedance, and the signal path included bipolar op-amps or something like that, all the high frequency noise will be detected by the amps and converted to audio.

Using a smaller digital signal level will obviously help, too.  Naked RS-422 wouldn't help you much here due to the high slew rate, but some RLC filtering can knock that down to quite reasonable levels.  And then you won't need to run as slow as 9600, though you still can.

The main downside is you'd need to add a sixth pin to the cable and connectors...

(Or you can do something quirky like multiplex it with the supply pin, which is possible with, say, Manchester encoded data and a transformer -- ala PoE -- but now we're talking lots of extra hardware.)

Tim

[josechow]

Not that you can have perfect knowledge about those sorts of things, but you can make SWAGs.

I admit, I had to look that one up "SWAG". Gave me a chuckle.

Ok, that sounds pretty good.  But, are those the frequencies that you're filtering them at (at either end, ideally both), or merely what you intend to be there?

If the two answers are different, you should probably add the filter to fix that.

Yup. For the balanced audio pair power supply, I have several RLC filters to keep the balanced pair as quiet as possible (at the very least) with all the ground terminations separate from all the noisey switching. I am designing the layout to use through hole components so its easier to adjust the values later.

You'll still have that problem with the uncontrolled impedances in the cable, unless you've very specifically obtained a cable that has the pair twisted independent from the rest.

Controlling slew rate and filtering the signals will be the biggest help.  If you didn't have any filtering, and the audio signal was high impedance, and the signal path included bipolar op-amps or something like that, all the high frequency noise will be detected by the amps and converted to audio.

Using a smaller digital signal level will obviously help, too.  Naked RS-422 wouldn't help you much here due to the high slew rate, but some RLC filtering can knock that down to quite reasonable levels.  And then you won't need to run as slow as 9600, though you still can.

The standard midi cable has pins 4/5 as a twisted pair, with 2 as shield. The complete 5 conductor cables have this scheme with the extra two wires floating outside of the shield on pins 1/3. Its a good thing you brought it up because I had to look it up and verify this was the case rather than cut open one of the cables I bought already. I assumed that it was two twisted pair and a shield covering the both of them... Assuming things never helps!

As for the RS-232, I saw the chip has slew control via external capacitor. I only really need 9600 baud or lower. It doesn't need to push data very often and not a lot of it.

[T3sl4co1l]

Separately shielded twisted pair sounds pretty sexy!  Then, putting a nice large digital signal on one of those outside wires should be pretty safe.

Tim

[uncle_bob]

Not that you can have perfect knowledge about those sorts of things, but you can make SWAGs.

I admit, I had to look that one up "SWAG". Gave me a chuckle.

Ok, that sounds pretty good.  But, are those the frequencies that you're filtering them at (at either end, ideally both), or merely what you intend to be there?

If the two answers are different, you should probably add the filter to fix that.

Yup. For the balanced audio pair power supply, I have several RLC filters to keep the balanced pair as quiet as possible (at the very least) with all the ground terminations separate from all the noisey switching. I am designing the layout to use through hole components so its easier to adjust the values later.

You'll still have that problem with the uncontrolled impedances in the cable, unless you've very specifically obtained a cable that has the pair twisted independent from the rest.

Controlling slew rate and filtering the signals will be the biggest help.  If you didn't have any filtering, and the audio signal was high impedance, and the signal path included bipolar op-amps or something like that, all the high frequency noise will be detected by the amps and converted to audio.

Using a smaller digital signal level will obviously help, too.  Naked RS-422 wouldn't help you much here due to the high slew rate, but some RLC filtering can knock that down to quite reasonable levels.  And then you won't need to run as slow as 9600, though you still can.

The standard midi cable has pins 4/5 as a twisted pair, with 2 as shield. The complete 5 conductor cables have this scheme with the extra two wires floating outside of the shield on pins 1/3. Its a good thing you brought it up because I had to look it up and verify this was the case rather than cut open one of the cables I bought already. I assumed that it was two twisted pair and a shield covering the both of them... Assuming things never helps!

As for the RS-232, I saw the chip has slew control via external capacitor. I only really need 9600 baud or lower. It doesn't need to push data very often and not a lot of it.

Hi

A simple R/C filter will let you set the slew rate with just about any RS-232 chip.

Bob

[damn_dirty_ape]

I notice a lot of really good suggestions here, but barring those, this is a really good chance to learn about forward error correcting codes.  To me, it would be most fun to implement some simple algorithms or try to come up with one of my own.

[josechow]

I notice a lot of really good suggestions here, but barring those, this is a really good chance to learn about forward error correcting codes.  To me, it would be most fun to implement some simple algorithms or try to come up with one of my own.

That was the second route, but probably an additional protocol to implement anyway.

Since the data I was sending wasn't time sensitive, I was imagining the transmitter sending 5 copies of one packet and have the receiver look and see if it got two identical copies and accept that packet, throw out the remaining copies as they come in, then wait for the next 5 packet burst to start the next verification process. Its a lot of overhead on the processing side, but that's okay. However, from that I wasn't sure if sufficient noise would throw off the synchronicity of the starting packet and corrupt the entire 5 packet train and render the protocol useless anyway.  I've played with TWI interface much more than UART, so I wasn't sure. I'll just have to try it and see where the test-bench results get me.

[uncle_bob]

Hi

Sending megabytes error free data down a 25 foot cable at much higher baud rates (on a shop floor) is not all that hard. It's done with RS-232 and no fancy codes every day of the week 365 days a year. It's done in a nearly infinite number of locations. This isn't rocket science. It's been done for > 40 years. You either are over-thinking the problem or you have an electrical fault that is likely to kill somebody.

Bob

[Z80user]

So I am kind of doing something a bit strange it seems, as I have been trying to get help on each piece as each problem comes up. But this is what I am looking at and I might have to change my approach or setup.

I am trying to fit the following connections down a 5-wire cable (a 5-din  midi cable)
1.) + audio (balanced pair)
2.) - audio (balanced pair)
3.) 24 V dc power
4.) Ground
5.) RX from one microprocessor to the receiving one

Within those
1.) The ground wire is the shield
2.) Cable resistance of each conductor is 3 ohm, capacitance is 1nF
3.) Audio balanced pair produces fundamentals from 20Hz to 3KHz, with prominent harmonics up to 10KHz
4.) 24 V power is a switching supply with noise in the 64Khz range and associated harmonics above up to 2MHz
5.) The receiving end powers 3 independent PWM led drivers that operate at 600KHz, with current pulses at 500Hz which is seen in the 24V line.

I think the cable have 4 wires and 1 shield, I know are some cable and inside of it have some shield pairs inside, everyone with their own shield normaly for audio signals that kind of cables can help you in the audio but because it's ballanced isn't necesary.
I think change between ttl rs232 and the real rs232 +15/-15V will fix any problem, speed problems with data corruption are one bit to can check it on every data send, don't will be a big issue.

You only can't check if the data are received because are only one wire to can do it, you can't add any handshake protocol or anything else, only know the worst case... how many time the recibe will need to move the data from the buffer to a safe place and "eat it", some microcontrolers have only 1 byte of buffer and can receive another one, in computers are upto 16 bytes in some 32 bytes
as you say send 5 transfers with the same data and check if 2 are equal aren't too expensive in software, I I guess the best thing in that case is add a int routime in your code to made a big buffer and fix that problem, I think the worst thing.

to add some security send 2 times the same code and the 3th time send the inverse and wait some time to send anything again... in the reciver check that and add something to check the timeout (that is more expensive in software)... but I still thinking that can't fix a source of noise, only to check the data and because the rs232 protocol add a parity bit, don't made things more complicated.

[nali]

You only can't check if the data are received because are only one wire to can do it

Seems a lot of fuss over what really is a pretty low data rate over an average length of cable. But you could try

Modulating the data onto the +24V (e.g. 25V mark 23V space), using the one wire as a return comm
Using collector+pullup transistor each end of the one wire OR'd, and use time slots

Consider that if you're talking about FEC you can use a lower baud rate & slew rates anyway...

[Ian.M]

I already mentioned LIN transceivers which do bidirectional half duplex over a single data wire.

[josechow]

I already mentioned LIN transceivers which do bidirectional half duplex over a single data wire.

There is not a ton of literature in my quick search online for them, do you have anything I could take a look at? Like an implementation diagram? They are about on par price-wise with the RS-232 solution, so I am digging into it now. Thanks for the heads up! Looks like a better solution just in case I want bidirectional communication in the future.

[uncle_bob]

Hi

So why the improperly used Midi cable? A lot of this revolves around that cable. The stuff you are putting on it will likely fry any Midi device you plug it in to so it's not for compatibility reasons. I'd actually argue that if you have Midi gear, that makes this a somewhat bad idea. There are common / low cost / purpose designed high volume cables and connectors that do multiple twisted pairs. They are easy to work with and come in a wide range of pair counts. Hint: 4 pairs / 8 wires is a real common one. There also are about 150 years worth of surplus parts out there to do things like drop power onto pairs in combination with low noise audio.

Bob

[josechow]

So why the improperly used Midi cable? A lot of this revolves around that cable. The stuff you are putting on it will likely fry any Midi device you plug it in to so it's not for compatibility reasons. I'd actually argue that if you have Midi gear, that makes this a somewhat bad idea. There are common / low cost / purpose designed high volume cables and connectors that do multiple twisted pairs. They are easy to work with and come in a wide range of pair counts. Hint: 4 pairs / 8 wires is a real common one. There also are about 150 years worth of surplus parts out there to do things like drop power onto pairs in combination with low noise audio.

The MIDI cable, at least in the interim, has everything I need with respect to cable flexibility and cost. I am aware that it should not be connected to a midi device and I will be putting red tags on the connectors to make sure I dont mistakenly do that!

I have been trying to look for a flexible, and relatively light cable to connect between the two points.  The one cable end is at a controller/amplifier, and the other is connected to an instrument to do some cool lighting effects and what not. So the light and flexible attribute is a mandatory convenience criterion. If you have any standard cables in mind, I am all ears

EDIT: I know that using a standard connector type is not recommended because users will almost always mess it up.  But the restriction and use of the cable has helped me explore different electrical engineering principles in regards to shielding, noise suppression, EMI, signal flow, etc. So yeah... probably not the best, but it has taken me down a pretty cool learning path.