Code: Select all
[10:31:09:440] Voltage: 13.4V
[10:31:09:448] Elm ID: ELM327 v2.1
[10:31:09:466] All Pro ID: Copyright (c) 2009-2018 ObdDiag.Net This is free software; see the source for copying conditions.
[10:31:09:482] All Pro self test result: PWM wiring is OK VPW wiring is OK ISO9141/14230 wiring is OK CAN wiring is OK
[10:31:09:488] All Pro firmware: 1.22
[10:31:50:958] Querying operating system of current PCM.
.
. snip
.
[10:45:28:022] Will save to T:\Automotive\PcmHacks\Bins\FirstFullRead-Allpro.bin
[10:45:28:028] Saving contents to T:\Automotive\PcmHacks\Bins\FirstFullRead-Allpro.bin
that it wasn't mentioned that the Allpro has the EXACT same issueNSFW wrote:but if you can figure out why the read requests had to be sent twice you might only need half as much patience.
Code: Select all
[10:31:59:000] Reading from 2048, length 2048
[10:31:59:007] TX: 35010800000800
[10:32:00:042] Unexpected response to message content: NO DATA
[10:32:00:050] Unable to send read request.
[10:32:00:058] TX: 35010800000800
On the good side of that ... I have learned a BUNCH, so I guess that's 'the price of an education'!
Don't get my words wrong, I'm super chuffed!
Now, armed with that new information maybe it can get resolved.
So the Sparkfun board works as good as the Allpro just a helluva lot slower!
Comparing logs (test kernel, read full) between the two 'tools' are basically the same except for speed.
All the same 'errors', 'no data', 'no responses', 'Timeouts', etc..., etc...
I have been thinking it was all because of the Sparkfun board.
BTW: That read was done with NO delays in kernel ReadMode35() ... The Sparkfun board can handle no more then ~5-7 delay with ElmPause(...).