Stopping the LIN bus "echo back".
Using a RS485 transceiver, there is a "direction pin" you set for transmit or receive, which switches the direction of the transceiver for receive or transmit.
On the LIN bus transceiver there is no direction pin and transmitting a packet will send all data back ("echo back") into the receive buffer.
Question: Is there a way to stop / disable / restart the receiver buffer on the Arduino? I hate time delays.
Note: The Arduino design team should look seriously at adding a transmit buffer and its functions to the Arduino. With the increased ram on the 328 and Mega this addition could be easily added and would be very helpful for the Arduino users. By knowing exactly when the tranmit buffer is done, the user could process other data in an orderly timed fashion.

Isn't the hardware ECHO BACK part of the LIN protocol specification (so it's the only way the LIN chip works)?
I think LADYADY made some modified BOOTLOADERS that do what you want. Arduino Hacks
Isn't the hardware ECHO BACK part of the LIN protocol specification (so it's the only way the LIN chip works)?
The LIN tranceiver chip, reguardless of the LIN 2.0 spec which I am not using, looks like it was made with the "echo back" built it.
I think LADYADY made some modified BOOTLOADERS that do what you want. Arduino Hacks
In my software, I try to stick with the standard Arduino release. By going to some "special" third party software, which may not be supported in the future, is a risk I will not take. I remember, a software serial library which did not work, when the standard release was made, and the timing messed up the third party's library.

The RXD on the LIN transceiver follows the signal on the LIN bus. The connection is internal to the chip and there is nothing you can do about it.
If you are using the hardware USART in the ATmega, you might have to write your own driver as "flushing" the receive buffer after every transmit "could" allow you to miss a slave response unless your slaves are well behaved. This is one of the reasons you were advised not to use the LIN transceivers for your project.
There is a transmit buffer in the ATmega chip. It's just not very deep. 
An interrupt is generated when the transmit buffer is empty. Use that to proceed in an orderly fashion. On the other hand, based on your baud rate you already know exactly how much time you have to do other processing between transmitted bytes. At the maximum 20k baud that the LIN bus supports you will have about 500 usec between bytes. Use it wisely, Grasshopper.

If you are using the hardware USART in the ATmega, you might have to write your own driver as "flushing" the receive buffer after every transmit "could" allow you to miss a slave response unless your slaves are well behaved.
That's what I exactly did ... Serial1.flush() then put the hated delay until
the real data arrived.
This is one of the reasons you were advised not to use the LIN transceivers for your project.
Its very hard to confvince me not to use the automotive harden LIN bus transceiver.
The only thing RS485 have is speed and a longer distance, but LIN has other unique features that RS485 cannot match.
#1 LIN RS485 Comparisons: LIN RS485
Max nodes: 16 32
Max cable length: 120 feet/40 meters 4000 feet/1200 meters
Max baud rate: 9600- 19,200 8N1 100kbs/sec
Bus diagnostics: YES (Built into transceiver) No
Cost per node: Low Low
Short circuit bus protection: Yes No
Master/ many Slaves Yes Yes
Half Duplex Mode only Yes Yes
Multi-Master NO Yes
Bus power supplies node power: Yes (50ma reg. @ 5Vdc max.) No
Can use Ethernet cabling Yes Yes
Termination for bus: Yes Yes
Bus wires needed (3) 1 wire bus, Pwr. & GND. (3) 2 wire Dif. Bus, GND.
Arduino I/O pins needed: (3) Tx, Rx, Fault (3) Tx., Rx. & Dir.
Easy to troubleshoot bus: Yes No
Nodes floats on bus fault: Yes No
Transceiver Low Power mode Yes No
Low cost unregulated power Yes No
Protected against shorts Yes No
Protected against loss of ground Yes No
Slave has Internal pull up and diode Yes No
Automatic thermal shutdown Yes No
Recessive state on loss of ground Yes No
... Sorry for the formatting.

