Support for j1850 VPW/PWM?

General Discussion
#124

I was actually working on my own J1850 VPW implementation with my '99 Suburban, but am in the process of finding a PWM vehicle to use to consolidate the two into one library. I haven’t done any PWM work yet but I do have a lot of the SAE documents for the implementation, including the full 4 page writeup on the protocols. If I get any work done on the PWM side, I’ll let you know.

Edit: side note; I was considering using my Tech2 to possibly add some support for the extended PIDs I can access. That said, as far as I know the PIDs are/can be different for each different vehicle or model year. I’ll see once I get to that point. As of now I’ve been having trouble communicating with my trucks’ PCM due to some ground issues that I’m still hunting down. (darn project vehicles!)

#125

I would be willing to do any testing. I can test with a macchina, but I also have an ELM327 and lists of commands and responces on the bus, and a ford star NGS tester for the ranger EV, which communicates to the modules.

#126

Is your VPW code non blocking?

The current library is a blocking library which needs to be updated. If you have a non-blocking library I would be interested in seeing it. I Hope to be able to get back to working on the new firmware that I started a couple months ago once my current semester is done and I get back from vacation.

I also have a Lab that I can use to test the PWM stuff to and integrate it but that will be secondary to my getting new software up and running that will support CAN/VPW. My lab can do pretty much all of the protocols the M2 is capable of so I should be able to get it working with all the protocols once I have time to work on it.

Rodney

#127

It’s been a while since I did any work on it, but I believe it’s blocking currently. I was looking into a non-blocking context but I haven’t gotten one of my part-truck PCMs up and running on a bench to do all the testing with the limited time before I go back to work. A collaboration doesn’t sound like a bad idea, as I’d certainly benefit from it with my project truck being a VPW PCM. :slight_smile:

#128

I have an '03 avalanche that uses the VPW and a 2012 CTS which uses CANBUS.

I also have the brain and a couple other modules mounted on a board from an '02 Bravada which should be the same as your 99 and I have a simulation board that has all of the protocols on it for testing and developing. I just haven’t had a chance to do much with it as I have had to deal with other stuff going on.

To make the VPW code should be pretty straight forward but I need to do a little more reading on the codebase to understand how Colin actually implemented the CANBUS stuff using the mailboxes. Basically to make it non blocking you take advantage of the fact any pin can throw an interrupt. You make an interrupt handler that reads in the stuff from the port then when the mail box is full you send it and start filling the next one. The normal code just watches for a mailbox to be ready to read and does so. To send the main code puts the send information into a mail box and marks it as send and sends it. So really the read part is the only part that needs to be interrupt driven. I just haven’t, as I already said, read Collins’ code well enough to understand how they are used.

#129

I was reading up on some of the Arduino non-blocking methods, but I didn’t think about actually checking out the M2 code. As soon as I can I’ll look it over and see if I can get something started. I like the idea you mentioned about creating a more modular library where protocols can be added like plugins, as well.

Also, I’m going to be ripping the PCM and other modules from one of my part trucks, either a '96 or '99 Tahoe (or both) to set up a bench testing method in the near future whenever I strip the trucks. That only offers me VPW testing but it helps for my plans of making an information display for my Suburban.

#130

If you are pulling modules I would suggest at a minimum the PCM and the BCM. You can communicate with them then via a standard ODBII program if you need to and track the communications with your M2. Thats how I tested that it worked in the first place. I actually have a PCM, BCM and cluster from a 2001 Trailblazer mounted on a board. The PCM case is pulled off because I wanted to look in it for another project.

Rodney

#131

Hi FunkyLuke. I just got my hardware and started experimenting with it in the car. I’m a little nervous that I’ll somehow brick it, but so far I’m just sniffing and not trying to send any messages. I’m using the J1850_M2_v1.ino above with some success. Is that what you used? Anyway, for my first experiment, I am trying to capture the message from the radio to the amplifier that turns the DSP on and off. I want to upgrade the stereo, but don’t want to lose the DSP functions that reside in the amplifier. That said, I think I’ve narrowed it down to a couple messages, but wondered if you (or anyone else reading) might confirm or discredit that the amplifier is $94 and the radio is $80? I kind of deduced that, but if anyone knows more or sees a flaw in my process, I’d love to hear it. Also, were you able to get a google doc around for the HUD stuff you’ve already sorted out?

