Welcome to the first issue of my newsletter. I’ve spent the past few months adding articles to my website and building out my online book, CAN Bus Embedded Development. I wanted to give you a few things to read before sending the first issue. Now there’s enough on the site to start sharing what’s new and what I’m working on.

As new posts go up, please fe…

Read more

I have finished the latest update to the JCOM1939 Monitor for Windows. The release adds two features I’ve wanted to have on the bench: a live view of the CAN Bus network condition, including receive/transmit error counters and a Silent Mode for recording traffic without transmitting. The diagnostics grew out of a customer question about J1939 frames that appeared to go missing during a test.

CAN bus status at a glance

The customer was transmitting identical PGNs from two nodes. I couldn’t reproduce the missing frames on my bench, but the test raised a practical question. If an expected frame never appears in the monitor, did the CAN controller encounter an error, or do I need to look more closely at what the ECU sent and how the Windows application handled it?

Note: Two or more J1939 nodes can technically broadcast the same PGN as long as they use different source addresses. Doing so, however, goes against an unwritten convention that a given broadcast PGN should originate from a single dedicated node. A receiving node should never have to rely on the source address to determine which broadcast message to use. When communication needs to take place between specific nodes, that’s what peer-to-peer messages are for.

The update puts a CAN bus condition indicator at the top of the main window. It shows green for normal communication, orange for communication issues or degraded communication, and red when communication is lost.

A dedicated CAN Bus tab shows the receive and transmit error counters, the controller’s error and operating status, and the current bus load.

The receive (Rx) and transmit (Tx) error counters can be difficult to interpret. They are part of the CAN controller’s internal error management system, and the CAN protocol defines when and by how much each counter changes. To make sense of the readings, it helps to understand how the controller handles errors during transmission and reception.

I’ll cover these rules in more detail in an update to the JCOM1939 Monitor User Manual. In upcoming articles on this site, I’ll show how the counters change under different network conditions and how you can use those changes to troubleshoot communication problems.

Silent Mode for passive monitoring

Silent Mode, also known as listen-only mode, lets the monitor receive and record traffic on a running J1939 network. In this mode, the monitor leaves arbitration and frame acknowledgments to the other nodes on the bus.

To enable it, select Silent Mode in ECU Setup before starting the CAN interface. When you need to send a request, claim an address, or simulate an ECU, start the interface in normal mode.

There’s one detail worth keeping in mind on the bench. If your setup consists of a single transmitting ECU and a monitor in Silent Mode, there’s no active receiver to acknowledge the ECU’s frames. The ECU can report acknowledgment errors and retry its transmissions. Adding another active CAN node gives the ECU a receiver while the monitor stays passive.

Release availability

Both features are included in the next release of the JCOM1939 Monitor. I have also updated the user manual to cover the status indicators, explain what the error counters show, and document how to enable Silent Mode.

Please be aware that the updated Windows software also requries an updated gateway firmware.

1. Download and install JCOM1939 Monitor V 4.10.00.

2. Download and install gateway firmware V 1.40.00.

Knowing C++ is one thing. Using it to develop firmware that interacts reliably with hardware is another. Embedded applications introduce constraints that desktop programmers may rarely encounter: limited memory, precise timing requirements, direct access to peripheral registers, and power consumption that can determine whether a device runs for months or only days.

C++ for Embedded Systems: With Exercises and Code Samples for Intermediate Developers by Gareth Thomas addresses that transition. Based on its description, the book targets developers who already have a working knowledge of C++ and want to apply it to microcontrollers and connected devices. It is positioned as a practical guide rather than an introduction to the language.

Connecting Software to Hardware

The advertised coverage includes GPIO, UART, I2C, SPI, and direct memory access (DMA), alongside register-level programming. These subjects form much of the foundation of embedded development. Before an application can process sensor readings, control an actuator, or exchange messages with another device, its firmware must configure and operate the underlying hardware.

For readers working with CAN Bus applications, that foundation is particularly relevant. Although the supplied description does not mention CAN specifically, a CAN-based device still depends on sound peripheral configuration, reliable data handling, and a clear division between hardware access and application logic. Those skills carry across communication interfaces and processor families.

Working Within Embedded Constraints

The book also lists real-time performance, real-time operating systems (RTOS), and low-power design among its topics. These areas bring a different set of questions into software development. How quickly must an event be handled? Which tasks can run concurrently? When can the processor sleep, and what must remain active to wake it?

Efficient firmware requires more than reducing execution time. Developers must also consider memory use, predictable behavior, and how different parts of a system share resources. C++ provides useful tools for organizing that complexity, but their suitability depends on the target hardware and the application’s requirements.

Learning Through Code and Exercises

According to the description, each subsection combines an explanation with a complete code sample and several exercises. That structure should appeal to readers who prefer to work through a concept rather than stop at a theoretical explanation.

In embedded development, however, code always has a hardware context. Peripheral registers, pin assignments, clock settings, and software libraries vary between microcontrollers. Readers should check which platforms and development environments the examples use before purchasing, particularly if they intend to follow along on a specific board.

Modern C++ and Connected Devices

The advertised scope extends to modern C++ features, secure IoT development, and cloud connectivity. That broadens the focus from operating individual peripherals to building devices that must communicate and remain dependable as part of a larger system.

For intermediate developers, the central challenge is learning where language features help produce clear, maintainable firmware and how their costs fit within an embedded platform’s limits. Abstraction can make a system easier to understand, but developers still need to know what the resulting code asks of the processor and memory.

Gareth Thomas’s C++ for Embedded Systems appears aimed at readers ready to move beyond language exercises and into practical firmware development. Its combination of hardware interfaces, system-level concerns, and exercises makes it a potentially useful title to investigate. This overview is based on the supplied book description rather than a hands-on assessment of its contents. More information…

One of the awkward things about developing marine electronics is that the equipment you need for testing may be sitting in a marina. You can power up a display on your workbench, inspect its menus, and admire its screen. But without incoming data, you have only answered the easiest question: Does it switch on?

The more useful questions come afterward. Does the engine speed indication follow changing RPM? Does the application interpret wind data correctly? Is an unexpected reading caused by the receiving software or by the data source?

My preferred approach is to make the input something I can control. That is where a device such as the Teensy 4.0 NMEA 2000 Simulator from Copperhill Technologies, becomes useful.

Give the display something to display

The simulator comes with a Teensy 4.0 installed and programmed. Its hardware includes six rotary potentiometers, two push-buttons, and a Micro-C connection for the NMEA 2000 network. Turning a knob provides a convenient way to change simulated values while watching the receiving equipment respond. The product documentation lists messages for environmental parameters, wind data, engine speed, and course and speed over ground.

Consider a simple development task: You are writing an application that displays engine RPM. A stationary value proves that your application can receive and display something. Changing that value lets you investigate much more.

Does the indication update smoothly? Does the application apply the correct scaling? Does switching between display units affect anything it should not? If you have implemented an alarm threshold, does the alarm appear and clear at the intended values?

For these checks, a knob on the workbench is a remarkably convenient substitute for asking someone to operate an engine.

Turn troubleshooting into a controlled experiment

Suppose a marine display powers up but shows no engine speed. On an installed system, several explanations might be possible. The expected data may be absent, the display may be configured incorrectly, or there may be a communication problem.

I would begin by reducing the number of unknowns. Build a small test network, connect the simulator and the receiving device, and select a message that the receiver supports. Then change one value and observe the result.

If the display responds, you have evidence that it can receive and interpret that message under those conditions. If it does not, you have a smaller system to investigate.

That distinction matters. Troubleshooting becomes much easier when every test answers a specific question. Changing settings at random can keep you occupied for an entire afternoon without making you any better informed.

Start with one useful test

I would resist the temptation to simulate everything at once. Start with a single quantity, such as engine RPM, and define what a successful result should look like.

Check several values across the range relevant to your application. Record the expected and displayed readings. Repeat the same checks after changing your software. Once that works, move on to another supported quantity.

The test network still needs the appropriate power, cabling, and termination. I would also verify the exact PGN and data fields expected by the receiving device before spending time investigating an apparent failure. A simulator and a display must agree on what information they are exchanging.

Adapt the source to the project

The firmware is open source, and the manufacturer provides an Arduino-style demonstration sketch. This gives developers a starting point for adapting the transmitted data to a particular application.

For example, I might want a value to follow a programmed sequence rather than depend on a manually adjusted knob. A repeatable sequence would let me compare application behavior before and after a software change.

That requires firmware work, including checking message definitions and transmission timing. Still, having access to the source code makes the simulator more useful as development progresses beyond the supplied demonstration.

Simulation and PGN Control

The simulator generates a set of predefined Parameter Group Numbers (PGNs) — the unique identifiers used in NMEA 2000 messaging. These PGNs are essential for transmitting different types of data over the CAN-based NMEA 2000 network.

This unit enables interactive control over eight PGNs, offering both real-time variability and fixed value toggling:

• Six PGNs are linked to rotary potentiometers, allowing analog adjustment of their data fields. For example, as the user rotates the knob, the simulated value for wind speed or engine RPM changes accordingly.

• Two PGNs are controlled by onboard push-buttons, suitable for toggling digital states such as engine status or heading lock.

The currently supported PGNs include:

• PGN 130310 – Environmental Parameters (e.g., Water Temperature): Simulates real-time changes in seawater temperature, allowing you to test temperature-sensitive systems such as chillers or alarms.

• PGN 130306 – Wind Data: Adjusts wind speed and direction to evaluate performance of instruments like wind gauges or sailing computers.

• PGN 127488 – Engine Parameters, Rapid Update: Sends live engine RPM values, useful for validating engine monitoring displays and alarms.

• PGN 129026 – COG & SOG, Rapid Update: Simulates course over ground and speed over ground to test navigation and autopilot systems.

The firmware is open-source, giving developers the flexibility to customize or expand the set of PGNs. Additional data types—such as fuel flow, heading, or AIS targets—can be added with minor code modifications. This openness makes the device suitable for both basic functionality checks and complex system development.

Know what the result tells you

A successful bench test establishes something valuable, but specific: Your equipment handled the simulated messages under the conditions you tested.

It does not establish that an entire installation will behave correctly aboard a vessel. Installation wiring, power conditions, other network participants, and the behavior of real sensors introduce additional variables.

I see the simulator as a way to resolve the basic questions early. Get the data reception working. Verify the interpretation. Exercise the display behavior. Then approach installation testing with fewer unanswered questions.

A boat is an excellent place to use marine electronics. For debugging the first version of your software, I would rather have a workbench, a controlled data source, and a cup of coffee that stays where I put it.

Looking back, I somewhat regret not taking a closer look at NMEA 2000 when I started developing JCOM1939. Our JCOM1939 Monitor software for Windows has grown considerably over the years, becoming a capable, affordable alternative to much more expensive tools on the market. Building something similar for NMEA 2000 would have been a rewarding opportunity.

The main obstacle at the time was the cost of entry. NMEA’s pricing policy, including membership and the substantial cost of obtaining the NMEA 2000 standard, put that initial investment beyond my development budget. For a small operation, those expenses matter—especially before writing the first line of application-specific code.

Still, some of the work already invested in JCOM1939 can be useful on an NMEA 2000 network. Our USB and Bluetooth gateways, together with JCOM1939 Monitor, provide a starting point for observing network traffic. Understanding where that approach helps, and where its limitations begin, is the subject of this post.

When a marine instrument stops displaying information, the first question is often straightforward: Is the data still arriving on the network? Before investigating the meaning of individual parameters, it helps to establish whether the equipment is transmitting at all.

This is where our JCOM1939 gateways, available with USB or Bluetooth connectivity, can provide a useful starting point. Together with the JCOM1939 Monitor software for Windows, they offer a way to inspect network traffic at the PGN and data-byte level.

