-
Notifications
You must be signed in to change notification settings - Fork 27
FAQ
This is a Raspberry Pi Pico 2 based FlexRay capture and MITM project. The goal is not just to read the bus, but to extract ADAS-related signals from FlexRay and eventually support controlled replacement or injection of selected control frames.
Many vehicles, especially some BMW ADAS architectures, do not rely on CAN alone. CAN by itself is often not enough to expose the full lateral or longitudinal control path, while FlexRay still carries part of the critical control traffic. This project aims to provide a low-cost, open, developer-friendly research platform for that space.
The Pico module sits directly on the FlexRay side. Timing-sensitive work such as forwarding, replacement, and checksum-related handling happens on the Pico. openpilot / sunnypilot are used for higher-level control logic and vehicle-state handling. There are already modified Cabana, pandad, and sunnypilot branches used with this setup, but they are not official upstream implementations.
The thread already shows the following milestones:
-
BSS Streamerimplemented - Bidirectional FlexRay proxy implemented
- Pico recognized as a USB Panda and streaming data into Cabana
- BMW lateral and longitudinal-related signals partially identified
- Steering-related frame replacement already validated
- At least some BMW platforms already tested with working sunnypilot-based driving
Both, but they are not equally mature. Capture, proxying, and distinguishing ECU-side versus vehicle-side traffic are already relatively solid. Safe, stable, and reusable control paths are still evolving, especially for longitudinal behavior, fault exit handling, and cross-model portability.
Yes, but the barrier is still fairly high. At minimum you should expect to need:
- Raspberry Pi Pico 2
- One or two FlexRay transceivers
- A custom pigtail / harness or equivalent wiring split
- The ability to solder TSSOP packages, or access to a ready-made board
- Model-specific wiring diagrams for SAS / BDC / FlexRay pins
Read-only capture is much easier than proxy or MITM. Once you move into proxy mode, two transceivers and more careful wiring are typically required.
The current recommendation is yes: use Pico 2 RP2350. Early discussion mentioned RP2040 as potentially workable, but later updates explicitly recommended Pico 2 because DMA trigger support makes the design simpler and more practical.
For the current mainline approach, yes. The project does not primarily wrap FlexRay as standard CAN-FD just to reuse the existing tooling. Instead, modified Cabana / pandad branches add FlexRay-specific unpacking. That reduces extra overhead on the Pico side, but it means the host side also needs changes.
Not on the main path. The idea was discussed, but it introduces CRC, bandwidth, and complexity tradeoffs, especially for longer payloads or higher-rate traffic. The later design direction leans more toward having the Pico handle FlexRay details directly and passing abstracted carState / carControl style data upward.
The strongest evidence so far is on BMW platforms, especially G30/G38, i4 (G26), i3, and related architectures. Other brands such as Mercedes, Audi, and Volvo are discussed in the thread, but that should not be read as confirmed support.
The more accurate statement is:
- The method is theoretically relevant to FlexRay vehicles in general
- Actual support depends on the vehicle's ADAS architecture, signal placement, checksum strategy, and bus accessibility
For BMW readers, there is now a dedicated BMW SP2018 page because that is the clearest sub-path in the current thread for practical integration work.
The main research path so far is the FlexRay link between SAS and BDC. Inserting the module on that link allows the project to capture traffic and, in proxy mode, distinguish traffic coming from each side before analyzing ADAS-related commands.
- Signal definitions still vary significantly by vehicle
- Many signals are multiplexed and must be decoded by cycle
- Longitudinal control is not yet a stable, generalized implementation
- Some critical state may live on KCAN, LIN, or Ethernet rather than FlexRay
- The current approach still lacks production-grade bypass and fail-safe design
No. The thread repeatedly frames this as a research project. The current implementation is already capable of MITM and real control experiments, but it is still far from production-grade in terms of fault handling, bypass behavior, safety policy, and redundancy.