LIN bus basics: the low-cost companion to CAN
LIN is a single-wire, low-speed network that handles the simple jobs CAN would be wasted on, such as mirrors, seats and climate flaps. One master sets the schedule, the slaves answer only when asked, and the whole thing runs on a plain UART. Here is how it fits together.
LIN is a single-master serial bus that adds cheap, low-speed control where wiring CAN to every part would cost too much. The master sends a header on a fixed schedule, one slave replies with up to eight data bytes and a checksum, and no node speaks unless the master asks it to. It runs on the plain UART already built into low-cost microcontrollers, which is what makes it inexpensive. LIN complements CAN, it does not replace it.
| Feature | CAN | LIN |
|---|---|---|
| Topology | several equal nodes, peer to peer | one master, up to 15 slaves |
| Wiring | twisted pair, CAN High and CAN Low | a single wire and a ground |
| Speed | up to 1 Mbit/s, more with CAN FD | up to 20 kbit/s |
| Bus access | arbitration on message priority | master schedule, no arbitration |
| Hardware | a dedicated CAN controller | a standard UART |
| Typical use | powertrain, safety and the backbone | body and comfort features |
| Error handling | counters and fault confinement | simple, on the slave side |
A cheaper bus for the simple jobs
CAN is excellent, but every CAN node needs its own controller and transceiver. That cost is hard to justify on a part that sends a few bytes now and then, such as a door switch or a temperature flap. LIN was created so those parts could join a network using the UART already inside a low-cost 8-bit microcontroller. It gives up speed and rich error handling in exchange for a much lower price per node.
The protocol came from a group of carmakers, BMW, Volkswagen, Audi, Volvo and Mercedes-Benz, working with Volcano Automotive Group and Motorola. LIN 1.0 appeared in 1999, the widely adopted version 2.0 followed in 2003, and the specification was later standardised as ISO 17987. Through all of that the core idea stayed the same: one master, a single wire and a predictable schedule.
You will find LIN behind the unglamorous comfort features of a modern car: window regulators, wing mirror adjust and fold, seat motors, sunroof drives, rain and light sensors, climate flaps, steering wheel buttons and interior lighting. None of these need the speed or the fault tolerance of CAN, so handing them to a cheaper sub-network keeps the wiring and the cost down while freeing the CAN bus for the work that matters.
Master, slaves and the schedule
A LIN cluster has exactly one master and up to 15 slaves. The master holds both a master task and a slave task, while each slave holds only a slave task. Nothing happens on the bus unless the master starts it. The master works through a fixed schedule, sending one header after another, and the slave that owns each identifier answers with its data. At most one slave replies to any given identifier, so two nodes never talk at once.
That single detail removes a lot of complexity. Because the master controls every frame, there is no arbitration and there are no collisions, and the timing of the bus is predictable to the millisecond. The sync field at the start of each frame lets a slave lock onto the master's bit rate, so a slave needs no precise clock of its own. That is another reason a LIN node can be so cheap.
The protected identifier
Every LIN frame is named by a 6-bit identifier, which gives 64 possible frames. Sending those six bits on their own would be risky, because a single flipped bit would point the network at the wrong frame. So the master does not send the raw identifier alone. It adds two parity bits worked out from the identifier, making an 8-bit protected identifier, usually written PID. Each receiver recomputes the parity from the bits it saw and ignores the frame if the two do not match.
The two parity bits follow a fixed rule. The first is the exclusive-or of identifier bits 0, 1, 2 and 4. The second is the inverse of the exclusive-or of bits 1, 3, 4 and 5. Identifiers 0 to 59 carry ordinary signals, 60 and 61 are set aside for diagnostics, and 62 and 63 are reserved. Build one below and watch the parity and the protected identifier change.
Inside a LIN frame
A LIN frame has two parts, a header and a response. The master always sends the header. It begins with a break of at least 13 dominant bits to mark the start of a frame, then a sync field of 0x55 whose alternating bits let every slave measure the master's bit rate, then the protected identifier. The slave that owns that identifier sends the response: one to eight data bytes followed by a single checksum byte. The master can also supply the response itself, which is how it publishes data to the slaves.
The checksum comes in two forms. The classic checksum, from LIN 1.x, covers the data bytes only. The enhanced checksum, introduced with LIN 2.0, also folds in the protected identifier, so it catches more faults. Both are formed the same way, an 8-bit sum of the bytes with carry added back in, then inverted.
Error handling stays deliberately light. There are no error counters and no bus-off state like the ones CAN uses. A slave checks the parity of the identifier and the checksum of the response, and on the first error it finds it stops processing the frame until the next break. The master can also notice when a response it expected never arrived. For the comfort features LIN looks after, that simple approach is enough.
CAN or LIN for the job?
The rule of thumb is short. If a function is fast, safety-related or central to how the car drives, it belongs on CAN. If it is slow, local and not critical, LIN will handle it for less. Almost every modern car uses both, with small LIN sub-networks hanging off a CAN backbone. Try a few functions below to see where each one usually sits.
LIN does the cheap, slow jobs so CAN does not have to. One master, a single wire and a fixed schedule, in return for giving up speed and heavy error handling.
LIN bus FAQ
What is the LIN bus used for?
Body and comfort features that do not need the speed of CAN, such as wing mirrors, seats, window motors, rain sensors and climate flaps. LIN is a low-cost sub-network, usually hanging off a CAN backbone, so the cheaper traffic stays off the main bus.
How fast is LIN?
Up to 20 kbit/s, with 19.2 kbit/s common, over a single wire of up to about 40 metres. CAN runs far faster, which is one reason the two are used together rather than one replacing the other.
How many nodes can a LIN bus have?
One master and up to 15 slaves, so 16 nodes in total. The master controls all traffic from a schedule, and each slave answers only for the identifiers it owns.
What is the difference between LIN and CAN?
CAN is a fast, multi-node, twisted-pair bus with arbitration and strong error handling, used for powertrain, safety and the vehicle backbone. LIN is a slow, single-wire, single-master bus for cheap body electronics. LIN complements CAN, it does not replace it.
What is a protected identifier in LIN?
A 6-bit frame identifier with two parity bits added, making an 8-bit value. The parity lets a receiver detect a corrupted identifier and ignore the frame, which guards against pointing the network at the wrong message.
Can Influx Technology loggers record LIN?
Yes. The data loggers from Influx Technology capture LIN alongside CAN, so a mixed vehicle network can be recorded together in one place rather than across separate tools.
Written by the engineering team at Influx Technology. LIN behaviour follows the LIN specification and ISO 17987. Confirm details against the specification for your hardware.
Record LIN and CAN side by side
The data loggers from Influx Technology record vehicle networks to a standard format, capturing LIN alongside CAN so a mixed network lands in a single log. The REXGEN and REBEL ranges cover the common channels, and REXDESK and DIALOG help you review what was recorded.
