gopoint technology obd programming manual extended sd logger v4 6__22feb2013

DRAFT

V4.6 22 Feb 2013 1

GoPoint OBD Programming Manual The user communicates with the GoPoint OBD II module via a serial data stream over Bluetooth. The GoPoint module relays OBD requests on the appropriate vehicle bus. When the response is received from the vehicle, the GoPoint module relays the response back to the user. There are two different types of command modes: standard and extended. The standard command mode uses functional and physical requests described below. For the standard command mode there is an automatic reading of the RPM every second. While in the standard mode, the command to read vehicle speed is the same for any type of vehicle bus, whereas, while in the extended mode the user must supply the appropriate header bytes for the current vehicle bus. For a CAN vehicle bus, the flow control message is automatically sent for multiframe response messages while in the standard mode. The extended mode gives the user more control and flexibility to send and receive messages. While in the extended mode, OBD II messages can be sent along with any type of message (OEM specific messages). When an extended command is used, the extended mode is entered and the automatic reading of the RPM every second is stopped (see extended command mode section). In the extended mode CAN flow control messages must be set up by the user using the flow control filter messages. When the GoPoint module powers up it is in the standard command mode. There is a three second delay before any discovery of vehicle bus is started. This can allow for a Bluetooth host to connect to the Gopoint module. Then the host can issue an extended command to enter into extended mode before vehicle bus discovery begins (or shortly thereafter).

Functional Requests

While in the standard command mode the user can make a functional request on any of the vehicle bus types. The user makes a functional request using frame ID 0x7DF. This message translates to a functional request on the vehicle bus. The response returned by the GoPoint module will have a frame ID between 0x0000 – 0x00FF. If the vehicle bus is CAN 11-bit ID, the returned response will be between 0x00E8 – 0x00EF. For other buses the returned response frame ID is the source address from the vehicle response message.

Physical Requests

While in the standard command mode, the user can make a physical request for select vehicle buses. For the CAN 11-bit ID vehicle bus, physical requests have a frame ID between 0x07E0 – 0x07E7. These frame IDs translate directly to the vehicle CAN bus.

DRAFT

V4.6 22 Feb 2013 2

For CAN 29-bit ID and ISO 14230 (3-byte address) vehicle buses, the target address on the vehicle bus can be specified using the frame IDs between 0x0000 – 0x00FF. The lower 8-bits of the frame ID are used as the target address on the vehicle bus. If a physical request is attempted on a vehicle bus that is not supported, the following status message is sent:

Not Supported CAN Status Message Example

ID Length Status ID ID MSB ID LSB Byte 0 Byte 1 Byte 2

0x0100 0x06 0x03 0x00 0x20 0x02 0x01 0x0D

The OBD request that caused this status message had an ID of 0x0020 and was performing a Mode 1 read of PID 0x0D. For a physical request, the responses returned are the same as described in the Functional Requests section.

Message Types

Request messages sent by the user to the GoPoint module are always sent in one message (n ot multiple messages). Messages have the following format:

ID MSB ID LSB Length Byte Data Byte 0 …

Data Byte N where 0 <= N <=11

The Length Byte can have values between 0x00 - 0x0C and follows after the 2-byte ID. In the standard command mode the GoPoint module returns the message responses from the vehicle and these are usually single frame messages. However, multiframe responses can also be returned by the GoPoint module (for example, VIN data). On a CAN vehicle bus, multiframe messages are passed unchanged. A length byte always precedes any multiframe message. For example, if an eight-byte consecutive frame message is received, the Length byte would be 0x08 followed by the eight data bytes. When the vehicle sends a first frame message, the GoPoint module automatically sends the flow control back to the vehicle. Next the vehicle sends consecutive frame messages until complete. The following table shows the described frames:

DRAFT

V4.6 22 Feb 2013 3

Address PCI Field Data Field

Byte 1

Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Message Type

CAN ID b7-b4 b3-b0

Single Frame 0x0000- 0x00FF

0 Length Data (Data) (Data) (Data) (Data) (Data) (Data)

First Frame 0x0000- 0x00FF

1 High

Length Length Data Data Data Data Data Data

Consecutive Frame

0x0000- 0x00FF

2 Seq. Num

Data (Data) (Data) (Data) (Data) (Data) (Data)

See ISO 15765-2 for more info on multiframe messages. On non-CAN vehicles, multiple responses are returned by the GoPoint module to the user. Each response is echoed by the GoPoint module as a single frame response. See SAE 1979 for examples on multiple responses. Example If the user wants to read the engine RPM it would send the Mode 1 request with following format:

ID Length Mode PID

0x07DF 0x02 0x01 0x0C

The following response would be returned:

ID Length Mode PID RPM MSB RPM LSB

0x00E8 0x04 0x41 0x0C 0x12 0x34

Three seconds prior to turning off the powering down, the following status message is sent to the user:

Power-down in 3 Seconds Status Message

ID Length Status ID

0x0100 0x01 0x00

There is an eight OBD message request buffer in the GoPoint module. If this buffer is overrun, a status message is sent with the ID of the request that is discarded with its data bytes.

DRAFT

V4.6 22 Feb 2013 4

ID Length Mode PID

0x07DF 0x02 0x01 0x0D

For example, if the above message is sent to the GoPoint module but cannot be stored due to a buffer overrun, the following status message is sent to the user:

OBD Buffer Request Overrun Status Message Example


0x0100 0x06 0x01 0x07 0xDF 0x02 0x01 0x0D

If the GoPoint module does not see an OBD response from the vehicle after a timeout, it will retransmit the OBD request one more time. If no response is received after the retry, the following status message is sent to the user:

OBD No Response Timeout Status Message Example


0x0100 0x06 0x02 0x07 0xDF 0x02 0x01 0x05

The OBD request that caused this status message had an ID of 0x07DF and was performing a Mode 1 read of PID 0x05. A message with ID 0x0100 is a global status message. The Status ID byte follows after the Length byte.

ID Length Status ID Data Data Data

0x0100 XX See Table XX … XX

The following table is a list of the Status IDs:

Status ID Description 0x00 Module power down in 3 seconds 0x01 OBD Command buffer overflow 0x02 No bus response message timeout 0x03 Not supported 0x04 Filters full (extended mode) 0x05 Bad parameter 0x06 Response buffer overrun 0x07 Periodic message buffer overrun

DRAFT

V4.6 22 Feb 2013 5

Not supported (0x03) will be sent while in the extended command mode if a frame ID is 0x07DF, 0x07E0 - 0x07EF, or 0x0000 - 0x00FF. While in extended command mode the Transmit Vehicle message (0x1100) must be used to transmit any message. The Response buffer overrun status ID returns two 16-bit overrun counters. The first overrun counter indicates how many received vehicle bus messages that were received by a filter but were discarded due to a buffer overrun over a one second interval. The other overrun counter is the number of received commands that had responses that were discarded due to a buffer overrun over a one second interval. If the discarded vehicle bus messages counter is seen (nonzero), the user filters might be passing too many messages too fast where messages are lost. If the received command response counter is seen (nonzero), too many commands where sent at once where there was no buffer available to send a response. This case can happen when many vehicle bus messages are being passed by user filters. In this situation only one command should be sent and wait until the command’s response is sent (if it has one) before sending the next command. Both counters are reset back to zero when this status message is transmitted.

Read Connection Information Message ($0700)

The Read Connection Information message (0x0700) is used to read the vehicle bus type, the model number of the OBD II module (GL1, BT1 Apple, BT1 Android, etc.) and the command mode type (standard or extended mode). The vehicle bus type is returned in the Connection Information Response message (0x0708) with the Connection Information Type ID byte set to 0x01. The model number of the OBD II device is returned in the same response message with the Connection Information Type ID byte set to 0x02. The command mode type is returned in the same response message with the Connection Information Type ID byte set to 0x03

Read Vehicle Bus Message

Byte Data Definition

1, 2 0x0700 Message ID

3 0x01 Message length byte

4 B4

Connection Information Type ID byte 0x01 Vehicle bus type request 0x02 Model type request 0x03 Command mode type request

Read Connection Information Response Message ($0708) The Read Connection Information Response message (0x0708) can contain the vehicle bus type, the model number of the OBD II device, or the command mode type depending on the value of the Connection Information Type ID byte. When this byte is set to 0x01, the response message contains the vehicle bus type. When this byte is 0x02, the response message contains the

DRAFT

V4.6 22 Feb 2013 6

model number of the OBD II device. When this byte is 0x03, the response message contains the command mode type. Vehicle Bus Type Response (0x01) The vehicle bus type response message is sent when the Bluetooth host is first connected and when the Read Vehicle Bus message (0x0700) or Configure Vehicle Bus message (0x1700) is sent.

Read Vehicle Bus Type Response Message (no Key Bytes)




4 0x01 Bus type request (Connection Information Type ID)

5 B5 Vehicle bus type enumeration (see table on next page)

Read Vehicle Bus Type Response Message (with Key Bytes)




4 0x01 Bus type request (Connection Information Type ID)

5 B5 Vehicle bus type enumeration (see table on next page)

6, 7 B6 B7 Key bytes (for ISO 9141 or ISO 14230 with initialization only)

Bus Type Vehicle Bus Description 0x00 CAN 11-bit ID, 500 Kbaud 0x01 CAN 29-bit ID, 500 Kbaud 0x02 CAN 11-bit ID, 250 Kbaud 0x03 CAN 29-bit ID, 250 kbaud 0x04 J1850 VPW (GM and Chrysler) 0x05 J1850 PWM (Ford SCP) 0x06 ISO 14230 KWP 5 baud slow initialization 0x07 ISO 9141 5 baud slow initialization 0x08 ISO 14230 KWP fast initialization 0x09 No bus found 0x0A CAN 11-bit ID, 125 Kbaud 0x0B ISO 9141 No initialization 0x0C ISO 14230 No initialization 0xFF Discover vehicle bus now or in discovery mode

DRAFT

V4.6 22 Feb 2013 7

The Bus Type can be used to adjust message response timeouts. For example, K-Line message responses will be slower than CAN and J1850 buses, and would require a longer timeout. Model Number Response (0x02) The model number of the OBD II device can be found in this response message.

Read Model Number Response Message




4 0x02 Model number request (Connection Information Type ID)

5, 6 B5 B6 Model number word (see table below)

Model Number Model Description 9100 (0x238C) GL1 Apple 9105 (0x2391) BT1 Apple 9205 (0x23F5) BT1 Android

Command Mode Type Response (0x03) The model number of the OBD II device can be found in this response message.

Read Command Mode Type Response Message




4 0x03 Command mode type request (Connection Information Type ID)

5 B5 Command mode type 0 – Standard command mode is active 1 – Extended command mode is active

DRAFT

V4.6 22 Feb 2013 8

Read Firmware Message ($0710)

The Read Firmware message (0x0710) is sent to read the current firmware version of the GoPoint module. The Read Firmware Response message (0x0718) is sent back with the current firmware version.

Read Firmware Message




Read Firmware Response Message ($0718)

The Read Firmware Response message (0x0718) is sent as a response to the Read Firmware message (0x0710). In this message, the software major / minor version and 32-bit checksum is returned.

Read Firmware Response Message




4 B4 Software major version byte

5 B5 Software minor version byte

6 – 9 B6 B7 B8 B9 32-bit software version checksum (B6 is MSB, B9 is LSB)

Read Battery Message ($0720)

The Read Battery message (0x0720) is sent to read the current battery voltage of the vehicle. The Read Battery Response message (0x0728) is sent back with the current battery voltage.

Read Battery Message




DRAFT

V4.6 22 Feb 2013 9

Read Battery Response Message ($0728)

The Read Battery Response message (0x0728) is sent as a response to the Read Battery message (0x0720). In this message, the battery voltage is returned as a 16-bit value in hundredths of voltage. The battery voltage returned is the voltage at the J1962 connector of the GoPoint module.

Read Battery Response Message




4, 5 B4 B5 16-bit battery voltage in hundredths of volts

For example, a Read Battery Response could have the following bytes: 0x0728 0x02 0x054C

0x054C is 1356 in decimal which would be 13.56 Volts.

Periodic Transmit Message ($0900)

