CANmod.router: 4 x CAN to 1 x CAN (or USB) Converter/Gateway

The CANmod.router is a small device that lets you connect up to four separate, isolated CAN buses (incl. CAN FD) via the DB25 connector. The data from/to these four CAN buses (CAN-S1, CAN-S2, CAN-S3, CAN-S4) is then 'routed' by the module through a single CAN bus (CAN-P) - or via a USB interface.

The device supports two different modes: Mux-mode and direct-mode.

In mux-mode, the data from the four isolated CAN buses is 'transported' via CAN frames onto the primary CAN bus. This works very similar to standard CAN transport protocols like ISO TP (as used in e.g. OBD/UDS). By transporting the data, it is possible to conmbine data from four separate CAN buses without having to worry about e.g. remapping CAN IDs to avoid collisions, as all this is abstracted away via the transport protocol. However, this also requires that the 'receiver' of the data on the primary CAN is able to 'demux' the data to re-create the original CAN frames from the various CAN buses. Our CANedge data logger is therefore ideal for this use case, as the related software/API tools natively enable demuxing of data - making it very easy to use the CANmod.router as an add-on for the CANedge, effectivley enabling you to record 1 x CAN + 4 x CAN (or beyond) with a CANedge + CANmod.router. For details see the CANmod.router Docs

In direct-mode, the data from the secondary CAN buses are routed as-is without any form of transport protocol being involved. This implies that you need to e.g. ensure CAN ID uniqueness on the primary CAN (by re-mapping CAN IDs in the device configuration as needed). However, it has the advantage that no demuxing is required by the receiver, making this mode ideal for standalone deployments. In practice, almost any use case that involves merging/splitting/converting CAN buses can be achieved via the direct-mode of the CANmod.router.

The CANmod.router is an extremely powerful device. Let us illustrate this via common use cases:

CANedge add-on: Log 5 x CAN

The CANmod.router lets you log 5 x CAN via one CANedge. Previously, you had to use 3 x CANedge units with multiple downsides:

1. Adding two 'extra' CANedge units is 300-1000 EUR more costly vs adding a CANmod.router
2. With three CANedge units, your data is split across three SD cards, MF4 files etc - making data/device management complex
3. The best cross-device time sync precision is 400 ms (via internal GPS) - versus 1 ms via the CANmod.router

4 x CAN-USB interface

The CANmod.router can be used as a 4 x CAN-to-USB interface (incl. CAN FD). This is powerful for multiple reasons:

1. The CANmod.router is 50%+ lower cost vs. comparable CAN-USB interfaces
2. The CANmod.router is 50%+ more compact vs. comparable CAN-USB interfaces
3. The CANmod.router comes with 100% free software/API tools for streaming
4. The software/API tools let you DBC decode and visualize data in real-time
5. SavvyCAN lets you receive/send data from/to all 4 x CAN buses in one GUI window
6. The Python API enables easy integration with custom systems like Raspberry Pis - e.g. for field deployments

CAN bus gateway

The device can be used standalone in direct-mode to enable practically any routing use case across multiple CAN buses. This has a number of benefits:

1. You drastically reduce costs vs. other routes (e.g. in development time, wiring, sensors, ...)
2. The deployment can be quickly modified via a simple configuration change
3. You can quickly prototype the implication of more expensive, structural network changes
4. Via galvanic isolation, the router provides a safe way of merging buses

In short, the CANmod.router offers a ton of functionality in a single device.

Note: The numbers stated below are preliminary/indicative and may change.

A common use case is to log 5 x CAN with a CANedge + CANmod.router - here we discuss performance considerations.

CAN channels

You can record any number of CAN channels with one CANedge by adding a daisy chain of CANmod.routers. You can add e.g. 10 x CANmod.routers to log 40+ CAN channels - the limitation is purely related to the combined frames/second (see below).

If you daisy chain CANmod.routers on the CANedge 2nd port, you may need to consider if the 5V supply is sufficient. If all CAN-S interfaces are in 'Monitoring' mode then it will suffice. If not, you may need to consider a separate supply.

Frames/second considerations

The primary thing to consider is the total #frames/second you need to record across all of the CAN channels.

We recommend to stay below 6,000 frames/second in total (after filters/prescalers).

• 90%+ of use cases will have far below 6,000 frames/second across 5 x CAN - even without filters/prescalers
• Channel distribution is not relevant - it could e.g. be 1 x 4,000 frames/second + 4 x 500 frames/second (or any other mix)
• The performance limit is higher - the 6,000 frames/second is mainly based on practical considerations (see below)
• During the split-second creation of a new log file, the CANedge may loose frames if recording at very high data rates

Using filters and prescalers

Even if the combined #frames/second exceeds the limit, this is not necessarily an issue at all. The CANmod.router lets you configure filters and prescalers across each of the secondary CAN channels (similar to the CANedge). This means that you can record 4 x CAN channels that have a combined load of e.g. 10,000 frames/second - as long as you filter & prescale this sufficiently.

Practical considerations on file size, SD storage and upload speed

If you do record ~6,000 frames/second 24/7 you will accumulate 5+ MB/min (compressed), 300+ MB/hour, 7+ GB/day and 200+ GB/month. In other words, a CANedge with 32 GB will only store ~5 days of data before it deletes old files to free up space.

Of course, you can get around this by using a CANedge2/3 to upload log files when created. However, in practice the upload speed may make it difficult to offload data fast enough if you go beyond 6,000 frames/second (in particular in intermittent coverage).

To recap: We recommend to stay below 6,000 frames/second - and to use filters, prescalers and compression to optimize file size.

You may wonder if your use case can be handled by the CANedge + CANmod.router. The short answer is "yes!" in 95%+ of cases.

As explained, the limitation to consider is the #frames/second you need to log (after filters/prescalers) across all CAN buses.

To determine this, we recommend the below process:

1. Record 5 min from each CAN bus with no filters via the CANedge CH1
2. Convert each MF4 log file to CSV via our mdf2csv converter
3. Open each CSV in Excel and note the #frames (count) and #seconds (last vs. first)
4. Sum up the #frames/second across all CAN channels

If your total #frames/second is below ~6,000 then you are OK and it is mainly a matter of optimizing file size when you deploy.

If your total #frames/second is above ~6,000 then review each CAN bus to determine what messages can be filtered out or prescaled. After accounting for this, revisit the combined #frames/second to see if it is within the limits.

You can of course contact us for sparring on this.

We offer a number of useful adapter cables as options for the CANmod.router:

DB9-DB9/DB9 (Y splitter): This can e.g. be used to connect a CANmod.router to a CANedge 2nd port, enabling the CANedge to record 4 x CAN on CAN CH2. Further, you can add additional Y-splitters if you need to daisy chain more CANmod devices.

DB25-to-4x-DB9: This adapter can be used with the CANmod.router to enable the connection of four separate CAN buses. The advantage of this adapter is that the DB9 pinouts match the CiA 303-1 standard (like the CANedge DB9 connectors), meaning that you can directly use all of our standard DB9 adapter cables, such as our DB9-OBD2, DB9-J1939, DB9-M12 etc. You can even use dual-channel adapters like our J1939-DB9/DB9, OBD2-DB9/DB9 and DT06-DB9/DB9 adapters.