J1939 Transport Protocol Deep Dive: BAM vs CMDT for Your Test Suite

CAN frames carry 8 bytes. A J1939 PGN can carry up to 1,785 bytes. Something has to bridge that gap - and that something is the J1939 Transport Protocol (TP). Two mechanisms exist: BAM (Broadcast Announce Message) and CMDT (Connection Mode Data Transfer). Most J1939 test suites test neither of them.

This is a gap worth closing. TP failures are among the hardest J1939 bugs to diagnose in the field because they are silent - the frames arrive, the data is partially reassembled, and the application layer sees nothing or sees corrupted data with no error indication.

The Fundamental Difference: Point-to-Point vs Broadcast

J1939 TP exists to fragment and reassemble PGNs larger than 8 bytes. The two variants differ in how they handle flow control:

BAM (Broadcast Announce Message) - Used for multi-packet broadcasts. The sender announces its intention to transmit (BAM frame: TP.CM_BAM), then sends all data packets sequentially with no flow control from receivers. Any node on the bus can listen and reassemble. The sender does not know or care who received it. If a receiver misses a packet, there is no retransmission.

CMDT (Connection Mode Data Transfer) - Used for point-to-point transfers between a specific sender and receiver. The receiver controls the flow: it sends Clear-To-Send (CTS) frames specifying how many packets it can accept before the next flow control message. Supports retransmission and acknowledgement. More robust than BAM; slower due to handshaking.

Which PGNs Use Which Mechanism

The choice of BAM vs CMDT is defined by the PGN's PDU format:

• PDU Format 1 (PF < 240): Peer-to-peer addressing - these use CMDT for multi-packet transfers
• PDU Format 2 (PF ≥ 240): Broadcast addressing - these use BAM for multi-packet transfers

Common BAM PGNs in a truck network: Software Identification (PGNSOFTWAREIDENTIFICATION, 0xFEDA, up to 200 bytes), Vehicle Identification (PGNVEHICLEIDENT, 0xFEEC, 17 bytes minimum for VIN). Common CMDT PGNs: Proprietary A PGN (0xEF00) used for manufacturer-specific peer-to-peer data, Request2 transfers, and ECU programming protocols.

Where BAM Fails Silently

BAM has no error recovery. If a receiving node misses packet 3 of a 5-packet BAM sequence - due to bus priority conflict, buffer overflow, or processing delay - it silently discards the entire partially reassembled PGN. The application layer sees nothing. The sender never knows. No error frame. No NAK. Silence.

This failure mode is typically triggered by bus load. At 30% bus load, BAM transfers complete reliably. At 70% bus load, a higher-priority CAN frame wins arbitration at exactly the wrong moment, and the receiving node misses a packet. The symptom: VIN reads intermittently as blank in the telematics system, but only when the engine is running and bus traffic is high.

Test case for BAM failure detection: Monitor the receiving node's PGN buffer after a BAM transfer under simulated 70% bus load (generated by background CAN traffic). Assert that the reassembled PGN payload matches the transmitted content. If the receiver reports a timeout or zero-length PGN, the BAM transfer failed silently. Run this test 100 times and measure the failure rate - anything above 0% is a defect.

Where CMDT Fails - The CTS Timing Window

CMDT's flow control makes it more robust than BAM, but introduces a different class of failures: CTS timing violations. After the sender transmits the allowed number of packets (defined in the preceding CTS frame), it waits for the next CTS before continuing. The waiting period is bounded by T2 (750ms default). If the receiver does not send the next CTS within T2, the sender must abort the connection.

Three CMDT failure scenarios worth testing:

1. CTS with zero packets allowed: The receiver sends CTS with packet count = 0 (hold condition - "I'm not ready yet"). The sender must wait for the next CTS. Test that the sender correctly holds, retries, and eventually aborts if hold exceeds T4 (1050ms).

2. Missing CTS after packet burst: Simulate a receiver that goes offline after the first CTS. The sender should detect the T2 timeout and send a Connection Abort (TP.Conn_Abort). Verify the abort reaches the network and the sender correctly cleans up its connection state.

3. Sequence number mismatch: Each data packet carries a sequence number (1 to N). Test that a receiver which receives an out-of-sequence packet correctly aborts the connection rather than reassembling garbage data.

Adding TP Tests to Your J1939 Test Suite

In TestBot, J1939 TP coverage requires two additions to a standard J1939 test suite:

1. BAM reception validation: Add a J1939 Monitor block specifically watching for multi-packet PGNs (FEDA, FEEC, or any manufacturer-specific broadcast PGN above 8 bytes). Assert the reassembled payload matches the expected content within the specified timeout. Run under load conditions.
2. CMDT connection lifecycle: For peer-to-peer PGNs, add J1939 Client Agent blocks that initiate an RQST2 transfer for a known large PGN, validate the CTS-data-CTS-data-EndOfMessageACK sequence, and assert the complete payload is received without retransmission requests.

Most engineers who add TP testing to their J1939 suite find at least one failure in the first week. Not because their ECU is poorly implemented - because TP failures require load conditions and specific timing that never occur in a low-traffic lab bench but occur immediately in a populated network.