The Periodic Transmit message (0x0900) is used to transmit periodic messages on the vehicle bus. The maximum number of periodic transmit messages that can be loaded is seen in the byte Maximum number of periodic messages allowed in the Number of Periodic Transmit Messages Used Response message (0x0908). These periodic messages are continuously transmitted at the periodic transmit period. This period can be changed with the Change Period of Periodic Transmit Message (0x0910). A Number of Periodic Transmit Messages Used Response message (0x0908) is sent as a response to the Periodic Transmit message (0x0900). If a message length byte of 0x00 is sent (0x0900 0x00) then all periodic transmit messages are disabled. In the standard command mode the transmitted messages use the appropriate vehicle bus headers. Functional requests use the frame ID 0x07DF. Physical requests can be sent following the format in the section Physical Requests. If the extended command mode is active, the periodic transmit messages are transmitted as is. See the Transmit Vehicle Message (0x1100) on the message format for the periodic messages while in the extended mode.

DRAFT

V4.6 22 Feb 2013 10

Periodic Transmit Message



3 B3 Message length byte (1 - 12)

4 b7 --- ----

For Extended CAN ID (29-bit) this bit is set to 1; otherwise this bit is used as data for non-CAN buses

- b6b5b4 b3b2b1b0 CAN ID bits or header bits

5 – N B5 … BN Message data bytes (where 5 <= N <= 15)

When the command mode changes from standard to extended mode or vice versa, all periodic messages are cleared. If a certain Pid is desired to be read more than other Pids, just add multiple periodic messages of that Pid. For example, the following periodic messages could be configured:

Send periodic transmit RPM message Send periodic transmit vehicle speed message Send periodic transmit RPM message Send periodic transmit MAP message

Then the periodic messages would be transmitted in this order:

RPM, vehicle speed, RPM, MAP, RPM, vehicle speed, RPM, … Periodic Transmit Message Example in Standard Mode The following example is for transmitting periodic messages while in the standard mode: The following byte sequence: 0x0900 0x05 0x07 0xDF 0x02 0x01 0x0D

Would be sent to periodically transmit the vehicle speed request on the current vehicle bus (assuming a valid bus is active). Periodic Transmit Message Examples in Extended Mode The following examples are for transmitting periodic messages while in the extended mode: The following byte sequence: 0x0900 0x0C 0x98 0xDB 0x33 0xF1 0x02 0x01 0x0D 0x00 0x00 0x00 0x00 0x00

Would be sent to periodically transmit the following extended (29-bit) CAN ID message: 0x18DB33F1 (ID) 0x02 0x01 0x0D 0x00 0x00 0x00 0x00 0x00 (8 data bytes)

DRAFT

V4.6 22 Feb 2013 11

The following byte sequence: 0x0900 0x0A 0x07 0xDF 0x02 0x01 0x0C 0x00 0x00 0x00 0x00 0x00

Would be sent to periodically transmit the following standard (11-bit) CAN ID message: 0x7DF (ID) 0x02 0x01 0x0C 0x00 0x00 0x00 0x00 0x00 (8 data bytes)

The following byte sequence: 0x0900 0x05 0x61 0x6A 0xF1 0x01 0x0D

Would be sent to periodically transmit the following J1850 PWM message: 0x61 0x6A 0xF1 0x01 0x0D (5 bytes including header) 0x8B (CRC) If a response with a target byte of 0x6B is received then an IFR byte of 0xF1 will be sent. The following byte sequence: 0x0900 0x05 0xC2 0x33 0xF1 0x01 0x0D

Would be sent to transmit the following ISO 14230 message: 0xC2 0x33 0xF1 0x01 0x0D ( 5 bytes including header) 0xF4 (Checksum)

Read Number of Periodic Transmit Messages Used Message ($0904) The Read Number of Periodic Transmit Messages Used message (0x0904) requests the number of periodic transmit messages used. The number of periodic transmit messages used is returned in the Number of Periodic Transmit Messages Used Response message (0x0908).

Read Number of Periodic Transmit Messages Used Message




Number of Periodic Transmit Messages Used Response Message ($0908)

The Number of Periodic Transmit Messages Used Response message (0x0908) is sent as a response to the Periodic Transmit message (0x0900) or the Read Number of Periodic Transmit Messages Used message (0x0904).

DRAFT

V4.6 22 Feb 2013 12

Number of Periodic Transmit Messages Used Response Message




4 B4 Number of periodic messages used

5 B5 Maximum number of periodic messages allowed

Change Period of Periodic Transmit Message ($0910) The Change Period of Periodic Transmit Message (0x0910) is used to change the period of the periodic transmit messages on the vehicle bus. Different vehicle buses have different default periods and minimum periods. For CAN buses the default period is 100 msec and the minimum is 1 msec. For J1850 buses the default period is 100 msec and the minimum is 5 msec. For K-Line buses (ISO 9141, ISO 14230), the default period is 500 msec and the minimum is the P3 time (default 55 msec) (see Read K-Line Timing Response message (0x1308)). If a period is less than the minimum period for the current bus, the period will be set to the minimum. Extreme care must be used when using this message because if too fast of a period is used, the vehicle bus could be flooded with periodic messages and halt vehicle functionality. When the vehicle bus is initialized (for example, using the Configure Vehicle Bus message (0x1700)), the period is set to its default value.

Change Period of Periodic Transmit Message




4, 5 B4 B5 16-bit time in msec for period of periodic transmit messages (B4 is MSB)

DRAFT

V4.6 22 Feb 2013 13

Read Period of Periodic Transmit Message ($0914)

The Read Period of Periodic Transmit Message (0x0914) requests the period of the periodic transmit messages. The period is returned in the Period of Periodic Transmit Messages Response message (0x0918).

Read Period of Periodic Transmit Messages Message




Period of Periodic Transmit Messages Response Message ($0918)

The Period of Periodic Transmit Messages Response message (0x0918) is sent as a response to the Change Period of Periodic Transmit Message (0x0910) or the Read Period of Periodic Transmit Message (0x0914).

Period of Periodic Transmit Messages Response Message




4, 5 B4 B5 16-bit time in msec for period of periodic transmit messages (B4 is MSB)

DRAFT

V4.6 22 Feb 2013 14

Extended Command Set

