Support for j1850 VPW/PWM?

redheadedrod · May 12, 2019, 6:59pm

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

MPRCTCL · May 13, 2019, 1:28am

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

redheadedrod · May 13, 2019, 3:21am

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

MPRCTCL · May 13, 2019, 1:00pm

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

redheadedrod · May 14, 2019, 1:47am

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…

nemiro · June 3, 2019, 11:14pm

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

redheadedrod · June 7, 2019, 3:56pm

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

Rodney

tcsibi · June 11, 2019, 3:51pm

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.

andrewgallagher87 · December 30, 2019, 3:34pm

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.

redheadedrod · December 31, 2019, 2:41am

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.

karanda · January 18, 2020, 8:00am

@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

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

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.)
Read the VPW section of Car Hacking book that I got with my M2.
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
Read this research paper on implementation of SAE J1850 (VPW)
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

redheadedrod · January 18, 2020, 3:18pm

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

karanda · January 19, 2020, 8:05am

Thank you very much Rodney! I tried running the sketch on my M2, and saw the following traffic:
23:26:14.946 -> RX: 48 6B 10 41
23:26:14.946 -> TX: 48 69 2D 4D 32 21 CC
23:26:17.197 -> RX: 48 6B 10 41
23:26:17.197 -> TX: 48 69 2D 4D 32 21 CC
23:26:19.377 -> RX: 48 6B 10 41
23:26:19.377 -> TX: 48 69 2D 4D 32 21 CC
23:27:12.748 -> RX: 48 6B 10 41
23:27:12.748 -> TX: 48 69 2D 4D 32 21 CC
23:27:14.386 -> RX: 48 6B 10 41
23:27:14.386 -> TX: 48 69 2D 4D 32 21 CC

This is me turning the key 4 times from off state to ignition state. I tried a couple of baud rates:
10.4k (10400), the default 115200, and in both cases the output was the same as above.

I’ll try it out with an ELM tomorrow and post any updates here.
Question: How do I read the RX message? i.e. are all bytes data only?
Thanks
Karan

redheadedrod · January 19, 2020, 3:51pm

This just shows the bytes as they are received. You will have to convert them to their proper data. This sketch was only a simple one to show it working. As far as I know no one has tried to make it better yet.If they have, they haven’t shared it.

karanda · January 21, 2020, 12:30am

@redheadedrod - this is awesome!
I tried the ELM device with a Y connector as you mentioned. I get the following messages:
16:06:17.283 -> RX: 68 6A F1 01 01 0A
16:06:17.317 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3
16:06:17.398 -> RX: 68 6A F1 01 01 0A
16:06:17.432 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3
16:06:17.683 -> RX: 68 6A F1 01 01 0A
16:06:17.716 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3
16:06:17.953 -> RX: 68 6A F1 03 CD
16:06:18.243 -> RX: 68 6A F1 03 CD
16:06:18.523 -> RX: 68 6A F1 03 CD
16:06:18.771 -> RX: 68 6A F1 07 B9
16:06:19.071 -> RX: 68 6A F1 07 B9
16:06:19.334 -> RX: 68 6A F1 07 B9
16:06:19.419 -> RX: 68 6A F1 02 00 00 29
16:06:19.472 -> RX: 48 6B 10 42 00 00 7E 1A 00 00 F4
16:06:19.566 -> RX: 68 6A F1 02 02 00 B1
16:06:19.566 -> RX: 48 6B 10 42 02 00 00 00 89
16:06:19.837 -> RX: 68 6A F1 01 01 0A
16:06:19.837 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3
16:06:19.911 -> RX: 68 6A F1 09 00 4D
16:06:20.614 -> RX: 68 6A F1 09 00 4D
16:06:21.259 -> RX: 68 6A F1 09 00 4D
16:06:21.777 -> RX: 68 6A F1 09 00 4D
16:06:22.479 -> RX: 68 6A F1 09 00 4D
16:06:23.129 -> RX: 68 6A F1 09 00 4D
16:06:52.479 -> RX: 48 6B 10 41
16:06:55.228 -> RX: 68 6A F1 01 01 0A
16:06:55.323 -> RX: 68 6A F1 01 01 0A
16:06:55.420 -> RX: 68 6A F1 01 01 0A
16:06:55.550 -> RX: 68 6A F1 02 00 00 29
16:06:55.640 -> RX: 68 6A F1 02 00 00 29
16:06:55.736 -> RX: 68 6A F1 02 00 00 29
16:06:55.872 -> RX: 68 6A F1 02 02 00 B1
16:06:55.973 -> RX: 68 6A F1 02 02 00 B1
16:06:56.073 -> RX: 68 6A F1 02 02 00 B1
16:06:56.173 -> RX: 68 6A F1 01 01 0A
16:06:56.307 -> RX: 68 6A F1 01 01 0A
16:06:56.390 -> RX: 68 6A F1 01 01 0A
16:06:56.521 -> RX: 68 6A F1 01 01 0A
16:06:56.602 -> RX: 68 6A F1 01 01 0A
16:06:56.706 -> RX: 68 6A F1 01 01 0A
16:06:56.841 -> RX: 68 6A F1 03 CD
16:06:56.922 -> RX: 68 6A F1 03 CD
16:06:57.023 -> RX: 68 6A F1 03 CD
16:06:57.123 -> RX: 68 6A F1 07 B9
16:06:57.245 -> RX: 68 6A F1 07 B9
16:06:57.377 -> RX: 68 6A F1 07 B9

