Log. Decode. Deliver.
CAN Bus data to cloud.

DBC files

DBC files can be uploaded to the CAN-FD Pro through AutoPi Cloud CAN Bus Management and assigned per channel or per logger. The interface supports selecting specific messages and signals for decoding. This selection step matters because DBCs often contain far more than the signals that are needed for a given test program.

DBC-based signal selection can also be used as an input to filtering. Instead of filtering on raw frame IDs only, pass filters can be derived from the chosen signals. This reduces bandwidth usage on 4G/LTE uploads and avoids exporting large quantities of unrelated traffic.

DBC files, CAN database files, describe how to interpret a raw CAN payload. They define frame identifiers, byte layout, bit positions, signedness, scaling, offset, and units. OEMs and equipment manufacturers typically maintain these internally, often with multiple versions per model year or ECU software release. The difference between a usable signal and a misleading one is sometimes just a scaling factor, which is why keeping track of the right DBC revision is not optional.

In mixed environments it is common to run with multiple DBCs at once, for example a powertrain DBC and a body DBC. Conflicts in message IDs happen, especially when gateways remap IDs or when supplier ECUs share ranges. The management layer helps keep these configurations explicit instead of buried in scripts.

CAN Bus channel detection

Channel detection supports two approaches: passive and active. Passive detection listens for broadcast traffic and evaluates what is present on the bus. Active detection can transmit requests and wait for a valid response, which is useful for OBD-II polling or confirming that a J1939 network responds to requests in a controlled way.

Channel configuration includes standard CAN and CAN-FD bit rates, with support for automatic baud rate detection. When working with CAN-FD, arbitration and data phase settings need to match what the network actually uses. A mismatch can look like “no traffic” even though the bus is active. That is common on bench setups and during early integration.

Advanced settings cover termination and transmit permissions. Termination is relevant when a device is added to a bench harness or a short test loop. Transmit permissions are important when the device is used as a passive logger versus a tool that also sends queries (PIDs, PGNs, UDS requests). Many test programs require passive capture only, while others depend on controlled polling.

Power environment is treated explicitly. The device is designed for 12 V and 24 V electrical systems, and channel setup can be aligned with heavy-duty use cases such as J1939, where traffic patterns and message sizes differ from passenger-car networks.

CAN Bus decoding

Decoding translates raw frames into physical values. On the CAN-FD Pro, decoding can run directly on the device, which keeps the pipeline simple when raw logs would otherwise need server-side parsing. Decoders are typically driven by DBC definitions, but Python-based decoding and custom logic are supported where a DBC is not available or where signals require additional post-processing.

Output formats include CSV, JSONL, and LOG for general workflows, plus MDF4 for programs that use ASAM tooling. MDF4 is widely used in automotive measurement and fits well with Vector tools such as CANalyzer, CANape, and CANoe. MDF4 output is also a practical choice when timestamps, channel metadata, and signal context need to be preserved for later correlation with other measurement systems.

Decoding is not only about human readability. It is also a way to control data volume. A selected set of decoded signals is often smaller than a full raw trace, especially on a busy CAN-FD bus. Projects with multi-hour logging sessions or fleets of vehicles tend to end up with a split approach: raw capture for a limited time window, plus decoded output for longer periods.

CAN Bus filters

Filters control which frames are logged, decoded, or forwarded. The CAN-FD Pro can record all raw traffic, but most deployments benefit from selective capture once the target signals and events are known. Filters can allow or block messages based on identifier, frame type, and identifier width.

Filters can distinguish between data frames, error frames, and remote frames. Identifier handling covers both 11-bit and 29-bit identifiers, including mixed traffic on the same channel. This matters on networks where standard CAN and J1939 traffic coexist, or where gateways forward subsets between segments.

Signal-based filtering can be derived from DBC files when decoding is enabled. This avoids hardcoding numeric IDs across multiple projects and ties filtering to a documented signal definition instead. It is common to start with broad ID filtering and later move to signal selection as the dataset stabilizes.

Filtering is one of the practical levers for cost control. High-load CAN-FD capture, uploaded over cellular, can become expensive quickly. Keeping raw data local and exporting a limited subset reduces ongoing data transfer without removing the option to retrieve the full trace when needed.

CAN Bus frame listeners

Frame listeners monitor live CAN traffic and trigger actions when specified conditions occur. This feature is used for event-driven data capture and device-side workflows, where a particular frame indicates a fault, mode transition, or threshold crossing. The action can be as simple as tagging a time window, or as complex as executing custom code and forwarding results to an external system.

Frame listeners integrate with AutoPi’s service concepts, including custom services, custom workers, custom triggers, and returners. These components support Python-based logic on the device and controlled delivery of output to cloud storage, HTTP endpoints, or internal infrastructure.

A typical workflow is fault-context capture: a listener detects a specific diagnostic frame and triggers an export of the last 30 minutes of raw CAN traffic. This creates a focused dataset for analysis without uploading raw traffic continuously. Another common workflow is “state-based logging”, where the logger switches profile when a vehicle transitions from ignition-off to ignition-on, or when a machine enters a working mode.

Frame listeners are not limited to passenger cars. Machinery networks often have consistent event frames and clear state machines, which makes event-triggered exports practical. The important part is repeatability, the same trigger should yield comparable captures across a fleet.

Output control

Output control governs how data is stored and exported, including destination, file format, and rotation. The CAN-FD Pro supports local storage on internal flash and can upload to external storage such as AWS S3. This is often combined with filters and decoding, depending on whether the output is raw frame dumps, decoded signals, or both.

Local formats include ASC (Vector ASCII), BLF (Vector Binary Logging Format), CSV, DB-backed storage, JSONL, and LOG. ASC and BLF are widely used when working with Vector tooling and protocol analysis. BLF is also useful when storage efficiency matters during long recordings. CSV is a pragmatic choice for quick analysis, JSONL fits logging pipelines and structured ingestion, and LOG gives a plain text view for troubleshooting.

File rotation is configurable by maximum file size and maximum age, preventing storage exhaustion during continuous capture. Rotation rules become important in multi-hour logging sessions, where raw CAN-FD traffic can generate large files quickly, depending on bus load and payload usage.

For cloud exports, AWS S3 can be configured as a remote destination with access key ID, secret access key, bucket, and folder path. This setup fits environments where a project already uses S3-based workflows for downstream processing, archival, or integration into analytics platforms. Other endpoints can be used via returners when exports need to land in internal systems.

Output control is one of the areas where most projects iterate. Raw capture is valuable, but output rules typically evolve once storage, bandwidth, and analysis workflows are known.

Tailscale integration

The CAN-FD Pro supports native integration with Tailscale, providing encrypted access over a private mesh network based on WireGuard. Devices can be reached without port forwarding or public inbound firewall rules, which reduces operational risk in fleet deployments.

Once enrolled, the device can be accessed over a private IP for SSH and controlled diagnostics. This is useful for remote troubleshooting, inspecting SocketCAN interfaces, validating logger state, and reviewing local logs when cellular uploads are delayed. In practical use, remote access often saves a site visit.

Tailscale setup is managed from the AutoPi Cloud interface and requires one-time authentication with a Tailscale account. Access control can then be handled through the Tailscale admin console, which is where most teams already manage device-to-engineer access policies.

Remote access is not a replacement for logging, but it helps shorten debugging cycles when a device behaves differently in the field than it does on the bench. This is a frequent issue in vehicle programs where bus traffic changes with ECU software versions and gateway configuration.