In my previous post, I discussed the differences between SAE J1939 and NMEA 2000. Here, I want to focus on a practical application of their shared foundation: using a J1939 monitoring tool to observe NMEA 2000 communication, while recognizing the limits of that approach.

What monitoring can tell you

You do not always need a fully decoded display to learn something useful about a network. Seeing which PGNs arrive, which source addresses transmit them, and whether their data changes can help narrow down a problem.

Consider an instrument that no longer shows a sensor reading. Monitoring can help establish whether the expected PGN is present. If it is missing, the investigation can turn toward the transmitting device, its configuration, power supply, or network connection. If the PGN is present, the next step is to examine its contents and determine why the receiving instrument does not use or display it.

Neither result provides an automatic diagnosis. However, both give you a more useful direction than simply knowing that the display is blank.

Filtering is particularly helpful on a busy network. Once you know the PGN associated with the information you are investigating, you can concentrate on that traffic instead of watching an uninterrupted stream of unrelated messages. JCOM1939 Monitor provides PGN filtering as part of its existing monitoring functions.

USB or Bluetooth?

The choice between USB and Bluetooth primarily concerns the connection between the gateway and the Windows computer. The purpose of the monitoring remains the same.

USB provides a direct connection for work near the network access point. Bluetooth offers more freedom to position the laptop without running a USB cable between it and the gateway. The gateway itself still requires a physical connection to the CAN network and the appropriate power supply.

Bluetooth should not be confused with automatic compatibility with marine apps. In this application, the gateway works with JCOM1939 Monitor on Windows. Connecting a phone or tablet requires software that specifically supports the gateway’s communication interface.

Use monitoring mode

For this application, the objective is to observe existing traffic. Keep the gateway in its listen-only monitoring mode rather than enabling ECU simulation or other transmitting functions.

The JCOM1939 gateway protocol provides a listen-only operating mode that does not require a source address or perform an address claim. It also uses receive filters to determine which traffic is forwarded to the host computer, so those filters must be configured appropriately. An empty display does not necessarily mean an empty network.

Functions intended for active J1939 communication should not be assumed to work as NMEA 2000 functions. In particular, monitoring existing messages is a different task from requesting information, configuring marine devices, or participating as a fully implemented NMEA 2000 node.

Raw data requires interpretation

The main consideration is that receiving a message does not mean understanding its contents.

A PGN and its hexadecimal data bytes can confirm that traffic exists. Turning those bytes into heading, temperature, tank level, or another engineering value requires the correct NMEA 2000 parameter definitions. The interpretation must account for field positions, scaling, units, and special values indicating unavailable or invalid data.

JCOM1939 Monitor’s J1939 functionality does not automatically supply those marine definitions. Likewise, a familiar-looking PGN or data pattern is not sufficient reason to interpret the payload using a J1939 parameter description.

Manufacturer-specific messages introduce another limitation. Their presence may be visible, but understanding their contents can require documentation from the equipment manufacturer.

Longer messages need additional handling

Some NMEA 2000 information spans several CAN frames using Fast Packet transport. Without NMEA 2000-specific reassembly, those frames remain separate pieces of a longer message.

They can still show that communication is taking place, but the complete payload must be reconstructed before its fields can be interpreted reliably. Existing J1939 transport-protocol support should not be mistaken for NMEA 2000 Fast Packet support.

This distinction matters when deciding what you expect from the monitor. Observing traffic is useful in its own right; displaying complete, decoded marine messages requires additional software capabilities.

Check the connection and configuration

The physical connection deserves as much attention as the software. A J1939 connector is not interchangeable with an NMEA 2000 connector merely because both networks use CAN.

Use a correctly wired adapter or cable, verify the gateway’s power requirements, and preserve the existing backbone and termination arrangement. Adding a monitoring connection should not introduce an unnecessary terminating resistor.

NMEA 2000 operates at 250 kbit/s. The gateway must operate at that rate, and the gateway firmware and monitor must preserve the complete PGN, including its data-page information. Compatibility should be checked with the particular hardware, firmware, and software versions being used.

It is also worth distinguishing message monitoring from electrical troubleshooting. A message display cannot show signal quality, reflections, or voltage problems in the way an oscilloscope can. Receiving traffic does not prove that every aspect of the physical network is healthy.

A practical additional use

I see this as an additional application for our existing JCOM1939 USB and Bluetooth gateways. For someone who already uses these tools, inspecting marine network traffic can be a useful extension of familiar equipment.

The value lies in answering practical questions: Is a device transmitting? Is the expected PGN present? Does the data change when the measured condition changes? Where should the investigation go next?

A raw monitor will not answer every NMEA 2000 question. But establishing what is actually being transmitted is often a productive first step toward finding the answer.

If you are familiar with SAE J1939, your first encounter with NMEA 2000 may look surprisingly familiar. There are CAN messages, 29-bit identifiers, source addresses, and Parameter Group Numbers. Much of the underlying structure seems to be the same.

That resemblance is no coincidence. NMEA 2000 belongs to the same protocol family, drawing on the J1939-based communication framework used in ISO 11783. However, calling it “J1939 for boats” leaves out several differences that matter when connecting equipment, developing software, or interpreting recorded data.

For me, the most useful way to understand the relationship is to separate three questions: How does the data travel? What does it mean? And what must a device do to participate in the network?

CAN provides the foundation

CAN Bus provides the underlying communication technology. It handles tasks such as transmitting frames, resolving competition for bus access, and detecting transmission errors. It does not, by itself, explain whether a particular data byte represents engine speed, water depth, or battery voltage.

That interpretation belongs to the higher-layer protocol.

SAE J1939 and NMEA 2000 both use extended CAN identifiers containing 29 bits. Their related identifier structures carry information such as message priority, source address, and the information used to determine the Parameter Group Number, usually abbreviated PGN. This common structure is one reason J1939 experience transfers well to NMEA 2000 development.

The important distinction is that recognizing the structure of a message does not necessarily mean understanding its contents.

Different equipment, different information

SAE J1939 is widely used for communication and diagnostics in diesel engine systems, including those found in trucks, buses, agricultural and construction machinery, trains, ships, and stationary generators. It allows engines, transmissions, and other electronic control units to exchange operating data, commands, and diagnostic information. Although its scope extends beyond diesel engines, this association helps explain why J1939 also appears aboard vessels: the distinction between J1939 and NMEA 2000 concerns their roles and message definitions, rather than simply trucks versus boats.

NMEA 2000 focuses on integrating marine equipment. Its scope includes navigation instruments, GNSS receivers, wind sensors, propulsion systems, batteries, lighting, and other vessel systems. A chartplotter, for example, may receive information from several independent devices through the same network.

This difference in purpose shapes the information each standard defines. A vehicle controller and a marine navigation display may both need engine information, but the navigation display also needs information that has little relevance to a truck.

A PGN identifies a message—not a universal data format

Both protocols organize information into parameter groups identified by PGNs. However, their application message definitions are different.

To interpret a message correctly, software must know the applicable PGN definition, the location of each field, its resolution, its units, and any special values indicating unavailable or invalid information.

This is where a common misconception arises: a program that extracts a PGN from an NMEA 2000 CAN identifier has not automatically decoded the marine data. It has identified the message category. Understanding the payload requires the appropriate NMEA 2000 definitions.

For example, NMEA 2000 defines PGN 127488 as “Engine Parameters, Rapid Update.” A marine display expecting this message will not automatically obtain the same information from an unrelated J1939 engine message merely because both travel over CAN. Garmin’s J1939 bridging documentation explicitly lists the NMEA 2000 engine and other PGNs it can make available through bridging.

Messages longer than eight bytes

A Classical CAN frame carries no more than eight data bytes. Both protocols therefore need a way to transmit information that will not fit into one frame.

Traditional SAE J1939 uses the transport protocol (TP) defined in J1939/21. It divides longer messages into multiple frames and uses transport management messages to coordinate their transmission. Depending on the transfer method, communication can involve a broadcast announcement or an exchange between a sender and a receiver.

NMEA 2000 adds a mechanism called Fast Packet. It carries a longer parameter group across several CAN frames while retaining the original PGN in their identifiers. Fast Packet supports messages containing up to 223 bytes.

This matters when selecting monitoring software. A tool may capture every CAN frame correctly while leaving a Fast Packet message scattered across several display lines. Capturing the frames and reconstructing the complete message are separate capabilities.

Protocol differences beyond Fast Packet

Fast Packet is the most visible addition to the message transport mechanisms, but the differences extend further. Although SAE J1939 and NMEA 2000 share the basic 29-bit identifier structure, PGN addressing, and address-claiming foundation, NMEA 2000 adds or specializes several aspects:

• Message definitions: Marine PGNs specify their own data fields, units, resolutions, and special values indicating unavailable or invalid information.

• Network services: NMEA 2000 defines services for identifying products, reporting supported transmit and receive PGNs, and configuring devices.

• Group functions: These provide standardized mechanisms for requesting information, commanding supported parameter changes, and acknowledging requests. Depending on device capabilities, they can also configure message transmission intervals.

• Device identity: NMEA 2000 uses marine-specific device classes, functions, and instance conventions within the shared identification framework.

• Required device behavior: NMEA 2000 specifies its own requirements for startup, responses to requests, and the transmission of mandatory information.

Consequently, adding Fast Packet support to a J1939 implementation addresses only part of the work. A complete NMEA 2000 implementation must also handle the applicable marine messages, network services, and device behavior.

Network speed and installation

NMEA 2000 operates at 250 kbit/s. Classical J1939 networks commonly operate at either 250 or 500 kbit/s, depending on the applicable physical-layer specification. Matching the bit rate is therefore an essential first step when attempting to monitor either network.

NMEA 2000 also provides a standardized installation approach built around a backbone, drop cables, connectors, and network power. Devices connect along the backbone, with termination at its two ends. These installation requirements are part of creating a predictable marine network, rather than leaving every equipment manufacturer to invent its own wiring arrangement.

An electrically suitable CAN interface may therefore be useful for development, but connecting it requires more thought than finding CAN High and CAN Low. Connector pin assignments, power connections, termination, and the interface’s electrical design all deserve attention.

Address claiming is shared territory

NMEA 2000 is designed to support a self-configuring network containing equipment from different manufacturers. Device identification and address management contribute to that behavior.

However, it would be misleading to say that NMEA 2000 supports address claiming while SAE J1939 does not. J1939/81 explicitly defines address selection and address claiming. The actual addressing behavior depends on the device and its implementation.

For developers, the lesson is straightforward: understanding J1939 network management provides a useful foundation, but an NMEA 2000 device must still satisfy the marine standard’s specific requirements.

Can a J1939 monitor read NMEA 2000?

At the raw CAN level, a suitable interface can capture NMEA 2000 traffic if it supports extended identifiers, operates at 250 kbit/s, and is connected correctly. A J1939-oriented monitor may also be able to display useful information such as source addresses, priorities, PGNs, and data bytes because of the related message structure.

That can be valuable for checking whether traffic is present, identifying transmitting devices, or recording messages for later examination.

Displaying meaningful marine measurements requires additional support: NMEA 2000 message definitions, the appropriate decoding logic, and Fast Packet reassembly where applicable. This follows directly from the distinction between the shared CAN structure and the additional NMEA 2000 protocol features.

I would therefore distinguish between monitoring NMEA 2000 traffic and providing a complete NMEA 2000 analyzer. Both can be useful, but they answer different questions.

Connecting the two networks

A marine engine may provide J1939 data while the vessel’s instruments communicate through NMEA 2000. A gateway can connect these systems by translating supported engine information into the messages expected by the marine equipment.

