Site Information

 Loading... Please wait...

Blog

SAE J1939 Development: Why Every Engineer Needs a Stable J1939 Test Network

Posted by Wilfried Voss on

SAE J1939 Development- Why Every Engineer Needs a Stable J1939 Test NetworkDeveloping an SAE J1939 application should be challenging because of your application logic—not because your test environment keeps changing.

Unfortunately, that’s exactly what happens in many development projects.

An engineer designs a new J1939 ECU, writes the firmware, connects it to another prototype node, and immediately starts chasing communication problems. The problem is that both nodes are under development. If communication fails, which one is responsible?

  • Is it your hardware?
  • Is it your CAN driver?
  • Is it your J1939 implementation?
  • Is it the second ECU?
  • Is it incorrect address claiming?
  • Is it Transport Protocol?
  • Is it timing?
  • Is it simply a wiring issue?

You have introduced multiple changing variables into the system.

That is rarely a productive way to develop software.

Engineering Rule #1: Reduce the Number of Changing Variables

One of the first lessons learned in engineering is to change only one variable at a time.

Suppose you modify hardware, firmware, network configuration, timing, and message handling simultaneously. In that case, every test result becomes questionable because you no longer know which change caused the behavior.

The same principle applies to J1939 development.

SAE J1939 Starter Kit And Network SimulatorYour application should be the only component under development.

Everything else should already work.

That is exactly the philosophy behind the SAE J1939 Starter Kit and Network Simulator.

Instead of connecting your prototype to another unfinished ECU, you connect it to a stable, fully functional J1939 network whose behavior is known and repeatable.

A Complete J1939 Network—Not Just Another Interface

Many CAN interfaces simply allow you to transmit and receive CAN frames.

That is useful.

But it does not create a working J1939 network.

The Copperhill Technologies Starter Kit includes two complete J1939 nodes communicating with each other, creating an actual SAE J1939 network that supports:

  • Address Claiming (SAE J1939/81)
  • Transport Protocol (SAE J1939/21)
  • PGN transmission and reception
  • Request messages
  • Diagnostic messages
  • ECU simulation
  • Network scanning

Because both nodes already operate correctly, they provide a reliable reference network while your own ECU is under development.


SAE J1939 Development CommunityJoin the J1939 Community: Connect, Learn, and Build Better SAE J1939 Applications

The J1939 Community is a place where embedded developers, software engineers, and system integrators can exchange practical knowledge about SAE J1939 development. Whether you’re designing a new ECU, debugging communication problems, implementing Transport Protocol, or simply trying to understand PGNs, you’ll find discussions focused on real-world engineering rather than theory. The community also features announcements about new development tools, software updates, technical articles, programming examples, and the ongoing J1939 Development for Embedded Systemsbook project.

If you work with SAE J1939—or plan to—you’re invited to become part of the community. Registration is free and gives you the opportunity to ask questions, share your experience, suggest new features for the JCOM1939 Monitor software, discuss development techniques, and connect with fellow engineers from around the world. Join the J1939 Community and help build a valuable resource for everyone developing SAE J1939 applications.


Why Two Nodes Matter

Many newcomers wonder why the starter kit contains two J1939 interfaces.

The answer is simple.

A J1939 node does not exist in isolation.

Even the CAN controller itself expects activity on the network. A controller transmitting onto an otherwise empty bus will eventually enter error states because nothing acknowledges its messages.

A functioning network requires multiple participants.

The Starter Kit provides exactly that.

Instead of spending hours building a test environment, you can start developing immediately.

Debug Your ECU—Not Your Test Bench

Imagine developing a new engine controller.

You connect it to the Starter Kit.

Your ECU transmits PGNs.

The simulated network responds exactly as expected.

If communication fails, your investigation becomes much simpler because you already know the simulator is operating correctly.

You have removed one of the largest unknowns from the equation.

That dramatically shortens debugging time.

Simulate Before the Machine Exists

Another major advantage is independence from actual vehicle hardware.

How often does one of these situations occur?

  • The vehicle is unavailable.
  • The prototype engine has not arrived.
  • The machine is in another state.
  • The customer cannot interrupt production.
  • Access to the vehicle is limited.

Development comes to a halt.

The Starter Kit eliminates this dependency by allowing engineers to simulate virtually any PGN defined by SAE J1939-71, including diagnostic messages from SAE J1939-73. Once you know which PGNs your application requires, you can build a realistic simulation without having access to the physical machine.

The Real Power Comes from the Windows Software

JCOM1939 Monitor Software for WindowsThe hardware is only one part of the solution.

The included JCOM1939 Monitor software transforms the Starter Kit into a complete development laboratory.

Using the software you can:

  • Monitor live J1939 traffic
  • Record communication sessions
  • Decode PGNs
  • Simulate ECUs
  • Generate custom PGNs
  • Configure periodic transmissions
  • Respond automatically to Request messages
  • Scan the network for active ECUs

Running two instances of the software allows you to observe both sides of the communication simultaneously, making it much easier to understand exactly what happens on the bus.

Expand Your Development Environment

