Mux-mode use cases
This page lists a range of typical use cases for the CANmod.router configured in mux-mode.
All examples assume that the CANmod.router is configured in mux-mode.
Mux-mode introduces an additional protocol allowing for full control of CAN-S from CAN-P using only a few message IDs.
CANmod.router conceptual illustration
Note
CAN-P, CAN-S1, CAN-S2, CAN-S3 and CAN-S4 are all galvanically isolated.
Data logging from multiple buses
An application requires logging of data from multiple buses. The CAN-buses each use individual bit-rates and must remain galvanically isolated. The four CAN-S interfaces are configured with individual bit-rates and connected to each bus. Mux-mode is configured to output received messages, transmission acknowledgements and error frames from all CAN-S to CAN-P. The raw (using the mux-protocol) mux message is logged by the data logger. During post-processing, the muxed message is demuxed into CAN-bus messages identical to those received and transmitted by the CAN-S interfaces (as if the data logger had been directly connected to each bus).
By installing the CANmod.router a data logger can log data from more buses. During post-processing, the original data from all four CAN-S interfaces is restored using a software tool supporting demuxing.
Note
More buses can be logged by installing multiple CANmod.router devices configured with distinct mux-mode message IDs.
Note
The CANmod.router works well with the CANedge series of data loggers and can be directly powered when connected to channel 2. Several CANedge software tools support demuxing.
PC interfacing with multiple buses
A user needs to communicate with multiple (potentially CAN-FD capable) CAN-buses. The CAN-buses each use individual bit-rates and must remain galvanically isolated. The user needs to be able to transmit and receive messages on each bus. In addition, the user must be able to confirm transmission by receiving transmission acknowledgements and monitor each bus for errors[1]. The four CAN-S interfaces are configured with individual bit-rates and connected to each bus. The mux-mode is configured to forward messages from CAN-S to CAN-P and to generate transmission acknowledgements and report errors on CAN-S. The PC is connected to CAN-P either using a CAN-to-USB interface or using the CANmod.router USB port. By using a PC tool supporting the mux-protocol (see csselectronics.com), the user is able to communicate with the four buses.
Note
More buses can interfaced with by installing multiple CANmod.router devices configured with distinct mux-mode message IDs.
Non-FD capable ECU interfacing with multiple CAN-FD buses
An application requires a (programmable) ECU[2] with a single standard (non-FD) CAN-bus interface to communicate with multiple individual CAN-FD CAN-buses. The CAN-buses cannot be directly connected and use individual bit-rate settings. The message IDs on the buses are generally unknown and potentially overlap. The four CAN-S interfaces are configured with individual bit-rates and connected to each bus. CAN-P is configured to not use CAN-FD in mux-mode. The mux-protocol is implemented/installed on the ECU and configured to use the (P-to-S and S-to-P ) IDs also configured for the CANmod.router.
By installing the CANmod.router a non-FD capable ECU is able to communicate with four galvanically isolated CAN-FD buses (including reception and transmission of CAN-FD messages).
Note
More buses can interfaced with by installing multiple CANmod.router devices configured with distinct mux-mode message IDs.