The gateway must understand the data on both sides. Simply changing the connector does not perform that translation. Furthermore, a gateway may support only selected parameters; proprietary engine information may remain unavailable to the NMEA 2000 display.

Product development goes beyond receiving messages

For a commercial product, NMEA 2000 development also involves licensing and certification requirements. NMEA specifies certification for products that read or transmit NMEA 2000 information, with testing intended to support interoperability.

SAE J1939 has its own network compliance document, J1939/82. Nevertheless, implementing a J1939 protocol stack does not, by itself, establish NMEA 2000 compliance.

The shared foundation makes NMEA 2000 approachable for someone with J1939 experience. Familiar concepts remain useful, and some CAN hardware and software components can be reused. The remaining work lies in understanding the marine messages, handling their transfer methods, and meeting the requirements of the network they serve.

The ESP32 provides a practical platform for developing SAE J1939 applications, including network interfaces, data loggers, gateways, and simulated electronic control units. Its processing power and wireless capabilities leave considerable room for application development beyond basic CAN communication.

However, CAN hardware alone does not turn an ESP32 into a J1939 device. The processor needs software that implements the protocol’s communication rules. For this project, I use ARD1939, my SAE J1939 protocol stack, together with an ESP32 CAN driver and the Arduino IDE.

The installation involves three software components: ESP32 board support for the Arduino IDE, the CAN driver, and the ARD1939 project. Understanding how these components work together makes the setup easier to follow.

CAN Hardware and J1939 Software

The original ESP32 used in this project includes a Classical CAN controller, referred to as TWAI in Espressif’s documentation. It supports the extended 29-bit CAN identifiers required for conventional SAE J1939 communication. However, it requires an external CAN transceiver to connect to the physical network. The processor’s TX and RX pins carry 3.3 V logic signals; they cannot connect directly to CAN_H and CAN_L.

For this project, I used the ESP32 WiFi, Bluetooth Classic, BLE, CAN Bus Module from Copperhill Technologies, which includes an onboard CAN transceiver.. A separate ESP32 development board and a suitable transceiver can serve the same purpose, provided the electrical connections and software pin assignments agree.

On the software side, the CAN driver handles communication with the controller. ARD1939 operates above that driver and supplies the J1939 protocol functionality. Your application then uses the stack to exchange J1939 messages.

This division matters when troubleshooting. A program that compiles successfully may still have an incorrect CAN pin assignment, while a working CAN interface does not by itself confirm that the J1939 application is configured correctly.

Preparing the Arduino IDE

Begin by installing the Arduino IDE and adding Espressif’s ESP32 board support through Boards Manager. If the ESP32 package is not available in the list, add Espressif’s board package address in the IDE’s Additional Boards Manager URLs setting, following the official installation instructions.

In Boards Manager, locate the “esp32 by Espressif Systems” package and install the version appropriate for the project. Then select the board configuration matching your hardware and choose its USB serial port. Before introducing the J1939 software, upload a simple sketch to confirm that compilation and programming work.

There is an important compatibility consideration here: the original ARD1939 ESP32 project uses an older CAN driver and a precompiled protocol component. Compatibility with every subsequent ESP32 board package should not be assumed. Espressif documents breaking changes between Arduino-ESP32 core versions 2.x and 3.0. If an older project fails to compile, investigate the software versions before changing the application code.

Once you establish a working combination, record the Arduino IDE version, ESP32 board package version, board selection, and library versions. These details make the installation reproducible.

Adding the ARD1939 Project

Download the ESP32 edition of ARD1939 provided with the original project and extract the archive into a local working folder. Preserve the supplied directory structure and open its Arduino sketch.

The ESP32 distribution includes a precompiled protocol component rather than the complete ARD1939 implementation source. Consequently, the supplied supporting files must remain available to the build process. Copying only the main sketch into a new project may leave required components behind.

Check the extracted package for installation notes and any libraries that need to be placed in the Arduino sketchbook’s libraries folder. An Arduino project archive is not necessarily a library archive, so the entire download should not automatically be installed through “Add .ZIP Library.”

Compile the supplied example before making changes. This first build establishes whether the development environment can locate the headers, CAN driver, and precompiled stack.

Using the Correct CAN Driver

For the original ESP32 implementation, I selected the ESP32 CAN Protocol Demo driver and modified it for use with ARD1939. The changes included adding CAN error reporting and making several C++ compatibility adjustments.

Those modifications are part of the integration. Replacing the project’s driver with an unrelated CAN library may require changes to the interface between the driver and the protocol stack. Even when two libraries support the same controller, their initialization, transmit, receive, and error-reporting functions can differ.

When reproducing the original project, begin with its accompanying driver files. Establish a working baseline before considering a migration to another driver.

Configuring the Hardware Interface

Before uploading the J1939 example, verify that the CAN transmit and receive GPIO assignments match the board’s wiring. On a board with an integrated transceiver, these connections are usually fixed by the hardware design.

Also check whether the transceiver has an enable or standby input that requires configuration. A correctly initialized controller cannot communicate through a transceiver that remains in standby.

The CAN bit rate must match the test network, and the driver must handle extended 29-bit identifiers. Use the settings appropriate to the supplied example and the network you intend to connect.

Running the J1939 Application

Begin with the supplied application’s existing initialization and processing sequence. Review its device identity, address settings, message handling, and transmission behavior before adapting it to your own project.

The protocol stack needs regular processing time. Preserve the example’s intended call sequence and avoid adding long delays or blocking operations that interfere with communication. Wireless connections, user interfaces, and data logging should be introduced after basic J1939 operation has been established.

Installing the stack also does not automatically provide an application that understands every engine parameter. Your program still needs to select the relevant Parameter Group Numbers, interpret their data fields, and apply the appropriate scaling and offsets.

Verifying the Installation

Use a small bench network for the initial test, with suitable termination and a second CAN interface or J1939 device. A CAN monitor provides an independent view of the messages exchanged by the ESP32.

Verify the installation in stages:

1. Confirm that the supplied project compiles and uploads.

2. Check any available startup and error messages.

3. Verify CAN reception and transmission.

4. Observe address claiming and the example’s intended J1939 traffic.

5. Introduce your own application changes gradually.

This sequence helps distinguish development-environment problems from wiring, driver, and protocol issues.

A Foundation for Further Development

With the hardware interface and example application working, ARD1939 provides a starting point for exploring embedded J1939 development on the ESP32. From there, the application can grow into a gateway, logger, simulator, or another purpose-built network device.

The original software is provided free of charge for demonstration and educational use, without warranty or technical support. My book, SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino, explains the ARD1939 interface and implementation concepts in greater detail. Although the original examples focus on other Arduino platforms, the protocol concepts remain relevant to the ESP32 version.

Upgrading marine electronics often creates an unexpected problem: the new equipment works, the old equipment still works, but they cannot exchange information. An older GPS receiver, depth instrument, or wind sensor may provide an NMEA 0183 interface, while a new chartplotter expects data from an NMEA 2000 network. Replacing every instrument would solve the compatibility problem, but it could also turn a modest upgrade into an expensive project.

The KC-2W bidirectional converter addresses this gap. It translates supported NMEA 0183 sentences into NMEA 2000 messages and performs the conversion in the opposite direction. This allows compatible equipment from different generations to share information, helping boat owners retain useful instruments while upgrading their onboard network.

Why a Cable Adapter Is Not Enough

NMEA 0183 and NMEA 2000 serve a similar purpose: exchanging information between marine electronic devices. However, they use different electrical interfaces, communication methods, and data formats.

NMEA 0183 transfers information as readable text messages called sentences. Each sentence carries a particular type of information, such as position, heading, or water depth. A conventional connection has one transmitting device, commonly called a talker, sending information to receiving devices known as listeners.

NMEA 2000 uses CAN Bus technology and carries information in binary messages identified by Parameter Group Numbers, or PGNs. Multiple devices communicate over a shared backbone rather than relying on individual serial connections for each data source.

Consequently, connecting the wires through a passive adapter cannot make these systems communicate. An active converter must receive a message, interpret its contents, and create the corresponding message for the other network.

What Bidirectional Conversion Makes Possible

Consider a boat with an older NMEA 0183 depth instrument and a recently installed NMEA 2000 chartplotter. If the converter supports the instrument’s depth sentences and the corresponding NMEA 2000 output, the chartplotter can receive that information through the network. The existing transducer and instrument can remain in service.

Conversion in the other direction is equally useful. Position information available on an NMEA 2000 network could be translated into an appropriate NMEA 0183 sentence for an older receiving device. A practical example is supplying position to a compatible VHF radio that requires an external GPS source.

These examples illustrate the converter’s main benefit: equipment replacement can follow the condition and usefulness of individual instruments instead of being dictated entirely by interface compatibility.

Bidirectional conversion does not mean that every possible message is translated. Compatibility depends on the converter’s supported sentences, PGNs, and conversion mappings, as well as the messages accepted by the receiving equipment.

Installation and Configuration

The KC-2W draws power through its NMEA 2000 connection, reducing the need for separate power wiring. Its NMEA 0183 input provides automatic baud-rate detection, while the output rate is configurable. Input detection does not automatically select the rate required by an older receiving instrument.

Published specifications differ between versions: the supplied listing states automatic detection up to 38,400 baud, while ONWA’s product page lists up to 115,200 baud. The documentation for the particular unit should determine installation settings.

ONWA also documents Wi-Fi for configuration and data output, with browser-based configuration and firmware-update facilities. Wireless access can make supported data available to compatible applications, but application format and connection requirements still matter.

The manufacturer lists a 9–30 VDC supply range, operation from −20°C to +55°C, and protection against overvoltage, power transients, and accidental reverse polarity. Its published waterproof designation is “IPX67,” an unusual notation that warrants clarification before choosing an exposed mounting location.

Check the Data Path Before Connecting

A successful installation starts with a simple question: which device needs which information?

Identify the source message, confirm that the KC-2W translates it, and verify that the destination accepts the resulting message. For an older instrument receiving serial data, check its required baud rate as well.

The NMEA 2000 backbone still requires correct power, termination, and connections. Automatic baud-rate detection simplifies part of the installation; it does not replace proper wiring or network planning. Where information can travel in both directions, plan the connections carefully to avoid feeding converted data back toward its original source.

For boats carrying a mixture of older and newer electronics, the KC-2W offers a practical bridge between two established marine communication standards. Its value lies in making existing information available where it is needed—and allowing useful equipment to remain useful. More information…

Developing an SAE J1939 application does not always require access to a truck or a running diesel engine. For many development tasks, what matters is receiving the messages that an engine controller and other electronic control units would normally transmit. A simulator can provide that traffic on a workbench, allowing developers to test their software under controlled and repeatable conditions.

Consider a dashboard that displays engine speed, coolant temperature, and oil pressure. Before connecting it to a vehicle, you need to determine whether it interprets the incoming data correctly. Does the tachometer show the expected speed? Does the temperature display use the correct units? Does a warning appear when oil pressure falls below the configured threshold? Simulated messages let you investigate these questions by choosing the values yourself.

The same approach is useful for testing gateways, recording devices, and remote monitoring systems. It also provides an accessible way to learn J1939: instead of trying to understand everything happening on a busy vehicle network, you can begin with a few known messages.

Signals, SPNs, and PGNs

Before configuring a simulation, it helps to distinguish between an individual parameter and the message that carries it.

An SPN, or Suspect Parameter Number, identifies a parameter such as engine speed. A PGN, or Parameter Group Number, identifies a parameter group that can contain several related parameters. Consequently, simulating three signals does not necessarily require transmitting three separate messages.