That's what I exactly did ... Serial1.flush() then put the hated delay until
the real data arrived.
Unnecessary if you will use a normal serial bus driver chip.
Some of your "yeses" come from your failure to read the data sheets for the available RS485 drivers. For example, thermal shutdown, low power mode and automotive temp range. Others come from your misinterpretation of what some of the "features" actually do. For example, !FAULT/TXI gives you even less information about what's actually wrong than the "check engine" light on the car's dash.
I think you have fallen prey to "buzz word fever" as so many young designers do and the only cure is like for a cold, just suffer through it. And whine, of course.

For example, !FAULT/TXI gives you even less information about what's actually wrong than the "check engine" light on the car's dash
This feature tells a user if there is a thermal overload, bus short to VBB or
bad chip. Having the Arduino poll this fault line and skipping the bad node
is fantastic. I would like to see the "old technology" RS485 do the same.

I would really like to see an example of polling a node that is in thermal shutdown, or polling anything on a shorted bus, or talking at all to a bad chip.
I've used this bus in the real world and the only diagnostic you get is "LIN bus failure". If I poll my RS485 slaves and don't get anything back, I know just as much.

You have to take the good with the bad, I guess. I really like the IDEA of LIN protocol and related hardware... it basically "fixed" some Dallas/Maxim 1-wire technology's most annoying shortcomings.
As we have discussed in the past, I'm taking the other fork in the road and working with aging RS485. It's old, but I don't think it's dead yet.
Clearly the benefits of hardware (UARTS, etc) doing the work are great but then you can have a hard time "fixing" them when you want variations. Putting the intelligence in the software has a price... but you gain flexibility.
IMHO - we are stuck with deciding on the trade-off's but then we have to live with them.
I'm all for someone re-inventing the SERIAL UART coprocessor with built in buffer we can attach to projects. I imagine there is something can be done... I just haven't seen it yet.
I would really like to see an example of polling a node that is in thermal shutdown, or polling anything on a shorted bus, or talking at all to a bad chip.
I have a RED LED on each LIN node to indicate a node failure. This sure helps troubleshooting node failures. No comm anaylzer needed.
In the MASTER polling software, on the 2 port Gator board , I have retries and timeouts. Having the VBB shorted the LIN bus or thermal overload is a very remote possiblity because I am not using it in a harsh environment of an automoblie. As with the RS485, when the bus goes down you are screwed and any helpful diagnostic is worth having besides I can disconnect a node and re-install a node in 3 seconds using Ethernet RJ45 wiring.

Exactly. And live with your decision.
RS485 is far from dead. Just take a look at the dozens of new drivers that Maxim and the lot have released.
The hardware USART chips with FIFOs satisfy the criteria for a serial usart coprocessor to a large extent. Some of the FTDI chips have FIFOs if USB is your bag.
@AA
Thank you. I rest my case. All of the things you mention apply to RS485 as well.
Folks, who missed my other link on the LIN bus.
Here is the "beta" schematic for my LIN node PCB
which is working with the "echo back" as we speak.
Please click on and "save the picture as" in case the Internet
service provider decides to change his file sharing terms:
Additional info ... For daring souls only.
If you need my FREE LIN node design packet for the LIN node PCB boards and BOM (bill of materials) for PCB components just send me a PM.
The schematic and PCB files are to be used with ExpressPCB FREE design software. You could use my design and import my PCB design into their software and Internet order the mini boards and have them in 5 days - have your credit card handy. You get 3 mini boards x 3 = 9 LIN boards (without silkscreen and soldermask). The cost is $51 + shipping.
Note: You need to shear the "step and repeat" boards apart yourself.
Note: I have no financial interest in ExpressPCB. Since I designed these LIN node boards myself there should be no reason to "re-invent the wheel"

LIN Software Testing Update:
Background: This origonal thread had to do with "echo back" caused by the LIN bus on every packet transmission. The Arduino receive buffer would fill up with the transmit bytes from the transmit packet array.
The Arduino has a 128 byte interrupt driven receive buffer but does not any transmit buffer except for 2 registers. When transmitting, a user has NO idea when the transmission of the bytes will finish. This will cause problems when receiving packets from other LIN nodes.
With my LIN hardware testing @ 19200 baud it takes about 34 ms to transmit 38 packet bytes. By using the "echo back" feature and reading the receive buffer, I can determine exactly when the transmisson of packet bytes are finished!
Problem solved.
