Delivering quality telemetry data from all types of machinery, trucks and vehicles

The right device depends on your bus type, required capture rate and compute needs. Here is a technical summary:

• AutoPi CAN-FD Pro: Dual independent CAN-FD channels (can0/can1) up to 5 Mbps each, >3,000 frames/sec capture, native J1939 PGN/SPN support, Standard (CSV/JSONL/LOG) and ASAM (MDF4) on-device decoding, NXP SE051 hardware security element, 12–35V DC input. Choose this for heavy-duty J1939 machinery, dual-bus CAN-FD logging or projects requiring onboard DBC decoding.

• AutoPi TMU CM4: Full CAN bus via SocketCAN on Raspberry Pi CM4, Docker pre-installed for containerized edge services, Tailscale SSH for remote shell access, extendable with HAT solutions and IP67 enclosures. Choose this for custom edge applications, protocol adapters or projects requiring compute headroom beyond logging.

• AutoPi Mini: OBD-II PID query engine with EV-specific parameters (SoC, thermal, charge state), direct OBD-II port fit with no custom wiring. Choose this for light-duty passenger vehicle and EV fleet deployments.

If you are unsure, contact us - we will match the device to your bus type, protocol and output requirements.

AutoPi devices log CAN bus data using SocketCAN on Linux. The general flow for a CAN-FD Pro deployment is:

1. Channel configuration: Configure can0 and/or can1 with a fixed bitrate (e.g. 250000, 500000, 1000000) or run an autodetect strategy - Any (passive listen), OBD (active SAE J1979 query), or J1939 (active PGN scan). The autodetect result fires an event tag (vehicle/bus/can0/autodetected) that can trigger downstream logic.

2. Logger setup: Create named loggers per channel with pass/block ID filters (11-bit or 29-bit). Select a decoder - Standard outputs CSV, JSONL or LOG; ASAM outputs MDF4 with signal-level decoding from imported DBC files. For J1939, use a frame ID mask of 1FFFFF00 to match PGN groups.

3. Storage and upload: Logged files are written to local eMMC with configurable rollover size. An output worker syncs completed files to AWS S3 (or another endpoint) with retry count and sync interval controls. A sync completion event (vehicle/bus/can0/logger/<name>/s3_sync/completed) confirms delivery.

4. Automation: Frame listeners with ID/mask filters can fire event reactors and workflow hooks (handler, converter, trigger, filter, enricher, returner) on specific frame matches - enabling on-device anomaly detection, alerting or conditional logging.

See the CAN-FD Pro User Guide for a full walkthrough of channel setup, logger configuration and output routing.

AutoPi supports two onboard decoder engines, selectable per logger:

• Standard decoder: Outputs raw or lightly processed CAN frames in CSV, JSONL or LOG format. Suitable for projects where decoding happens downstream (in Python, MATLAB, Vector Analyzer, etc.) or where raw frame capture is the primary requirement.

• ASAM decoder: Outputs signal-decoded data in MDF4 format (ASAM MDF 4.x standard). Requires importing a DBC file and selecting the signals to decode. The device applies the DBC on-device and writes physical-unit values directly into the MDF4 file. This is the recommended format for J1939 PGN/SPN logging, measurement tools and integration with ASAM-compatible analysis platforms.

Both decoders can run simultaneously on separate loggers on the same channel - for example, one Standard logger capturing all raw frames and one ASAM logger decoding a specific J1939 PGN subset. Onboard decoding is available on the AutoPi CAN-FD Pro.

J1939 uses 29-bit extended CAN identifiers structured as PGN (Parameter Group Number) and SPN (Suspect Parameter Number). AutoPi handles this natively on the CAN-FD Pro:

• Autodetect: The J1939 autodetect strategy actively scans for J1939 traffic and confirms bitrate and protocol automatically.

• Frame ID filtering: Use a 29-bit pass filter with mask 1FFFFF00 to match frames by PGN group without specifying every source address. This is the recommended mask for DBC-based J1939 decoding.

• DBC decoding: Import a J1939 DBC file, select the SPNs of interest, and the ASAM decoder will extract physical values (RPM, coolant temperature, fuel rate, etc.) directly on-device into MDF4 output files.

• Query engine: The J1939 query type allows sending PGN requests at a configured interval and logging responses - useful for parameters not broadcast passively.