The extended command set is a group of special commands that allow total control of messages transmitted and received on the vehicle bus. An extended command has a command ID that is in the range of 0x1000 through 0x1FFF. Data is sent as big endian (most significant byte (MSB) first). For example, for 32-bit quantities, the most significant byte (MSB) starts first and ends with the least significant byte (LSB). When an extended command is sent, the extended command mode is entered where there is no automatic reading of the RPM, so if the vehicle bus is ISO 9141 for example, the user must periodically transmit a vehicle bus message less than every 5 seconds so the module does not time out. Also when in this extended mode, there are no retransmissions of vehicle messages when no response is seen. In this mode there is no time minimums between back-to-back transmitted requests, for example, the 100 msec time requirement for back-to-back transmitted requests is not enforced. When the GoPoint module comes out of a reset, the Bluetooth radio is turned on and there is a 3 second delay before the vehicle bus is initialized or 1 second delay after the iPhone authenticates. This delay allows the iPhone to authenticate and then send an extended command like Configure Vehicle Bus Message (0x1700) to set the bus to No Bus (0x09) before the vehicle bus is initialized. By sending an extended command, the extended mode will be entered and there is no periodic RPM message, message timeouts or retransmissions. Then the proper vehicle bus can be configured and then initialized. If the GoPoint module is in vehicle bus discovery mode when the extended mode is entered, the vehicle bus type will be sent to no bus (0x09) and discovery mode is halted. The extended mode exits and returns to standard mode when either the Bluetooth host is disconnected or when the iPhone’s data session closes (pressing the menu button). Abbreviations and symbols used in message descriptions: B3 refers to byte 3 b7 refers to bit 7 $34 refers to 34base16 0x34 refers to 34base16

$5x where x is a don’t care hexadecimal nibble ($0 - $F)

DRAFT

V4.6 22 Feb 2013 15

Receive Vehicle Message (0x1000)

The Receive Vehicle message contains the received vehicle message for the current vehicle bus mode. Only messages that have a correct CRC or checksum are returned. All of the message data that is returned is unprocessed. However, for CAN buses, the message CRC is not returned. For J1850 messages the CRC is returned; however, for J1850 PWM, the In Frame Response (IFR) bytes are not returned. For ISO 9141 and ISO 14230, the message checksum is returned. A Receive Vehicle message is only sent when the received vehicle message passes a user filter defined by the User Filter message (0x1200). If the vehicle bus is a CAN bus and an extended CAN ID (29-bit) is received, the most significant bit of the byte containing the ID bits 24-28 will be set. Starting with byte 4, the first 4 data bytes make up the extended CAN ID. If a standard CAN ID message is received the most significant bit is not set in byte 4 and the ID will be in the byte 4 and byte 5.

Receive Vehicle Message




4 b7 --- ----

For Extended CAN ID (29-bit) this bit is set to 1; otherwise this bit is used as data for non-CAN buses


5 - N B5 … BN Message data bytes (where 5 <= N <= 15)

Receive Vehicle Message Examples The following byte sequence: 0x1000 0x0A 0x92 0x34 0x56 0x78 0xAB 0xCD 0xEF 0x40 0x50 0x60

would be received for the following extended (29-bit) CAN message: 0x12345678 (ID) 0xAB 0xCD 0xEF 0x40 0x50 0x60 (6 data bytes)

The following byte sequence: 0x1000 0x0A 0x07 0xE8 0x41 0x0C 0x12 0x34 0x00 0x00 0x00 0x00

would be received for the following standard (11-bit) CAN message: 0x7E8 (ID) 0x41 0x0C 0x12 0x34 0x00 0x00 0x00 0x00 (8 data bytes)

The following byte sequence: 0x1000 0x08 0x41 0x6B 0x10 0x41 0x0C 0x74 0x80 0xFC

would be received for the following J1850 PWM message: 0x41 0x6B 0x10 0x41 0x0C 0x74 0x80 (7 bytes including header) 0xFC (CRC)

DRAFT

V4.6 22 Feb 2013 16

Transmit Vehicle Message (0x1100)

The Transmit Vehicle message is used to transmit a vehicle message for the current vehicle bus mode. For CAN messages, bit 7 of byte 4 is set to indicate an extended (29-bit) CAN ID and uses 4 bytes for the 29-bit ID (bytes 4 - 7). Standard (11-bit) CAN messages have bit 7 of byte 4 cleared and uses 2 bytes for the 11-bit ID (bytes 4 -5). For CAN messages, a 2 or 4 byte ID with up to 8 data bytes can be transmitted. Transmitted CAN messages are not echoed back by the GoPoint module. For J1850 messages, the message CRC is automatically calculated and transmitted. For a transmitted J1850 PWM message, the source address (3rd data byte transmitted (byte 6)) is used for the In-Frame Response (IFR) of the vehicle response message only if the vehicle response message has a target address (2nd data byte transmitted (byte 5)) + 1 (see example below). IFR bytes will be transmitted up to 1 second after the transmitted message was successful. For J1850 messages, the maximum message length is 12 bytes so up to 10 data bytes (automatic CRC and IFR) or 11 data bytes (automatic CRC) can be sent. Also a J1850 transmitted message can be seen in a Receive Vehicle message (0x1000), if the user filters are configured to pass this message. For ISO 9141 and ISO 14230 messages, the message checksum is automatically calculated and transmitted. However, for ISO 14230 messages, all of the header bytes (format byte, target address byte, source address byte, and extra length byte) are supplied by the user. This gives the user the flexibility of sending messages that have 1 to 4 header bytes. The user has to ensure that the length supplied (either in the format byte or extra length byte) is correct. For ISO 9141 and ISO 14230 messages, the maximum message length is 12 bytes so up to 11 data bytes can be sent (automatic checksum). If a Transmit Vehicle message is sent when the vehicle bus type is no bus, then the 0x100 error status message with bad parameter will be sent.

Transmit Vehicle Message




4 b7 --- ----

For Extended CAN ID (29-bit) when set to 1; otherwise this bit is used as data for non-CAN buses


5 – N B5 … BN Message data bytes (where 5 <= N <= 15)

DRAFT

V4.6 22 Feb 2013 17

