Press "Enter" to skip to content

SAE J1939 VIN Simulation and Request Demo – Understanding PGN 65260 (VIN)

In previous quick demos, we focused on SAE J1939 parameters that are transmitted periodically, such as engine speed, vehicle speed, fuel level, and engine temperatures. These messages are broadcast automatically at predefined intervals, allowing any node on the network to receive the data without explicitly asking for it.

The Vehicle Identification Number (VIN), however, works differently.

In SAE J1939, the VIN is transmitted using PGN 65260 (FEEChex) and is classified as a request-based message. This means the ECU does not continuously broadcast the VIN on the network. Instead, another node must first send a Request message (PGN 59904), asking for PGN 65260. Upon receiving the request, the ECU responds by transmitting the VIN.

This request-response mechanism reduces unnecessary bus traffic because information such as the VIN rarely changes and is typically needed only occasionally for identification, diagnostics, service tools, or fleet management applications.

As a side note, the VIN is not the only SAE J1939 message that is available on request. Other commonly requested identification messages include the Software Identification (PGN 65242), Component Identification (PGN 65259), and various diagnostic and configuration-related messages. Unlike continuously broadcast operating parameters, these messages are generally transmitted only when specifically requested by another network node.

In this demonstration, we will first configure our JCOM1939 Monitor software to simulate a VIN response and then show how to retrieve the VIN by sending a standard SAE J1939 Request message.

Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is transmitted using PGN 65260 (0xFEEC). Unlike most J1939 parameter messages, the VIN contains a text string rather than numerical sensor data. The message can carry up to 17 ASCII characters, representing the vehicle’s unique identification number assigned by the manufacturer.

Because a VIN is longer than the eight data bytes available in a single CAN message, it is normally transmitted using the J1939 Transport Protocol, which automatically splits the VIN into multiple CAN frames and reassembles it at the receiving node. The VIN itself is encoded as plain ASCII text, making it easy to read and interpret once the transport protocol transfer has been completed.

Vehicle Identification Number (VIN) Setup

The setup for responding to a request is very similar to configuring a standard PGN transmission. In the Transmit section of the JCOM1939 Monitor software, enter the PGN that will be requested—in this case, PGN 65260, which represents the Vehicle Identification Number (VIN).

The priority is already set to 6 (the default value), and the destination address is 255, indicating a Global Destination Address. To make the setup easier to identify later, we also enter a descriptive label, as shown in the screenshot.

The VIN data entered in this example is intended solely for demonstration purposes and does not represent an actual vehicle identification number.

Next, set the Transmission Rate field to On Request and click the Save button.

Request Message Response Setup

There is one essential step still missing: we need to claim a node address. According to the SAE J1939 standard, an ECU must have a valid network address before it can transmit any data, including responses to Request messages.

To do this, switch to the ECU Setup section, select ‘ECU Simulation Mode’ and claim address 128, which is the default setting. Once the address claim process has completed successfully, the node is ready to participate in the network and respond to incoming requests.

Starting ECU Simulation Mode

With this configuration, the JCOM1939 Monitor will not transmit the VIN automatically. Instead, it will wait for a Request message (PGN 59904) asking for PGN 65260 and then respond with the VIN data.

With the VIN simulation now configured, it is time for a proof of concept. For this demonstration, we are using our J1939 Starter Kit with two network nodes. The first node acts as the responder and has been configured to provide the VIN upon request, while the second node serves as the requester.

This setup allows us to demonstrate the complete request-response process, from sending the Request message for PGN 65260 to receiving and displaying the VIN transmitted by the responder.

Setting Up the Requestiong Node

We have now opened a second instance of the JCOM1939 Monitor software and connected it to the second node of our J1939 Starter Kit. Before we can send a Request message, this node must also claim a valid network address.

There is one additional consideration: according to the SAE J1939 standard, each node on the network must have a unique NAME. Since both software instances initially use the same default settings, we first need to modify the NAME before attempting an address claim.

To do this, switch to the ECU Setup section and enable ECU Simulation Mode. Then change the ECU Instance field from 0 to 1. This modification changes the node’s NAME, making it unique on the network.

Requesting node address claim

Next, initiate the address claim process. The software will initially attempt to claim address 128, but since that address is already occupied by the VIN responder, the J1939 address claim procedure will automatically assign the next available address, which in this case is 129.

With both nodes now operating under unique NAMEs and valid network addresses, we are ready to request the VIN from the responder node.

In the Transmit section, enter PGN 65260, which represents the Vehicle Identification Number (VIN). Unlike a normal transmission setup, no data entry is required here. Simply click the Request button, and the software will automatically generate the appropriate Request message, including all necessary data bytes.

Once transmitted, the requester node will wait for the response from the VIN responder and display the received VIN data.

Click Save to store the request configuration. Then click Transmit to send the Request message onto the network. The responder node will immediately return the VIN data, which will then be displayed by the software.

VIN Request and Response

The image above provides proof of concept for the VIN request-response process. The requesting node displays both the transmitted Request message, marked with TX, and the received VIN response, marked with RX.

Note: One detail that often causes confusion: while the actual VIN PGN 65260 has a default priority of 6, once it is transported through the J1939 Transport Protocol, the CAN identifiers on the bus belong to PGNs 60416 and 60160, both of which use priority 7. The original PGN 65260 appears only inside the TP.CM_BAM payload and is not transmitted directly on the bus.

However, the gateway automatically reassembles the Transport Protocol (TP) sequence into a single message and forwards the complete payload to the JCOM1939 Monitor software. As a result, the VIN appears as one consolidated message rather than as a series of TP.CM and TP.DT packets. Since the original transport protocol frames are removed during this process, the priority displayed by the software is not associated with the actual TP messages transmitted on the network.

As demonstrated, the JCOM1939 Monitor can easily simulate a VIN responder and generate the corresponding Request message to retrieve the VIN. This functionality is particularly useful for testing, diagnostics, and application development, allowing engineers to verify request-based SAE J1939 communications without requiring access to an actual vehicle or ECU.


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.

Copyright © 2024 Copperhill Technologies Corporation
wpChatIcon
wpChatIcon