Decoding data bus message

Printable View

08-31-2017
PeteS

Decoding data bus message

I'm working on a project with a GM BCM and I I'm trying to figure out how to call this PID. I've searched all over and haven't found this any thing referencing this and since it's in the BCM there isn't much info on commands. I'm working off an ELM327 chip(not a cheap one) with a serial terminal and have been able to send PCM commands and decode the response via searching and even setup formulas to make the returned values readable. But this is outside of any thing I can find in terms of what type of AT command would be used to send the same response.

I have isolated the line that's the transmit command:
A8 3A 40 30 01 ED

The returned line is:
A8 3A 40 30 00 F0

The way I have isolated the BCM is by removing it and setting it up on a bench and simulated every thing it would connect to so it was happy living on my workbench. When I activate this circuit the lines I posted are the only 2 that come up outside of the BCM's normal repeater line of E8 FF 40 03 ED

Here's a snippet of the log when I activate the circuit I'm looking for PID id for:
E8 FF 40 03 ED
E8 FF 40 03 ED
E8 FF 40 03 ED
A8 3A 40 30 01 ED
E8 FF 40 03 ED
A8 3A 40 30 00 F0
E8 FF 40 03 ED
E8 FF 40 03 ED

Can someone give me some guidance on how to call this pid? I've gathered that the BCM is mode 40 and I've tried all sorts of combinations to access it but every thing in try in 40xx or 40xxxx comes back as no data..... I'll admit that programming is likely my weakest area so I honestly don't understand a lot of the hex decoding, binary coding or any sort of translation.

Thanks
08-31-2017
dzidaV8

I don't know it will be helpful, but here's what I can get from the communication you provided:

First, the header:

Code:

Byte 0 - priority : A8 - priority 5, physical node to node message Byte 1 - destination ID : 3A - Suspension controller module Byte 2 - source ID : 40 - BCM

So, both of the frames you labeled as "transmit request" and "response" come from the same node - BCM!

Next is communication mode:

Code:

Byte 3 - mode : 30 - Input/Output Control by Data Value ID

So i guess this is probably a message with suspension mode button status, or something simmilar.
What car are you simulating? Seems like something with adaptive suspension. GMT800? Vette?
09-01-2017
PeteS

Quote:

Originally Posted by dzidaV8

I don't know it will be helpful, but here's what I can get from the communication you provided:

First, the header:

Code:

Byte 0 - priority : A8 - priority 5, physical node to node message Byte 1 - destination ID : 3A - Suspension controller module Byte 2 - source ID : 40 - BCM

So, both of the frames you labeled as "transmit request" and "response" come from the same node - BCM!

Next is communication mode:

Code:

Byte 3 - mode : 30 - Input/Output Control by Data Value ID

So i guess this is probably a message with suspension mode button status, or something simmilar.
What car are you simulating? Seems like something with adaptive suspension. GMT800? Vette?

It's off a GMT800 with a 411 pcm and it's tow/haul Pid on the class 2 data line I'm after. After weeks of searching for it I just decided to go get a BCM and wire it up to extract the data the hard way.....the issue is now I really don't know what to do with it or how to proceed. Any time I've ever needed to look for something like this the pid being used is already provided so it's just a matter of sending the command. How they got that command out of the type of data I captured is beyond me and I've been stumped on this for a while now. I've even looked for a way to try and just the bcm for every data pids.......like some type of automated script that would run and search various combination but I wasn't able to come up with any thing like that either.
09-01-2017
1project2many

So you're looking for the pcm input for tow/haul? And the message you've isolated does not appear to be going to / from the pcm? Seems strange indeed...

Are you trying to duplicate tow/haul? Or use the input for another purpose?
09-01-2017
PeteS

Quote:

Originally Posted by 1project2many

So you're looking for the pcm input for tow/haul? And the message you've isolated does not appear to be going to / from the pcm? Seems strange indeed...

Are you trying to duplicate tow/haul? Or use the input for another purpose?