The transmitted data must also use the correct encoding. A physical value, such as a temperature or rotational speed, usually needs to be converted into a numerical representation using the specified resolution and offset. Its position and length within the message matter just as much as its value.

The SAE J1939 Digital Annex provides the PGN and SPN definitions needed for this work, including data lengths, units, resolutions, offsets, and transmission information.

Choosing What to Simulate

A useful simulation begins with the requirements of the receiving device. There is little benefit in generating a large collection of messages if the application only uses a handful of parameters.

For an initial dashboard test, engine speed, coolant temperature, and oil pressure may be sufficient. A vehicle monitoring application might additionally require road speed, fuel level, fuel consumption information, and vehicle position. Identification and maintenance functions may depend on information such as the vehicle identification number and accumulated engine operating hours.

Start with fixed values. These make it easy to compare the transmitted data with the receiving device’s output. Once the basic interpretation is correct, introduce changing values and more demanding conditions.

For example, you could gradually increase engine speed, raise coolant temperature toward a warning threshold, or interrupt a message to examine how the application handles missing data. Each test should answer a specific question about the receiving system.

Message Timing and Requests

Correct values are only part of a useful simulation. Message timing also affects how the receiving application behaves.

A display may interpret a missing periodic message as a communication failure. A gateway may update its output only when new data arrives. If the simulator transmits everything at an arbitrary rate, the test may overlook problems that appear under the expected operating conditions.

Request handling deserves separate attention. When an application requests a particular parameter group, the simulator must recognize that request and provide the appropriate response. Periodically broadcasting the same information may allow a display to show a value, but it does not verify the application’s request-and-response behavior.

For each required parameter group, establish how it should be transmitted and what behavior the application expects.

A Practical JCOM1939 Example

In my original diesel engine simulation project, I used a JCOM1939 USB interface together with the Windows-based JCOM1939 Monitor software. The configuration included common engine and vehicle parameters, along with information made available in response to requests.

The interface provided J1939 address claiming and transport protocol support, while the software allowed the simulation messages to be configured and saved.

This division is useful because ECU simulation involves more than repeatedly transmitting CAN frames. Address claiming establishes the simulated node’s network identity. Transport protocol support handles parameter groups whose payload exceeds the eight-byte capacity of a Classical CAN data frame.

When selecting a simulator, check these capabilities against your application. A tool that can transmit individual frames may be sufficient for a basic display test, while a more complete ECU simulation requires additional protocol behavior.

Building a Repeatable Test

Keep a record of each simulation configuration, including the transmitted values, message timing, source addresses, and expected results. A saved configuration becomes especially valuable when you need to repeat a test after changing software or replacing hardware.

It is also helpful to monitor the bus independently. Comparing the actual transmitted traffic with the receiving application’s output makes it easier to determine whether a problem originates in the simulation or in the device being tested.

Begin with a small, understandable setup, then add complexity as each function is verified. The objective is to create predictable conditions that reveal how your application behaves.

Diesel Truck Signal Simulation

In order to simulate some frequently used SAE J1939 signals, we have chosen the following parameters:

• Engine Speed

• Wheel Based Vehicle Speed

• Accelerator Pedal Position

• Engine Oil Pressure

• Engine Oil Temperature

• Engine Coolant Temperature

• Fuel Level

• Engine Fuel Rate

• Engine Fuel Economy

• Vehicle Position (GPS)

All of the above parameters are transmitted automatically using their corresponding frequencies. The following signals are available on request, a modus that is also supported by our simulator board.

• Engine Hours of Operation

• Vehicle Identification Number (VIN)

• Time/Date

• Vehicle Direction

The image below lists these parameters including their definition (PGN, SPN, frequency, etc.):

The following image demonstrates how these signals have been entered (and saved to a file) using the jCOM1939 Monitor Software:

All signals are transmitted into an SAE J1939 vehicle network and displayed on the screen in order of appearance.

What the Results Tell You

A successful bench test demonstrates that the application handles the simulated traffic as expected. Its value depends on how well that traffic represents the intended vehicle or machine.

Fixed values can verify decoding. Changing values can exercise display updates and application logic. Deliberately interrupted messages can test timeout handling. More coordinated scenarios can examine how the application responds when several operating conditions change together.

Final testing on the intended equipment remains necessary. Real networks introduce additional traffic, manufacturer-specific behavior, electrical conditions, and interactions between controllers. A simulator helps you resolve many basic problems before reaching that stage—and makes those problems easier to reproduce when they occur.

Over the years, I have received numerous inquiries about possible OBD-II applications. Some involve straightforward data logging, such as recording engine speed, coolant temperature, or vehicle speed. Others start with a considerably broader assumption: connecting a CAN Bus interface to the OBD-II socket will provide access to the vehicle’s internal communications and allow the user to control certain functions.

That assumption confuses a physical connector, a diagnostic communication standard, and the networks responsible for operating the vehicle. They are related, but understanding their different roles is essential before choosing hardware or writing software.

One symptom of this misunderstanding is surprisingly common: someone connects a CAN Bus interface to the diagnostic socket, starts monitoring, and sees no data. The immediate suspicion is that the interface or software is defective. However, a silent connection can be entirely consistent with the way diagnostic access works.

What OBD-II Provides

OBD-II, short for On-Board Diagnostics II, provides standardized access to emissions-related diagnostic information. Depending on what the vehicle supports, this includes current operating values, diagnostic trouble codes, freeze-frame data captured when a fault occurred, and the status of emissions monitoring tests.

Its value lies in standardization. A compatible scan tool can request an operating parameter without needing a separate definition of that parameter for every vehicle manufacturer. Engine speed, for example, has a standardized parameter identifier and a defined method for converting the returned bytes into RPM.

However, this standardized access has a defined scope. OBD-II does not provide a universal command set for operating windows, switching lights, controlling steering, or otherwise directing the vehicle’s normal functions.

It is also more accurate to describe OBD-II as a diagnostic system and interface than as a separate diagnostic network. On vehicles that use CAN for OBD-II communication, diagnostic messages travel over CAN. Earlier OBD-II implementations used other communication technologies. OBD-II and CAN are therefore not interchangeable terms.

Why Listening May Produce No Data

Conventional OBD-II readings follow a request-and-response model. The diagnostic tool asks for information, and an appropriate electronic control unit responds.

For example, a tool requesting engine speed sends a diagnostic request identifying the service and parameter it wants to read. The ECU returns a response containing the requested value, provided that the parameter is supported and the request can be processed.

A continuously updating RPM display usually results from repeated requests. The scan tool keeps asking for fresh readings and updates its display as responses arrive. Connecting the tool does not cause the vehicle to begin broadcasting every available OBD-II parameter automatically.

This matters when using a general-purpose CAN interface. An interface configured only to receive messages does not generate diagnostic requests. If no other tool is making those requests, there may be no OBD-II responses to observe.

Of course, an empty receive window alone does not establish the cause. Incorrect CAN settings, wiring problems, ignition state, and other configuration issues can also prevent communication. The important point is that diagnostic data should not be expected merely because a cable has been connected.

The Vehicle’s Normal CAN Traffic

During normal operation, vehicle controllers exchange messages to coordinate their work. An engine controller may transmit information used by the instrument cluster, transmission controller, or other modules. Depending on the function, messages may be sent periodically or in response to events.

Those messages serve a different purpose from standardized OBD-II requests and responses. Even when both contain engine speed, the CAN identifier, byte positions, scaling, and other details may differ.

Consequently, knowing the OBD-II parameter identifier for engine speed does not tell you where engine speed appears in the manufacturer’s ordinary CAN messages.

CAN defines how frames are communicated. It does not, by itself, define what each payload means. Interpreting the vehicle’s normal traffic generally requires manufacturer-specific information or reverse engineering.

A screen full of CAN frames is therefore not the same thing as a screen full of recognizable OBD-II parameters.

What the Diagnostic Socket Exposes

The diagnostic socket is an access point. Its presence does not guarantee unrestricted visibility into every network inside the vehicle.

Some vehicles expose ordinary CAN traffic at the connector. In that situation, a passive monitor may receive numerous messages without sending anything. Other vehicles provide diagnostic access through a gateway that controls communication between the external tool and internal networks. Ordinary operating traffic may not be forwarded to the diagnostic connection.

This explains why a monitoring setup can produce a busy receive window on one vehicle and remain silent on another.

Neither behavior changes the fundamental purpose of standardized OBD-II communication. The connector’s accessibility should not be mistaken for a guarantee that the vehicle’s internal networks are equally accessible.

Diagnostics Can Include Commands

Describing OBD-II as diagnostic access does require one qualification: diagnostics is not exclusively about reading information.

Standardized diagnostic services include actions such as clearing emissions-related diagnostic trouble codes and resetting associated diagnostic information. Manufacturer-specific diagnostic systems can go further, supporting actuator tests, service routines, configuration, and other workshop functions.

However, these capabilities should not be confused with a universal OBD-II vehicle control interface. A professional tool that activates a component during a service test may be using manufacturer-specific diagnostic commands, additional protocols, and authorization procedures.

The fact that such a tool uses the same physical socket does not mean its functions are available through ordinary standardized OBD-II parameter requests.

Why the Available Explanations Often Fall Short

Much of the introductory OBD-II material a newcomer encounters concentrates on trouble-code interpretation. Other resources provide parameter tables, conversion formulas, or software examples that produce a useful reading with a few lines of code.

Those resources can be helpful, but they often begin after an essential explanation has been skipped: how the diagnostic exchange actually works.

A table explaining a fault code does not explain who transmits the request. A list of parameter identifiers does not explain CAN addressing. A library function that returns RPM may conceal message construction, response handling, timing, and transport details.

The formal documentation exists. SAE J1979 and ISO 15031-5 describe diagnostic services for conventional emissions-related OBD communication, while other standards address the underlying communication and transport mechanisms. These documents serve as engineering specifications, however, rather than a guided introduction.

The educational gap is therefore not a complete absence of documentation. It is the difficulty of finding a clear explanation that connects the diagnostic connector, CAN communication, diagnostic requests, and returned data before moving on to code tables and programming examples.

Start with the Intended Application

For a project that records supported operating values, standardized OBD-II requests may be exactly the right approach. The application needs to determine which parameters the vehicle supports, request them at suitable intervals, and interpret the responses.

For a project intended to examine the vehicle’s normal CAN communications, the task is different. It requires determining which traffic is accessible and obtaining the information needed to decode it.

For a project intended to control vehicle functions, the requirements are different again. Neither a CAN interface nor an OBD-II cable supplies the necessary command definitions simply by being connected.

Before selecting a board or downloading a software library, establish which of these applications you are actually building. OBD-II offers useful standardized diagnostic access. Understanding the scope of that access is the first step toward making the application work.

BLCKTEC 460T OBD2 Scanner & Car Code Reader

The BLCKTEC 460T combines standard OBD-II diagnostics with vehicle-specific access to systems such as the engine, transmission, ABS, and airbags. It supports all 10 OBD-II modes, reads and clears diagnostic trouble codes, displays freeze-frame information, and checks emissions readiness. Users can view, graph, record, and replay live data, overlaying up to four data streams for comparison. Automatic vehicle identification and scanning simplify setup, while supported service functions include oil maintenance resets, ABS bleeding, electronic parking brake resets, steering angle sensor calibration, battery initialization, and throttle body relearn.

The scanner pairs with the subscription-free RepairSolutions2 app to provide scan reports, verified repair information, maintenance schedules, technical service bulletins, and recall details. It also includes free lifetime updates and U.S.-based support in English and Spanish. Intended for use in the United States and Canada, the 460T supports many OBD-II-compliant vehicles from 1996 onward, but system coverage and service functions vary by year, make, and model. Check BLCKTEC’s compatibility information before purchasing to confirm support for your vehicle and the specific functions you need. More information…

