pcmhacking.net

Yeah I wrote the verification stuff with my OBDX so i verified based on that lol.

Shouldn't be difficult to handle both situations to actually verify responses. I got frustrated trying to figure out how to properly pass data between threads in python and called it a night.

I'm not sure how, but right now it works letting me call a UI update function from another thread. This is not how I do this on embedded devices...

Assuming a UI is anything like the embedded world, i'd
1) Have a thread for serial handling (I do now). It waits for new lines from the tool then passes them off to a queue
2) Another thread for processing these raw messages from the device. Once processed, it puts the updated/processed message into another queue
3) UI thread gets the message from thread in #2, and can update the UI elements based on new data.

In FreeRTOS or similar RTOSes, you have very convenient queues and sleep functions that can wait for an event to wake the thread. I'm not quite sure what the equivalent process is in python for TKinter. The joys of trying to correct all the layers of "it'll mostly work" thrown into this tool so I could get a sniffing tool thrown together quickly.

I really wanted something platform agnostic since I develop in Linux, Windows and MacOS (M1 and x86). I hate being tied down to an OS

Sorry, don't do much python, no help here ...

jlvaldez wrote:Yeah I wrote the verification stuff with my OBDX so i verified based on that lol.

As most would, then add others ... In a perfect world we would start with the perfect one first and modify for the imperfect ... Fortunately this is not a perfect world!

jlvaldez wrote:I really wanted something platform agnostic since I develop in Linux, Windows and MacOS (M1 and x86). I hate being tied down to an OS

Amen!
Not the same OS's though ...

Gampy wrote:

Tazzi wrote:OBDX responds different for ATZ. It was an oversite on my behalf.

Shame on you!

All them atta boys wiped out by that one awe shit!

Technically, according to Hoyle (the specs), ATZ returns the Product ID so software can configure appropriately, the important part being, so software can configure appropriately.

That is correct. Typically I find most software's use ATZ to simply reset back to standard settings, and then use ATI to get identification information about the tool once they know the tool is on the default setup and baud rates.


As for using multiple threads. Most modern day computers should be able to happily process VPW to screen on a single thread without lag. This is not to say it wouldnt be working hard, but should be more the capable of so.
The way I deal with logging with multiple threads (Although I use dot net tasks):
1) Main Processor thread - This handles frames received from scantool for displaying or calculating.
2) Serial/scan tool thread - This fires once data is received, formatting into a defined message and setting an 'event' for the main processor thread to continue

'lag' on screen happens when too many things on the UI are refreshed. In dot net, the screen refresh can be delayed until all elements on the UI have been set, and then the update occurs. I noticed HUGE improvements when I was updating a gridview style element with lots of boxes, since it would update the entire app in hit instead of updating each cell individually.

Tazzi wrote:That is correct. Typically I find most software's use ATZ to simply reset back to standard settings, and then use ATI to get identification information about the tool once they know the tool is on the default setup and baud rates.

And somewhere in the details it states something like (it's been a long time), ATI reports the same as ATZ without interrupting the device ...

Gampy wrote:

Tazzi wrote:That is correct. Typically I find most software's use ATZ to simply reset back to standard settings, and then use ATI to get identification information about the tool once they know the tool is on the default setup and baud rates.

And somewhere in the details it states something like (it's been a long time), ATI reports the same as ATZ without interrupting the device ...

Correct, along those lines.
The ATZ is meant to report the device information after its reset itself and set the baud rate back to standard. If the baud has been modified (To make it faster), then its also very easy to miss or only capture part of the response when trying to cycle through the baud rates to reset the device back.

Tazzi wrote:Correct, along those lines.
The ATZ is meant to report the device information after its reset itself and set the baud rate back to standard. If the baud has been modified (To make it faster), then its also very easy to miss or only capture part of the response when trying to cycle through the baud rates to reset the device back.

I cannot attest to what others may or may not have issues with!

We take that script as a base and did some improvements, now it is part of Universal Patcher. Not that nicely looking but does the same job. Maybe some improvements can be made overtime.

I think it is time to decode the payload data. I suspect first byte is data identifier for example XX=rpm and second byte is actual data for example 80=3600 rpm.

It will be lots of work and have no idea if there is any info about it.

Currently it supports wider range of cables and for injecting custom commands without loosing incoming frames
I suggest a second cheap elm device be used on a second instance of program to send data to bus.

That's cool.

Fwiw there is some information about decoding frames formats but GM uses a lot of PIDs that aren't in the SAE spec.

You're generally right with the bytes. The header also describes the frame format. There can be single and double byte PIDs and the data follows the PID typically from what I've seen.

kur4o wrote:We take that script as a base and did some improvements, now it is part of Universal Patcher. Not that nicely looking but does the same job. Maybe some improvements can be made overtime.

I think it is time to decode the payload data. I suspect first byte is data identifier for example XX=rpm and second byte is actual data for example 80=3600 rpm.

It will be lots of work and have no idea if there is any info about it.

Currently it supports wider range of cables and for injecting custom commands without loosing incoming frames
I suggest a second cheap elm device be used on a second instance of program to send data to bus.