Independent research and documentation of Line 6 control protocols, hardware interfaces and foot-controller communication, with an initial focus on the FBV family.
This project is not affiliated with or endorsed by Line 6 or Yamaha. Product names and trademarks belong to their respective owners.
Information about Line 6 control protocols is scattered across old projects, source code, forum posts, service information and hardware experiments. This repository aims to collect that information in one place while clearly separating:
- directly confirmed facts;
- facts independently confirmed by several implementations;
- hardware-specific behavior;
- strong inferences;
- conflicting reports;
- unanswered questions;
- results reproduced on real hardware.
The long-term goal is to make the protocols understandable enough to build both:
- hosts that communicate with original Line 6 FBV controllers;
- small custom controllers that emulate only the FBV functions actually required by a target device;
- Linux and microcontroller tools for capture, decoding and experimentation.
The public implementations studied so far strongly support a common FBV message family using frames of the form:
F0 <length> <command> <payload...>
Several important commands are independently present in multiple projects, including:
0x04 LED state
0x05 RGB LED colour on FBV3
0x08 short / preset display
0x10 main display
0x20 flat / accidental indicator
0x81 button event
0x82 expression-pedal event
A typical button event is:
F0 03 81 <physical_id> <state>
with commonly observed states:
01 = pressed
00 = released
Public working implementations use both:
31,250 baud
32,150 baud
Neither value is silently normalized in this project. The exact rate may depend on controller generation, hardware clocks or implementation details and should be measured on real hardware when possible.
The physical IDs for A-D, FS1-FS5, Tap, Up, Down, Function and the toe switch have been recovered from public source code and cross-referenced where possible.
The current evidence also indicates that musical functions such as Looper are primarily interpreted by the connected Line 6 host. A physical FBV switch ID must therefore not be treated as a universal musical command.
The two-button FBV2 remains an important target because it provides direct preset previous/next control with a very small hardware design.
Its exact wire protocol and electrical interface are still unresolved. Public teardown reports identify a P87LPC760-family MCU and SN74HC14 logic, but no usable raw FBV2 capture has yet been recovered. The repository therefore keeps FBV2 electrical and protocol details explicitly marked as unknown until measured.
| Label | Meaning |
|---|---|
SC |
Source-confirmed: directly visible in public source code or project documentation |
XSC |
Cross-source confirmed: independently present in at least two public implementations |
INF |
Strong inference, not yet reproduced against real target hardware |
XR |
External report not independently reproduced here |
CONFLICT |
Public sources disagree or appear generation-dependent |
TODO |
Unknown / needs capture or measurement |
LAB |
Independently reproduced by this project on real hardware |
SC never means universal compatibility. Device model and generation always matter.
- Framing and baud rates
- Startup / handshake
- Known commands and IDs
- FBV3 physical IDs
- Display and tuner
- Hardware and electrical layer
- Electrical families
- FBV2 minimal-controller notes
- FBV2 electrical analysis
- FBV2 measurement procedure
.
├── docs/ protocol notes, hardware analysis and experiments
├── captures/ raw or annotated protocol captures
├── tools/ decoding and analysis utilities
├── sources/ source index and provenance notes
├── README.md
├── README_FR.md
├── CONTRIBUTING.md
├── CHANGELOG.md
└── LICENSE
When new hardware is available, the preferred workflow is:
- capture the idle / startup baseline;
- perform one action repeatedly;
- compare frames and isolate changing fields;
- identify direction, timing, voltage levels and baud rate;
- replay only harmless, well-understood commands;
- document model, firmware, hardware revision and confidence level;
- promote a finding to
LABonly after it has been independently reproduced by this project.
Passive capture is preferred before active fuzzing.
Contributions are welcome, especially:
- original captures from real Line 6 hardware;
- oscilloscope or logic-analyzer measurements;
- corrections with a primary source;
- device-specific behavior and firmware versions;
- hardware pinouts and PCB observations;
- small tools for parsing or comparing captures.
Please read CONTRIBUTING.md before submitting protocol claims.
Original material and tools in this repository are released under the MIT License, unless a file explicitly states otherwise.
Third-party source material remains under its original copyright and license and is referenced rather than republished where appropriate.