Transmit Vehicle Message Examples The following byte sequence: 0x1100 0x0C 0x98 0xDB 0x33 0xF1 0x02 0x01 0x0D 0x00 0x00 0x00 0x00 0x00

Would be sent to transmit the following extended (29-bit) CAN ID message: 0x18DB33F1 (ID) 0x02 0x01 0x0D 0x00 0x00 0x00 0x00 0x00 (8 data bytes)

The following byte sequence: 0x1100 0x0A 0x07 0xDF 0x02 0x01 0x0C 0x00 0x00 0x00 0x00 0x00

Would be sent to transmit the following standard (11-bit) CAN ID message: 0x7DF (ID) 0x02 0x01 0x0C 0x00 0x00 0x00 0x00 0x00 (8 data bytes)

The following byte sequence: 0x1100 0x05 0x61 0x6A 0xF1 0x01 0x0D

Would be sent to transmit the following J1850 PWM message: 0x61 0x6A 0xF1 0x01 0x0D (5 bytes including header) 0x8B (CRC) If a response with a target byte of 0x6B is received then an IFR byte of 0xF1 will be sent. The following byte sequence: 0x1100 0x05 0xC2 0x33 0xF1 0x01 0x0D

Would be sent to transmit the following ISO 14230 message: 0xC2 0x33 0xF1 0x01 0x0D (5 bytes including header) 0xF4 (Checksum)

User Filter Message (0x1200)

The User Filter message is used to define filters for what messages are returned back via Received Vehicle Messages (0x1000). If a message length byte of 0x00 is sent (0x1200 0x00) then all of the user filters are cleared and no messages are passed. A User Filter Response message (0x1208) is sent as a response to the User Filter message. In this message, the number of user filters configured is sent. Once all of the filters have been configured, any User Filter message sent thereafter will result in a 0x100 error status message. When a filter is configured for extended CAN IDs, the filter length must be set to 4 bytes.

DRAFT

V4.6 22 Feb 2013 18

User Filter Message




4

b7 --- - --- Extended CAN ID (29-bit) when set to 1

- b6b5b4 b3 --- Unused bits

- --- - b2b1b0 Filter length in bytes (valid range: 1 - 4)

5 - 8 B5 B6 B7 B8 32-bit filter mask (B5 is MSB, B8 is LSB)

9 - 12 B9 B10 B11 B12 32-bit filter data value (B9 is MSB, B12 is LSB)

The following table shows what filter mask byte(s) and filter data value(s) need to be supplied for various filter lengths.

Filter Length Mask Bytes Data Value Bytes

1 B8 B12

2 B7 B8 B11 B12

3 B6 B7 B8 B10 B11 B12

4 B5 B6 B7 B8 B9 B10 B11 B12

When filtering J1850 messages or ISO 9141 / 14230 messages, the first listed byte will pair with the first byte of the message. For example, for a 3 byte filter, B6 and B10 will be used on the first message byte; B7 and B11 will be used on the second message byte and B8 and B12 will be used on the third message byte. User Filter Message Examples The following data sequence defines a user filter for a 29-bit CAN message ($18DAxx10): 0x1200 0x09 0x84 0x1FFF00FF 0x18DA0010

The following data sequence defines a user filter for an 11-bit CAN message ($5xx): 0x1200 0x09 0x02 0x00000700 0x0x00000500

The following data sequence defines a user filter for a J1850 message ($48 $xx $10): 0x1200 0x09 0x03 0x00FF00FF 0x0x00480010

DRAFT

V4.6 22 Feb 2013 19

Read Number of User Filters Used Message ($1204)

The Read Number of User Filters Used message (0x1204) requests the number of user filters used. The number of user filters used is returned in the User Filter Response message (0x1208).

Read Number of User Filters Used Message




User Filter Response Message ($1208)

The User Filter Response message (0x1208) is sent as a response to the User Filter message (0x1200) or the Read Number of User Filters Used message (0x1204). In this message, the number of user filters configured is sent. The maximum number of user filters allowed to be configured is returned in the Maximum number of user filters allowed byte.

User Filter Response Message




4 B4 Number of user filters used (valid range: 0 - 16)

5 B5 Maximum number of user filters allowed

Flow Control Filter Message (0x1210)

The Flow Control Filter message is used to define a First Frame / Flow Control Frame ID pair. These filters are only used on CAN vehicle buses for when multiframe data is needed. When the First Frame ID is seen on the bus, then the Flow Control Frame ID will be automatically transmitted. If a message length byte of 0x00 is sent (0x1210 0x00) then all of the flow control filters are cleared and no Flow Control Frames are transmitted. A Flow Control Filter Response message (0x1218) is sent as a response to the Flow Control Filter message. In this message, the number of user flow control filters configured is sent. Once all of the filters have been configured, any Flow Control Filter message sent thereafter will result in a 0x100 error message.

DRAFT

V4.6 22 Feb 2013 20

When a filter is configured for extended CAN IDs, bit 7 of byte 4 (extended CAN ID bit) must be set to 1.

Flow Control Filter Message




4 b7 --- ---- Extended CAN ID (29-bit) when set to 1

- b6b5b4 b3b2b1b0 Unused bits

5 - 8 B5 B6 B7 B8 32-bit First Frame ID bytes (B5 is MSB, B8 is LSB)

9 - 12 B9 B10 B11 B12 32-bit Flow Control ID bytes (B9 is MSB, B12 is LSB)

Flow Control Filter Message Examples The following data sequence defines a flow control filter for a 29-bit CAN messages with a First Frame ID of 0x18DAF110 and a Flow Control ID of 0x18DA10F1: 0x1210 0x09 0x80 0x18DAF110 0x18DA10F1

The following data sequence defines a flow control filter for an 11-bit CAN messages with a First Frame ID of 0x7E9 and a Flow Control ID of 0x7E1: 0x1210 0x09 0x00 0x000007E9 0x000007E1

Read Number of Flow Control Filters Used Message ($1214)

The Read Number of Flow Control Filters Used message (0x1214) requests the number of flow control filters used. The number of flow control filters used is returned in the Flow Control Filter Response message (0x1218).

Read Number of Flow Control Filters Used Message




DRAFT

