Ah true, I Guess is would be quite quick. Wasnt sure if messing with the priority byte at the beginning makes much difference.Holden202T wrote:yeah when you think about it the high priority stuff gets more and more, like maf or map, tps, knock, spark etc they all move very rapidly
on a side note, i got elm back from a mate so i should be able to do some testing for you ?
i have a vz alloytec and a holden cruze i can try it on.
Yeah VZ or a cruze would be fine. You might need to run that serial port monitor again to see whats happening in the background, Hopefully we dont get any "No Data" messages again. And that the elm actually fires up properly!
In saying that, if you cant connect to the elm when in car, try other baud rates, Seems a few better programs actually run through all baud rates till it finds one that the elm responds to.
*Edit
My PCM emulator app is coming along. It works in theory.. although I have no idea how long it will take the elm device to swap from monitoring mode to sending a request and then back to monitoring. This is important as Im unsure how quick the Tech2/scantool will request data.. and how long it waits before timeout ect.
Anyone with a y-cable and scantool to test will be of great use right now! Should be able to reverse anything that use obd2 in tech2.
Will also need to have try out the "monitor all" function with a scantool connected in car to see what requests the scantool makes and what the car responds with so that these messages can be mimiced back onto the bench setup.
Im hoping that the tech2 doesnt search for an aldl heartbeat to detect car presence before requesting OBD2 data, as that will be a royal pain! But I think from memory it didnt care if the bcm was connected or not from the OBD2 engine stuff and went on attempting to request info (So I thought).