I'm trying to duplicate turning tow/haul on and off the same way the BCM does. My issues is that I have been able to isolate the message but unable to send the message over class 2. The 1st line of the message is whats sent to the pcm, the 2nd line is what the pcm sends back to the bcm. If I use the BCM by itself I only recive the 1st line of the message.

I have linked the Pcm to the Bcm via pin 58 on the pcm and pin C1-A12 off the Bcm as well as C2-A1 on the Bcm directly to the pcm via pin 59 the way it was in the vehicle and have been able to get the send and response that takes place as I've posted earlier. The issue is with or with out the BCM any time I try and send that command via class 2 line I get a Searching....... followed by NO DATA. I can send commands with the terminal window to the pcm all day with no issue and get a response back using mode's 1-9 and various commands. I have tried sending various messages using mode 40 and have yet to get any thing back other then No Data. I have even tried various combinations as Mode 1 and Mode 22 but that also got me no where.

What I'm trying to do is basically recreate the send command and then read the response line from the pcm. I don't really care is all I do is copy and recreate the send command somehow or if I just issue a command in the terminal program. I have tried this now with a couple of various elm327 dongles as well as a Uart communication development board. I know for a fact that the elm327 device I started using can communicate with the BCM since I've found a couple of apps in the playstore that it worked with. The main device I've been using is the OBDLink Mx bluetooth dongle. It's a VERY fast chip and should be more then cable of this since it's able to access "Some" bcm stuff with free apps.

Just really not sure what I'm doing at this point, I'm more of a hardware person than a software person when it comes to stuff like this.
09-01-2017
dzidaV8

I think that there's another message from BCM to PCM for the tow/haul input. The one you isolated must be some kind of auxillary message for suspension module that the tow/haul mode is active.
The thing that without PCM the second message doesn't appear doesn't have to mean it's sent by the PCM.
09-01-2017
kur4o

You should change the header on the messages you send. Elm sends by default f1 or f0 header and it means it is diagnostic tool. If you want to replicate the bcm or Pcm messages you need to use the headers they are assigned to. Try hooking another elm device on the bus configure it for listen mode and allow long message. Than you can see what you are actually sending via the elm device.
09-02-2017
PeteS

Quote:

Originally Posted by kur4o

You should change the header on the messages you send. Elm sends by default f1 or f0 header and it means it is diagnostic tool. If you want to replicate the bcm or Pcm messages you need to use the headers they are assigned to. Try hooking another elm device on the bus configure it for listen mode and allow long message. Than you can see what you are actually sending via the elm device.

What would you suggest I change the header to? I have read about the headers in the elm data sheets but I don't know what I would change it to.

I have been using headers on and long messages on.
09-02-2017
PeteS

Quote:

Originally Posted by dzidaV8

I think that there's another message from BCM to PCM for the tow/haul input. The one you isolated must be some kind of auxillary message for suspension module that the tow/haul mode is active.The thing that without PCM the second message doesn't appear doesn't have to mean it's sent by the PCM.

I'm not saying that isn't possible but once every thing is powered up and the buss chatter subsides from power up there are only 2 messages on the buss, 1 looks to be coming from the pcm and comes from the BCM. When I have only the BCM on it sends one of the messages I see when Pcm and Bcm are both on. If I have just the PCM on I see the other message. The 2 lines I highlighted only occur when I ground the wire that comes from the Tow/haul switch to turn it on.

I have been able to observe the BCM with a Snap-On scanner and when I ground the Tow/haul wire it does show it changes in the data pid. Unfortuntully this scanner doesn't display the tow/haul pid in the transmission data so I have not been able to verify the pcm accepts the command.