RX:	8	FF	81	3	69			
RX:	8	FF	99	3	87			
RX:	28	FF	40	6	6	8	0A	C5
RX:	8	FF	A6	3	E5			
RX:	8	FF	C1	3	83			
RX:	8	FF	18	3	2			
RX:	8	FF	82	3	BD			
RX:	8	FF	89	3	33			
RX:	8	FF	B1	3	A8			
**RX:	8A	94	80	24	80	5	7E	0B**
RX:	8	FF	80	3	25			
RX:	8	FF	A4	3	7D			
RX:	8	FF	97	3	68			
RX:	8	FF	60	3	73			
RX:	8	FF	A1	3	1C			
RX:	8	FF	81	3	69			
**RX:	8A	94	80	A4	80	5	7E	3E**
RX:	8	FF	99	3	87			
RX:	28	FF	40	6	6	8	0A	C5
RX:	8	FF	A0	3	50			
RX:	8	FF	40	3	6			
RX:	8	FF	A6	3	E5			
RX:	8	FF	82	3	BD			
RX:	8	FF	89	3	33			
RX:	8	FF	B1	3	A8			
RX:	8	FF	80	3	25			
RX:	8	FF	A4	3	7D			
RX:	8	FF	97	3	68			
RX:	8	FF	60	3	73			
RX:	8	FF	A1	3	1C			
RX:	8	FF	81	3	69			
RX:	8	FF	99	3	87			
RX:	28	FF	40	6	6	8	0A	C5
RX:	8	FF	C1	3	83
#132

I have some information about the GM VPW protocol and how it works…
I am thinking about writing it up in a wiki page onsite for people to look at but haven’t done that yet. I did actually post this on another forum I am on.

Here is a tidbit to help you out…

Physical Node Addresses:
ID Module

$00-$1F Powertrain controllers
$00-$0F Integration/Manufacturer Expansion
$10-$17 Engine controllers
$18-$1F Transmission controllers
$20-$3F Chassis controllers
$20-$27 Integration/Manufacturer Expansion
$28-$2F Brake controllers
$30-$37 Sterring controllers
$38-$3F Suspension controllers
$40-$C7 Body controllers
$40-$57 Integration/Manufacturer Expansion
$48-$5F Restraints
$60-$6F Driver information/Diplays
$70-$7F Lighting
$80-$8F Enterntainment
$90-$97 Personal communications
$98-$9F Climate control (HVAC)
$A0-$BF Convenience (doos, Seats, Windows, etc.)
$C0-$C7 Security
$C8-$CB Electric Vehicle Energy Transfer System (EV-ETS)
$C8 Utility connection services
$C9 AC to AC conversion
$CA AC to DC conversion
$CB Energy storage management
$CC-$CF Future expansion
$D0-$EF Manufacturer specific
$F0-$FD Off-Board Testers/Diagnostic scan tools
$FE All nodes
$FF Null node

Please note that you are not likely to brick anything. You may lock up modules but simply pulling the battery connection should be sufficient.
It might be a good idea to pull the AirBag fuse however just in case… I have not heard of anyone poping an air bag when playing around but it is not impossible.

If there is a need I can write a page in the Wiki That explains how this all works. And programming a Module is much more difficult and not something you are going to do accidentally.

Rodney

#133

Thanks Rodney.