For brevity - I removed the line that sends “Hello M2!” after each RX.
I suspect a majority of the messages are coming from the ELM device pinging various ECU’s on the bus. Of all the pings it seems the following messages get a response back - I’m pasting the TX of ELM device, followed by response (RX):
16:06:17.283 -> RX: 68 6A F1 01 01 0A
16:06:17.317 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3

16:06:19.566 -> RX: 68 6A F1 02 02 00 B1
16:06:19.566 -> RX: 48 6B 10 42 02 00 00 00 89

16:06:19.837 -> RX: 68 6A F1 01 01 0A
16:06:19.837 -> RX: 48 6B 10 41 01 00 07 E1 E1 A3

From this analysis - it seems I’m only getting 2 messages from the car:

48 6B 10 41 01 00 07 E1 E1 A3
48 6B 10 42 02 00 00 00 89

Any tips/advice on how to read these?
It seems that even after doing multiple scans - these seem to be the only 2 messages returned. Am I missing something here possibly?

Happy to contribute to the code if I can get to the point where I can listen in on all the messages

MPRCTCL · March 7, 2020, 3:36pm

I set this project aside for awhile knowing it would be easier this winter when I didn’t need to keep the car in service. Well, it’s winter so I’m ready to start back.

Before I paused, I learned/ deduced a couple important things that I thought I’d throw out here in case they help someone else.

Each device on my class2 bus has two addresses: one it listens to and one it talks on. That’s HUGE. It may be common knowledge, but I never heard it and it really delayed me as I was filtering too much out.

Secondly, and this is important for my project where I’m trying to replace the stock radio and retain features it controlled in other devices, is that all the devices need to send a heartbeat message frequently. If any device isn’t heard from for two seconds, other devices will stop responding to it’s commands and may even take over some functions themselves.

Does this trigger any thoughts / hints / ideas from you all?

daiku · March 7, 2020, 6:31pm

I’re reverse-engineered some of the protocol between the Head Unit and the 6-CD Changer in my '02 Yukon. I’m using an arduino, but that won’t matter for the protocol. Implementing the J1850 bus was not hard, but figuring out the messages has been a challenge. At least on my GM vehicle, the first 3 bytes are header, destination address, source address. For example, the heartbeat from the HU is:

0x08, 0xFF, 0x80, 0x03

So the destination is 0xFF (broadcast) and the source is 0x80 (HU). Source addresses are “physical” addresses, and are pretty consistent. Destination addresses are “functional”, and a device may respond to several. For example. 0x9B is the CD Changer system. Both CD and HU will send using that destination address. If any of this matches what you are seeing in your vehicle (did you say it was a Caddie?), let me know, and I can post more. CB.

MPRCTCL · March 10, 2020, 9:23pm

Yes, that’s completely in-line with what I’m seeing. I was able to acquire all the control module ID numbers as well as the numbers emulated by the BCM and bridged to the high speed GMLAN, but what was really throwing me off was, like you said, some devices are responding to messages with multiple “destinations.” Today was a big milestone. I was able to find and decode the outside temperature on the bus, filter for that, then display it on an OLED display. It comes from the HVAC (0x99) to 0xF3 with two data bytes and a checksum. Most of the project till be controlling the Bose amp and interfacing to the IR port of a Sony head unit. Yes, it’s a 2008 Caddy (XLR-V) and yes, I’d love to hear about any other things you’ve seen and learned about the class 2 implementation.

daiku · March 11, 2020, 12:06am

I’d be interested in learning more about the BCM interaction. I can set up the HU in my lab, but the CD changer won’t fire up without the BCM, so most of my data capture has taken place out in the truck!

Here’s a summary of what I’ve discovered so far. My focus has been on the conversation between CD Changer and HU. Some is pretty obvious, but some is clearly conjectural:

Byte 0 = header.  Z-bits always 2 => multiple data bytes.  Address type always FA = Functional.

