antus wrote: ↑Sat Feb 08, 2025 5:18 pm
The 'correct' fix will be to implement a state machine in front of the VPW code, so that it knows which messages to expect a response for and knows the mode with be the mode of the original message plus 0x40. It can then discard any mis-matching messages and seek the correct response. That approach does not play well with ELM style async communications protocols though so I have been holding off looking at that so far. It may be longer timeouts but the existing approach get parity with the older version turbo_v6 is comparing with, and probably would be a good place to get it to, to put a version 2 release. At that point improving the in car support would be a good next target, as well as maybe dropping support for scantool and allpro. Users of those interfaces would need to continue using the 2.0 release with some in-car reliability limitations.
The Query class allows that sort of thing, using a callback function for parsing. If you look at the code in Vehicle.QueryVoltage you can see an example of it.
Basically to create an instance of Query you pass a function that generates the request and a function that parses incoming messages to look for the response, and when you call Query.Execute it send the message and calls the parsing function for each incoming message until it times out or finds what it was looking for.
I would hate to drop the scantool devices. Partly because we've been recommending them (though not as the first choice) for years, and partly because maintaining compatibility with mutliple devices ensures that the code stays structured in a way that makes adding new devices pretty simple. AllPro is less of priority since they've been out of production for so long, and were only available briefly. But they're almost as fast as the OBDX devices so I use one for testing at home when my OBDX is in my car.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Re: scantool, the hard part is that a streaming protocol like AVT, J2534, OBDXPro (native) can monitor an unlimited number of packets before it sees the right response. Allpro I think max is about 5, I cant remember scantool, it might have been 10? But I recall us having to spam the bus with tester present messages regularly to reset the monitor to be able to see the response, or in the case of looking for module responses we only log the first 5? and drop the rest as they are only informational at that location in the code. The stop and start monitoring required by the device is a chance to miss a message, and so if there is chatter on the bus and you get more than 5 pieces of chatter - you break. If you get a timeout and miss the response while you are sending a packet to start monitoring again - you break. Further to that we see a lot of scantools (hardware) breaking in the wild. That could be because a lot of them are out there, but also the company has been difficult to deal with, changed specs causing issues for developers and perceived low quality hardware. LSDroid dropped support for new scantools quite some time ago. Its really hard to justify the time working for free on what is quite a messy driver so that users can have the lowest quality pcmhammer experience while the scantool company makes the money from the hardware. As we gradually add support for more PCMs it gets harder to test new releases each time as well incase a new timing issue comes up on only one particular platform with that particular device. If we did drop support for them, and add the above query code pcmhammer would gain reliability and the older builds would continue to work so anyone who has a scantool is still able to use the tool. If we wanted to we could tag and freeze a legacy version and update it's version of .net and the logger for maintenance but otherwise leave it behind as we improve reliability of in-car flashing with the better designed tools. We could implement the above but I still think people would cause bricks flashing in car because of the limitations in the interface monitoring.
Tried reading my P04. It got to 50% then just stopped. 2001 GTP L67 3800 v6 using a MAC tools branded Bosch VCI J2534 device. Not sure if it bricked it. Added debug log.
For our record, can you tell us what type of device it is? I dont think that is going to be fixable by us as it looks like a hardware or driver failure rather than pcm hammer itself but we'll keep record of it and any details you have about type of tool incase we find any patterns in that.
For our record, can you tell us what type of device it is? I dont think that is going to be fixable by us as it looks like a hardware or driver failure rather than pcm hammer itself but we'll keep record of it and any details you have about type of tool incase we find any patterns in that.
From what I can tell it's a Bosch VCI J tool that's branded by MAC tools. It read my PCM fine with the earlier version of this so I'm surprised it failed. I did a battery reset and the car came back and started without issue. Should I try again or is the OBDVX a better tool?
So this was in car, not on the bench? Are you set up to test on the bench? What version did work? Not the official pcmhammer release as that didnt have p04. You can try again, but its not designed to work in car, and there isnt much more I can do to debug from here. Would need to log the data bus at the same time and see what happens on the wire that pcmhammer cant see. It could be something like another module wakeing up when it shouldnt and transmitting at 1x and maybe the tool sees the traffic at the other speed and disconnects. It might be possible to get it to work by 1) bench flash, 2) try it at 1x speed (setting where you select the tool) 3) pull some fuses to potentially power down a rouge device in the car. 1 will probably work, 2 will confirm if its a rouge module in car and if so 3 might make it work at 4x.
antus wrote: ↑Sun Feb 16, 2025 8:34 am
So this was in car, not on the bench? Are you set up to test on the bench? What version did work? Not the official pcmhammer release as that didnt have p04. You can try again, but its not designed to work in car, and there isnt much more I can do to debug from here. Would need to log the data bus at the same time and see what happens on the wire that pcmhammer cant see. It could be something like another module wakeing up when it shouldnt and transmitting at 1x and maybe the tool sees the traffic at the other speed and disconnects. It might be possible to get it to work by 1) bench flash, 2) try it at 1x speed (setting where you select the tool) 3) pull some fuses to potentially power down a rouge device in the car. 1 will probably work, 2 will confirm if its a rouge module in car and if so 3 might make it work at 4x.
My apologies it was in car. I do have a setup for bench testing I was just impatient and jumped ahead haha. The version I used was from the P04 thread from last year that someone posted as a test version.
Thanks for the detail. At this point I'm not chaseing in car compatibility. There are too many variables, and I have future plans to modify the app (as mentioned earlier in the app) for in car-reliability. For now, some cars may work but its officially not supported or recommended and has never been tested by myself other than in Australian VY/VZ Commodores with P01 and P59 due to vehicle availability in Australia. I am definitely interested in results on the bench for P04.
Very cool. I have been out of the loop for a little bit and I am trying to get caught up. I will have to test a bunch of my PCMs on the bench and see how it goes.
I flashed my Corvette about a dozen times this weekend (P59, in-car) using the new kernels, and it all went well.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
