UART signal buffering down a long wire

[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.