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.

[uncle_bob]

Hi

8 pair is a standard ethernet cable. They come in all sorts of materials. You can wire them so they what you need *and* will not fry a normal switch port. If you have PoE stuff around, it already does much of what you are trying to do.

Bob

[T3sl4co1l]

Hi

8 pair is a standard ethernet cable. They come in all sorts of materials. You can wire them so they what you need *and* will not fry a normal switch port. If you have PoE stuff around, it already does much of what you are trying to do.

Bob

But don't accidentally plug it into Ethernet devices, especially PoE sources.

Shielded is better, as it preserves common mode and differential signals.  Running diff pairs naked through space is scary.  You need to take some serious precautions.  Like friggin' transformer coupling.  Which would be heroic for audio, but is quite neatly achieved for 10Mb+ Ethernet.

Tim

[Ian.M]

I also think that Cat5 STP cabling would be preferable. You could then use RS485 (with slew rate limiting) for the data signal on one pair, balanced audio over another pair leaving you two pairs for low resistance power and ground. 

However, if you are committed to using those MIDI cables, and want to implement single data wire bidirectional comms, an introduction to the LIN bus can be found here: http://www.eetimes.com/document.asp?doc_id=1272421
and the actual physical layer specifications (see section 6) here:
http://tge.cmaisonneuve.qc.ca/barbaud/R%C3%A9f%C3%A9rences%20techniques/Bus%20LIN/LIN-Spec_Pac2_1.pdf
There's no need to implement the LIN packet format or protocol, though it would be a good idea to wait between transmissions long enough to guarantee you don't violate the duty cycle limits with worst case data (all 0xFF).

Then grab the datasheet for a 24V rated LIN Transceiver (the standard only requires an 18V rating so you need to be slightly picky) and see if it makes sense to you. 
e.g. Maxim's MAX13020 ±60V Fault-Protected LIN Transceiver: https://www.maximintegrated.com/en/datasheet/index.mvp/id/5189

[SeanB]

Ethernet STP cable can also have offset plugs and sockets, which have the clip in a different position than the centre. this was used a lot on IBM equipment as interconnects, though there they tended to use a 10 way connector and even a few 12 way ones.  You could have 4 identical cables ( near enough) with the only difference being the width and clip position, and never be able to incorrectly connect them provided you were not a ham fisted idiot.

Only issue with them is that standard cheap crimp tooling does not work on them. You will be buying expensive tooling.  So just use regular ends and use coloured sleeving and boots with a bright colour to mark them as special.

[josechow]

So I am having a little trouble understanding the physical layer of the LIN transceiver.

I've attached a crudely painted sketch of the transciever and signals I am interested in and what I think will happen. So, from my understanding, the LIN transceiver just does a buffer delay and signal filtering. From that, in the event that one uC sends out a serial message on TX, it will receive its own message on its RX at a delay; then, the protocol of the sending uC unit must understand that the RX signal it just received must be ignored, correct?

So, just to clarify fully, I cannot attach a LIN transciever to two connected uC's and use the standard Serial.send and SerialEvent() methods of a typical arduino serial library/protocol because of the resulting send and receive collisions, right?

[uncle_bob]

Hi

8 pair is a standard ethernet cable. They come in all sorts of materials. You can wire them so they what you need *and* will not fry a normal switch port. If you have PoE stuff around, it already does much of what you are trying to do.

Bob

But don't accidentally plug it into Ethernet devices, especially PoE sources.

Shielded is better, as it preserves common mode and differential signals.  Running diff pairs naked through space is scary.  You need to take some serious precautions.  Like friggin' transformer coupling.  Which would be heroic for audio, but is quite neatly achieved for 10Mb+ Ethernet.

Tim

Hi

Well ... the telephone company seems to have been able to get along with unshielded pairs over many miles for many years without spending a lot of money per circuit. The same dirt cheap / small transformers they used will do a fine job here. RS-485 / RS-422 is intended to handle this sort of thing so ... no transformers for the data side.

Bob

[Ian.M]

The LIN bus needs 1K of pullup resistance (with a series diode) to Vbat.  If you use >24V continuous rated transceivers, Vbat could simply be your 24V rail.  This is normally put at the master.