Source 0x80 = HU (Head Unit)
Source 0x81 = Amp?  Broadcasts hearbeat, and sends to 0x95
Source 0x82 = CD (Slave 6-cd changer )
Source 0x89 = Back Seat controller. Sends heartbeat, and a few messages at igntion on and off.
(Sources other than 0x8* filtered out)
OTher possibilities are Rear COntroller, and Overhead DVD

GM uses "functional addressing" for destinations
Dst 0xFF = Broadcast?  Always used for heartbeats
Dst 0x9B 1011 Functional Address "CD"?  Always used from both sources for everything but heartbeat
Dst 0x94 0100 FA maybe not CD?  Only sent by HU.  Seem to go with power on/off and insert disc
Dst 0x95 0101 ?? Sent by CD when ejecting disc.  Maybe saying "active/inactive"?  Only sent by 0x81 and 0x82
Dst 0xEA and 0xEB Only seen during ignition off, door open, etc.  Never from Cd (only 80 and 80)

Byte 1 = msg type

0x01 = Command.  Byte 3 is Command Type:
   0x01 - Next Track - reply with 0x0B 0x02 0x0F and 0x0C 0x00 0x0F
   0x02 - prev track - reply with 0x0B 0x02 0x0F and 0x0C 0x00 0x0F
   0x0B - CD Should start playing - reply with 0x0C 0x00 0x0F
   0x0C - CD should stop playing - reply with 0x0D 0x02 0x0F
0x02 = Reply to Command.  Usually seen only after 0x01.  One exception is when CD inserted.  CD sends unsolicited with 0x01 0x02 0x0F.
                                                     Also when CD ejected.  Send unsolicited 0x02 0x02 0x0F.
0x03 = heartbeat - sent to 0xFF by all components every 2 secs.
0x04 = track status
0x05 = Power down?  Sent when opening car door.
0x06 = mute. Sent by HU when switching away from CD.  CD Answers with same.
0x07 = sent by CD to 95 during eject sequence
0x30 = Sent by HU in shop at Power On. and off.
0x47 = HU -> 94 : Immediatley after 0x87 below.
0x93 = Always from HU to 94.  Can probably ignore.
0x85 = never sent by CD, Just HU when CD starts playing.  Never to 9B or FF, only 94 and 95. 81 always answers with same message.
0x86 = unmute. HU sends, CD Responds with 0x86 or 0x89
0x87 = CD -> 95 : Disc Loaded.  First command of that sequence.  HU responds with 47
0x89 = On Air.  HU Sends, CD Responds with 0x89
0x13 = never sent by CD.  Just 80 and 81 94 and 95 (never 9B).  Can probably ignore.

Byte 2 = (almost) always 0x80 or 0x81

Other messages from CD to HU
0x02 0x81 0x0B 0x02 0x0F  Perhaps "command received"?  Only after change track command
0x02 0x81 0x0C 0x00 0x0F  Perhaps "command complete"?  Seen when changing tracks, switching from FM to CD.
0x02 0x81 0x02 0x02 0x0F  When CD ejected
0x02 0x81 0x0F 0x02 0x0F  When CD removed (changer icon goes out)

From CD -> 0x95:
0x89 0x81  When switching to CD
0x86 0x81  When switching to CD (Resume)
0x07 0x81  Eject CD while playing
0x87 0x81  Insert CD

CD Broadcast heartbeat
H:0x08|P0|H3|FA|Z:0x0|dst:0xFF|src:0x82|Data: 0x03

HU Broadcast heartbeat
H:0x08|P0|H3|FA|Z:0x0|dst:0xFF|src:0x80|Data: 0x03

CD Insert Disc:
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x87 0x81                     CD: c87_im_ready
H:0xEB|P7|H3|FA|Z:0x3|dst:0x94|src:0x80|Data: 0x47 0x81                     HU: r47_you_ready
H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x89 0x81                     HU: c89_on_air
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x89 0x81                     CD: r89_on_air
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x0B                HU: c1b_start
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F      CD: r2c_start
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x01 0x00 0x00 CD: track_status

CD Insert Disc (Radio off) (CD Light Comes on):
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x87 0x81                     CD: c87_im_ready
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x01 0x02 0x0F      CD: c2_12f
H:0xEB|P7|H3|FA|Z:0x3|dst:0x94|src:0x80|Data: 0x47 0x81                     HU: r47_you_ready

Track Status (once a second):
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x01 0x00 0x01
                                                    Disc Trak Min  Sec    All Values BCD

H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x02 0x01 0x00 0x59
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x02 0x01 0x01 0x00
                                                    Disc Trak Min  Sec    Disc 2 track one rolling from min 0 to min 1

Skip forward one track:
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x01                    -> Next Track
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0B 0x02 0x0F          <- Ack
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F          <- Part 2 ack next track ?
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x02 0x00 0x00     <- track status
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x02 0x00 0x01     <- track status