V4.6 22 Feb 2013 21

Flow Control Filter Response Message ($1218)

The Flow Control Filter Response message (0x1218) is sent as a response to the Flow Control Filter message (0x1210). In this message, the number of flow control filters configured is sent. The maximum number of flow control filters allowed to be configured is returned in the Maximum number of flow control filters allowed byte.

Flow Control Filter Response Message




4 B4 Number of flow control filters used (valid range: 0 - 16)

5 B5 Maximum number of flow control filters allowed

Configure K-Line Timing Message ($1300)

The Configure K-Line Timing message (0x1300) is sent to change the K-Line timing parameters, P3 and P4 and the end-of-message time. Before changing any of these parameters, the current K-Line timing parameters can be read by using the Read K-Line Timing message (0x1304). Then the parameters that will not be changed can be supplied with the previously read values in the Configure K-Line Timing message. A Read K-Line Timing Response message (0x1308) is sent as a response to the Configure K-Line Timing message. The end-of-message time is used to determine the end of a message response from an ECU. This timing parameter is similar to the P2 time except that it does not apply to the time between the tester (GoPoint module) request and ECU response (can be 0) but it does apply to the time between two ECU responses. If the time between the two received bytes exceeds this end-of-message time, the latter byte received is used as the start of another ECU response message. Care must be used when changing this parameter. This time cannot be shorter than the inter-byte time of the ECU (P1) or each byte would be considered a start of a new message. This end-of-message time is especially important for ISO 9141 messages because of no length byte in the message data. The P3 timing parameter is the time between the end of an ECU response and the start of the tester (GoPoint module) new request. This time will be waited before transmitting another (tester) message. When periodic messages are active, the period of the periodic transmit messages cannot be faster than the P3 timing value. The P4 timing parameter is the inter-byte time of the GoPoint’s transmitted messages.

DRAFT

V4.6 22 Feb 2013 22

Configure K-Line Timing Message




4, 5 B4 B5 16-bit time in msec for end-of-message time (ISO 9141)

6, 7 B6 B7 16-bit time in msec for P3 time (ECU response to GoPoint request)

8, 9 B8 B9 16-bit time in msec for P4 time (GoPoint module inter-byte time)

Read K-Line Timing Message ($1304) The Read K-Line Timing message (0x1304) is sent to read the current settings of the K-Line timing parameters. These timing parameters are returned in the Read K-Line Timing Response message (0x1308). The timing parameters can be read before modifying them with the Configure K-Line Timing message (0x1300).

Read K-Line Timing Message




Read K-Line Timing Response Message ($1308)

The Read K-Line Timing Response message (0x1308) contains the read K-Line timing parameters. This message is sent as a response to Configure K-Line Timing message (0x1300) or the Read K-Line Timing message (0x1304). For a description of the K-Line timing parameters, see the Configure K-Line Timing message (0x1300).

DRAFT

V4.6 22 Feb 2013 23

Read K-Line Timing Response Message




4, 5 B4 B5 16-bit time in msec for end-of-message time (ISO 9141)

6, 7 B6 B7 16-bit time in msec for P3 time (ECU response to GoPoint request)

8, 9 B8 B9 16-bit time in msec for P4 time (GoPoint module inter-byte time)

Configure K-Line Baud Rate Message ($1310) The Configure K-Line Baud Rate message (0x1310) is used to change the K-Line baud rate. The default baud rate is 10400 baud. The 16-bit desired baud rate is sent in bytes 4 and 5. The K-Line Baud Rate Response message (0x1318) is sent as a response to the Configure K-Line Baud Rate message (0x1310).

Configure K-Line Baud Rate Message




4, 5 B4 B5 16-bit desired baud rate (valid range: 300 - 19200) (B4 is MSB)

Read K-Line Baud Rate Message ($1314) The Read K-Line Baud Rate message (0x1314) is sent to read the current baud rate of the K-Line bus. The baud rate is returned in the K-Line Baud Rate Response message (0x1318).

Read K-Line Baud Rate Message




DRAFT

V4.6 22 Feb 2013 24

K-Line Baud Rate Response Message ($1318)

The K-Line Baud Rate Response message (0x1318) is sent as a response to the Configure K-Line Baud Rate message (0x1310). In this message, the 16-bit actual calculated K-Line baud rate is returned in bytes 4 and 5.

K-Line Baud Rate Response Message




4, 5 B4 B5 16-bit actual baud rate (B4 is MSB)

Configure Vehicle Bus Message ($1700)

The Configure Vehicle Bus message (0x1700) is used to change the vehicle bus. When a bus is selected by this message, the extended mode is entered and the GoPoint module will not power down if vehicle bus messages are not seen (see Extended Command Set description). When the vehicle bus is initialized, the Vehicle Bus Type Response message (0x0708) is sent (this message is not sent if an ISO bus with initialization does not initialize correctly). When a bus type of 0xFF (discover bus now) is sent, the bus types with values between 0x00 (CAN 11-bit 500Kbaud) through 0x08 (ISO 14230 KWP fast init) is attempted to be discovered by sending a Mode 1, PID 0x0C (RPM). When a bus is discovered, the Vehicle Bus Type Response message (0x0708) is sent (no bus will be sent if no bus is discovered). If message filters are opened, J1850 messages that are transmitted in order to discover the bus will be echoed.

Configure Vehicle Bus Message




4 B4 Vehicle bus type enumeration (see table below)

DRAFT

V4.6 22 Feb 2013 25

Bus Type Vehicle Bus Description 0x00 CAN 11-bit ID, 500 Kbaud 0x01 CAN 29-bit ID, 500 Kbaud 0x02 CAN 11-bit ID, 250 Kbaud 0x03 CAN 29-bit ID, 250 kbaud 0x04 J1850 VPW (GM and Chrysler) 0x05 J1850 PWM (Ford SCP) 0x06 ISO 14230 KWP 5 baud slow initialization 0x07 ISO 9141 5 baud slow initialization 0x08 ISO 14230 KWP fast initialization 0x09 No bus or halt discovery mode 0x0A CAN 11-bit ID, 125 Kbaud 0x0B ISO 9141 No initialization 0x0C ISO 14230 No initialization 0xFF Discover vehicle bus now

