SAE J1939 defines some special PGNs for PGNs that require more than 8 bytes. For example, PGN 60416 is the “header” packet, defining the real PGN and the number of “packets” to receive. PGN 60160 contains the data of the “real” PGN defined at the previous packet. PGN 60160 is sent as many times as the expected number of packets to be received.
I’ve tried to use MPJ1939Receive to receive a PGN that is sent by the ECU using multi-packet, but I do not receive anything. It works when receiving “normal” single packet PGNs.
Is there anything I’m doing wrong, or is it not supported?
I don’t have any experience with mappJ1939, or with J1939 in common.
But I tried to use your question to learn a bit about J1939, and as I understood the’re two different kind of multipart message:
the Broadcast Announce Message Transport Protocol (BAM TP)
the Destination Specific Transport Protocol (CM TP)
Both use the same PGNs like you’ve described.
BAM sends the data without handshake (every 50 milliseconds or so until all data was sent), but CM needs a handshake between sender and receiver via PGN 60416.
So if you’re not receiving anything, could it be that it’s a CM TP data exchange?
Because if yes I think, the handshake has to be implemented in your application by reading and writi ng data to PGN 60146?
I also think, that in both cases you have to restore the data fragments (sent via PGN 60160) back into the complete nessage by your own application.
As I said I’m new to J1939 and I hope my questions do not point completely in the wrong direction.
The information about the 2 different types of multipart message I got from here.
@EscuadraLevante , CAN 2.0b frames contains mainly an identifier (11 or 29 bits) and a payload of up to 8 bytes.
SAE J1939 is a protocol over CAN, and defines the identifiers and the payload for each identifier, in order to standarize the parameters send by the controllers of a vehicle.
Mappj1939 works like setting mailboxes. If the CAN message received matches the CAN ID programmed in the mailbox (this is the PGN in J1939), then the payload is stored. The way used for storing is direct access to memory (like pointers in C), so you set the variable for each byte of the payload. This is great as it reduces code, but SAE J1939 defines those multipacket messages that use some CAN ID to encapsulate a different message with a payload of more than 8 bytes, and it seems it does not work with them
@alexander.hefner , in my case, it is a BAM message. As I’m only receiving one PGN using multipacket, and i’m going to receive always the same type of data, it is easy to implement it using ArCan library. I thought about using mappJ1939 against PGN 60160 instead of the expected PGN, and then implement the data extraction, but I prefered to do it in plain ArCan and have the same code for all PGNs.
From my side, it is solved by using ArCan, but if anybody wants to dig into this, this is the data captured by a CAN sniffer
PGN 60416 Source 135 Priority 6 Payload 20130003 FFD0FB00 → 0x20 BAM 32, Size 0x0013, 0x03 packets, 0xff reserved, PGN 0x00fbd0 (64464) PGN 60160 Source 135 Priority 6 Payload 01401F50 46A000C8 → 0x01 sequence number, followed by data (PGN 64464 specific data), data follow in next message PGN 60160 Source 135 Priority 6 Payload 0200B80B C008FFFF → 0x02 sequence number, followed by data (PGN 64464 specific data) PGN 60160 Source 135 Priority 6 Payload 03FFFFFF 7E09FFFF → 0x03 sequence number (expected 3 packets), followed by data.
the mapp component MpJ1939 definitely supports multi-packages. The MpJ1939Receive and MpJ1939Transmit function blocks can receive and send J1939 multipacket messages up to 1785 bytes long.
This short Power Point presentation may help you to understand the protocol mechanism of the multi-packages: MpJ1939 - BAM.pptx (2.0 MB)