H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x01                    -> next track
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0B 0x02 0x0F          <- Ack
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F          <- ack 2?
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x02 0x00 0x00     <- track status


Skip back one track:
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x04 0x01 0x37    <- track status
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x02                   -> prev track
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0B 0x02 0x0F         <- ack
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F         <- ack part 2  ?
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x04 0x00 0x00    <- track status

H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x04 0x00 0x03     <- track Status
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x02                    -> prev Track
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0B 0x02 0x0F          <- Ack

H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x02                    -> prev tracl
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F          <- ack
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x03 0x00 0x00     < - track status
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x02 0x00 0x01

Next track intiated from steering wheel:
H:0xC9|P6|H3|FA|Z:0x1|dst:0xA8|src:0x80|Data: 0x50                              Perhaps ack from HU to steering wheel?
H:0xC9|P6|H3|FA|Z:0x1|dst:0xA8|src:0x80|Data: 0x50                              "
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x01                    Next Track
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0B 0x02 0x0F          ack
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0C 0x00 0x0F          ack
SOF Too Short: 32
******* Error: SOF too short
H:0xCA|P6|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x04 0x81 0x01 0x04 0x00 0x00   track status

Eject CD while playing:
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x07 0x81
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x02 0x02 0x0F
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x0C
M:0|H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x93 0x80 0x00
M:0|H:0x6A|P3|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x06 0x81
M:0|H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x85 0x80 0x00 0x01
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x0C
M:0|H:0x08|P0|H3|FA|Z:0x0|dst:0xFF|src:0x81|Data: 0x03
M:0|H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x13 0x80 0x00

H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x07 0x81                 CD:  c87_not_ready
H:0xEB|P7|H3|FA|Z:0x3|dst:0x94|src:0x80|Data: 0x47 0x81                 HU:  r47_you_ready
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x02 0x02 0x0F  CD:  c2_22f
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x0C            HU:  c1c_stop
H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x93 0x80 0x00            HU->Amp Mute
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x81|Data: 0x93 0x80 0x00            AMP: Ack
H:0x6A|P3|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x06 0x81                 HU: c6_mute
H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x85 0x80 0x00 0x01       HU -> AMP something
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x82|Data: 0x06 0x81                 CD: r6_mute
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x81|Data: 0x85 0x80 0x00 0x01       AMP -> HU:  Ack
H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x80|Data: 0x01 0x81 0x0C            HU:  c1c_stop
H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x13 0x80 0x00            HU -> AMP something
H:0xAA|P5|H3|FA|Z:0x2|dst:0x95|src:0x81|Data: 0x13 0x80 0x00            AMP -> HU:  Ack

Eject CD when radio off:
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0F 0x02 0x0F   CD:  Ejecting


Pull CD:
M:0|H:0xAA|P5|H3|FA|Z:0x2|dst:0x9B|src:0x82|Data: 0x02 0x81 0x0F 0x02 0x0F

HU Powers down after 10 mins in shop:
<- RX T:729.996 	0x8A 0xEB 0x80 0x30 0x00 0x01 0x08 0x02 0x10 0x01 0x09 
<- RX T:730.010 	0x8A 0xEB 0x80 0x30 0x03 0x01 0x08 0x02 0x10 0x01 0x09 
<- RX T:730.025 	0x8A 0xEB 0x80 0x30 0x04 0x01 0x08 0x02 0x10 0x01 0x09 

And power on again:
<- RX T:1126.758 	0x8A 0xEB 0x80 0x30 0x00 0x01 0x08 0x02 0x10 0x01 0x09 
<- RX T:1126.777 	0x8A 0xEB 0x80 0x30 0x03 0x01 0x08 0x02 0x10 0x01 0x09 
<- RX T:1126.789 	0x8A 0xEB 0x80 0x30 0x04 0x01 0x08 0x02 0x10 0x01 0x09 
<- RX T:1126.804 	0xEA 0xEB 0x80 0x2E 0x04 0x08 0x08 0x08 0x08 0x08 0x08 
<- RX T:1126.814 	0x8A 0x94 0x80 0x89 0x81 

Open car door:
H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x05 0xB3 0x00 0x00 

M:0|H:0x8A|P4|H3|FA|Z:0x2|dst:0x94|src:0x80|Data: 0x05 0xB3 0x00 0x00

MPRCTCL · March 11, 2020, 2:55am

Yeah, I think I have some deductions of my own that may fill in some gaps. I was planning to keep the CD changer originally, so I did some work with it, but it has an additional hardwire connection to the head unit off the bus, so I gave up that idea. I’ll pull some stuff tomorrow, see how it fits with yours, and make a post. I also found something online describing that other communication for various brands and I think ours is (from memory) made by Pioneer.