Reset Message ($1FFF) The Reset message (0x1FFF) is sent to reset the GoPoint module. The Bluetooth host is disconnected first, then the reset occurs.

Reset Message


1, 2 0x1FFF Message ID


DRAFT

V4.6 22 Feb 2013 26

SD Logging Commands With the SD hardware version, vehicle messages are logged to the SD card when there is no active iPhone data session. Logging is temporarily halted when iPhone authentication is occurring. Once authentication is complete, logging will resume and continue until a data session is opened. Logging to the SD card is stopped when a valid iPhone data session is opened. The user sets user filters to pass vehicle bus messages via Bluetooth or to log them to the SD card. When a valid iPhone data session is opened, the vehicle bus messages are sent via Received Vehicle Messages (0x1000). When logging is active (no data session), vehicle bus messages are logged to the SD card with an 8-byte time stamp and a 4-byte record number. These logged vehicle bus messages can later be read by opening a data session and sending a Download Records from SD File message (0x1860) and then monitoring the Logged Vehicle Bus messages (0x1800) that are sent. Everytime the GoPoint SD logger module has a reset (unplugged and plugged back in), a new SD file is created for logging. SD files are accessed through a file number. Files start with file number 1 and go through 65535. When the SD logger resets, a new SD file number will be incremented if the previous SD file had records in it. For example, if File #3 had 1000 records, and a reset occurred, then File #4 would be logged to once the user filters are configured by the iPhone. Each vehicle bus message that is logged to the current SD file has a unique 4-byte record number. Each record number starts at one and increase sequentially. The Get Number of SD Files message (0x1820) gets the number of files on the SD card. The number of records an SD file has can be read through the Get Number of Records in SD File message (0x1830). Once the total of number of file records is known, all of the file records or a portion of the file records can be downloaded via the Download Records from SD File message (0x1850). If a large number of file records is being downloaded, the process can be terminated by the Abort Download message (1852). When downloading SD records, the Received Vehicle Messages (0x1000) are not sent to the iPhone. To erase all the logging files on the SD card, the Erase All Files message (0x1840) is sent. When vehicle bus messages are being logged, an 8-byte time stamp is saved for each logged message. This 8-byte time stamp is incremented every 1 msec and can be loaded with an 8-byte value via the Set Logging Time Stamp (0x1860) message. The 8-byte time stamp is reset to 0 at reset and should be reloaded when the user filters are configured. Each SD command has a response and the host should wait for that response before sending another command.

DRAFT

V4.6 22 Feb 2013 27

Since data is being logged to the SD card, care must be taken when unplugging the GoPoint SD logger to avoid any SD file corruptions. There are two cases when the SD logger can be safely unplugged:

1) When the SD logger is in sleep mode (no LEDs on and red LED is faintly blinking every one second)

2) When an iPhone data session is opened (logging is stopped)

Logged Vehicle Bus Message (0x1800) The Logged Vehicle Bus message contains the logged CAN vehicle bus message that was saved to the SD card. The vehicle message format follows the message format in the Receive Vehicle message (0x1000). For vehicle bus messages to be logged to the SD card, the user filters must be configured (User Filter message (0x1200)) so messages can be logged. This message is sent when an SD file is being downloaded to the host. If an extended CAN ID (29-bit) is received, the most significant bit of the byte containing the ID bits 24-28 will be set. Starting with byte 16 (MSB), the first 4 data bytes (bytes 16 - 19) make up the extended CAN ID. If a standard CAN ID message is received the most significant bit is not set in byte 16 (MSB) and the ID will be in the bytes 16 - 17. The 1-byte CRC byte follows after the CAN message data and uses the SAE J1850 polynomial. The CRC is computed over all of the message bytes (included 16-bit message ID and length byte).

Logged Vehicle Bus Message




4 - 11 B4 B5 B6 B7 B8 B9 B10 B11 8-byte time stamp in msec. (B4 is MSB and B11 is LSB)

12 - 15 B12 B13 B14 B15 4-byte record number starting with record 1 (B12 is MSB and B15 is LSB)

16 b7 --- ----

For Extended CAN ID (29-bit) this bit is set to 1; otherwise this bit is 0 for Standard CAN ID (11-bit) messages

- b6b5b4 b3b2b1b0 CAN ID bits

17 - N B17 … BN Message data bytes (where 17 <= N <= 27)

N+1 BN+1 8-bit CRC byte (uses SAE J1850 polynomial)

DRAFT

V4.6 22 Feb 2013 28

Logged Vehicle Bus Message Examples The following byte sequence: 0x1800 0x19 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x87 0x65 0x43

0x21 0x92 0x34 0x56 0x78 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x23

would be received for the following extended (29-bit) CAN message: 0x12345678 (ID) 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 (8 data bytes)

and has an 8-byte time stamp of 0x1122334455667788 and a 4-byte record number of 0x87654321

and a CRC byte of 0x23 The following byte sequence: 0x1800 0x17 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x87 0x65 0x43

0x21 0x07 0xE8 0x41 0x0C 0x12 0x34 0x00 0x00 0x00 0x00 0x77

would be received for the following standard (11-bit) CAN message: 0x7E8 (ID) 0x41 0x0C 0x12 0x34 0x00 0x00 0x00 0x00 (8 data bytes)

and has an 8-byte time stamp of 0x1122334455667788 and a 4-byte record number of 0x87654321

and a CRC byte of 0x77

Logged SD Status Message (0x1810)

The Logged SD Status message contains SD status information. The 16-bit SD buffer overrun counter indicates how many received vehicle bus messages that were received by a filter but were discarded due to a buffer overrun over a one second interval. This overrun counter is cleared to zero after the status message is logged. This message is sent when an SD file is being downloaded to the host. The 1-byte CRC byte follows after the 16-bit overrun counter and uses the SAE J1850 polynomial. The CRC is computed over all of the message bytes (included 16-bit message ID and length byte).

Logged SD Status Message



3 0x0F Message length byte (15 bytes)

4 - 11 B4 B5 B6 B7 B8 B9 B10 B11 8-byte time stamp in msec. (B4 is MSB and B11 is LSB)

12 - 15 B12 B13 B14 B15 4-byte record number starting with record 1 (B12 is MSB and B15 is LSB)

