One of the more common questions when analyzing or simulating SAE J1939 traffic is surprisingly simple:
“How accurate must a J1939 message frequency be?”
If a message is supposed to be transmitted every 100 milliseconds, does that mean exactly 100 milliseconds? Can it be 101 milliseconds? 105 milliseconds? What happens when the network gets busy?
As with many engineering questions, the answer is: it depends.
What Does the J1939 Standard Say?
The SAE J1939 standards define transmission rates for many Parameter Groups (PGNs). For example, one message may be transmitted every 20 milliseconds while another is sent every second.
What the standards generally do not specify is a strict timing tolerance such as ±1% or ±5%.
The reason is simple: CAN is an event-driven network that relies on message arbitration. Even if an ECU intends to transmit a message at a precise moment, the actual transmission may be delayed by higher-priority traffic already occupying the bus.
In other words, some timing variation is expected and completely normal.
The Reality of CAN Bus Arbitration
Imagine three ECUs attempting to transmit at nearly the same time.
The highest-priority message wins arbitration and gains immediate access to the bus. The other ECUs wait until the bus becomes available again.
The result is that even a perfectly programmed ECU may occasionally transmit a message a little later than intended.
This is not a malfunction.
It is exactly how CAN was designed to work.
Bus Load Matters
One of the biggest influences on message timing is network utilization.
On a lightly loaded bus, messages typically appear very close to their intended transmission interval.
On a heavily loaded network, delays become more noticeable.
For example, a message configured for a 100 ms transmission interval may produce observations like:
- 100 ms
- 100 ms
- 101 ms
- 99 ms
- 102 ms
Under heavier traffic conditions, you might occasionally see:
- 100 ms
- 103 ms
- 101 ms
- 104 ms
- 99 ms
As long as the average transmission rate remains correct and no messages are being lost, this behavior is generally considered normal.
This is why experienced engineers often pay more attention to long-term averages than to individual timing deviations.
Measuring Frequency Deviations
When evaluating message timing, the percentage deviation is often more important than the absolute number.
Consider these examples:
| Nominal Interval | 1 ms Deviation | Percentage |
|---|---|---|
| 1000 ms | ±1 ms | 0.1% |
| 100 ms | ±1 ms | 1% |
| 50 ms | ±1 ms | 2% |
| 20 ms | ±1 ms | 5% |
| 10 ms | ±1 ms | 10% |
A one-millisecond variation is almost insignificant for a one-second message but becomes more noticeable for a 10-millisecond message.
Even then, the network itself may introduce additional variation due to arbitration delays.
What About J1939 Simulators?
When engineers evaluate a simulator, they often expect laboratory-grade precision. Fortunately, J1939 is not a laboratory instrument. It is a practical communication system designed for trucks, agricultural equipment, construction machinery, marine applications, and countless other real-world environments.
In the J1939 ECU Simulator, message timing is generated directly by the firmware using an internal scheduler with a 1-millisecond time base.
Typical transmission deviations are within 1 to 2 milliseconds.
For example:
| Nominal Interval | Typical Deviation |
| 1000 ms | ±1-2 ms |
| 100 ms | ±1-2 ms |
| 50 ms | ±1-2 ms |
| 20 ms | ±1-2 ms |
For most J1939 applications, these values are well within practical requirements and compare favorably with timing behavior observed on many real vehicle networks.
More importantly, the timing is generated within the simulator firmware itself rather than relying on PC-based software timing.
Why Windows Is Not the Story Here
A common misconception is that the connected PC somehow determines message transmission timing.
In reality, the J1939 ECU Simulator handles message scheduling internally.
The PC is simply used to configure messages, change parameter values, and monitor activity.
Once the simulator is running, message timing remains under firmware control regardless of what the PC is doing.
Whether the operator is running a browser, checking email, or opening another application has no impact on the simulator’s message transmission schedule.
The Bigger Picture
When analyzing message frequencies, it is important to remember that no CAN network operates in a vacuum.
Actual transmission timing depends on several factors:
- ECU scheduling accuracy
- CAN bus arbitration
- Network utilization
- Message priorities
- Overall traffic patterns
For that reason, expecting every message to appear at exactly the nominal interval is neither realistic nor necessary.
What matters is that messages are transmitted consistently, predictably, and at rates that accurately represent real-world J1939 network behavior.
And in the real world, a little timing variation is not only acceptable—it is expected.
Final Thoughts
Engineers often become concerned when they observe a message that appears at 101 ms instead of 100 ms or 21 ms instead of 20 ms.
In most cases, that concern is unnecessary.
The SAE J1939 network was designed to tolerate normal timing variations caused by arbitration and bus loading. A small deviation does not indicate a faulty ECU, a faulty simulator, or a faulty network.
In fact, if every message arrived with perfect clock-like precision regardless of bus traffic, that would probably be less representative of a real J1939 network than a system that occasionally exhibits the small timing variations naturally produced by CAN bus communication.
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). More Information…
Comments are closed.