Application and simulated OBD

  • 776 Views
  • Last Post 22 October 2016
GregF posted this 19 October 2016

I am writing an OBD Simulator and have come to a stop in my development.

I successfully receive messages from your application (via BLE PLX Kiwi3) to which I respond successfully, so far I have received and responded as follows, but after these exchanges I receive no further messages from the iPhone app.

Receive: PIDs mode 0 (2,1,0,0,0,0,0,0)

Respond: 0x7E8, 0, 7, 4, 65, 0, 8, 16, 128, 16

0x7E8 is my own CANid

0 is for standard frame

7 is the length of the message

4 means "answer"

65 is for mode 1 (41h in decimal)

0 is the PID I respond to

8, 16, 128, 16 the flags for the reponse

Receive OBD Standard (2,1,28,0,0,0,0,0)

Response (Same pattern as above): 0x7E8, 0, 4, 4, 65, 28, 3

Receive MIL Light (2,1,1,0,0,0,0,0)

Response: 0x7E8, 0, 7, 4, 65, 1, 0, 0, 0, 0

Receive PIDs mode 9 (2,9,0,0,0,0,0,0)

Response  0x7E8, 0, 7, 4, 73, 0, 192, 192, 0, 0

I suspect one of my responses is missing some information for your application to continue processing ?

Note, it continues to loop asking for PIDs Mode 0, there are no Dynamic Parameters or OBD records in the iOS application after these sequences.

 

Can you help

Many thanks

Greg

 

Order By: Standard | Newest | Votes
Incardoc posted this 20 October 2016

Hi Greg

I can't exactly recognize exact sequences you are sending from the simulator.

Please note that program expect from adapted simple ASCII strings. In case of OBD-II command it should be ​hexadecimal presentation of the response. Each response MUST have termination (or ready) symbol '>'

The response expected to be well formed according to the request command. The key check is done when program analyze response to Mode 01 PID 00 command: so program sends "0100" and expect to receive something like "4100FFFFFFFF>" or "7E8064100FFFFFFFF>"

You could turn on debug logging Menu-Settings-Logging-Debug logging so program will record all in and out data flow. After recording your experimental session you cold send the log by mail with ​Menu-Settings-Logging-Send message for review the process and compare responses from real and simulated adapters. 

 

If have a more questions just send logs for us too, we will try to help!

Thanks!

GregF posted this 21 October 2016

Hi many thanks for your reponse, I will try your suggestions and let you know if I need further help.

Kind regards

Greg

 

Incardoc posted this 21 October 2016

One correction, just missed that's about iPhone version. You should not turn Debug logging, it's automatic, just after experiments use Settings-Send Log

Thanks!

 

GregF posted this 22 October 2016

Hi, after some debugging it seems my response is truncated somewhere.

In response to your 0100 request, I send 0x04, 0x41, 0x00, 0x88, 0x12, 0x80, 0x10 using CANID 0x7E8 and a standard frame, in the logs from the application I see the response you get is only 41008812, so the last two bytes are missing.

Requests for 011C (OBD Standard) work fine, I send 0x04, 0x41, 0x1C, 0x0C and the application accepts it.

So it seems that short responses (1 byte) are ok, but longer ones (7 bytes) aren't.

I've debugged the libraries which interface with my hardware and they appear to be attempting to send the full messages, after that I don't know, it's in the hardware (CAN adapter) which is out of my hands.

I will ask the hardware guys if they are aware of similar issues.

I've sent the log files to your support team separately, I can't paste here due to the NULL characters.

Many thanks

Greg

 

Incardoc posted this 22 October 2016

NOT BINARY. please just STRINGS as you typing in console:​"7E8064100FFFFFFFF>" and with a terminating '>'

that is the exact presentation as it expected at input socket of app