The Starter Kit is only one component of a complete J1939 development workflow.

Copperhill Technologies offers a broad range of hardware for engineers developing embedded applications, including USB interfaces, Bluetooth gateways, CAN interfaces, embedded controllers, and protocol development tools.

Whether your target platform is Windows, Linux, Raspberry Pi, Arduino, ESP32, or another embedded processor, the same development philosophy applies:

Create a stable environment first.

Then develop your application.

For an overview of available development hardware, visit the Copperhill Technologies J1939 Development section.

Learn While You Build

A development tool is only as useful as the knowledge behind it.

For that reason, the JCOM1939 website contains an extensive collection of technical resources, including:

  • Programming tutorials
  • Quick-start guides
  • Technical articles
  • Application notes
  • Troubleshooting information
  • Protocol explanations
  • Software documentation

Whether you’re learning J1939 for the first time or implementing advanced features such as Address Claiming or the Transport Protocol, the goal is the same: reduce the learning curve and spend more time building reliable applications.

Final Thoughts

Every experienced engineer eventually reaches the same conclusion:

Debugging is much easier when you already trust the test environment.

The SAE J1939 Starter Kit and Network Simulator was designed around that principle.

Instead of trying to determine whether two prototype ECUs are communicating correctly, start with a known-good network and focus on what really matters—your own application.

Reduce the number of changing variables.

Your development time—and your sanity—will thank you.


Additional Resources

Arduino Due Dual CAN Bus Development Platform for Rapid CAN Bus and SAE J1939 Prototyping

One of the biggest obstacles in CAN bus development is not understanding the CAN protocol itself—it is finding a development platform that lets you move from an idea to a working prototype without spending weeks configuring hardware, writing low-level drivers, or debugging interface electronics. Whether you are developing an automotive controller, an industrial CAN node, an [...]

Read More »


Developing SAE J1939 Applications with ARD1939 and Copperhill Technologies Hardware

One of the challenges of developing SAE J1939 applications is finding a protocol stack that is both affordable and flexible enough for prototyping, education, and custom embedded projects. To address this need, we developed ARD1939, a portable C++ SAE J1939 protocol stack that serves as the software foundation for many of our development projects and examples. Originally [...]

Read More »


ESP32-S3 MicroPython Programming for CAN Bus and NMEA 2000

The embedded systems world has traditionally been dominated by C and C++, but over the past several years another language has been gaining remarkable momentum: Python. More specifically, MicroPython has become one of the most attractive development environments for engineers who want to prototype and deploy embedded applications quickly without sacrificing access to the underlying [...]

Read More »


MicroPython Meets CAN Bus: The Fastest Way to Build Industrial IoT and Embedded CAN Applications

If you’ve ever programmed a CAN Bus application in C or C++, you already know the learning curve. Before sending the first CAN message, you typically need to configure a compiler, install SDKs, understand build systems, and write dozens of lines of initialization code. But what if you could start communicating over a CAN network with [...]

Read More »


CANPico V2 with Raspberry Pi Pico WH: Build Connected CAN Bus Applications with MicroPython and Wi-Fi

Have you ever wanted to build a smart system that sends data to the cloud, responds to remote commands, or monitors equipment in real time? With the CANPico V2 featuring a pre-installed Raspberry Pi Pico WH, those ideas can become working prototypes in hours instead of weeks. Combining industrial-grade CAN Bus hardware, integrated Wi-Fi, and the [...]

Read More »


Teensy 4.1 Triple CAN Bus Board with Ethernet and LCD – The Ultimate Platform for High-Performance CAN Network Development

When developing modern embedded systems, one challenge appears repeatedly: How do you connect multiple CAN networks, process large amounts of real-time data, provide a local user interface, and communicate with Ethernet or cloud services—all without running out of processor performance? The answer is the Teensy 4.1 Triple CAN Bus Board with 240×240 IPS LCD and Ethernet [...]

Read More »


Why Would You Need Two CAN Ports on a Raspberry Pi?

When developers first start working with CAN bus networks, a single CAN interface is usually sufficient. It allows them to monitor traffic, transmit messages, and develop applications for automotive, industrial, marine, or agricultural systems. However, as projects become more sophisticated, the limitations of a single CAN port quickly become apparent. This is where dual-channel CAN interfaces [...]

Read More »


Why CAN Bus Is One of the Most Reliable Communication Systems Ever Created

When engineers design communication systems for vehicles, industrial machinery, agricultural equipment, marine electronics, and embedded control systems, reliability is often more important than raw speed. A lost message in a music streaming application may go unnoticed. A lost message containing engine speed, brake status, steering angle, or hydraulic pressure can lead to equipment malfunction, downtime, or [...]

Read More »


Free SAE J1939 Protocol Stack for ESP32 — Open New Paths for CAN Bus Innovation

We at Copperhill Technologies are excited to announce that we are releasing a fully functional SAE J1939 protocol stack for the ESP32 — and best of all, it’s completely free to use. Whether you’re an engineer, a student, or a maker, this opens up serious possibilities for CAN-bus projects and vehicle network applications — without [...]

Read More »