news / 2025-02

CANmod.router 'direct-mode': The ultimate CAN gateway!

We have now released FW 01.02.01 for the CANmod.router, introducing 'direct-mode'.

Until now, the device has supported 'mux-mode' to allow our CANedge data loggers to log 5 x CAN. However, this mode is not ideal for standalone deployments as the CAN traffic is routed via a 'transport protocol' on the primary CAN side.

However, with the new 'direct-mode' the device can be installed as a full-fledged CAN bus gateway. Now, traffic from the four secondary CAN buses can be routed onto the primary CAN bus. The data can be filtered (to e.g. reduce busload or remove CAN FD frames) and IDs can be re-mapped (to avoid collisions).

Check out the example use cases below - and contact us if questions!

---

Example 1: Merge 4 x CAN buses into 1 x CAN bus

Direct-mode enables bit-rate conversion between CAN buses (e.g. from 500K to 250K) and merging of CAN buses that have conflicting CAN IDs. The latter can e.g. be useful in daisy chaining sensor-to-CAN modules with fixed CAN IDs. You can also use this to connect e.g. a Classical CAN ECU to multiple CAN FD buses - forwarding only the Classical CAN frames to avoid errors. Finally, it offers a simple way to add more CAN channels on 3rd party CAN bus data loggers/interfaces, beyond our own CANedge.

---

Example 2: Split 1 x CAN bus into 4 x CAN buses

You can also route data from the single primary CAN bus to the secondary CAN buses. This lets you e.g. use the device as a CAN bus splitter to repeat data from an expensive sensor-to-CAN module when you want this data to be available on multiple CAN buses - while retaining 100% isolation of each network. This can drastically reduce cost and complexity.

---

Example 3: Control 4 x CAN buses with 1 x CAN bus interface

A single 'master node' may need to control multiple CAN buses. To achieve this, the master can be connected to the primary CAN bus, with filters controlling what messages are routed from/to each secondary CAN bus. All secondary CAN buses remain isolated, but the master can interact with each as if directly connected.

Learn more

---

Webinar: CAN Bus Telematics at Scale [watch now]

Watch our recent webinar on CAN telematics at scale!

The ~1 hour webinar covers how to manage your CANedge device fleet, setting up Parquet data lakes, Grafana dashboards, MATLAB/Python analysis - and much more!

Watch now

---

Updated: Intros to LIN bus + CANopen improved!

We have now updated our 'simple intros' to both LIN bus and CANopen. The articles have been massively improved through restructuring/rewriting, 10+ new deep dive sections, 40+ new illustrations and more - check them out!

Learn more

---

New: LIN Description File (LDF) Explained - A Simple Intro

Want to fully understand LIN bus? Then this is a must-read!

The LIN Description File (LDF) is a text file that describes a complete Local Interconnect Network (LIN) cluster. To some extent, the LDF plays a similar role in LIN as the DBC plays in CAN. In this tutorial we cover below key topics:

• What is an LDF?
• LDF syntax
• How to get the LDF?
• LDF software tools
• LDF vs. DBC files (incl. how to convert)

The CANedge is commonly used to log LIN bus data. The device can act as a silent LIN node or as a LIN master, controlling the communication of a LIN cluster. The latter is particularly useful for data acquisition from isolated LIN sensors for testing/development.

With the latest update to the asammdf GUI, you can now also decode your raw LIN bus data with your LDF file directly - without first converting the LDF to a DBC file. This makes it even simpler to use the CANedge for all your LIN data acquisition needs!

Learn more

---

Logging LIN battery data (HELLA)

Learn more

---

5 x CAN bus EV telematics

Learn more

---

This update was sent as part of our newsletter on 27 February 2025. You can also download it as a PDF.

Want updates like this in your inbox? Join our newsletter - or see all news.

More news