Software On ELM Street - OBD2 Software Development

[Jayme]

Tazzi, do any of those logs above include the DPID setup and firing off packets? in vpw, mode 2C is DPID setup then you have 8 DPIDs from F7 to FE and 6 bytes in each DPID. then once setup you then request a DPID packet using mode 2A. I dont see anything like this in the above logs. does the VZ use a way different system?

[Tazzi]

The CANDI didnt even light up when I first plugged it in and turned the tech2 on. I know then that when the CANDI is working correctly, the tech2 will display a "CANDI attached" on the main startup screen. My VCI module (where the tech2 cards go into) is a bit dodgey as my mate rested the tech2 on the steering wheel an the cable on the seat..which then fell.. causing it to damage the serial pins.. so my cable has to be positioned perfectly for communication to work again *sigh* Will have to pick another module up sometime soon. Will be happy to donate the dodgey one to someone if they want a go at fixing it? Pretty sure it only needs a new serial connector soldered on.


Brilliant! Yeah well knowing what each ECU communicates over is my main aim at the moment.. it would be nice to add a simple car definition box and let the software automate the protocol choice ect. Id assume the VZ LS1 vehicles would communciate over VPW? And the 6L would also be CAN.. wouldnt have a cue if it would be 11bit or 29bit?
But yeah, I chuck up a log of the DPID setup momentarily.

*Edit,
Nah havent posted them up yet Jayme, Just about to grab a new set of logs now since I was way too tired at 2am lat night haha. (was a tad excited playing with this stuff).
It looks quite similar to the VPW stuff, you can see it designating the 8PIDS (FE,FC ect)

[Jayme]

yeah the 5.7 VZ is literally the same PCM as the VY, it just has a 1 meg flash instead of 512. even the code on it is based on the same source code, they have just added some more stuff in it and it ran over 512 by a little bit so they went up to 1 meg... most of the second half of the VZ bins is empty space!>

the 6L is the E38 so yeah it would be can. a mate has a 2007 6L VE I can get a dump of with my AVT to see what its talking like, now that I figured out how to command the avt to listen to all packets and optimised my app to keep up with the incredible amount of data!

[Tazzi]

hmmm lost communication with the candi module. Havent moved/touched it over night... might see what happens it I let it "warm up" first.

[Tazzi]

Ahh just connected... take about 5-10mins warmup before the tech2 recognizes it.
That has to be the most weirdest things it does.

Im amazed the elm is keeping up.. its logging ~305frames/s

[Tazzi]

I got rid of the generic data being sent.. and only captured the first DPID answers by the ecu as it gets pretty hectic!

*Just cleaning it up a bit

Code: Select all

 [10:02:29:223]   Received: 7E0 10 0C 2C FE 00 0C 11 C9 
