J1850 VPW Sniffer

[jlvaldez]

Antus or Tazzi,

I got the OBDX device and went to the car with my laptop and started playing.

First things first, where is the manual that describes the extra features of this command set? I can't find it on the obdx website that lists the comands...

Also, I'm not sure who wrote the firmware, but using the elm327 commands, atmr and atmt seems to be broken. They both seem to work the same as atma, or I don't undrestand how the addressing works.

So I was using elm327 commands (mainly atma) to monitor and sniff things.
I was able to get the car to do the following
1) Set gas gauge
2) Roll windows up and down, together, or separate
3) Lock and unlock doors, both or seperately
4) open trunk
5) get cluster to show a trans over temp warning (so I can see the trans temp).
6) Switch between tcs on, tcs off, and competition mode

However, I don't understand how GM's addressing works.

If I read the elm manual correctly, with headers , I see a packet 8A CA A0 81 22 xx.
I understand that xx is the checksum (though adding the bytes together doesn't get me a 0, so maybe it's a crc?).
8A: is the priority. Higher number = higher priority. When I change this priority, the packet doesn't do what i expect. This is confusing.
CA: Transmitter, the address of the transmitting node
A0: Receiving node.

Seems like modules can have many addresses. For example I found the HUD responds to 10 and 04 apparently...

I have a lot of reading to do about this protocol, because I'm fawking confused by how I can change the priority or the transmitting node address and suddenly the command doesn't work. But on other commands (window up/down commands for example), I can change the transmitting address and it works. Weird.

Edit: NSFW pointed me to https://www.fastfieros.com/tech/vpw_com ... otocol.htm to read up on VPW, so I'm goin to look through this.
I still have no idea what list of commands are available to me.

I plan to use my RPi with my analog signal board to datalog signals and the OBDX device to sniff bus traffic while on track.

[Tazzi]

I will have to look at the ATMT and ATMR commands in the firmware and check if they were completed, or just added for compliance.

I believe I made it so the mask can adjust which data is received when using ATMA, but again Ill need to verify that one.

The command reference manual is provided upon request from OBDX site. Simply because Im constantly adding to it and updating the information to better describe features and how to use them.


As for your transmitter/receiver information. You need to think of it in a more human sense, where imagine you have your mate Bob which always tells you the time. You will always look for Bob for the time. Even if dear old Karen (Fuck Karen) tries to tell you the time, you will never listen to her.. cause she doesnt know whats going on... and will only listen to bob.

Both of them may say the same thing to you (The receiver), but you only care about one of them.

[jlvaldez]

Thanks tazzi, I'll request the manual on the site.

After reading the link I posted, I see I had a lot of stuff backwards. I understand now that the first byte does a lot more than just be a priority.

CAN devices behave in a similar way. I need to write some UI to better log the incoming packet with a table view rather than a string of bytes.

[jlvaldez]

Did you get my email request on the website? I never got the manual

I will have to look at the ATMT and ATMR commands in the firmware and check if they were completed, or just added for compliance.

I believe I made it so the mask can adjust which data is received when using ATMA, but again Ill need to verify that one.

The command reference manual is provided upon request from OBDX site. Simply because Im constantly adding to it and updating the information to better describe features and how to use them.


As for your transmitter/receiver information. You need to think of it in a more human sense, where imagine you have your mate Bob which always tells you the time. You will always look for Bob for the time. Even if dear old Karen (Fuck Karen) tries to tell you the time, you will never listen to her.. cause she doesnt know whats going on... and will only listen to bob.

Both of them may say the same thing to you (The receiver), but you only care about one of them.

[antus]

If you use the commands exactly that I entered earlier in the thread that should give you the best results. I have used that a fair bit to monitor things on my bench. The first byte, priority, might be used for priority but its really information about the packet, which mostly you dont need to know. The next is the recipient, then next is the sender. The next two are what the packet is doing, and then the payload is specific to the packet type. Device IDs FE and FF are broadcasts.

[jlvaldez]

Yeah I plan to use the commands you sent for datalogging. I just like seeing what's available to me in case I want to filter or change Baud rate of the serial interface. I fear that a bus at full tilt will overload a 38.4kbaud serial using ASCII to send bytes of data. 10.4 kbps VPW, but each byte of data requires 3 bytes of ASCII. Not sure about how 4x speed is supported over an ASCII uart pipe.

I'm looking at writing something in QT as a UI for datalogging more than just. Dump to console. At work, I've used some fancy CAN datalogging tools that cost $20k, and would love to get some of those features at the DIY level.

I know many of you are windows fans, but I'm big into Unix/Linux haha. QT supports cross platform compiling... I guess Java does as well...

[antus]

Fair enough. The xpro on USB goes a lot faster than 38400 so I dont think you'll overflow it but im not sure what the limit is. It also supports binary mode, take a look at its drivers in the pcmhammer source tree, otherwise if you can get Tazzis attention you will probably get the current revision of that document. In theory you should also be able to use the pcmlibrary to handle the comms for you. pcmhammer uses it in 'stream' mode, not elm mode which is probably more what your looking for.

As for windows, well, I know there are a lot of linux people around (myself included), but linux was a non-starter for ALDL because its serial API was too old to do 8192 baud. Thats not a problem for this kind of work, but I just kinda got used to windows in the context of these types of tools even though when I develop (with the exception of pcmhammer, ls1flash, oseplugin) its always been linux.

[jlvaldez]

I hadn't even considered that! Thanks. I'll dig through the source for pcmhammer.

I saw in a few threads as I was digging through other part of the forums that you have a few tools/software you wrote for yourself for datalogging? Anything you care to share?

I envision some sort of table view for interpreting packets as they come in, and a "unique" packet view to allow ignoring of repeated packets and what not. The ability to do basic interpretation of certain frames would be a plus as well. Since I'll be using my RPi, I was thinking of using X11 over SSH or VNC since I'll probably have the RPI under the seat and will connect to it via WiFi.

[antus]

I used to use this until I had a handle on the P01 hardware (AVT required), now I use the xpro with putty just dumping to screen as described. viewtopic.php?f=42&t=6604&p=96929#p96929

[babbish]

I wanted a sniffer as well a few months ago and I already had some Bluepill STM32 boards so I wrote some code to do the VPW -> UART for them, I was planning on writing about it/publishing it but haven't had the time yet.
The best thing about those boards are they are ~$3 USD including the programmer (subsequent boards are cheaper without the programmer) from Aliexpress (https://www.aliexpress.com/item/32649400326.html)

The code definitely isn't very good but it does mostly work, so if anyone wants a copy let me know and I'm happy to send it. Eventually I hope to clean it up and implement writing with correct contention handling as well, which would make this a very cheap very nice tool.

The one caveat is the voltage obviously, these are 3V boards, but for sniffing a simple voltage divider (2 resistors) worked perfectly, obviously writing would be more involved but I'm hoping the PCM is more sensitive to out of spec voltages than it should be.