The transceiver echos every bit sent locally with a delay of less than one bit time, but the UART doesn't finish receiving the byte till the stop bit is sent, so from the MCU's point of view, it receives every character sent immediately after its finished sending it.  The echoed character should be checked against what was sent to detect hardware bus faults.  Local echo is extremely common (e.g. RS485 also has hardware local echo) and you shouldn't have any problem using the Arduino libraries with it.   You must avoid collisions by making the slave wait for the master to finish transmission before it is permitted to respond.  As the master is expecting a reply, it will also need to wait till the slave has finished before it sends another message.

For serial software testing, you can 'fake' a LIN bus at TTL logic levels by simply connecting a Schottky diode from UART RX to TX, cathode to TX, with a pullup resistor from RX to Vdd.  Wire the RX pins of all the devices together to form the bus. Don't forget to connect the Gnd pins and don't try to make the fake bus longer than a metre or so!  Obviously this wont implement the LIN hardware wakeup signalling.

[josechow]

The LIN bus needs 1K of pullup resistance (with a series diode) to Vbat.  If you use >24V continuous rated transceivers, Vbat could simply be your 24V rail.  This is normally put at the master.

The transceiver echos every bit sent locally with a delay of less than one bit time, but the UART doesn't finish receiving the byte till the stop bit is sent, so from the MCU's point of view, it receives every character sent immediately after its finished sending it.  The echoed character should be checked against what was sent to detect hardware bus faults.  Local echo is extremely common (e.g. RS485 also has hardware local echo) and you shouldn't have any problem using the Arduino libraries with it.   You must avoid collisions by making the slave wait for the master to finish transmission before it is permitted to respond.  As the master is expecting a reply, it will also need to wait till the slave has finished before it sends another message.

For serial software testing, you can 'fake' a LIN bus at TTL logic levels by simply connecting a Schottky diode from UART RX to TX, cathode to TX, with a pullup resistor from RX to Vdd.  Wire the RX pins of all the devices together to form the bus. Don't forget to connect the Gnd pins and don't try to make the fake bus longer than a metre or so!  Obviously this wont implement the LIN hardware wakeup signalling.

Awesome. Should I still be able to get about the same noise immunity properties if I use a lower voltage? Say 5V on Vbat? None of the datasheets I saw provided me that much information other than the obligatory "this unit handles well in high EMI environments".

Below is a code structure I think i'll have to implement from your response.

Code: [Select]

loop(){
   other_code();
   if (send_packet == true){
      verified_packet = false;
      sent_message = what_im_sending();
      while (verified_packet == false ){
         send_three_bytes(sent_message);
         delay(10);
         local_return_valid = read_three_bytes(sent_message);
         if (local_return_valid == false){
            throw_fault_warning();
            break;
         }
         delay(100);
         received_return_valid = read_three_bytes(sent_message);
         if (received_return_valid == true){
            verified_packet = true;
         }
      }
   }
}


[Ian.M]

No.  The noise immunity is solely due to the large difference in input threshold levels and the large output voltage swing.  Also I wouldn't expect LIN transcievers to work properly below 9V Vbat so yu cant simply run them from 5V.  The diode combined single wire 'fake 5V LIN' bus has *extremely* poor noise immunity as the diodes compromise the logic low threshold - its *PURELY* for software testing before you buy any LIN transceivers.

If you do decide to go down the LIN route, and don't have a DSO with a protocol analyser that understands LIN, get an extra transceiver and hook it up to a PC serial port, either using a USB<=>serial (logic level) bridge or a MAX232 or similar so you can easily sniff the bus and send test messages.   You'll need a terminal program that lets you twiddle the handshake lines manually so you can do the transceiver wakeup sequence.

[T3sl4co1l]

I'm missing how it benefits the OP to use a protocol which is more than specified, and requires high voltage on both ends...



Tim

[Ian.M]

I'm missing how it benefits the OP to use a protocol which is more than specified, and requires high voltage on both ends...

The high voltage is there anyway, and if one doesn't have balanced lines, in the presence of ground bounce one needs enough difference between the mark and space levels for the ground noise not to compromise the logic thresholds.    The fact that LIN is multi-drop bi-directional is just icing on the cake.  You could simply use RS232, but that would be unidirectional.   I'm *NOT* suggesting using *anything* from the higher layers of the LIN protocol, just the physical layer and normal UART character framing at <20Kbaud.  LIN transceivers also tolerate loss of ground or Vbat without damage and have good ESD immunity - both beneficial features if the cable is removable and there is any risk of hot-plugging.