I regularly receive inquiries that begin with a question about one of our products and quickly develop into a description of a substantial business opportunity. The proposed market is large, the existing products are expensive, and inexpensive hardware apparently offers a way to compete at a much lower price.

Then comes the part where somebody needs to make it work.

Usually, that requires expertise the person making the proposal does not have. Sometimes there is no meaningful development budget. In other cases, financial resources may be available, but the technical work has not been sufficiently understood to estimate its cost. The opportunity is presented with considerable confidence; the development requirements remain much less specific.

A recent inquiry concerning marine electronics reminded me of a similar conversation several years ago about an Electronic Logging Device, or ELD. The markets were different, but the underlying argument was familiar: established products cost too much, the hardware could be purchased inexpensively, and a lower-priced alternative could capture a significant share of an attractive market.

It is a persuasive starting point. It is also an incomplete business case.

The Hardware Is Only the Beginning

The availability of inexpensive processors, interface boards, and communication modules has made sophisticated hardware accessible to small businesses and individual developers. That is a genuine advantage. Functions that once required substantial custom hardware development can often be demonstrated using readily available components.

But demonstrating a function is not the same as delivering a product.

The hardware still needs software that performs the required tasks reliably. It needs configuration, error handling, recovery procedures, testing, documentation, and a practical way to install updates. The finished system must also accommodate customers whose equipment and operating conditions differ from those used during development.

Lower hardware costs do not automatically reduce any of that work. A less expensive processor does not make a programming task take fewer hours.

One Product Can Require Several Development Efforts

The ELD proposal illustrates the issue. The envisioned product involved more than an onboard device. It also required a server-side system to receive, store, process, and present the information.

Those are distinct development responsibilities. The team working on the onboard equipment must address device operation, vehicle communication, data collection, and behavior when connections fail. The server-side team must address data handling, user access, application functions, and operation of the supporting service.

In a small organization, some people may contribute to both areas. Nevertheless, the work remains different and requires appropriate expertise. The two sides must also be integrated and tested together. Depending on the proposed product, mobile applications and other interfaces can add further development work.

Purchasing an inexpensive board does not provide those resources. Nor does a working prototype establish how much effort remains before the system can be sold and supported.

A Large Market Does Not Finance Development

Another recurring feature of these inquiries is the emphasis on potential sales. There may be hundreds of thousands of possible customers. Capturing even a small percentage would supposedly generate impressive revenue.

Perhaps it would. But a market estimate does not pay the people developing the product.

Engineering expenses begin before sales revenue arrives. Hardware must be purchased, software written, prototypes evaluated, and problems corrected. Applicable compliance requirements must be identified and addressed. Production, documentation, and customer support must be prepared.

Some expenses can be staged, and production can be organized in batches. Even so, somebody must provide the funding and accept the risk that sales will arrive later than expected—or fail to arrive at all.

A credible proposal needs to connect the market opportunity with a development budget, a realistic schedule, and a funded path to delivery. Without that connection, the revenue forecast is largely an expression of optimism.

Price Is Not the Same as Component Cost

It is easy to examine an established product, estimate the cost of its electronics, and conclude that the manufacturer is charging too much.

That comparison leaves out much of the business.

The selling price must recover development expenses and fund continuing software maintenance, technical support, warranty service, administration, and distribution. For a connected product, it may also need to support ongoing server infrastructure and operations. The company must then earn enough profit to remain viable and invest in the product’s future.

This does not mean every established product is reasonably priced or that a new competitor cannot improve the economics. It means a high selling price is not, by itself, evidence of greed. It may reflect the financial responsibility of maintaining a product and supporting the customers who depend on it.

A competitor promising the same functionality at a substantially lower price needs to explain which costs it can reduce and how. Pointing to cheaper hardware is rarely a sufficient answer.

Expertise Is Part of the Investment

For me, these inquiries also raise a practical question: who is expected to supply the missing technical knowledge?

An initial product question can gradually become a discussion of system architecture, development strategy, component selection, and project feasibility. Those subjects require professional judgment built through years of experience. They have value, even when the conversation takes place before a formal project exists.

I understand why an entrepreneur wants to explore an idea before committing money. But uncertainty about a business opportunity does not make the expert’s contribution cost-free. If technical guidance is necessary to establish whether the venture is viable, that guidance belongs in the project budget.

Inexpensive hardware can provide an excellent foundation for a new product. Turning it into a successful business requires funded development, capable people, realistic expectations, and a price that supports the responsibilities being accepted. Until those elements are accounted for, the inexpensive board is simply the least expensive part of the proposal.

Recently, I received a somewhat vague inquiry concerning Raspberry Pi-based marine electronics and our PiCAN-M interface board. No specific project was proposed, but the wording of the message suggested an interest in exploring a commercial opportunity. The accompanying YouTube video presented an inexpensive Raspberry Pi system as an alternative to costly marine electronics.

It was not the first time the idea had crossed my desk. At Copperhill Technologies, we had already considered offering a computer system with NMEA 2000 and NMEA 0183 connectivity. With the PiCAN-M board in our product line, it was a natural possibility to explore. We ultimately decided not to pursue it.

That decision was not a rejection of the technology. A Raspberry Pi running software such as OpenPlotter and Signal K can be a useful platform for collecting, displaying, and recording marine instrument data. It also provides opportunities for experimentation and specialized applications. For a technically inclined boat owner, putting such a system together can be an interesting and worthwhile project.

Selling it as a finished product is a different undertaking.

The video’s headline centers on a $209 computer. That is an attractive number, particularly when placed beside an invoice for several thousand dollars of commercial marine equipment. But buying two circuit boards does not give you a complete, installed, supported marine computer. Someone still has to provide the power supply, storage, cooling, cables, and mounting hardware. Someone has to assemble the system, install and configure the software, test it, and explain how to use it.

If the owner does that work, the investment is partly money but mostly personal time. If a business does it, that time becomes a cost that must be recovered through the selling price.

There is also the matter of what happens after the package arrives. Copperhill Technologies is a small business, and we would not have technicians traveling around the country to install computers aboard customers’ boats. Installation would fall to the owner or a local installer. Questions about power connections, network wiring, missing instrument readings, and software settings would nevertheless find their way back to us. Supplying the computer would only be the beginning of that responsibility.

I receive proposals from time to time that start with inexpensive hardware and end with predictions of substantial sales. I understand the appeal. There is a large market for marine electronics, and the prospect of giving boat owners a more affordable, flexible way to use their instrument data deserves consideration. But the size of the broader market does not tell me how many customers would buy a particular product, what they would pay, or how much support they would need.

As a business owner, those are the questions I have to answer. Copperhill Technologies serves several technical markets beyond marine electronics, and every new product competes for the same limited development time and support resources. A promising concept needs to become a sustainable product before it becomes a business opportunity.

Nevertheless, the inquiry did inspire me to revisit the subject. In the following sections, I will examine the video’s argument and then work through the costs of supplying the proposed system as a commercial product. The Raspberry Pi approach has real merits. Understanding them requires a more complete comparison than the price of the boards.

What the Video Gets Right—and What It Leaves Out

First, I appreciate that the video mentions Copperhill Technologies several times, identifying us as the manufacturer of the PiCAN-M board. It is welcome exposure for our business and the products we offer. However, that recognition does not prevent me from taking a critical look at the video’s technical claims and economic assumptions.

The video builds its argument around the consolidation of the marine electronics industry. It describes how familiar brands, including Raymarine, Simrad, B&G, Lowrance, and Navionics, became part of larger corporate portfolios. It then connects those acquisitions with equipment prices, chart subscriptions, and the difficulty of moving away from an established manufacturer’s ecosystem.

Its intended message is clear: boat owners have more alternatives than the major manufacturers would like them to believe.

To support that message, the video introduces a Raspberry Pi computer with a PiCAN-M interface board, running OpenPlotter, Signal K, and OpenCPN. This combination can connect to existing marine instruments, make supported data available to other applications, and provide chart viewing and navigation functions. Instrument readings can also be displayed on a cell phone connected to the boat’s local Wi-Fi network.

There is a useful idea here. Boat owners can gain more control over how they display, record, and process their instrument data. Open-source software also gives developers opportunities to create functions beyond those supplied by an equipment manufacturer. Those are legitimate advantages, and they deserve an informed discussion.

Unfortunately, the video wraps that discussion in a much broader claim about corporate ownership, excessive margins, and an inexpensive route to independence. Its financial figures and technical descriptions create an impression of thorough research, but several of the conclusions go beyond what the information actually establishes.

AI Production Does Not Replace Technical Understanding

YouTube identifies the video as containing altered or AI-generated sound or visuals. That disclosure alone does not establish how the script was researched or written. However, the presentation illustrates a familiar weakness of AI-generated material: assembling plausible facts into a confident narrative without adequately examining the connections between them.

The visual presentation raises further concerns. Several computer screens and product images do not accurately represent the equipment or software being discussed. These appear to be AI-generated illustrations, although their origin cannot be established from appearance alone. In a technical presentation, such images can mislead viewers about what the proposed system actually looks like and how it operates. They reinforce the impression that the finished video was not adequately reviewed by someone familiar with the technology.

A list of references does not resolve that problem. A source may support an acquisition price, a product specification, or a revenue figure without supporting the conclusion drawn from it. Several important claims in the video are insufficiently substantiated, particularly where it moves from those individual facts to assumptions about technical equivalence, customer dependence, and business economics.

For example, the video repeatedly points to the substantial revenues of major marine electronics manufacturers. Those figures demonstrate the size of the businesses being discussed. They do not establish the potential sales volume for a Raspberry Pi-based marine computer. Revenue from a broad portfolio of chartplotters, radar, sonar, instruments, and other products cannot simply be treated as an available market for a small open-source data hub.

There may be a worthwhile market for such a product. The video does not establish its size.

The Technical Comparison Is Incomplete

The most obvious problem is the comparison between the proposed $209 computer and the expensive collection of equipment presented at the beginning.

A Raspberry Pi and PiCAN-M board do not replace every function represented by that invoice. They do not become a radar system merely because they can display instrument data. They do not include a marine display, and they still depend on sensors and other equipment to produce the information they process.

To its credit, the video acknowledges some of these limitations. It recommends retaining a commercial chartplotter at the helm and keeping the Raspberry Pi system in a protected location. That is an important qualification, but it also weakens the dramatic price comparison. If the owner retains the primary navigation equipment, the Pi is an additional system whose value must be assessed against the additional functions it provides.

The power arrangement also receives too little attention. The video presents the PiCAN-M’s onboard supply as a straightforward way to power both boards from the NMEA 2000 backbone. A Pi 5 installation requires a more careful assessment of the supply capacity, peripheral load, wiring, and available network power. For the commercial configuration considered here, I would use an independent power supply rather than assume that an existing instrument network can reliably carry the additional load.

Likewise, installing Signal K does not guarantee that every connected device and every proprietary function will become available. The required messages must be supported, connections must be configured, and the results must be checked. Displaying an existing reading through an available dashboard is one task. Developing a new application or supporting an unusual device is another.

The flexibility is real. So is the work required to use it.

The Economic Comparison Leaves Out the Work

The video’s central price covers two major components. It leaves out much of what turns those components into a usable product.

Storage, power conversion, cooling, an enclosure, cables, protection, and mounting provisions all cost money. Assembly, software configuration, and testing require time. A system installed aboard a boat must then be checked against that boat’s particular equipment and network.

A technically capable owner may perform those tasks personally. That can make the project economical, especially if the owner enjoys the work. But unpaid personal effort cannot be carried into a commercial cost calculation as though it does not exist.

