Page 1 of 3
VPW Analyzer Tool
Posted: Wed Jan 26, 2022 4:28 pm
by jlvaldez
Well, after a few request for this, I decided to make a github and publish this barely working tool that I used to sniff out a lot of VPW data on my car. I'll warn that it's rough, and that I am NOT a UI developer. I deal primarily with MCUs and embedded devices.
https://github.com/jonofmac/vpw_analyzer
I threw this together for my ABS sniffing project as I was trying to get around and understand the ABS module's ice mode. It's also been helpful for some other personal projects.
Features
- Parses VPW frames headers, target and source addresses
- Can export received messages to a text file
- Can import text files
Bugs/Not Implemented
- Crashes when closing (often times requires a ctrl-c on the task to end it) - Fixed in v0.2
- Does not support sending any messages
- General Bugginess
Requirements
- Moderately quick machine to keep up. Python isn't efficient, nor is my software
- Python 3 or higher
- Tkinter (tk)
- Pandas
- serial
How to use
Easiest way to install these if you have a command line interface is with pip
Then simply point python3 to the python file by being in the correct folder and running
I've provided an example log of my C5. Enter the relative path to a log in the OBD Serial Device Port, for example: "example_logs/keyon.txt" and then press "Read". You should see it populate the tables as if it were reading it live.
Any ELM327 device should be compatible with this, as it uses only basic AT commands to listen to the bus.
You need to enter the serial port into the "OBD Device Serial Port" box. For Windows, this is typically a "COM1" name. Check device manager to get the actual COM port.
For Linux, you need to specify the full /dev/tty device path.
Once the serial device is entered, press the "Read" button to connect and begin listening to the bus.
I'm honestly uploading this so that it might provide some help to the community, and if someone is more familiar with python, helping clean it up a bit.
Re: VPW Analyzer Tool
Posted: Wed Jan 26, 2022 6:04 pm
by antus
thats really useful for the protocol, thanks!
Re: VPW Analyzer Tool
Posted: Thu Jan 27, 2022 3:32 am
by jlvaldez
I think th crashing bug is related to the threaded task not receiving the request to kill app. It hangs and eventually has the terminate the task.
I did a lot of reading into VPW protocol and actually can decide messages further with some more software work but I'd like to get the basic functionality a bit more stable.
The "last MID" column seems to not work properly either. Which is weird because I swear it used to lol.
Being able to look for repeating messages is convenient.
I realize my car published my VIN and odometer reading to the bus in that log I uploaded. Haha whoops. I've got a few more logs I can upload as examples too.
I really wanted the OBDX device to have a way to support transmitting a message (or writing the data to the pipe to transmit) without having to drop incoming messages. It's been a problem on some other projects I can't work around.
Seems that if you want to send, ATMA must be cancelled. There was a background reception mode on OBDX I saw but that also seems to drop any packets that were received while the input pipe was not cleared. I was hoping it would store incoming messages in a FIFO then transmit them after the message to send line has received it's newline character.
Re: VPW Analyzer Tool
Posted: Thu Jan 27, 2022 9:10 am
by Tazzi
jlvaldez wrote:I think th crashing bug is related to the threaded task not receiving the request to kill app. It hangs and eventually has the terminate the task.
I did a lot of reading into VPW protocol and actually can decide messages further with some more software work but I'd like to get the basic functionality a bit more stable.
The "last MID" column seems to not work properly either. Which is weird because I swear it used to lol.
Being able to look for repeating messages is convenient.
I realize my car published my VIN and odometer reading to the bus in that log I uploaded. Haha whoops. I've got a few more logs I can upload as examples too.
I really wanted the OBDX device to have a way to support transmitting a message (or writing the data to the pipe to transmit) without having to drop incoming messages. It's been a problem on some other projects I can't work around.
Seems that if you want to send, ATMA must be cancelled. There was a background reception mode on OBDX I saw but that also seems to drop any packets that were received while the input pipe was not cleared. I was hoping it would store incoming messages in a FIFO then transmit them after the message to send line has received it's newline character.
ELM protocol does not save message when exited out of ATMA mode.
On an OBDX, we do have something called "Passthrough" (DX PT1) which allows all messages that meet the filter requirements to be sent by serial to the software. Its basically like using the ATMA command, except in this mode you can also send frames to the network. Makes it really handy for reverse engineering and simulating tools or ecu responses
Re: VPW Analyzer Tool
Posted: Thu Jan 27, 2022 11:16 am
by jlvaldez
Tazzi wrote:jlvaldez wrote:I think th crashing bug is related to the threaded task not receiving the request to kill app. It hangs and eventually has the terminate the task.
I did a lot of reading into VPW protocol and actually can decide messages further with some more software work but I'd like to get the basic functionality a bit more stable.
The "last MID" column seems to not work properly either. Which is weird because I swear it used to lol.
Being able to look for repeating messages is convenient.
I realize my car published my VIN and odometer reading to the bus in that log I uploaded. Haha whoops. I've got a few more logs I can upload as examples too.
I really wanted the OBDX device to have a way to support transmitting a message (or writing the data to the pipe to transmit) without having to drop incoming messages. It's been a problem on some other projects I can't work around.
Seems that if you want to send, ATMA must be cancelled. There was a background reception mode on OBDX I saw but that also seems to drop any packets that were received while the input pipe was not cleared. I was hoping it would store incoming messages in a FIFO then transmit them after the message to send line has received it's newline character.
ELM protocol does not save message when exited out of ATMA mode.
On an OBDX, we do have something called "Passthrough" (DX PT1) which allows all messages that meet the filter requirements to be sent by serial to the software. Its basically like using the ATMA command, except in this mode you can also send frames to the network. Makes it really handy for reverse engineering and simulating tools or ecu responses
Awesome. That's exactly what I need for some other projects. Too bad I can't drop your IC or MCU onto that PCB. I've been using the STN1101 and it has no such feature, actually makes some tasks very difficult because I risk dropping frames when I try to respond to the ECU. I hate it.
Re: VPW Analyzer Tool
Posted: Tue Feb 01, 2022 8:22 am
by jlvaldez
I was out of town last weekend and aaronc7 was doing some testing and found some bugs. I've added them to the issue list as well as some of the other obvious bugs I'm aware of and committed a fix for a single one that aaronc7 ran into to the dev branch.
Need to verify it first, but I really want to fix the crashing issue when closing the app. I suspect it's due to the separate thread not exiting the while True loop when receiving a request to close the program.
Seems like a good excuse to become more familiar with github.
I need to add some function to verify the output from the AT commands. Would be useful for making it smart enough to know it's an OBDX device that can support passthrough modes.
Re: VPW Analyzer Tool
Posted: Tue Feb 01, 2022 10:22 am
by aaronc7
Thanks again for helping me getting it working. It's really cool to have that sniffing ability using only my trusty old OBDLink MX. Here's the specific sleep / init commands I ended up with:
Code: Select all
#configure the modem
time.sleep(2)
self.sp.write(b'z\r\n') # Just send garbage in case we get stuck in a weird mode
time.sleep(1)
self.sp.write(b'atz\r\n')
time.sleep(1)
self.sp.write(b'atl1\r\n')
time.sleep(1)
self.sp.write(b'atsp2\r\n')
time.sleep(1)
#self.sp.write(b'ate0\r\n')
self.sp.write(b'ath1\r\n')
time.sleep(1)
self.sp.write(b'atma\r\n')
time.sleep(1)
Re: VPW Analyzer Tool
Posted: Tue Feb 01, 2022 11:24 am
by Gampy
aaronc7 wrote:Code: Select all
#configure the modem
time.sleep(2)
self.sp.write(b'z\r\n') # Just send garbage in case we get stuck in a weird mode
time.sleep(1)
Just send chr(13) for wake up ... That would be according to Hoyle! (i.e. the standard)
Re: VPW Analyzer Tool
Posted: Tue Feb 01, 2022 3:49 pm
by jlvaldez
Gampy wrote:aaronc7 wrote:Code: Select all
#configure the modem
time.sleep(2)
self.sp.write(b'z\r\n') # Just send garbage in case we get stuck in a weird mode
time.sleep(1)
Just send chr(13) for wake up ... That would be according to Hoyle! (i.e. the standard)
So i was concerned with sending a carriage return character, because I found on some units that pressing "return" after ending a command, would re-enter the previously used command.
I.e. if the device was in atma, but then received some key to cancel it, then received a carriage return, it would re-enter atma. This would break my code since there's no feedback we're in ATMA unless we receive a message.
Unless the requirement is to receive \r\n together for this. I'm not sure if \r by itself
I'm about to test this myself on my bench ECU and try to fix some of these bugs tonight with a little free time I have.
Re: VPW Analyzer Tool
Posted: Tue Feb 01, 2022 5:46 pm
by Gampy
That is exactly what is supposed to happen ... It is followed by ATZ, atz needs to be tested to ensure it returns OK, then the rest of the commands while also checking each for their proper response.