Now something I was thinking about last night, the Bcm and Pcm were out of 2 different vehicles. I flashed the PCM with a file that would match what the bcm came out of and changed the vin in the pcm to match the bcm, I have done this in other application before so that the bcm/pcm would live happly on the same network with out flagging mismatch codes but with this being on a bench setup I have not been able to actuality start an engine. I monitored the theft system state when I put the 2 on the same bus and was able to get the pcm to relearn the anti theft code from the bcm so my assumption is they are talking nicely with each other but that's just based on what I have observed with the theft relearn. To simulate a key/lock cylinder I used a remote start bypass modules that already had a key code stored in it, something I've done in the past that worked fine.
09-02-2017
kur4o

Header is very impotant. It contains id of the module, lenght and priority. If you are trying to simulate bcm, you need to change the header to match the bcm`s. If not the Pcm will recieve a message that is send from a diagnostics tool and will simply ignore it.

Every 2 seconds each module sends state of health message. It means that module is alive and on the bus. You will have to simulate that also or the pcm will store a dtc that bcm is down and will go to emergency mode.
09-03-2017
PeteS

Quote:

Originally Posted by kur4o

Header is very impotant. It contains id of the module, lenght and priority. If you are trying to simulate bcm, you need to change the header to match the bcm`s. If not the Pcm will recieve a message that is send from a diagnostics tool and will simply ignore it.

Every 2 seconds each module sends state of health message. It means that module is alive and on the bus. You will have to simulate that also or the pcm will store a dtc that bcm is down and will go to emergency mode.

Would you happen to know what the at command is to set the header to simulate the BCM? Is there any "easy" way to get the elm327 to send the message every 2 seconds or do I need to write a script that transmits that message repeatedly to keep the link going......or would it be possible to use a script to transmit the message as the BCM from one device and use a second device with the same header settings to issue terminal commands?

I have a script for sending and receiving sensor data from the pcm I could modify to send the repeating message using an altered header but I wouldn't be able to use any "terminal" commands with that elm device while the script was running. I would have to setup an additional set of parameters that would be activated with a switch.... but all the commands would need to be written into the script before I started it to even go down that road.

I feel like this thread has made some real progress even though I have't gotten any thing working yet....I'm getting close to what feels like the information I'm missing to make this work.
09-03-2017
kur4o

E8 FF 10 03 B3
E8 FF 60 03 98
E8 FF 40 03 ED
E8 FF 58 03 03
E8 FF 80 03 CE

These are state of health messages.
E8 is the priority I don`t have much information about this byte.
FF is the destination module ID. In that case FF means to all modules on the bus.
10 is ID of PCM
40 is ID of BCM
58, 60, 80 is other modules ID. I guess you can find chart on google.

You need to send following commands to elm device
AT H1, AT AL, AT MA.

Than you can make a huge sniff log. Make sure you press the tow,haul button multiple times and watch for some repeating messages. When you have enough data we can find the message of interest and clone it to the elm device.
09-03-2017
PeteS

Quote:

Originally Posted by kur4o

E8 FF 10 03 B3
E8 FF 60 03 98
E8 FF 40 03 ED
E8 FF 58 03 03
E8 FF 80 03 CE

These are state of health messages.
E8 is the priority I don`t have much information about this byte.
FF is the destination module ID. In that case FF means to all modules on the bus.
10 is ID of PCM
40 is ID of BCM
58, 60, 80 is other modules ID. I guess you can find chart on google.

You need to send following commands to elm device
AT H1, AT AL, AT MA.

Than you can make a huge sniff log. Make sure you press the tow,haul button multiple times and watch for some repeating messages. When you have enough data we can find the message of interest and clone it to the elm device.

Commands sent from this Elm and the response

Quote:

>aattmmaa
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED

Second Elm that was monitoring the same network but issued no commands

Quote:

Quote:

E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 01 ED
A8 3B 10 30 01 08
E8 FF 10 03 B3
E8 FF 40 03 ED
E8 FF 10 03 B3
E8 FF 40 03 ED
A8 3A 40 30 00 F0
A8 3B 10 30 00 15
E8 FF 10 03 B3
E8 FF 40 03 ED

