I am repeating myself over and over, but the Arduino Due is my preferred choice when it comes to quick prototyping of SAE J1939 and CAN Bus applications. It is the ease of programming and the great performance that makes it all possible. In fact, I created this application in only a few hours, mostly by copying and pasting existing code.

The Hardware

Quite obviously, I did use the Arduino Due but with some important additions. First of all, I added our Dual CAN Bus Interface for Arduino Due to support the SAE J1939 protocol stack, specifically its hardware layer. We also offer the same board which comes with an extended power supply range of 7 VDC to 36 VDC. Add to this combination a J1939 cable and you are ready to go and write your own J1939 application.

Secondly, in order to read GPS information, I added our UART GPS Module and connected it to the Arduino Due's RX1, TX1 (Serial1) port. The GPS sensor provides data according to NMEA 0183 (as does any standard GPS sensor), and decoding the data is fairly easy to accomplish with the appropriate information, the so-called NMEA output sentences, at hand. 

The Software

As I mentioned previously, this project was primarily created by copying and pasting code from several other applications I developed for the Arduino Due. It would take a lot more pages to explain the code for this GPS project in detail, but I deemed it more effective to provide references to the other applications. They are:

• SAE J1939 Protocol Stack Sketch for Arduino Due
• Arduino Due: Dual CAN Port Test Sketch With LED CAN Traffic Indicators
• Electronic Logging Device (ELD) - GPS And Real-Time Clock (RTC) Breakout Board For The Arduino Due

And yes, the project includes a full-blown SAE J1939 protocol stack, but please be aware that the actual protocol stack comes in a pre-compiled form. The protocol settings are documented in the above listed hyperlink.

Disclaimer

This Arduino program is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

The protocol settings, such as the J1939 NAME, are designed to have a minimum impact on a J1939 vehicle network's operation, i.e. the application will yield its node address to any competing node. Nevertheless, the setting of NAME and node addresses in this project serve only as a demonstration.

Click here to download the entire Arduino Sketch (zip file).

PGN 65267 - Vehicle Position

The output of the application is PGN 65267 (0xFEF3) according to the SAE J1939-71 standard:

Transmission Rate: 5 s
Data Length: 8 bytes
Default Priority: 6

SPN 584

Resolution: 10^-7 deg/bit, -210 deg offset
Data Range: -210 to 211.1008122 deg
Operational Range: -210 deg (SOUTH) to 211.1008211 deg (NORTH)

SPN 585

Resolution: 10^-7 deg/bit, -210 deg offset
Data Range: -210 to 211.1008122 deg
Operational Range: -210 deg (WEST) to 211.1008211 deg (EAST)

Proof of Concept

The image below shows the data output of the application.

Line 1 documents the address claim. The application is set up for an address range between 128 (0x80) and 247 with a preferred address of 128. Since there is no other competing node, the application claims the address easily. The following lines are valid GPS data (pointing to my Windows 10 PC in my office; I moved the board as far as the cable allowed and changes are visible). 

Please note that the SAE J1939-71 Standard uses Small Endian for data transmission, meaning LSB comes first, MSB comes last. Also be aware, it might take several minutes after startup before the GPS module can provide a valid position (Once found, it takes only seconds with clear reception). The SAE J1939-71 Standard does not cover that situation, i.e. the data output for such a case is not defined. Rather than not sending anything at all, I chose to set all 8 data bytes to 0xFF.