J1939 Request and Acknowledgement: PGN 59904 and 59392
Most parameter groups in J1939 are transmitted cyclically: engine speed, temperatures or lamp status arrive unprompted at a fixed rate. Some information, however, is only available on request – the DM2 fault memory, software and component identification, or the address assignment of the devices on the network. For these cases SAE J1939-21 defines two parameter groups: the Request (PGN 59904), used to ask for any PGN, and the Acknowledgement (PGN 59392), which a device sends when it answers with a confirmation instead of data. Both are quick to implement. The rules on when a device must respond and when it must stay silent, however, are a common cause of problems between devices from different manufacturers.
Why J1939 needs its own request
Classical CAN provides the remote frame for requests. J1939 does not use it. Instead, the Request is an ordinary data frame whose payload carries the requested PGN. This has two advantages: the request can be sent to one specific device or to all of them, and the requester is clearly identified by its source address. These two pieces of information are exactly what governs the response behaviour.
Structure of the Request
The Request has PGN 59904 (0xEA00) and uses the PDU1 format: the PF value 0xEA is below 240, so the PS field carries a destination address. The default priority is 6. A service tool with address 0xF9 sending a request to the engine controller (address 0x00) uses the identifier 0x18EA00F9. The same request sent to all devices uses 0x18EAFFF9.
The payload consists of exactly three bytes, the requested PGN:
| Byte | Content |
|---|---|
| 1 | PGN, bits 0–7 (least significant byte) |
| 2 | PGN, bits 8–15 |
| 3 | PGN, bits 16–23 (contains Data Page and Extended Data Page) |
The PGN is transmitted least significant byte first. To request DM2 (PGN 65227, 0x00FECB), you send CB FE 00, not 00 FE CB. For PDU1 PGNs, the middle byte of the requested PGN is always 0x00, because the destination address is not part of the PGN.
The Request is one of the few parameter groups with a DLC below 8: J1939-21 specifies DLC 3. In practice, requests with DLC 8 and padding bytes still show up, because some interface APIs extend every frame to eight bytes. A robust receiver therefore evaluates the first three bytes and does not discard longer requests.
Besides the Request, J1939-21 defines a Request2 (PGN 51456) with additional identification bytes and the option to have the response sent via the Transfer parameter group. It plays a much smaller role in practice and is not covered in this article.
Destination-specific or global: two different sets of rules
How a device reacts to a request depends primarily on the destination address. The most important rule is: a destination-specific request must always be answered, a global request only by the devices that actually support the requested PGN.
| Situation | Destination-specific request (DA = own address) | Global request (DA = 255) |
|---|---|---|
| PGN is supported | Response with the requested parameter group | Response with the requested parameter group |
| PGN is not supported | NACK | no response |
| PGN supported, device busy | Cannot Respond | no response |
| PGN supported, access locked | Access Denied | no response |
| Destination address of the response for PDU1 parameter groups | Address of the requester | global (255) |
| Response longer than 8 bytes | usually CMDT to the requester | BAM |
The reason for staying silent on global requests is bus load: if every device that does not know a PGN sent a NACK, each global request would trigger a flood of frames from which the requester learns nothing anyway.
One rule is often overlooked: on a global request, the requester itself must also process the request and respond if it supports the PGN. Since a CAN controller normally does not receive its own frames, the protocol stack has to pass the request to itself internally.
If a device supports a PGN but currently cannot provide individual parameters within it, NACK is the wrong answer. Instead, it sends the parameter group and sets the affected parameters to “not available” (all bits set to 1). A NACK says “this PGN does not exist on this device”, which is a different statement from “this value is currently missing”.
Structure of the Acknowledgement
The Acknowledgement (ACKM) has PGN 59392 (0xE800), also in PDU1 format and with default priority 6. Although it could carry a destination address, J1939-21 requires it to always be sent to the global address 255. A NACK from the transmission controller at address 0x03 therefore uses 0x18E8FF03, regardless of who sent the request.
| Byte | Content |
|---|---|
| 1 | Control byte (type of acknowledgement) |
| 2 | Group Function Value, otherwise 0xFF |
| 3–4 | reserved, 0xFF |
| 5 | Address Acknowledged: address of the requester |
| 6–8 | acknowledged PGN, least significant byte first |
Four values of the control byte matter in practice:
- 0 – Positive Acknowledgement (ACK): the requested action has been carried out.
- 1 – Negative Acknowledgement (NACK): the PGN is not supported.
- 2 – Access Denied: the PGN is supported, but access is locked, for example by a security function.
- 3 – Cannot Respond: the PGN is supported, but the device cannot respond right now. The requester should try again later.
Because the Acknowledgement is sent globally, every node sees it. Byte 5 and the PGN in bytes 6 to 8 are therefore not additional information, but the only way to match an Acknowledgement to the right request. A service tool that filters only on PGN 59392 and the source address of the queried device will, on a network with two tools, also evaluate the NACKs meant for the other tool.
A complete example: service tool 0xF9 requests PGN 65248 (0xFEE0) from transmission controller 0x03, which does not support it.
| Direction | Identifier | Data | Meaning |
|---|---|---|---|
| Tool → transmission | 0x18EA03F9 |
E0 FE 00 |
Request PGN 65248, addressed to 0x03 |
| Transmission → all | 0x18E8FF03 |
01 FF FF FF F9 E0 FE 00 |
NACK for PGN 65248, requester 0xF9 |
When a positive Acknowledgement is sent
For an ordinary request, the response is the requested parameter group itself; no additional ACK is sent. Positive Acknowledgements occur where a request does not fetch data but triggers an action. The best-known example are the clear services of J1939 diagnostics: a request for DM11 (PGN 65235) resets the active faults, a request for DM3 (PGN 65228) clears the previously active ones. On a destination-specific request, the device confirms with ACK once it has cleared, and with NACK if it could not.
| Direction | Identifier | Data | Meaning |
|---|---|---|---|
| Tool → engine | 0x18EA00F9 |
D3 FE 00 |
Request DM11, addressed to 0x00 |
| Engine → all | 0x18E8FF00 |
00 FF FF FF F9 D3 FE 00 |
ACK for DM11, requester 0xF9 |
Timing
J1939-21 requires a device to respond to a request within 200 ms. The requester waits up to 1.25 s before treating the request as unanswered. If there is no reaction at all by then, this is an error of the queried device in the case of a destination-specific request, because it should at least have responded with a NACK. For a global request, on the other hand, silence simply means that no device supports the PGN.
Special case: Address Claimed
A request for PGN 60928 (0xEE00) asks the other nodes for their Address Claimed messages. Sent globally, it yields an overview of all addresses in use on the network, which makes it the basis of every network scan. Some special rules apply here, which are described in detail in the article on J1939 Address Claiming:
- A device that does not have an address yet may send the request with the null address 254 as its source address. The global request is then
0x18EAFFFEwith the data00 EE 00. - Address Claimed is always sent to the global address, even if the request was destination-specific.
- On a global request, the requester itself must also send its Address Claimed message, provided it has already claimed an address.
Typical implementation errors
- PGN in the wrong byte order: the request for DM2 is sent as
00 FE CB. The target device sees a request for a PGN it does not know and responds with NACK. - NACK on global requests: this violates the standard and generates unnecessary frames on every network scan.
- No response to destination-specific requests: the requester runs into the 1.25 s timeout and cannot tell whether the device does not know the PGN or is not reachable at all.
- Acknowledgement not matched: without evaluating byte 5 and the acknowledged PGN, a tool mistakes other tools’ NACKs for answers to its own request.
- Own global request not processed: the device sends a global request for Address Claimed but does not appear in its own node list.
- NACK instead of “not available”: the device responds with NACK although it knows the PGN and only individual values are missing.
- Long responses not anticipated: requests for Software Identification (PGN 65242) or Component Identification (PGN 65259) usually return more than 8 bytes. The requester therefore has to handle both transport protocols, because which one is used depends on whether it asked destination-specifically or globally.
Request and Acknowledgement in the trace
In a raw trace, requests and responses are hard to match: the requested PGN sits in the payload with its bytes reversed, the Acknowledgement goes to everyone, and for long responses an entire transport protocol transfer lies between request and data. The emotas CANinterpreter with the J1939 extension displays PGNs, source and destination addresses in interpreted form and reassembles transport protocol transfers. This makes it easy to see whether a request was followed by the data, an acknowledgement or nothing at all. With the recording function, this can also be traced afterwards for intermittent problems in the field.
For device manufacturers
- Answer every destination-specific request, with data or an acknowledgement. The safest approach is to handle this centrally in the protocol stack: every PGN the application does not serve is answered there with a NACK automatically.
- Never acknowledge global requests, neither positively nor negatively.
- Document which PGNs are only sent on request. For integrators this is one of the most important pieces of information, because a PGN that never arrives unprompted remains invisible in the trace until someone requests it.