pcmhacking.net

well that took a turn for the better!

Finally some success, good to see!! Can start playing now, not fixing.

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?

and with logging. hmmmmmmmm.

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.

And we have some level of protocol decode

This is probably good enough for now

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.

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.

This is all waaay beyond me, looks like lots of hard work, great job there ant

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.