HARNESS AS-SCREED 1070660 - Caterpillar

Trimble Multi-frame Broadcast (Broadcast DC over CAN) Message Protocol
The "Trimble-proprietary" multi-frame broadcast protocol is used for transmitting:
GSOFs
CMRsTrimble Multi-Frame Broadcast Message Format
Trimble multi-frame broadcast messages are in the format shown below.
Table 1
   
Byte     Name     Description    
0     "Msg Type"     0xD2: Multi-frame message 1 ProtocolType    
1     "Protocol Type"     0x08 : Broadcast DC    
2     "Reserved"     Set to 0x00 on transmit. Ignore on receive.    
3     "Packet Type"     One of:
0x40: GSOF
0x93:CMR
0x94: CMR+    
4     "Length"     Number of bytes from byte 5 to the final byte, inclusive.    
5-N     "MsgBody"     Message body    J1939 Proprietary-Layer Message Processing
Illustration 1 g03397889
Priority Layer Message ProcessingThe multi-frame broadcast message protocol uses the following proprietary messages to support the protocol:
"PC_FRIEND_RESPONSE"
"PC_FRIEND_REQUEST"The multi-frame broadcast message protocol uses the following J1939 message types for data transport:
J1939 single frame addressed message
J1939 single frame broadcast message
J1939 multi-frame broadcast messageTrimble multi-frame broadcast MTU
The MTU for Trimble multi-frame broadcast messages is 260 bytes. None of the messages that are encapsulated into multi-frame broadcast messages should ever exceed 256 bytes, with the remaining 4 bytes used for the encapsulation.Using the Multi-Frame Broadcast Message Protocol
Requesting a PC_FRIEND relationship
Any device that is planning to transmit broadcast multi-frame messages must identify the device as a friend. A friend to the devices on the CAN bus the messages are intended for.The request is issued using the proprietary message "PC_FRIEND_REQUEST."Note: Since this transmit is a broadcast protocol, there is no mechanism provided to prevent messages from being read by devices or controller applications that do not identify the device as friends.