I was overly-cautious because it’s a super-limited production car that I can’t easily get modules for, but I will calm down given your comment about the effort to program modules. I’ve made a ton of progress after writing a little code. I have a simple program that only echos commands originating from the radio. Any more data you have is definitely welcome. I’ve narrowed it down to a few addresses that seem to be affected. My ultimate goals are to manipulate the amplifier (which I have surmised to be $94 and the HUD. I want to be able to send channel info to the HUD (like FM or XM does in the OEM system). It appears that the HUD may be $A5, $EB or both, but the encoding of the message still eludes me. Since you may have selected any frequency, that implies that the radio has to be explicitly sending text to the HUD in some format.

When I change from one FM preset to another (FM 98.3), I get this traffic:

From	RADIO	to	94	Payload	=	19	80	E0	6C	7E	7E	5D	10	00
														
From	RADIO	to	A5	Payload	=	98	80	03	D7	14	88	12	08	00
														
From	RADIO	to	EB	Payload	=	0B	0A	15	00	00	15	09	08	00

$94 seems to be the EQ setting to the amplifier (the car lets you save your EQ independently for each channel) and I assume the other two messages relate to the HUD and ??.

I’m not asking you to do all the work for me, but if you see something familiar or can point me in a direction, I would really appreciate it!

Bob

#134

Are you sure your Amplifier is a datalink controlled amplifier?
For instance, I have a 2003 GM truck. This truck the amplifier is NOT datalink controlled but the rear audio system is… The XM Radio is also a separate module that chats via Datalink.

If I were to get the upgraded radio from an Escalade however that system uses a datalink controlled Amplifier and a different head unit.

I have not tested the theory but since the Xm Radio and Rear Audio are connected to the radio I don’t believe they are directly connected to the main databus but on their own Databus shared on the output side of the radio. They can be accessed via a Tech2 so it is possible they are connected to the main bus in my case. But Also supported are steering wheel controls. With steering wheel controls the BCM gets an electrical signal from the steering wheel which it converts to whatver code it needs and then sends out code to the radio. The radio also gets the RAP (radio power on) signal, speed signal and others from the trucks main bus and deals with them as it needs.
I don’t recall seeing what type of car you are dealing with… I have the shop manual for all GM’s up through 2009 model year that I can look in and get some information if you are dealing with a GM. Some of the older vehicles may not be as well shown. Such as my '94 Caprice… It doesn’t really show anything for that but I have printed copies of those manuals anyhow I don’t thing GM used electronic copies until later.

Rodney

#135

Thanks. I’m sure the amp is class 2. I can see traffic when I adjust the tone controls or balance, so I’m 95% sure that the radio is telling the amp to make those changes. I have some experience when I worked for an OEM audio company to know that it is common for all the EQ to live in the amplifier.

I’m playing with a 2008 Cadillac XLR-V. I have the service manual which may be different from the shop manual? I’m looking at the data wiring diagram now and the class 2 data bus goes to:

  • DATA LINK connector
  • exhaust control module
  • driver door module
  • driver door switch assy
  • airbag module
  • head up display
  • instrument panel cluster
  • HVAC
  • radio
  • remote control door lock receiver
  • audio amp
  • passenger door module
  • folding top module
  • driver memory seat
  • digital radio (XM)
  • CD changer
  • VCM (OnStar)
  • BCM

The ECM has a speed signal output that goes directly to:

  • HUD
  • instrument panel cluster
  • radio
  • sensor control module

The steering wheel controls are analog and go to the BCM. I assume they “come out” as class 2 data, but I am (so far) only monitoring the radio outgoing messages.

Do you know if any of the data is “human interpretable?” I mean, since XM channel names can change over the years, and since the HUD displays that name, the information must be coming across the class2 bus. I tried converting the payload to ASCII characters but I either did it wrong, or its more complicated than that. Maybe that is coming from the XM module, but the HUD also displays the FM frequency, so that definitely is coming from the radio.

Thanks for hanging with me…

Today, I may associate what I think are EQ setting messages with M2 buttons to confirm those assumptions, but I’m ready to drill into the harder HUD part.

Bob

#136

Ahh ok… It did also have CANBUS but only for:
BCM (Bridge Module)
DSCC (Cruise control)
VCIM (Also accessed both databuses)
ESC(Suspension)
TCM (Transmission)
Headlight control module
Electronic Brake control Module
Engine Control Module.

So this vehicle wasn’t upgraded to SWCAN until later years if it ever was.
There are sites where people have looked at the HUD and Dash cluster information for other vehicles. Might be worth your while to search on those to see what others came up with. Much of what you are looking at were already figured out on other vehicles. Sorry that I don’t have a link but if you do a google search car hacking you should find them. Generally GM likes to reuse modules so it is possible that what you are looking for has already been Reverse Engineered.

I have a 2012 Cadillac CTS Sportwagon. Previously had a 2009 CTS Base model.

The Base model had the non datalink style amplifier. My 2012 is a “Luxury Performance” model so it has the Datalink style amplifier. Since GM brought much of the same stuff over to CANBUS once you understand the dataformat for either version it should carry over. I probably should create a VPW programming guide in the Wiki here…

#137

Has anyone used these modules with a Chrysler J1850 bus with any success?

#138

Is the Chrysler a VPW or PWM buss?
I have only seen the VPW buss working with the M2 so far.

Rodney

#139

Not trying to hijack the topic.

I have a 2005 Colorado pickup.
I’d like to trigger the key fob learning in the BCM.
I’d need the communication log from Tech2 what to send to $40 BCM.

Thanks for the help.

#140

Hi guys good work on the J1850 VPW protocol.

I’ve just received my M2 in Australia and am having it shipped over to Germany where I’m currently living. My ultimate goal with the M2 is to control various dash gauges as well as boost control, electro-hydraulic PS pump control, meth injection and fuel pumps in a turbo LS swap project. I’m looking at using the Speeduino code to interface with TunerStudio which will allow the user to calibrate the boost control live, as well as configuring comms messaging and many other inputs and outputs.

I’ve had a quick look through the code and it looks like it can’t detect collisions, but correct me if I’m wrong! When I’m data logging using either HPtuners or EFIlive controller there might be a chance that the M2 could conflict with these devices if it’s not configured with a unique tool identifier. Has anyone tried this yet?

Also, have you guys figured out how to request Dynamic PIDs where you can request multiple PIDs in a single message? You have to use Mode 2C to define the PIDS then Mode 2A to request the PID data. This would probably be the best way to reduce the overall data being transferred on the bus. If you want more information then I can send through some documentation that defines all the messages. Just shoot me a private message.

I can do it myself but I’m still waiting for my M2 and P59 PCM to arrive to Germany.

#141

At this time the J1850 code is very crude. I hope to get back to it soon. I had a rough semester and currently trying to get some non working computers working and some auto mechanic type stuff that I am working on.

The code really only contains send and receive code. Nothing else is included but I will shoot you an email.

#142

@redheadedrod - Thank you so much for your repo: https://github.com/redheadedrod/j1850
I uploaded your example sketch to my M2 and attached it to my 1995 Toyota Landcruiser, but couldn’t receive a message. I tried tinkering with your c file - mostly to run your tests, print in_pin and out_pin status, print the buffer created to receive a message etc… but I get 0 responses back from my car :confused:

Here’s the research I’ve done so far:

  1. Validate that the OBD2 port on my car uses SAE J1850 (VPW) based on [this pinout diagram](http://J1850 VPW --The connector should have metallic contacts in pins 2, 4, 5, and 16, but not 10.)
  2. Read the VPW section of Car Hacking book that I got with my M2.
  3. Wrote test sketches to illuminate all LEDs on my M2 - making sure that M2 does get powered when it is connected to the OBD2 port
  4. Read this research paper on implementation of SAE J1850 (VPW)
  5. Glanced through another useful VPW protocol reference

Please help - I’ve been banging my head against the wall on this for past week. If there’s any guidance or reading material you could provide, I’d love to take it and attempt to make progress :slight_smile:

#143

Are you sure it uses J1850 VPW first off?

Insure that the ODBII port has the proper pinout to match up. IE that the pins on your connector match up to the pins on the connector. For J1850 VPW you need minimum of 3 pins.

2 should be the data pin, 16 should be 12volts and 4-5 should be ground but can be tied together for most usages. (Doing from memory.)

This repository as it sits SHOULD list whatever it is getting and to send commands you have to code them in. It is a very basic program.

A couple things, are you getting any garbage or anything at all when you run the sketch? It is possible, assuming your car uses J1850, that it uses a different baudrate. This would be easy to see if the information you see appears to be garbage.

The other thing you can try is to get a generic ELM device and use generic software to communicate with your car. This should tell you what protocol and speed you have and verify that the port is actually working. You should then be able to use the M2 using a Y cable to also see what the ELM device is sending and receiving. If you get the ELM device to work and you can see it on the M2 then you should be good to go.

These generic devices can generally be had for less than $30 and the Y cables for less than that. I would use one of these devices anytime I am developing software to insure that everything is working correctly.

Rodney