• Adapters: Purpose-built J1939 adapter cables are available for Cummins (9-pin, 12-pin), Caterpillar (538-5051), Komatsu and other major OEMs - no custom wiring required.

Yes. AutoPi CAN-FD Pro and TMU CM4 run standard Linux (Raspbian) on Raspberry Pi Compute Module 4. Docker is pre-installed and managed through AutoPi Cloud:

• Deploy Docker containers to individual devices, groups or entire projects from the Cloud UI or REST API.

• Containers have access to SocketCAN interfaces (can0, can1), GPIO, serial and USB - enabling custom protocol translators, local ML inference, modem integrations and more.

• Workflow hooks (handler, converter, trigger, filter, enricher, returner) can be attached to frame listeners or event reactors to build event-driven pipelines on-device without a full container.

• Tailscale VPN is pre-configured, giving secure SSH access to the device shell from anywhere without firewall changes or static IPs.

The underlying AutoPi Core stack (SaltStack, Python, SocketCAN) is fully open-source and documented at docs.autopi.io/core.

AutoPi Cloud acts as the central configuration plane for all devices. Configuration changes are pushed to devices via SaltStack on the next connection:

• Templates: Define a configuration template (channels, loggers, decoders, output workers, advanced settings) and apply it to a device, group or project in one operation.

• API parity: Every Cloud UI operation is available through the REST API at api.autopi.io - including template application, logger control, event queries and OTA updates. Use it for infrastructure-as-code, CI/CD integration or custom management tooling.

• Event stream: Monitor device state changes in real time via event tags - autodetect results, logger status transitions, S3 sync completions and disk housekeeper events are all surfaced as queryable event records in Cloud.

See docs.autopi.io/cloud for the full Cloud documentation.

AutoPi software is structured in three layers:

• AutoPi Core: Open-source on-device stack running on Linux with SocketCAN, Python and SaltStack. Handles CAN channel management, logger execution, decoder pipelines, frame listeners, event reactors and workflow hooks. Documented at docs.autopi.io/core.

• AutoPi Cloud: Hosted control plane at my.autopi.io for remote device configuration, fleet management, OTA updates and event stream monitoring. Included with every AutoPi device. Templates allow fleet-wide configuration rollout.

• AutoPi REST API: Full API parity with the Cloud UI at api.autopi.io, plus MQTT for real-time data streams. Use the API to integrate AutoPi into existing backends, data platforms or deployment pipelines.

AutoPi devices are used across a broad range of industries wherever CAN bus or OBD-II data is needed:

• Heavy machinery and construction: J1939 data logging on excavators, wheel loaders and trucks via Cummins, Caterpillar and Komatsu adapter cables. Log PGNs for engine load, fuel rate, coolant temperature and hours of operation.

• CAN bus research and development: Capture dual raw CAN-FD streams at >3,000 frames/sec for protocol analysis, reverse engineering and DBC development. Export to MDF4, JSONL or CSV for offline toolchain integration.

• EV battery monitoring: Log EV-specific OBD-II parameters including state-of-charge, battery temperature, charge state and range estimation via AutoPi Mini on passenger EVs.

• Fleet telematics: Deploy AutoPi Cloud templates across vehicle groups for consistent channel, logger and upload configuration. Correlate CAN event streams with trip records and GPS telemetry.

• Edge compute and custom integrations: Run containerized applications on TMU CM4 for protocol translation, local model inference or custom data pipelines with full SocketCAN access.

• OEM and white-label products: AutoPi hardware and Cloud can be white-labeled, logo-free and custom-engraved for OEM projects. Custom OS images and private API access supported.

Want to discuss a specific use case? Contact us.

Yes, both AutoPi hardware and the Cloud platform support white labeling:

• Devices can be ordered without the AutoPi logo. Custom engraving on the casing is available on request.

• AutoPi Cloud can be white-labeled with your branding on the interface and subscription plans.

• The device supports custom OS images - install your own Raspbian build, configure SocketCAN and AutoPi Core independently, or build on top of the open-source stack.

• SIM card and connectivity management can be handed over to your own subscription infrastructure.

For white-label pricing and options, contact us.

Approximately 2–5 business days depending on your location. All devices are in stock and ship from Denmark.

• Orders are dispatched within 48 hours of payment confirmation.

• A tracking number is provided once the order has shipped.

• We offer worldwide shipping. Devices are CE, FCC and RoHS certified for global deployment. If your country is not listed at checkout, contact us.