I'm not sure where the additional 00F0 is coming from now but it's defiantly related to this. These were tested and recorded after the Pcm and Bcm had been on and doing it's back and forth thing for about 10 minutes just to make sure nothing else was being transmitted. The ONLY thing that was done was grounding the tow/haul input wire to the BCM repeatedly at various speed and duration. Every change in message I was able to watch occur when the wire made contact with ground. Holding the wire grounded had no impact I could tell, I was thinking the 00F0 may have been something to do with being grounded for too long but that didn't seem to have any thing to do with it.

The ONLY thing connected here is the BCM and the PCM. I have a couple codes in the bcm right now for a door pin switch circuit and a seat belt circuit. Pcm has no codes stored in history or as current.

If you also would like to see the power on bus data I can get that as well but there's a whole lot of stuff going on for the 1st 20-30 seconds or so after power on even with out activating any thing.

Thanks
09-04-2017
kur4o

If the switch is a momentary contact. One press will be on next press will be off.

The way I see the messages is
A8 3A 40 30 01 ED bcm send tow request on.
A8 3B 10 30 01 08 PCM answers that message is recieved.

A8 3A 40 30 00 ED bcm send tow request off.
A8 3B 10 30 00 08 PCM answers that message is recieved

LAST byte is checksum of message.
01 is on
00 is off
09-04-2017
PeteS

Quote:

Originally Posted by kur4o

If the switch is a momentary contact. One press will be on next press will be off.

The way I see the messages is
A8 3A 40 30 01 ED bcm send tow request on.
A8 3B 10 30 01 08 PCM answers that message is recieved.

A8 3A 40 30 00 ED bcm send tow request off.
A8 3B 10 30 00 08 PCM answers that message is recieved

LAST byte is checksum of message.
01 is on
00 is off

It is a momentary switch to ground, not a toggle on/off type of ground switch.

So do you have any thoughts on what/or how I should configure the Elm header to in order to simulate the send command? If the second line is in fact the On response I can get that part of this project rolling but with out being able to actually command it I'm still kind of dead in the water for the time being.

Thanks again......I'll check back for header settings in the meantime I'll go work on the On response from the pcm.
09-04-2017
kur4o

Change the header to a8 3a 40.
Than send commands 30 01 - on, 30 00- off
09-04-2017
PeteS

Quote:

Originally Posted by kur4o

Change the header to a8 3a 40.
Than send commands 30 01 - on, 30 00- off

I was able to set the header and issue the command however the serial terminal I'm monitoring from goes haywire when I issue the command. It sends several lines of repeating capital A's and looks like it resets the data bus since it spits out a whole bunch of lines and they are the same lines it spits out on startup.

I was kind of able to get it to work by creating a repeater of the
E8 FF 10 03 B3E8 FF 40 03 ED
and then issuing the 3001 command but the line had to be inserted into the code after the 40 03 ED line to not reset the bus and the back and forth of the pcm/bcm chatter has to be perfectly timed. If the pcm send's it's line twice with out the bcm responding it spits of a bunch of stuff and looks to reset. The same happens if the bcm line is send twice before the pcm responds with it's line. This appears to be some type of timed send/receive message since the rate that it occurs isn't constant, I tried monitoring it with 2 different type of devices at the same time to see if it was an adapter issue and both windows stay in time with each other, it's the rate the messages are sent that changes. That makes it hard to be able to keep my fake bcm message in time with the pcm and still be able to send the pid ID, once it's sent it drastically alters the timing for a couple of seconds and my program falls out of time almost instantly. It's progress since it does send the response message back that should mean it's been turned on but I have no way of trying the off command since it resets so quickly after falling out of time.

Back to the drawing board for the time being on getting the timing to work and stay lined up. I'm sure someone that programs for a living could whip this out pretty quick but...that's not me lol.

Good information and thanks for the help, now I just need to work this out so I can move forward with the off command.
09-04-2017
kur4o

The problem is how elm is configured. It doesn`t accept raw hex command easily. I think there was a translation between ascii characters and hex characters.

Search for elm237ds.pdf. You will find some very useful information there.