Direct-mode use cases

This page lists a range of typical use cases for the CANmod.router configured in direct-mode.

All examples assume that the CANmod.router is configured in direct-mode.


Direct-mode introduces no additional protocol as messages are generally forwarded directly between CAN-P and CAN-S.

../../_images/canmod_router.svg

CANmod.router conceptual illustration

Note

CAN-P, CAN-S1, CAN-S2, CAN-S3 and CAN-S4 are all galvanically isolated.


Merge CAN-buses

An application uses multiple CAN-buses configured with individual bit-rates. Some of the buses support (and use) CAN-FD and some do not. The four CAN-S interfaces are configured with individual bit-rates and connected to each bus. Filters on CAN-S are configured to forward selected messages from each CAN-S to CAN-P. All CAN-FD messages from CAN-S are filtered (rejected) as CAN-P does not support CAN-FD. Filter pre-scalers are applied to specific high frequency messages on CAN-S, to avoid overloading CAN-P. A few overlapping message IDs on CAN-S are remapped to avoid ID duplication on CAN-P.

By installing the CANmod.router it is possible to observe specific messages from all CAN-S bussed via CAN-P using a non-FD capable interface without generating bus errors. The combined bus load is managed using filters and pre-scalers.

Note

More buses can be merged by installing multiple CANmod.router devices.


Split CAN-buses

An application uses an expensive sensor generating a CAN-bus output. The output of the sensor should be available on multiple separate CAN-buses (without connecting the buses directly). The expensive sensor is connected to CAN-P. The four CAN-S are connected to each of the buses requiring the sensor data. Filters on CAN-P are configured to forward the specific sensor message from CAN-P to all CAN-S. Filters on CAN-S are configured to not forward any messages from CAN-S to CAN-P.

By installing the CANmod.router it is possible to share the output from an expensive sensor with multiple CAN-buses without connecting them.

Note

A bus can be split into more buses by installing multiple CANmod.router devices.


Multiple OBD buses

An application is required to poll OBD data from multiple CAN-buses. It is not possible to connect the buses directly. Each of the four CAN-S buses are connected to a separate OBD bus. Transmit messages for each CAN-S are configured to automatically request OBD data periodically. The CAN-S filters are configured to forward the OBD response messages from CAN-S to CAN-P. To avoid message ID duplication on CAN-P, the four OBD response IDs are individually remapped to new unique message IDs.

By installing the CANmod.router it is possible to poll and monitor OBD responses from four individual OBD buses via CAN-P.

Note

More OBD buses can be serviced by installing multiple CANmod.router devices.


Control multiple actuators

An application uses multiple actuators controlled via CAN-bus. The actuators use one (the same) non-configurable message ID for control and one non-configurable message ID for status. The actuators cannot be connected to the same bus as the status messages collide and generate bus errors. All actuators should be controlled by one CAN-bus ECU. The four CAN-S are connected to the CAN-bus of each actuator. CAN-P is configured to forward the control message to all CAN-S. Optionally, the status messages can be forwarded (and ID re-mapped) from CAN-S to CAN-P to receive status from all actuators.

By installing the CANmod.router it is possible to control multiple actuators from a single CAN-bus ECU connected to CAN-P.

Note

More actuators can be controlled by installing multiple CANmod.router devices.