This post is a bit more personal in nature—something I’ve been meaning to share for a while. I’ve been working with Controller Area Network (CAN) and SAE J1939 technologies for many years now, and, as you can imagine, I’ve gathered quite a bit of hands-on experience along the way. Naturally, when newer engineers or developers are assigned to a project they’re not fully familiar with, they may come across my work or products and reach out for guidance—which I appreciate. It’s always a good sign when someone is eager to learn and seeks reliable resources.
That said, I can’t always provide one-on-one technical mentoring—there just aren’t enough hours in the day. That’s precisely why I’ve written books on the subject and maintain comprehensive, frequently updated content across our websites. These resources are designed to answer common questions and guide users through the more challenging aspects of CAN and J1939 development.
Now and then, however, I receive messages from individuals claiming that our products—of which we’ve sold thousands—“don’t work” or “don’t follow the standard.” In every one of those cases so far, the issue has stemmed not from the product but from a misunderstanding or incomplete implementation. And let me be clear: this isn’t a dig at anyone’s intelligence or background. I’ve been in those shoes—grappling with complex systems that didn’t seem to make sense, especially when documentation was scarce or overly technical.
What I take issue with is not inexperience, but the resistance to diving deeper into the material—to really learn the technology. Because that’s what engineering is: a lot of trial, error, head-scratching, and perseverance. No shortcuts. I’ve gone through it all—burned evenings, frustrated weekends, and stubborn bugs that took days to isolate. But I came out the other side with real insight, and I’ve tried to pass that along in every resource I publish. It’s all there—but yes, it does require reading.
We live in a time when access to information is easier than ever. Between technical documentation, blog posts, videos, and even AI-powered tools, the answers are out there. But they won’t do you much good unless you take the time to read and absorb them.
Let me share a quick anecdote, based on a recent support request:
“I’m contacting you about an issue with a JCOM.CAN.ESP32-W board that we purchased last year and are using with the J1939 simulator firmware. We followed the setup instructions, confirmed proper termination and wiring, and tried the board on multiple CAN buses. However, it doesn’t seem to claim a J1939 address. We don’t see any address claim messages, and the simulator doesn’t appear to initiate or respond.”
Furthermore, they requested a link to download the device’s firmware along with instructions to re-flash the code—an action that, frankly, has no relevance to the actual issue. It’s a classic case of “shooting in the dark,” and it reflects a certain level of mistrust in the quality of our product, which is both unwarranted and unhelpful in resolving the matter.
It turns out the user, despite the previous statement, hadn’t connected a second J1939/CAN node. Now, if you’re familiar with CAN or J1939, you’ll know this is a fundamental requirement—networks need at least two active nodes to communicate. It’s like expecting a conversation to happen with only one person in the room.
To make matters more confusing, they likely used an oscilloscope to look for the address claim—something common in automotive diagnostics—but an oscilloscope is not a protocol analyzer. It may show electrical activity, but it won’t interpret J1939 traffic.
And this brings me full circle: we have detailed troubleshooting tips like this on our website, including an entire post dedicated to getting started with J1939 development. But again—it all depends on whether you’re willing to read and explore the available resources.
I encourage every engineer—novice or experienced—to take that extra step. Dig in. Ask questions, absolutely. But first, give yourself a solid foundation by using the documentation that’s already been prepared for you.
That’s how engineering works—and trust me, it’s worth it.
SAE J1939 Starter Kit and Network Simulator
Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.
The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP).
Comments are closed.