Message decoder for ODB / J1850 /J2178

[marantz2600]

I have an old 2001 Chevrolet Cavalier that has an intermittent problem that seems like it might be a computer module going bad.

The symptoms are that after turning the key off, dash lights will flash and relays click, etc. Sometimes it seems like it is shut down but maybe later in the night, the radio will turn on and it will often run the battery dead fiddling things.

I used an oscilloscope and looked at the power and ground and the data bus. Nothing seemed too bad.

My next thought was to dump the data bus and see what messages were going around. To my surprise, I couldn't seem to find anything that would do this.

So I thought how hard could it be to decode these little short messages. So I started writing a Python program. Well it turned out a bit harder that I had initially supposed.

So here it is. Not complete by any means but it can decode a bit of stuff. The worst thing is that despite putting in most of the stuff in the standards document, there are lots of things showing up that are not in the standards.

Here are a couple of examples:

Code: Select all

$ ./dj1850.py vspeed.log 

88291002344DFF
PCM:  Vehicle Speed
-- STATUS
	Vehicle Speed =  104.6015625 KPH


$ ./dj1850.py rpm-and-map.log 

101CD317D33AB9
Engine RPM-Speed-MAP
	RPM =  1844.75
	Vehicle Speed =  47.6484375 KPH
	 Engine RPM-Speed-MAP  =  58


$ cat rpm-and-map.log 
10 1C D3 17 D3 3A B9 


$ cat vspeed.log 
88 29 10 02 34 4D FF

dj1850.py

(81.8 KiB) Downloaded 108 times

If anybody out there understands this stuff, I would be glad to hear from you.

Thanks!

[antus]

Thanks for shareing the tool! It would have been quite an interesting journey coming at it that way.

Some of those radios are built to communicate with the dash, and might communicate with other parts too. Try pulling the fuse or the radio and leave it off the bus for a week and see if the rest of the problems go away. There is a lot of proprietary, or not well known stuff on the bus. Even though the addressing adheres to standards, its unlikely you'll be able to make sense of all of it, and that 'radio comes on' is a red flag. If not try some of the other modules, probably BCM next, and you'll probably get to the bottom of it quicker that way.

[marantz2600]

It is funny/frustrating but as soon as I got the OBDLink SX tool that could record messages with the ATMA command, the problem disappeared. Hasn't happened once since then.

I joke that the car is possessed but it is probably cold related. I had a similar situation the previous winter where it was acting up in a similar manner but then after I built a bench setup to test the computer modules off the car, it quit doing it.

My first thought was some cold related connector/solder joint problem. But after thinking about it a bit, I am kind of thinking it might be related to the current draw off the battery when starting in cold weather. Maybe this glitches the computers in some way.

I did try disconnecting the radio. I have an aftermarket radio and it requires an interface module to simulate the operation of the factory radio. So this was something that could easily be wrong. But disconnecting did not seem to make a difference.

I maybe need to buy a new battery but those are pricey and I don't want to waste the money if I don't have to. The current battery will start the car every time even when the fuel mixture gets goofed up and it has to crank a long time to clear out the bad fumes.

I am pretty old now but at one time I was computer programmer / embedded systems engineer. Any time we were developing a bus related product, the company would get hold of a bus monitoring device. It didn't solve every problem but it was nice to be able to see what was going on. So that is why I looked for something like this when it appeared that the computers were going insane.

So anyway, just playing around. Luckily I am still able ride a bike if I have to as a backup. Ha ha...

[marantz2600]

dj1850.py

(110.55 KiB) Downloaded 117 times

dj1850.py

(110.55 KiB) Downloaded 117 times

Here is an update to the message decoding program.

I added a field to the data definitions to indicate the source of the information. Mostly this is from the standard but it could also be me just guessing which is of course less reliable.

I also put in some command line processing that allows for a '-v' or '--verbose' flag that will show a lot of debugging information.

Notably, the odometer messages now decode. I discovered that both the BCM and the PCM broadcast odometer information but in different data formats.

In my car, I noticed that someone must have replaced the BCM without changing the eprom info. So the odometer reading from the BCM and the PCM are different. My guess
is that if both modules broadcast in the same format, the instrument panel display might flip back and forth?