A supplier must also prepare installation instructions, connection diagrams, troubleshooting guidance, and recovery procedures. After the sale, someone must answer questions when the phone cannot connect, an expected engine reading is missing, or the computer restarts intermittently. The cause may be the supplied product, the boat’s wiring, another instrument, or a configuration setting. Determining which one is responsible is itself technical work.

The video also uses gross margin as evidence of how much money manufacturers retain from their products. Gross margin is not net profit. The remaining revenue must fund engineering, software maintenance, support, administration, and other operating expenses. Its example of money spent at a dealer also overlooks the distinction between the dealer’s retail revenue and the manufacturer’s revenue.

None of this means that commercial marine equipment is always reasonably priced. It means that the video has not made a complete economic comparison.

My objection is therefore not to the Raspberry Pi approach. It is to the suggestion that inexpensive components demonstrate an inexpensive finished solution—or an obvious opportunity for a supplier to make money. Establishing either claim requires accounting for the work between purchasing the boards and delivering a system that a customer can install, operate, and obtain support for.

From a DIY Project to a Commercial Product

A Raspberry Pi-based marine computer is an attractive proposition in terms of both price and functionality. Combined with a PiCAN-M board and suitable open-source software, it provides a flexible platform for displaying instrument data, recording information, and running navigation applications. For a boat owner who is willing and technically capable of assembling, configuring, and installing the system, it is an entirely valid choice.

The economics change when a business offers that same system as a finished product. The customer is then paying for more than the components. They are buying an assembled, configured, and tested computer, together with documentation, technical assistance, and the expectation that somebody will take responsibility when it does not work as expected.

For our estimate, the hardware would include the Raspberry Pi 5, PiCAN-M board, PiCAN-M enclosure, microSD card, independent power supply, cooling, and the necessary connections. However, that does not include the larger expenses associated with supplying and supporting the finished system.

Those expenses include:

• Assembly, software installation, configuration, and testing.

• Online documentation, installation instructions, and troubleshooting guidance.

• Technical support before, during, and after installation.

• Customer service, order processing, and payment fees.

• Packaging, shipping materials, and outbound shipping.

• Applicable import duties, customs charges, and tariffs.

• Warranty service, returns, and replacement units.

• Ongoing software maintenance and compatibility testing.

Some of these costs occur with every unit. Others must be spread across an uncertain number of sales. Documentation, for example, requires substantial effort before the first shipment and continued attention as software and supported hardware change. Technical support is even harder to predict: one customer may need little assistance, while another may require hours of troubleshooting.

Taking these responsibilities into account, our preliminary estimate is a selling price of roughly $1,100 to $1,250 per unit. This is a planning estimate rather than a quotation, but it reflects the difference between purchasing inexpensive components and operating a business that supplies a supported product. The margin must cover the expenses beyond assembly and leave enough profit to make the undertaking worthwhile.

Even at that price, the system would still require installation aboard the boat. We would not have personnel traveling around the country to perform that work. The customer would have to install it personally or hire a local technician, adding either their own time or another invoice to the total investment.

Installation would also generate support requests. A missing instrument reading might result from software settings, unsupported messages, wiring, or another device on the network. From the customer’s perspective, however, the new computer is not doing what they expected. Helping establish the cause becomes part of the supplier’s workload, even when the supplied hardware is functioning correctly.

At this point, the comparison with professional marine equipment becomes much closer than the video’s $209 figure suggests. The Raspberry Pi system may still offer valuable flexibility, particularly for specialized applications, but its commercial appeal must stand on those capabilities and the complete delivered price.

That is why I distinguish between recommending the technology and deciding to manufacture a finished system around it. A capable owner can build something useful and economical by contributing their own time and knowledge. A supplier must charge for that work and accept continuing responsibility for the product.

Final Thoughts

I receive similar inquiries regularly, often accompanied by predictions of substantial future business. This particular inquiry prompted me to revisit an idea we had already considered: offering a Raspberry Pi-based marine computer as a finished commercial product. The technology remains attractive. The business case requires considerably more than inexpensive hardware and an encouraging estimate of market size.

For illustration, suppose there were 100,000 potential installations and we could convert 1% into sales. Those are hypothetical assumptions, not a market forecast. At approximately $1,200 per unit, the resulting 1,000 orders would generate $1.2 million in revenue. That sounds promising, but it says little about the investment required or the profit remaining. Our estimated selling price allows for the costs of supplying and supporting each unit; it does not establish the upfront funding needed to purchase inventory, develop documentation, and arrange sufficient personnel and production capacity. Manufacturing in batches would reduce the initial commitment, but somebody would still have to finance those batches.

The sales timeline matters just as much. Selling 1,000 units in one year creates a very different business from selling them over five years, while support and operating expenses continue throughout. Before committing, I would need credible evidence of demand at the actual selling price, a realistic sales schedule, and a return that justifies the money and time invested. A Raspberry Pi marine computer can be an excellent project for a capable boat owner. Turning it into a supported commercial product is a separate undertaking—and the inexpensive boards do not make that undertaking inexpensive.

A Raspberry Pi equipped with a PiCAN2 CAN Bus interface provides a useful platform for exploring vehicle diagnostics and recording CAN traffic. However, connecting the hardware to a vehicle’s OBD-II port is only the beginning. Successful data logging requires an understanding of the electrical connection, the CAN configuration, and the diagnostic messages exchanged with the vehicle.

Over the years, I have received numerous questions from users attempting this project. Many difficulties arise from the same assumption: once the interface is connected, recognizable engine data should appear automatically. In practice, capturing CAN frames and obtaining meaningful OBD-II measurements are two different tasks.

CAN Bus and OBD-II Serve Different Purposes

CAN Bus provides the communication mechanism that allows electronic control units to exchange messages. OBD-II defines diagnostic services through which a tester can request information such as engine speed, coolant temperature, diagnostic trouble codes, and emissions-related operating conditions.

The distinction matters because a CAN interface receives frames containing identifiers and data bytes. It does not automatically recognize those bytes as engine speed, vehicle speed, or temperature. Software must interpret the messages according to the applicable protocol.

Furthermore, an OBD-II connector does not guarantee that the vehicle uses CAN for diagnostics. Older vehicles may use other OBD-II communication protocols that the PiCAN2 cannot access directly. Before selecting hardware or configuring software, establish which diagnostic protocol the vehicle supports.

Passive Monitoring Versus Diagnostic Requests

There are two approaches to collecting data through a vehicle’s diagnostic connector.

Passive monitoring records traffic already present on the accessible CAN network. This approach can reveal message identifiers, transmission intervals, and changing data values. However, much of that traffic may use manufacturer-specific formats. Without documentation, a recording can contain thousands of frames while providing little immediately useful information.

OBD-II data acquisition usually involves an active exchange. The diagnostic application sends a request, and one or more control units return a response. For example, an application can request engine speed using the appropriate diagnostic service and parameter identifier, commonly called a PID.

Consequently, a logger that only listens cannot assume that standardized OBD-II measurements will appear continuously. Some vehicles expose considerable traffic at the diagnostic connector; others provide access through a gateway that limits what is visible until a diagnostic request is received.

Sending supported diagnostic requests is part of normal OBD-II operation. Nevertheless, arbitrary CAN transmissions should be avoided. A diagnostic data logger should send only the messages required for its intended function, with a controlled request rate.

Choosing and Powering the Hardware

The Raspberry Pi runs the logging application, while the PiCAN2 provides the CAN controller and transceiver needed to communicate with the network.

If the system will receive power from the vehicle, the PiCAN2 version with an onboard switch-mode power supply offers a convenient arrangement. It converts the vehicle supply to the voltage required by the Raspberry Pi, provided the installation remains within the board’s electrical ratings and available power budget.

The power arrangement deserves attention beyond simply getting the Raspberry Pi to boot. The OBD-II power connection may remain energized after the ignition is switched off. A logger left connected can therefore continue drawing current from the battery.

A permanent installation should account for standby consumption, vehicle electrical conditions, and orderly shutdown. Repeatedly removing power while the Raspberry Pi is writing data can damage files or corrupt its storage.

Connecting to the Diagnostic Port

For CAN-based OBD-II communication, the principal connector assignments are:

These assignments do not replace the wiring instructions for the interface board and cable. Check the connector orientation carefully, and follow the manufacturer’s guidance for power and ground connections.

The PiCAN2 can be connected through its DB9 connector or screw terminal.

When using an OBD-II-to-DB9 cable, verify that its wiring matches the PiCAN2 connector configuration. A DB9 connector does not establish a universal CAN pinout. The PiCAN2 solder jumpers must also be configured appropriately for the chosen cable.

An open-ended OBD-II cable offers another option, but every connection must be identified before wiring it to the terminal. Wire colors vary between cable manufacturers and should never be treated as a standard.

Leave the Vehicle’s Termination Intact

A properly installed vehicle CAN network already has its termination resistors. Connecting a diagnostic interface generally does not require an additional resistor.

The PiCAN2 termination resistor should therefore normally remain disabled when connecting to an existing vehicle network. Adding another termination resistor changes the electrical load and can interfere with communication.

This differs from a small bench network, where the developer must provide suitable termination at both physical ends of the bus.

Configuring the Raspberry Pi

The PiCAN2 uses an MCP2515 CAN controller connected to the Raspberry Pi through SPI. Linux accesses the controller through SocketCAN, which presents the CAN channel as a network interface, typically named can0.

Configuration involves enabling SPI and loading the appropriate device-tree overlay. The controller’s oscillator frequency and interrupt assignment must match the actual board.

Use the PiCAN2 documentation together with the instructions for the installed Raspberry Pi OS version. Older tutorials may refer to configuration file locations or overlay entries that differ from those used by newer releases. There is no benefit in copying an old configuration without checking whether it applies to the hardware and operating system.

Once the controller is recognized, the CAN interface must be configured with the correct bit rate. A rate of 500 kbit/s is common for CAN-based OBD-II, but it should not be assumed for every application.

For initial passive monitoring, listen-only mode is useful because it prevents the interface from transmitting onto the network. Active diagnostic requests require normal operating mode.

Recording Frames Is Only the First Step

Utilities such as candump, supplied with Linux CAN utilities, can display and record received frames. They are valuable for confirming that the interface works and for capturing timestamped traffic for later analysis.

However, candump does not automatically turn a raw CAN recording into an OBD-II report. Obtaining useful measurements requires software that generates diagnostic requests, identifies responses, and applies the correct decoding rules.

For example, standardized OBD-II engine speed is calculated from two response bytes:

Engine speed in rpm = (256 × A + B) / 4

The application must first identify a valid response to the engine-speed request before applying that formula. It must also handle unsupported parameters, response timeouts, and potentially responses from multiple control units. Longer diagnostic messages may require ISO-TP transport handling.

For a practical logger, decoded measurements should be saved with timestamps, parameter names, units, and an indication of missing or invalid responses.

Troubleshooting in a Logical Order

If no data appears, check the system one layer at a time:

1. Confirm that the vehicle supports CAN-based OBD-II.

2. Verify the cable wiring, board jumpers, and ground connection.

3. Check that the PiCAN2 termination resistor is disabled.

4. Confirm that Linux recognizes the CAN controller.

5. Verify the oscillator configuration and CAN bit rate.

6. Check whether the vehicle must be awake or the ignition switched on.

7. Establish whether passive traffic is available or diagnostic requests are required.

8. Confirm that the requested OBD-II parameters are supported.

A quiet diagnostic connector does not necessarily indicate defective hardware. The vehicle may be asleep, a gateway may restrict access, or the desired information may only be transmitted in response to a request.

A Raspberry Pi and PiCAN2 make a flexible platform for learning these distinctions. Start by establishing a reliable connection, then capture traffic, introduce supported diagnostic requests, and finally build the decoding and storage functions that turn individual responses into a useful vehicle data log.