[10:02:29:244]   Received: 7E8 30 20 02 2C 7F 7F 7F 7F 
[10:02:29:246]   Received: 7E0 21 00 05 00 0F 00 10 00  
[10:02:29:286]   Received: 7E8 02 6C FE 00 00 00 00 00 
[10:02:29:322]   Received: 7E0 10 0E 2C FD 00 04 13 1F 
[10:02:29:323]   Received: 7E8 30 20 02 4C 00 00 00 00 
[10:02:29:325]   Received: 7E0 21 11 9D 13 B0 13 1E 14 
[10:02:29:327]   Received: 7E0 22 93 00 00 00 00 00 00 
[10:02:29:356]   Received: 7E8 02 6C FD 00 00 00 00 00 
[10:02:29:390]   Received: 7E0 10 0A 2C FC 11 06 11 05 
[10:02:29:391]   Received: 7E8 30 20 02 7F 7F 7F 7F 7F  
[10:02:29:394]   Received: 7E0 21 11 02 11 01 00 00 00 
[10:02:29:446]   Received: 7E8 02 6C FC 00 00 00 00 00 
[10:02:29:480]   Received: 7E0 10 0E 2C FB 00 0D 11 A1 
[10:02:29:482]   Received: 7E8 30 20 02 7F 7F 7F 7F 7F 
[10:02:29:484]   Received: 7E0 21 11 A2 12 B1 16 64 16 
[10:02:29:486]   Received: 7E0 22 61 00 00 00 00 00 00  
[10:02:29:538]   Received: 7E8 02 6C FB 00 00 00 00 00   
[10:02:29:574]   Received: 7E0 10 10 2C FA 13 C3 11 07 
[10:02:29:575]   Received: 7E8 30 20 02 54 7F 7F 7F 7F 
[10:02:29:577]   Received: 7E0 21 11 00 14 8D 19 9A 16 
[10:02:29:578]   Received: 7E0 22 69 16 5F 00 00 00 00   
[10:02:29:641]   Received: 7E8 02 6C FA 00 00 00 00 00  
[10:02:29:676]   Received: 7E0 10 0E 2C F9 13 B8 13 B9 
[10:02:29:678]   Received: 7E8 30 20 02 EC 7F 7F 7F 7F 
[10:02:29:679]   Received: 7E0 21 13 C0 13 C1 13 C2 13 
[10:02:29:681]   Received: 7E0 22 7A 00 00 00 00 00 00  
[10:02:29:744]   Received: 7E8 02 6C F9 00 00 00 00 00  
[10:02:29:781]   Received: 7E0 10 0A 2C F8 00 0E 12 D9 
[10:02:29:783]   Received: 7E8 30 20 02 BC 82 00 00 01 
[10:02:29:785]   Received: 7E0 21 13 2A 13 79 00 00 00   
[10:02:29:833]   Received: 7E8 02 6C F8 00 00 00 00 00  
[10:02:29:866]   Received: 7E0 10 0E 2C F7 11 70 00 07 
[10:02:29:868]   Received: 7E8 30 20 02 5E 7F 7F 7F 7F 
[10:02:29:869]   Received: 7E0 21 00 08 13 78 00 09 11 
[10:02:29:870]   Received: 7E0 22 04 00 00 00 00 00 00 
[10:02:29:934]   Received: 7E8 02 6C F7 00 00 00 00 00 
[10:02:29:970]   Received: 7E0 10 0C 2C F6 00 06 11 46 
[10:02:29:971]   Received: 7E8 30 20 02 67 00 00 00 18 
[10:02:29:973]   Received: 7E0 21 14 94 11 49 13 77 00 
[10:02:30:024]   Received: 7E8 02 6C F6 00 00 00 00 00 
[10:02:30:054]   Received: 7E0 10 0B AA 04 FE FD FC FB 
[10:02:30:055]   Received: 7E8 30 20 02 40 00 00 00 0C 
[10:02:30:058]   Received: 7E0 21 FA F9 F8 F7 F6 00 00  
[10:02:30:400]   Received: 5E8 FE 00 00 6E 00 00 00 00 
[10:02:30:422]   Received: 5E8 FD FF 00 FF 10 AB 0D 00   
[10:02:30:429]   Received: 5E8 FC 60 E0 01 05 00 00 00  
[10:02:30:465]   Received: 5E8 FB 00 00 00 0A 00 00 00 
[10:02:30:475]   Received: 5E8 FA 00 0C 82 86 00 00 00  
[10:02:30:507]   Received: 5E8 F9 00 00 00 00 00 00 B8 
[10:02:30:515]   Received: 5E8 F8 80 00 00 00 00 B8 B8 
[10:02:30:547]   Received: 5E8 F7 00 80 80 80 00 80 C0 
[10:02:30:568]   Received: 5E8 F6 80 00 00 00 80 00 C0 

[Tazzi]

7E0 10 0C 2C FE 00 0C 11 C9
7E0 = from tech2 to ecu
10 = multiline response will occur
0C = 12bytes will follow (excluding 2C)
2C = setup DPIDs (i think from memory?)
FE = load into DPID FE
00,0C = pid
11,C9 = pid

7E8 30 20 02 2C 7F 7F 7F 7F
7E8 = from ecu to tech2
30 = flow control response (response to 0x10)
no idea what the rest is... I assume is confirms the above?

