Allpro development
Re: obdpro
well that took a turn for the better!
- VL400
- Posts: 4991
- Joined: Sun Mar 01, 2009 2:54 pm
- cars: VL Calais and Toyota Landcruiser. Plus some toys :)
- Location: Perth, WA
- Contact:
Re: obdpro
Finally some success, good to see!! Can start playing now, not fixing.
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
Writing the decoder plugin has been hard. dsview sends nothing back to the user - no compiler errors, no reasons why the code isnt working. Either the decoder is listed or it isnt, and it decodes or says "decoder failure". Im not a python guru and the API isnt entirely clear.
None the less, 2 nights and a lunch break and complete start again and I have managed this: So I need to put a state machine in the decoder so it can grab the data in context and rebuild bytes, and figure out how have a variable amount of data on one row (at the moment its a staticly coded list of 30 annotations which is why they stop 3/4 of the way down the screen shot) then I should be able to start decoding bytes, and from there decode actual packets.
The timing is surprisingly all over the place. I thought VPW 1x would be pretty exact but you can see from the microsecond counters even when sampling at 2mhz that the timing drift per byte gets really close to the threshold.
So many 97us when the spec draws the rx cutoff between a long and a short at <=96 is short, and > 96 is along. Unless im missing something, it seems wierd for the timing to be so borderline. Actually Im assuming these packets are vats as ive just got a pcm on the bench which im not logging. Any ideas?
None the less, 2 nights and a lunch break and complete start again and I have managed this: So I need to put a state machine in the decoder so it can grab the data in context and rebuild bytes, and figure out how have a variable amount of data on one row (at the moment its a staticly coded list of 30 annotations which is why they stop 3/4 of the way down the screen shot) then I should be able to start decoding bytes, and from there decode actual packets.
The timing is surprisingly all over the place. I thought VPW 1x would be pretty exact but you can see from the microsecond counters even when sampling at 2mhz that the timing drift per byte gets really close to the threshold.
So many 97us when the spec draws the rx cutoff between a long and a short at <=96 is short, and > 96 is along. Unless im missing something, it seems wierd for the timing to be so borderline. Actually Im assuming these packets are vats as ive just got a pcm on the bench which im not logging. Any ideas?
- Attachments
-
- vpw timings.png (43.22 KiB) Viewed 3836 times
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
and with logging. hmmmmmmmm.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
Ive figured out some more of the multiple row annotation API as well as unlimited length decode and annotate. Real close to having another row for byte decode on top of this.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
And we have some level of protocol decode
This is probably good enough for now
This is probably good enough for now
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
Added a check for VPW 1x or 4x timings to the IDLE state of the state machine, so when a 4x SOF is detected it knows to divide all timings by 4 for the following packet. And BOOM! Vpw 4x auto detection and decode.
Damn these are some long long packets compared to the logging I was doing with the obdpro/elm interface.
Damn these are some long long packets compared to the logging I was doing with the obdpro/elm interface.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
-
- Posts: 1215
- Joined: Sun Mar 15, 2009 10:20 am
- cars: 2004 VYII Acclaim Wagon V6 Auto LPG/Petrol
2004 VYII Berlina sedan V6 Auto
2005 VZ Monaro CV8 manual - Location: Geelong, VIC
Re: obdpro
Nice work as usual antus!!
Your skill set with software/hardware never ceases to amaze me, along with your persistence.
Keep up the good work, will be interested to see where it all ends up.
Your skill set with software/hardware never ceases to amaze me, along with your persistence.
Keep up the good work, will be interested to see where it all ends up.
Re: obdpro
This is all waaay beyond me, looks like lots of hard work, great job there ant
According to chemistry, alcohol is a solution...
- antus
- Site Admin
- Posts: 8250
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: obdpro
Tonights progress... I managed to get some much longer packets out of the device. Heres a dump of a 0x64 byte payload packet. It seems happy up to 0x84 bytes but then something else breaks and the first 0x84 bytes are lost and i get the remainder of my attempt only.
There was 1 'sort of' bug... the obdpro does internally does a connect first up and then sends the packet and the connect part trys to read pid 00 (hard coded) for the auto protocol detection feature. It still does this even if you are set to VPW and not auto. Since I dont have a pcm connected there was no reply and so the connect stage would fail and my packet would not get send. Once I figured it out I just removed the test... I dont need auto protocol detect.
There was 1 'sort of' bug... the obdpro does internally does a connect first up and then sends the packet and the connect part trys to read pid 00 (hard coded) for the auto protocol detection feature. It still does this even if you are set to VPW and not auto. Since I dont have a pcm connected there was no reply and so the connect stage would fail and my packet would not get send. Once I figured it out I just removed the test... I dont need auto protocol detect.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396