As a starting point for the OBD2 section of this blog, I will introduce and recommend literature that can help readers build a foundation before I explore individual topics in greater detail. Understanding vehicle diagnostics involves more than connecting a scan tool and looking up a trouble code. It requires some knowledge of engine operation, the purpose of individual sensors, and how the engine control unit interprets their signals.

One book worth considering is Engine Sensors & OBD-II Codes Explained by Madhurjya Dutta, founder of OBDCode.org. According to its description, the book combines explanations of common engine sensors with diagnostic trouble codes, symptoms, testing procedures, live data patterns, and troubleshooting flowcharts. Its emphasis is on identifying the cause of a problem before deciding which component, if any, needs replacement.

Moving Beyond the Trouble Code

An OBD-II trouble code provides a starting point for diagnosis. It identifies a condition detected by a vehicle’s monitoring system, but it does not necessarily identify a defective part. A code associated with an oxygen sensor, for example, may require investigation of wiring, intake or exhaust leaks, fuel delivery, or other operating conditions before replacing the sensor.

The book’s stated focus on diagnostic reasoning makes it relevant to readers who want to move beyond simply reading and clearing codes. Its description includes mass airflow (MAF), manifold absolute pressure (MAP), oxygen (O₂), throttle position (TPS), and engine coolant temperature (ECT) sensors, along with fuel, timing, and evaporative emissions topics. Understanding what these sensors measure is an essential step toward interpreting the information reported by a scan tool.

Live Data and Basic Testing

Another topic highlighted in the description is live data, including fuel trims. Trouble codes record detected faults, while live data provides a view of what the control system is reporting during operation. Observing how readings change at idle, as the engine warms up, or under load can help narrow the investigation.

The advertised coverage also includes multimeter basics, sensor testing procedures, and symptom guides for conditions such as rough idle, misfires, and vacuum leaks. These subjects connect the electronic information available through OBD-II with checks performed on the vehicle itself. However, the appropriate test method depends on the sensor and vehicle; a multimeter is useful for many basic checks, but some investigations require additional equipment and manufacturer service information.

A Starting Point for Further Learning

Based on the publisher’s description, this book appears worth considering as an introductory resource for readers interested in practical engine diagnostics. This is an introduction to its advertised scope, rather than a review based on a complete reading of the book. Claims about repair savings or professional-level results should be treated as promotional statements rather than guaranteed outcomes.

In future posts, I will examine OBD2 concepts in more detail, including the distinction between a trouble code and a diagnosis, the interpretation of live data, and the communication between a diagnostic tool and the vehicle. Introducing relevant literature first gives readers an opportunity to establish some background and follow those discussions with a clearer understanding of the terminology.

More information…

After writing my previous post comparing CAN Bus and LIN Bus, I became curious about a practical question: If LIN connects sensors, switches, and actuators throughout a vehicle, could I connect my own hardware and interact with those devices? My background in CAN Bus and SAE J1939 made the idea particularly interesting. Reading sensor values, adding a custom control, or operating an existing actuator all sound like worthwhile projects. However, LIN’s inexpensive hardware and relatively simple communication protocol do not automatically make an existing vehicle network easy to modify.

Connecting Is Only the Beginning

Tapping into a LIN network can mean several different things. It might involve passively recording messages, interpreting sensor readings, simulating a missing device, or actively changing how a subsystem operates. These activities have very different requirements.

Observing communication is generally the least intrusive starting point. A suitable interface can receive traffic without deliberately transmitting onto the bus. Active participation requires a much deeper understanding of the network, because your hardware must transmit the correct information at the correct time.

Before either activity, you need to identify the actual LIN connection. A device’s function alone does not reveal its interface. A motor might connect directly to a controller, while that controller communicates over LIN or CAN. Likewise, a nearby LIN wire may belong to a different group of devices than the one you want to investigate.

The Appeal: Inexpensive Hardware and Useful Access

LIN offers an attractive starting point for embedded development. A microcontroller with a suitable UART or LIN peripheral, together with a LIN transceiver, can provide the basic communication hardware. An ordinary USB-to-serial adapter alone is insufficient because its electrical interface does not match the automotive LIN bus.

The potential applications extend well beyond operating a particular actuator. A developer might investigate a switch panel, record temperature sensor readings, study a climate-control subsystem, or build a test fixture for a removed automotive component.

This access can be especially useful on the workbench. Instead of installing an entire vehicle subsystem, a developer can provide power and emulate the communication needed by an individual device. Once its requirements are understood, that arrangement can support troubleshooting, demonstrations, and component testing.

The First Obstacle: Understanding the Messages

LIN defines how information travels, but it does not provide a universal command set for every connected device.

A frame identifier and several data bytes do not explain themselves. Those bytes might represent a requested position, a measured temperature, switch states, operating modes, or several signals packed together. Their meaning depends on the particular application.

The most useful starting point is the correct LIN Description File, commonly called an LDF. It describes the network’s frames, signals, publishers, subscribers, and schedules. Even with that file, additional application documentation may be needed to understand operating conditions or device behavior.

Without documentation, investigation becomes a process of observation and comparison. You record traffic while changing one known input at a time, then look for corresponding changes in the messages. This can reveal useful relationships, but a changing byte is only a clue. It may be a command, feedback, a counter, or an unrelated value.

The Second Obstacle: LIN Has a Commander

LIN communication follows a schedule managed by one commander, traditionally called the master. The commander transmits a frame header, and the designated publisher provides the response. Depending on the frame, the publisher may be the commander itself or another node.

That structure matters when adding custom hardware. You cannot assume that a newly connected device may transmit whenever it has something to say. The existing network already assigns responsibility for each frame.

If your controller sends headers while the original commander is operating, their transmissions can overlap. If it supplies a response already assigned to another device, both may transmit simultaneously. LIN does not use CAN’s priority-based arbitration to resolve that competition.

Consequently, understanding a command is only part of the task. You must also determine how your hardware can transmit it without conflicting with the existing participants.

Listening, Replacing, and Modifying

There are three broadly useful approaches, each with its own advantages and limitations.

Passive monitoring is a sensible first step because it establishes what the original system actually does.

Standalone operation provides greater freedom. With the original commander disconnected, your controller can manage the schedule. However, some components may expect initialization, configuration, or repeated communication before they operate.

An inline gateway offers more flexibility within an existing installation, but it is substantially more demanding. It creates separate electrical segments and must fulfill the appropriate communication role on each side. It must also preserve the behavior that the original controllers expect.

Why Replaying a Captured Message May Fail

Capturing a message during a particular action can make replay seem like an obvious next step. Sometimes it works, especially in a simple bench setup. In other cases, the captured message is only one part of a larger exchange.

A device may require a wake-up sequence, an operating-mode command, or periodic updates. The message you recorded might report an action rather than request it. Some applications also include counters or additional validity checks.

Even a valid command may have only a temporary effect if the original controller sends a different value during the next scheduled cycle.

Successful control therefore requires an understanding of the device’s ongoing conversation, including what happens before, during, and after the desired action.

Electrical Simplicity Still Requires Care

LIN’s single communication wire simplifies the network, but that wire is part of an automotive electrical system. A suitable transceiver provides the interface between the bus and the microcontroller’s logic signals. Power, grounding, and protection remain part of the design.

The interface’s operating mode also matters. Equipment intended only to observe traffic should not accidentally transmit, wake sleeping devices, or apply an inappropriate commander pull-up arrangement.

Sleep behavior deserves particular attention in an installed vehicle. A custom device that repeatedly wakes a LIN branch—or prevents it from sleeping—can keep other electronics active and increase battery consumption.

These issues are manageable, but they illustrate why a successful bench experiment is only one step toward a dependable vehicle installation.

Where the Effort Pays Off

Tapping into LIN is particularly rewarding when the objective is specific and the relevant documentation is available. Recording a known signal, testing a documented actuator, or emulating a defined node can be a practical embedded project.

The effort increases considerably when both the message definitions and the operating sequence are unknown. At that point, much of the work involves discovering the manufacturer’s application behavior rather than implementing LIN itself.

That distinction is the most useful lesson from my curiosity. LIN makes inexpensive automotive networking possible, and it offers interesting opportunities for independent development. Accessing an existing network, however, requires more than an electrical connection. The useful information lies in the messages, the schedule, and the behavior of the devices exchanging them.

My work has long focused on CAN Bus and SAE J1939, but I was curious to learn more about LIN Bus and the reasons behind its development. Why did the automotive industry need another communication network when CAN was already well established? Exploring that question led me to LIN’s simpler design, lower cost, and role in connecting devices that do not require CAN’s capabilities. This post reflects what I learned and explains how these two technologies complement each other.

CAN and LIN: Different Roles in Automotive Networks

CAN Bus and LIN bus frequently appear together in automotive electronics, but they serve different requirements. CAN provides communication between electronic control units that need reliable message exchange, priority handling, and relatively high data rates. LIN provides an economical way to connect simpler devices whose communication needs are much more modest.

LIN was developed specifically for automotive applications, where adding a full CAN interface to every small sensor, switch, or actuator could introduce unnecessary expense. CAN also originated in the automotive industry, but its use expanded into industrial automation, medical equipment, marine electronics, and many other areas. The distinction is therefore one of design priorities and application scope: LIN was created for inexpensive local automotive networks, while CAN became a broadly adopted communication technology.

Why LIN Was Created

Consider the communication requirements of an electrically adjustable mirror. Its controller may need to receive a position command and report a few status values. A ventilation flap actuator has similarly limited needs: move to a requested position and indicate whether that position has been reached.

These functions do not require large amounts of data or particularly high communication speeds. Nevertheless, connecting each device through CAN requires a CAN controller, a suitable transceiver, and the associated wiring and software.

LIN, short for Local Interconnect Network, was developed to address this situation. It provides a standardized, low-cost network for devices that do not need CAN’s capabilities. Its intended role was to complement CAN within the vehicle, allowing manufacturers to select a communication system appropriate to each subsystem. Typical applications include mirrors, seats, door electronics, and climate-control actuators.

How LIN Keeps Costs Down

LIN’s cost advantage comes from several design decisions working together.

First, LIN uses one communication wire referenced to ground. Conventional high-speed CAN uses two communication wires, CAN_H and CAN_L, with differential signaling. LIN can therefore reduce communication wiring and connector requirements. The single-wire description applies to the communication connection; LIN devices still need power and ground.

Second, LIN communication can be implemented using a microcontroller’s UART, supported by suitable software or dedicated LIN features. A LIN transceiver is still required to connect the microcontroller to the physical bus. This allows inexpensive microcontrollers to serve as network nodes without requiring a CAN controller.

Third, responding LIN nodes can synchronize their communication timing from the header transmitted by the controlling node. Suitable implementations can consequently avoid a separate precision crystal or ceramic resonator at each responding node. Across the many small devices installed in a vehicle, these component savings become significant.

Different Ways of Sharing the Bus

CAN and LIN also differ in how they decide when a device may transmit.

CAN uses message-based arbitration. Multiple nodes can attempt to transmit when the bus becomes available. If transmissions begin simultaneously, the arbitration process determines which message continues according to its identifier. The other nodes wait and try again without corrupting the winning message.

LIN uses one commander node, traditionally called the master, to organize communication. It transmits message headers according to a schedule, and the designated publisher supplies the response. Depending on the frame, that publisher may be the commander itself or another node.

This arrangement removes the need for CAN-style arbitration and makes routine communication predictable. It also means that the schedule must provide suitable opportunities for commands and status updates. A device’s response time depends partly on when its information is scheduled for transmission.

Speed and Data Capacity

