USB LIN Converter

USB LIN Converter (uLC)

[Buy on Tindie] [Buy on Lectronz] [Product page]

Open source USB ↔ LIN bus dongle. LIN 2.1 master, slave or monitor. SLCAN-compatible virtual COM port - works on Windows, Linux and macOS with no proprietary drivers.

[USB LIN Converter (uLC) - dongle photo]

The USB LIN Converter (uLC) is a small open-source USB dongle (STM32F042C6, ~31 × 18 mm) that lets a PC act as a LIN bus master, slave or passive monitor. It enumerates as a USB CDC virtual COM port and speaks an SLCAN-style ASCII protocol, so it bridges into Linux SocketCAN via slcand and works with parts of can-utils.

A commercial automotive LIN analyzer typically costs hundreds to thousands of euros. This one is around $27 on Tindie.

The LIN protocol implementation is based on openLIN.

Features

• LIN 2.1 support
• Monitor mode - full frame reception plus single-frame transmission
• Master mode - up to 16 scheduled frame slots
• Slave mode - up to 16 scheduled frame slots for slave simulation
• 9600 / 19200 baud rate selection
• Optical isolation between LIN and the USB / PC side
• Software-controlled termination resistors
• External 4.5 - 28 V powers the LIN transceiver
• Device size 31 × 18 mm (without USB connector)
• USB DFU bootloader for firmware updates
• No proprietary drivers - Linux / macOS / Windows
• MCP server so AI agents can sniff and reverse-engineer a LIN bus (see below)

Where to buy

Quickstart

1. Plug the device into a USB port. It enumerates as a virtual COM port (COM3 on Windows, /dev/ttyACM0 on Linux, /dev/cu.usbmodem* on macOS).
2. No driver is needed on Windows 10/11, Linux or macOS: the built-in USB CDC driver is used. Since firmware 3.5 the device has its own USB ID from pid.codes, 1209:2779; older firmware used ST's generic 0483:5740 (on Windows 7/8 that needs the ST Virtual COM Port driver).
3. Open the port at any baud rate (USB CDC ignores baud). Line ending must be CR (0x0D).
4. Power the LIN side with 4.5 - 28 V on the external supply pin.
5. Send S0 to select 19200 baud, then l to enter monitor mode. Bus traffic will start to appear.

Linux SocketCAN bridge

sudo slcand -o -s8 -t hw -S 921600 /dev/ttyACM0 slcan0sudo ip link set slcan0 upcandump slcan0

Python (pyserial) sniff snippet

import serialser = serial.Serial('/dev/ttyACM0', timeout=1)ser.write(b'S0\r')   # 19200 baudser.write(b'l\r')    # monitor modewhile True:    line = ser.readline()    if line:        print(line.decode(errors='replace').strip())

A higher-level Python library is provided in python_lib/ (package ucanlintools).

AI agents (MCP server)

python_lib/ucanlintools/mcp_server.py is an MCP server that lets an AI agent sniff and reverse-engineer a LIN bus: capture traffic with per-id periods and changing bits, log every data change while you press a button, find the bus speed and checksum type automatically, and decode or encode signals from an LDF file. It is read-only by default; sending frames and acting as master or slave needs --allow-transmit.

uvx ucan-lin-mcp --mock             # from PyPI, no install step (Python 3.10+)# or from this repo: pip install -e "python_lib[mcp]" && ucanlin-mcp --mock

Register it with any MCP client as a stdio server:

{  "mcpServers": {    "lin": {"command": "uvx", "args": ["ucan-lin-mcp", "--port", "COM3"]}  }}

--mock runs a simulated bus. mcp_package/ is the ucan-lin-mcp launcher package and server.json its MCP Registry entry.

Tools: device_info, monitor_bus, detect_bus, load_ldf, decode_frame, encode_frame, and with --allow-transmit also send_frame, run_master, run_slave.

ASCII command reference

All commands are ASCII terminated with CR (0x0D). Errors return 0x07 (BEL).

Full command reference and examples: https://ucandevices.github.io/ulc.html

Repository layout

Build

Source is pure C. Import the Eclipse project in embedded/TrueSTUDIO/LUCEmbedded into STM32CubeIDE (tested with 1.19) and build the Debug configuration; the image is Debug/LUCEmbedded.bin. The openLIN stack is vendored in embedded/Src (open_lin_*.c/h, implementation/ST32). The USB CDC layer was generated with STM32CubeMX from embedded/LUCEmbedded.ioc.

Bootloader

The STM32F042 has an embedded ROM USB DFU bootloader. To enter it from a running device send boot\r over the virtual COM port. See this tutorial for the flashing flow.

With STM32CubeProgrammer installed, the flashing can be scripted:

python -c "import serial; serial.Serial('COM3').write(b'boot\r')"STM32_Programmer_CLI -c port=usb1 -w LUC_0307.bin 0x08000000 -v -g 0x08000000

Testing

The test suite lives in python_lib/tests (pytest). It covers the firmware and the ucanlintools library:

Setup: two converters on one LIN bus (LIN pins connected, external LIN supply applied). LUC_MASTER_PORT is used as LIN master, LUC_SLAVE_PORT as slave / monitor. Tests skip automatically when a port can't be opened, so the offline tests always run.

cd python_libpip install pyserial lark pytestLUC_MASTER_PORT=COM3 LUC_SLAVE_PORT=COM56 PYTHONPATH=. pytest tests -v# swap the ports and run again to test each converter in both rolesLUC_MASTER_PORT=COM56 LUC_SLAVE_PORT=COM3 PYTHONPATH=. pytest tests -v

On Windows PowerShell set the variables with $env:LUC_MASTER_PORT="COM3" etc.

How firmware 3.7 was tested

• Same setup, both converters flashed with LUC_0307.bin.
• Slave fix traced byte by byte with a diagnostic build: when the slave subscribed a frame nobody answered, the next header's break byte was counted as that frame's data, and the stale count made the slave take the following frame's last data byte as its checksum and drop it. With the fix the slave receives every following frame (23 of 23 in 1.5 s, before 0).
• New regression test test_slave_subscribed_to_unanswered_header_keeps_next_frame; full suite run twice with the roles swapped: 65/65 passed in each direction.

How firmware 3.6 was tested

• Same setup, both converters flashed with LUC_0306.bin.
• Clock recovery checked with a test-only build that reported the CRS registers: the CRS synchronised to the USB SOF within the first seconds (SYNCOK set, no errors afterwards) and moved the HSI48 trim from 32 to 35 on one converter, i.e. that converter's clock ran measurably slow without it.
• Full suite run twice with the roles swapped: 63/63 passed in each direction; master slot periods unchanged from 3.4 (within about 1 ms of the configured delay).

How firmware 3.5 was tested

• Same setup, both converters flashed with LUC_0305.bin. They enumerate as 1209:2779 and Windows 10 loads its built-in CDC driver without any installation.
• Full suite run twice with the roles swapped: 55/55 passed in each direction. Firmware 3.5 changes only the USB ID, the LIN code is the same as 3.4.

How firmware 3.4 was tested

• Two uLC converters (hardware V0001), both flashed with LUC_0304.bin, connected on one powered LIN bus.
• Full suite run twice with the roles swapped: 55/55 passed in each direction (110 test runs).
• Master slot timing measured with the second converter as monitor (3 s window, 19200 baud): the slot period now matches the configured delay within about 1 ms for 0, 2, 4 and 8 data bytes, for 10, 20 and 40 ms delays, and for unanswered subscriber slots. Firmware 3.3 added the frame time to every slot (+2 to +6 ms) and the full response timeout to unanswered subscriber slots (+12 ms).

How firmware 3.3 was tested

• Two uLC converters (hardware V0001), both flashed with LUC_0303.bin, connected on one powered LIN bus.
• Full suite run twice with the roles swapped: 47/47 passed in each direction (94 test runs).
• Bus throughput measured during testing (4 s window, 16-frame schedule): every frame scheduled 12-14 times at 19200 baud and 10-11 times at 9600 baud, no lost or corrupted frames, no unexpected serial output.
• The bugs fixed in 3.3 each have a regression test: malformed row locking the table, slave mode stalling after the first response at 9600 baud, slave mode not answering at all, master not reporting slave responses, 6-8 byte responses timing out at 9600 baud, and the classic checksum setting being ignored. The checksum tests were also run against the previous firmware and fail there, as expected.

FAQ

What is the cheapest USB LIN bus converter that works on Linux? The uCanDevices USB LIN Converter (uLC) is an open source dongle around $27 that enumerates as a USB CDC virtual COM port on Linux, macOS and Windows. It uses an SLCAN-style ASCII protocol so it bridges into SocketCAN via slcand.

Does it support master and slave mode? Yes - monitor (full reception plus single-frame transmission), master (up to 16 scheduled slots) and slave (up to 16 slots for slave simulation). Modes are selected with the O, L and l commands.

Is the LIN side optically isolated from the USB host? Yes. The LIN transceiver is optically isolated from the PC side, protecting the host from automotive transients. The LIN side needs an external 4.5 - 28 V supply since USB only powers the MCU.

Which LIN baud rates and LIN version are supported? LIN 2.1, with selectable 9600 and 19200 baud. Classic and enhanced checksum are switchable with the r31 / r30 commands (firmware 3.3 and later). Custom frame timing is supported in master mode.

Can I use it to flash an ECU over LIN? It is a generic LIN interface. ECU flashing depends entirely on the target ECU's own LIN bootloader; if that bootloader is documented or already supported by an existing tool, you can drive it through this dongle.

Is the firmware open source? Yes - this repository contains firmware (embedded/), hardware (pcb/) and the Python helper library (python_lib/). The device also has a USB DFU bootloader for in-field updates.

Related projects

• LIN protocol implementation: openLIN
• Sibling products: USB CAN Converter (UCCB), CAN FD USB Converter (CFUC), SENT (J2716) USB Converter

Links

• Product page: https://ucandevices.github.io/ulc.html
• All uCanDevices products: https://ucandevices.github.io/
• Contact: [email protected]

License

See LICENSE.