Message filtering on the CAN bus
Every node on a CAN bus hears every frame, including your data logger. Acceptance filters let it keep the messages you care about and ignore the rest, which saves storage and makes the analysis easier.
A CAN bus is a broadcast: every frame reaches every node, so a data logger left unfiltered records the whole bus and fills its storage fast. A message filter tells the logger which identifiers to keep and which to drop, using acceptance filters built into the interface. You can pick a single ID, a range of IDs through a mask, names from a DBC file or J1939 parameter groups. The result is a smaller log focused on the data you actually need.
| Method | How it works | Good for |
|---|---|---|
| Single ID | Accept one identifier and drop the rest | one message of interest |
| ID range | Accept a block of IDs using a mask | a family of related IDs |
| DBC file | Load a database and choose messages by name | working from a known schema |
| J1939 | Filter by parameter group number | heavy-duty networks |
How a CAN filter works
CAN has no addressing in the usual sense. A transmitter does not send a frame to a particular node; it puts the frame on the bus and every node receives it. Each node then decides for itself whether the frame is relevant. That keeps the wiring simple, but it means a logger sees everything, useful or not, and unfiltered it will happily fill its card with traffic you never wanted.
An acceptance filter is the firmware in the interface that makes that decision before a frame is stored. It compares each incoming identifier against the rule you have set and keeps only the matches. Set it to a single ID and you log one message. Set it to a range and you log a family of them. Either way the work happens at the point of capture, so the unwanted frames are dropped rather than written and sorted out later.
Filtering a whole family with a mask
Logging a single identifier is easy enough, but often you want a related group: every message from one ECU, say, or a block of addresses. That is what a mask is for. Alongside the filter identifier the interface holds a mask, and the mask decides which bits of the identifier actually have to match.
The rule is simple. Where a mask bit is 1, that bit of an incoming identifier must equal the filter. Where a mask bit is 0, that bit is a do not care and either value is accepted. A mask of all ones therefore means an exact match on one ID. Relax the lowest four bits to zero and you accept a run of sixteen, so a filter of 0x100 with a mask of 0x7F0 logs everything from 0x100 to 0x10F. The same idea, widened or narrowed, covers most filtering you will need. Try it directly below.
Build a filter and watch it work
Set a filter identifier and a mask, then read off which of the identifiers on this example bus would be logged and which would be dropped. Start from a preset, then change the mask a bit at a time to see the accepted set grow and shrink.
Why filtering is worth the setup
The benefit is twofold. You prioritise the data that matters instead of recording everything indiscriminately, and you save storage on the logger, which matters most on long tests or remote installs where you cannot swap a card on a whim. A focused log is also faster to open and easier to read, because you are not scrolling past thousands of frames you never cared about.
The effect is real. In a simple example bus carrying four identifiers, four minutes of unfiltered logging comes to about 1 MB. Narrow the filter to the one identifier that matters and the same four minutes drops to roughly half that. The REXGEN data loggers and Module Analyser software from Influx Technology both support CAN message filters, including J1939, configured either by hand or from a DBC file.
See the saving for yourself
The faster a message repeats, the more of the log it occupies, so dropping a high-rate group you do not need saves far more than dropping a slow one. Switch the groups below on and off to see how the log size follows the frames you choose to keep.
Filter at the source. A logger that records only what matters runs longer, fills less and hands you a cleaner dataset to work from.
Message filtering FAQ
What is a CAN message filter?
It is a rule in the interface firmware that decides which frames to keep based on their identifier. Because every node on a CAN bus receives every frame, a filter lets a data logger record only the identifiers you care about and drop the rest at the point of capture.
How does an acceptance filter and mask work?
The filter holds an identifier and a mask. Where a mask bit is 1, that bit of an incoming identifier must match the filter. Where it is 0, that bit is ignored. A frame is accepted when the identifier, masked, equals the filter, masked, which lets you match one ID or a whole range.
How do I filter a range of CAN IDs?
Relax the lower bits of the mask. A filter of 0x100 with a mask of 0x7F0 accepts every identifier from 0x100 to 0x10F, because the lowest four bits are treated as do not care. Widen or narrow the mask to cover a larger or smaller block.
Does filtering really save much storage?
Yes. In the article example, four minutes of unfiltered logging is about 1 MB, and filtering to a single identifier roughly halves it. The saving scales with the run, and high-rate messages dominate the file, so dropping a fast group you do not need saves the most.
Can I filter using a DBC file or J1939?
Yes. The REXGEN data loggers and Module Analyser software from Influx Technology support CAN message filters including J1939, and filters can be configured by hand or loaded from a DBC file so you select messages by name rather than raw identifier.
Written by the engineering team at Influx Technology. Filter behaviour and mask conventions vary by device, so confirm against your hardware documentation.
Capture the right CAN data, not all of it
The data loggers from Influx Technology, including the REXGEN and REBEL ranges, support CAN message filtering by identifier, range, DBC or J1939, so your logs stay focused and your storage lasts. REXDESK and DIALOG help you set the filters and review the result.