LIN supports communication rates up to 20 kbit/s. That is modest, but entirely adequate for many switches, sensors, and small actuators. A ventilation flap does not need a high-speed network to receive an occasional position command.

Classical CAN supports bit rates up to 1 Mbit/s, subject to network length and physical design. CAN FD increases available throughput by permitting a faster data phase and expands the maximum data payload from eight bytes to 64 bytes per frame. These capabilities make CAN more suitable when numerous devices must exchange information frequently or transfer larger amounts of data.

The additional capacity carries additional implementation requirements. Where only a few bytes need to move at modest intervals, LIN’s lower performance can be an appropriate engineering choice.

CAN and LIN at a Glance

The CAN wiring comparison refers to conventional high-speed CAN; other CAN physical-layer variants exist.

How They Work Together

A vehicle can use CAN to connect its main control units while using LIN for smaller groups of local devices. A control unit equipped with both interfaces acts as the connection between the two networks. Texas Instruments describes this use of LIN as a sub-bus for CAN as a common application.

For example, a climate-control unit could receive information over CAN and control several ventilation flap actuators over LIN. The climate-control unit translates the required actions into scheduled LIN messages and collects status information from the actuators.

The two buses remain electrically and logically separate. Connecting them requires a controller that understands both interfaces and implements the necessary application behavior. A LIN transceiver alone cannot convert LIN messages into CAN messages.

Automotive Origins, Different Reach

Both technologies have automotive roots, but their subsequent roles differ. CAN developed into a communication foundation for many industries, supported by higher-layer protocols that define how devices exchange application data. Its adoption extends well beyond passenger vehicles.

LIN remains closely associated with the automotive requirement that motivated its creation: connecting numerous inexpensive devices without giving every device a more capable network interface than it needs. Its use is not technically restricted to vehicles, but automotive subsystems remain its principal application area.

Choosing between CAN and LIN therefore starts with the application’s communication requirements. CAN offers greater capacity and flexibility. LIN offers an economical solution for simple, scheduled communication. Within a vehicle, combining them allows each function to use the network best suited to its needs.

For more technical background information see Introduction to the Local Interconnect Network (LIN) Bus.

Automotive electronics often combine several communication networks, each serving a particular purpose. CAN connects electronic control units, while LIN provides an economical way to communicate with simpler devices such as sensors and actuators.

For developers working across these networks, the Teensy 4.0 Dual LIN and CAN FD Board brings two LIN channels and a CAN interface onto one compact platform. With the Teensy 4.0 included and installed, the board provides a foundation for custom firmware, bench experiments, and automotive network development.

Where LIN Fits

LIN, short for Local Interconnect Network, is a single-wire serial communication system operating at speeds up to 20 kbit/s. It is widely used for automotive functions where modest data rates and low implementation costs are appropriate. Climate-control flap motors are one example; other applications involve switches, sensors, and small actuators.

A LIN network uses a commander, traditionally called the master, to schedule communication with responder devices. This predictable communication pattern makes LIN useful for recurring control commands and status updates.

Why Two LIN Ports Matter

The board’s two LIN ports are particularly useful when a project involves two separate LIN networks. Each channel provides a connection to its own bus, allowing developers to work with both networks from one microcontroller.

Consider a bench setup with a climate-control actuator on one LIN network and a lighting module on another. With suitable firmware, the Teensy can schedule communication on each channel, issue commands, and collect responses. Both devices can participate in the same experiment while retaining separate bus wiring and communication schedules.

That arrangement offers several practical advantages:

• Separate communication schedules: Each LIN network can follow the timing required by its connected devices.

• More capacity across two buses: Traffic can be distributed between networks. Each bus retains LIN’s speed limit, but the devices do not all compete for one bus schedule.

• Easier comparison testing: Developers can connect two devices or configurations to separate channels and compare their behavior under similar test conditions.

• More flexible prototypes: One controller can coordinate two LIN subsystems, reducing the need for a second development board.

Separate LIN channels also make it possible to experiment with different bus configurations without repeatedly rewiring a single interface. The channels are separate communication interfaces; this does not imply galvanic isolation.

Applications: From Device Testing to Gateway Development

One useful application is a programmable LIN test fixture. With the appropriate message definitions and firmware, developers can send commands to a LIN device, read its responses, and repeat a test sequence. Two channels allow a fixture to exercise two separate LIN networks during the same test.

Another application is a CAN-to-LIN gateway prototype. For example, firmware could receive a command over CAN, translate it into a LIN transaction, and return the resulting status over CAN. With two LIN ports, that prototype could address devices on two different LIN branches.

This translation requires application software. CAN and LIN use different communication methods and message structures, so the board provides the hardware foundation while the firmware defines scheduling, signal mapping, and error handling.

The same platform can support educational projects that demonstrate how a central controller coordinates multiple networks. Developers can explore the relationship between CAN commands, LIN schedules, and device responses in a manageable bench setup.

Teensy 4.0 Provides the Processing Platform

Teensy is a family of compact, USB-programmable microcontroller development boards. The Teensy 4.0 uses a 600 MHz Arm Cortex-M7 processor and supports development through the Arduino IDE with Teensy software support. Its processing capability leaves room for application logic alongside network communication, such as evaluating responses, managing test sequences, or preparing data for a host computer.

The interface board adds two Microchip MCP2004A LIN transceivers and support for Classical CAN or CAN FD. It also includes a 120 Ω CAN termination resistor, an onboard 5 V regulator accepting a 7–12 V DC input, reverse supply voltage protection, and ESD protection.

For engineers, educators, and embedded developers, the main attraction is the combination: two LIN networks, a CAN interface, and one programmable controller. It creates a practical starting point for testing individual devices and exploring how multiple automotive subsystems work together.

View the Teensy 4.0 Dual LIN and CAN FD Board at Copperhill Technologies for product details.

CAN Bus error injection is used to test how a network or an individual device responds when communication is disrupted. The available tools range from simple boards with switches and adjustable resistors to sophisticated hardware and software systems that introduce precisely timed disturbances during a CAN message.

The distinction matters because “error injection” covers several different activities. A board that simulates a broken wire does not necessarily generate a CRC error at a selected bit position. Likewise, a tool that alters a CAN frame does not necessarily reproduce the voltage characteristics of a failing transceiver.

The following survey identifies representative commercial options and their capabilities. It is not an exhaustive list of every manufacturer or product.

Read more

View the complete Table of Contents →

This post was inspired by a customer inquiry about simulating CAN Bus faults and capturing them with an oscilloscope. The customer wanted to create a collection of reference waveforms for troubleshooting networks in the field.

I was familiar with CAN Bus error detection, but deliberately simulating physical faults was not a topic I knew well enough to offer a detailed answer. The question made me curious, so I started researching the available methods and equipment.

As I discovered, some faults can be introduced with a relatively simple test setup, while others require specialized hardware. In this post, I will explain why error simulation can be useful and explore some of the ways to put a CAN network to the test.

For a market survey, see my post CAN Bus Error Injection: Available Hardware and Software.

Understanding CAN Bus Error Simulation

A CAN Bus network is designed to detect communication errors and recover from many of them automatically. But how can you be sure that your application responds correctly when something goes wrong?

One way is to deliberately introduce faults into a controlled test network and observe the results. CAN Bus error simulation helps developers, technicians, and engineers understand what failures look like, how CAN controllers respond, and whether an application can recover when normal communication returns.

Error simulation can range from a simple wiring change to sophisticated equipment that disturbs individual bits in a CAN message. The right approach depends on the fault you want to reproduce and what you want to learn from it.

Who Benefits from CAN Bus Error Simulation?

CAN Bus error simulation is useful both for evaluating an entire network and for developing an individual node. From a network perspective, it can reveal how wiring faults, incorrect termination, electrical interference, or a faulty transceiver affect communication. For a node under development, the focus is on how that device responds to such conditions: whether it detects and reports errors, how it behaves if it enters the bus-off state, and whether it recovers when the fault is removed. In either case, the node is tested as part of a network so its interaction with other devices can be observed.

The extent of CAN Bus error simulation depends on the requirements of the application. A simple educational project may need only basic communication tests, while applications that demand high reliability—such as vehicles, medical equipment, industrial machinery, and robotics—benefit from more extensive fault testing. In these systems, developers need to understand how a device or network responds to communication failures and whether it can recover or enter a safe state.

Read more

Table of contents…

The Thomson user manual assumes that the reader is familiar with the SAE J1939 standard. Terminology from the standard is used, but not described in detail.

As I mentioned in the introduction, you don’t need to implement an SAE J1939 protocol stack to control the actuator. Mere CAN Bus communication will do. Nevertheless, a basic knowledge of both will help to better understand the terminology used in the manual.

Controller Area Network

Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is a network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.

CAN is a two-wire, half duplex, high-speed network system, that is far superior to conventional serial technologies such as RS232 regarding functionality and reliability and yet CAN implementations are more cost effective.

While, for instance, TCP/IP is designed for the transport of large data amounts, CAN is designed for real-time requirements and with its 1 MBit/sec baud rate can easily beat a 100 MBit/sec TCP/IP connection when it comes to short reaction times, timely error detection, quick error recovery and error repair.

CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication system for intelligent devices. Some users, for example in the field of medical engineering, opted for CAN because they must meet particularly stringent safety requirements.

Similar requirements had to be considered by manufacturers of other equipment with very high safety or reliability requirements (e.g., robots, lifts, and transportation systems).

The greatest advantage of Controller Area Network lies in the reduced amount of wiring combined with an ingenious prevention of message collision (meaning no data will be lost during message transmission).

The following shows a need-to-know overview of CAN’s technical characteristics.

Controller Area Network

• Is a serial networking technology for embedded solutions.

• Needs only two wires named CAN_H and CAN_L.

• Operates at data rates of up to 1 Megabit per second.

• Supports a maximum of 8 bytes per message frame.

• Does not support node IDs, only message IDs. One application can support multiple message IDs.

• Supports message priority, i.e., the lower the message ID the higher its priority.

• Supports two message ID lengths, 11-bit (standard) and 29-bit (extended).

• Does not experience message collisions (as they can occur under other serial technologies).

• Is not demanding in terms of cable requirements. Twisted-pair wiring is sufficient.

For further details, see my book A Comprehensible Guide to Controller Area Network.

SAE J1939

SAE J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy-duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

Even though extremely effective in automobiles and small, embedded applications, CAN alone is not suitable for projects that require a minimum of network management and messages with more than eight data bytes.

Consequently, higher layer protocols (additional software on top of the CAN physical layer) such as SAE J1939 for vehicles were designed to provide an improved networking technology that support messages of unlimited length and allow network management, which includes the use of node IDs (CAN supports only message IDs where one node can manage multiple message IDs).

SAE J1939

• Is a standard developed by the Society of Automotive Engineers (SAE)

• Defines communication for vehicle networks (trucks, buses, agricultural equipment, etc.)

• Is a Higher-Layer Protocol using CAN as the physical layer

• Uses shielded twisted pair wire

• Applies a maximum network length of 40 meters (~120 ft.)

• Applies a standard baud rate of 250 Kbit/sec

• Allows a maximum of 30 nodes (ECUs) in a network

• Allows a maximum of 253 controller applications (CA) where one ECU can manage several CAs

• Supports peer-to-peer and broadcast communication

• Supports message lengths up to 1785 bytes

• Defines a set of Parameter Group Numbers (PGNs, predefined vehicle parameters)

• Supports network management (includes node IDs and an address claiming procedure)

Compared to other, function-driven protocols such as CANopen and DeviceNet, SAE J1939 is primarily data-driven. In fact, J1939 provides a far better data bandwidth than any of these automation protocols.

For further details, see my book A Comprehensible Guide to J1939.