7E0 21 00 05 00 0F 00 10 00
7E0 = from tech2 to ecu
21 = first multi frame from tech2
00,05 = pid
00,0F = pid
00,10 = pid
(I think?)

7E8 02 6C FE 00 00 00 00 00
7E8 = from ecu to tech2
02 = 2 bytes to follow
6C = ack 2C request
FE = DPID loaded up

7E0 10 0E 2C FD 00 04 13 1F
7E0 = from tech2 to ecu
10 = multiline frame
0E = 14 bytes to follow (excluding 2C)
2C = request dpid loading
FD = load up FD
00,04 = pid
13,1F = pid

7E8 30 20 02 4C 00 00 00 00
7E8 = from ecu to tech2
30 = flow control response (response to 0x10)
dunno about the rest.. different to first one.

7E0 21 11 9D 13 B0 13 1E 14
7E0 = from tech2 to ecu
21 = first multiline response
11,9D = pid
13,B0 = pid
13,1E = pid
..14??

7E0 22 93 00 00 00 00 00 00
7E0 = from tech2 to ecu
21 = second multiline response
93.. ??
possible 14,93 = pid?

7E8 02 6C FD 00 00 00 00 00
7E8 = from ecu to tech2
02 = 2 bytes to follow
6C = ack 2C request
FD = DPID loaded up

this repeats all the way to F6..then..
7E0 10 0B AA 04 FE FD FC FB
7E0 = from tech2 to ecu
10 = multiline response
0B = 11 bytes follow
AA = .. ? Fire off frames
04 = ..? next 4 dpids?
FE,FD,FC,FB = dpids loaded

7E8 30 20 02 40 00 00 00 0C
7E8 = from ecu to tech2
30 = ack, flow control

7E0 21 FA F9 F8 F7 F6 00 00
7E0 = from tech2 to ecu
21 = first multiline frame
FA,F9,F8,F7,F6 = dpids

then the data spews out at ~200frames a second
5E8 FE 00 00 6E 00 00 00 00
5E8 FD FF 00 FF 10 AB 0D 00
5E8 FC 60 E0 01 05 00 00 00
5E8 FB 00 00 00 0A 00 00 00
5E8 FA 00 0C 82 86 00 00 00
5E8 F9 00 00 00 00 00 00 B8
5E8 F8 80 00 00 00 00 B8 B8
5E8 F7 00 80 80 80 00 80 C0
5E8 F6 80 00 00 00 80 00 C0

[Tazzi]

Im assuming the elm didnt miss anything.. there was no "buffer fulls" during that period

Trying to use different modes to get the enhanced pid requests working.. but the format must be slightly different or something.

Its a bit of a pain to do the DPID requests on the elm.. setting up is easy..Im hoping we can request each dpid 1 at a time like in vpw..

so on vpw..:
6C 10 F0 2A 14 FE 00 00 00 = continuously send for ~4seconds
0x6C 0x10 0xF0 0x2A 0x01 0xFE = request frame once


sooo applying that to CAN:
7E0 10 0B AA 04 FE FD FC FB = continuous
7E0 03 AA 01 FE = single?

[Jayme]

I tested my buffer by unplugging the obd2 plug.... if it took ages to stop reading data in my app... I know there was a big buffer somewhere.... but in my case it was the windows serial port buffer that was filling as my app couldnt process the frames quick enough lol.

[Tazzi]

I tested my buffer by unplugging the obd2 plug.... if it took ages to stop reading data in my app... I know there was a big buffer somewhere.... but in my case it was the windows serial port buffer that was filling as my app couldnt process the frames quick enough lol.

Not a bad Idea.. i'll test that now..

*edit
Nah, stops instantly when I pull the cable out.
I have multiple threading going on in the background grabbing all the data from the serial port. While other threads update the textboxs/counter
So instead of waiting for windows "serialdata.received".. I keep checking if bytes are available, then fire them off into a thread pool for the work to be completed.