16 – 17 B16 B17 16-bit SD buffer overrun counter (B16 is MSB)

18 B18 8-bit CRC byte (uses SAE J1850 polynomial)

DRAFT

V4.6 22 Feb 2013 29

Logged SD Status Message Example The following byte sequence: 0x1810 0x0F 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x87 0x65 0x43

0x21 0x10 0x20 0x29

would be received for a status overrun counter of 0x1020 and has an 8-byte time stamp of 0x1122334455667788 and a 4-byte record number of 0x87654321 and a CRC byte of 0x29

Get Number of SD Files Message ($1820)

The Get Number of SD Files message (0x1820) requests the total number of files that exist on the SD card. Files are accessed by a file number. A valid file number is from 1 to 65535. The Number of SD Files Response message (0x1828) returns the total number of SD files.

Get Number of SD Files Message




Number of SD Files Response Message ($1828)

The Number of SD Files Response message (0x1828) is sent as a response to the Get Number of SD Files message (0x1820). Files are accessed by a file number. A valid file number is from 1 to 65535. If zero is returned then that is write problem with the SD card.

Number of SD Files Response Message




4, 5 B4 B5 Total number of SD files (B4 is MSB)

DRAFT

V4.6 22 Feb 2013 30

Get Number of Records in SD File Message ($1830)

The Get Number of Records in SD File message (0x1830) requests the total number of records in the requested file number that exists on the SD card. Files are accessed by a file number. A valid file number is from 1 to 65535. The Number of Records in SD File Response message (0x1838) returns the total number of records.

Get Number of Records in SD File Message




4, 5 B4 B5 SD file number to get number of records (B4 is MSB)

Number of Records in SD File Response Message ($1838)

The Number of Records in SD File Response message (0x1838) is sent as a response to the Get Number of Records in SD File message (0x1830). If the number of records returned is 0 then the log file has no records (after a reset but no user filters configured). Since each log file is limited in size there will never be a number of records near the maximum number of record. So error results use the following 4-byte number of records: 0xFFFFFFFF Bad parameter (illegal file number) 0xFFFFFFFE SD card error 0xFFFFFFFD File size error (not multiple of record size)

Number of Records in SD File Response Message




4 - 7 B4 B5 B6 B7 Total number of records in SD file (B4 is MSB and B7 is LSB)

DRAFT

V4.6 22 Feb 2013 31

Erase All SD Files Message ($1840)

The Erase All SD Files message (0x1840) erases all of the files on the SD card. The SD Status message (0x1888) is sent with either the erase complete status byte when all of the files have been erased or the erase error status byte if an error occurred while erasing.

Erase All SD Files Message




Download Records from SD File Message ($1850)

The Download Records from SD File message (0x1850) is sent to download records from the SD file specified in this command. Files are accessed by a file number. A valid file number is from 1 to 65535. Records are downloaded from the start record number to and including the end record number. If the start record number or end record number is invalid, the SD Status message (0x1888) is sent. When all of the records have been sent, the SD Status message (0x1888) is sent indicating the downloading is complete. When downloading SD records, the Received Vehicle Messages (0x1000) are not sent to the iPhone. Also only one file can be downloaded at a time.

Download Records from SD File Message



3 0x0A Message length byte

4, 5 B4 B5 SD file number (B4 is MSB)

6 - 9 B6 B7 B8 B9 Start record number (B6 is MSB and B9 is LSB)

10 - 13 B10 B11 B12 B13 End record number (B10 is MSB and B13 is LSB)

DRAFT

V4.6 22 Feb 2013 32

Abort Downloading Message ($1852)

The Abort Downloading message (0x1852) is sent to abort a downloading that was started with the Download Records from SD File message (0x1850). This command could be used to stop a time consuming download. The SD Status message (0x1888) is sent with either the downloading aborted status byte when this command is sent.

Abort Downloading Message




Set Logging Time Stamp Message ($1860)

The Set Logging Time Stamp message (0x1860) is used to change the 8-byte time stamp that is used when CAN messages are logged to the SD card. This 8-byte time stamp is in msec and is incremented every msec. The Current Logging Time Stamp Response message (0x1868) is sent as a response to this command with the current logging time stamp.

Set Logging Time Stamp Message




4 - 11 B4 B5 B6 B7 B8 B9 B10 B11 New 8-byte time stamp in msec. (B4 is MSB and B11 is LSB)

DRAFT

V4.6 22 Feb 2013 33

Get Current Logging Time Stamp Message ($1864)

The Get Current Logging Time Stamp message (0x1864) requests the current 8-byte logging time stamp. This 8-byte time stamp is in msec and is incremented every msec. The Current Logging Time Stamp Response message (0x1868) is sent as a response to this command with the current logging time stamp.

Get Current Logging Time Stamp Message




Current Logging Time Stamp Response Message ($1868)

The Current Logging Time Stamp Response message (0x1868) sent as a response to the Set Logging Time Stamp message (0x1860) or the Get Current Logging Time Stamp message (0x1864). The 8-byte time stamp returned is in msec and is incremented every msec.

Current Logging Time Stamp Response Message




4 - 11 B4 B5 B6 B7 B8 B9 B10 B11 Current 8-byte time stamp in msec. (B4 is MSB and B11 is LSB)

DRAFT

V4.6 22 Feb 2013 34

SD Status Message ($1888)

The SD Status message (0x1888) is sent for various commands. This message is sent after an Erase All SD Files message (0x1840) to indicate when all of the SD files have been erased on the SD card or that an error occurred while erasing. This message is also sent after a Download Records from SD File message (0x1850) to indicate when downloading is complete, when a downloading error occurred, or when downloading was aborted.

SD Status Message




4 B4

SD Status byte 0 – Special debug status 1 – All SD files are erased 2 – Erase error occurred 3 – Download complete 4 – Download error occurred (SD access) 5 – Download aborted 6 – Bad download parameter 7 – SD command not processed

gopoint technology obd programming manual extended sd logger v4 6__22feb2013

Automotive

id vehicle bus

appropriate vehicle

vehicle bus discovery

discovery of vehicle

type of vehicle bus

vehicle response message

standard mode

standard command mode