E46 Can bus project.

[SeanCollins]

Hello All. been working on the circuit layout for the "analog" solution. Attached is a PDF showing what I'm thinking about for wiring. Please have a look and provide feedback. I've tested all but the fuel consumption, simulating what I believe the LS1 PCM does, and it looks good. (I don't have a solenoid so can't simulate the fuel injection circuit) But I am open to input on improvements. Garrett is working on the physical circuit layout. I'll try to hook this to my LS1 when I'm home and see how it works.I'm currently starting to pack and move.

Due to the move: between June 24th and around July 4th my internet access will be sporatic if at all. So if I don't reply right away don't take offence




If by some miracle the 2 sensors provided simlar outputs then perhaps we coulo get one sensor to send both signals. THe both operate on 5V.

with airflow adaptives, the ecu should be able to compensate for some variation, it is something that can be calibrated in the ECU tables for airflow vrs liquid line pressure.

[douglee25]

My WIP!
M3 cluster controlled by a game. Couldn't have done without your work on the canbus

http://youtu.be/sHjEXv_bb5k
+ Reply to Thread
Again, thank you

Nice work!

Embedded so folks can see.

[Thaniel]

Hi Everyone. for those that are interested I'mback in USA. Things have been busy trying to get the house and cars back in order. And there is good news and bad news.

For those that are keeping track I'll give the good news and bad news on the non running $2000 E46 I bought (the red BMW).
Good news: It is in better condition than I thought and has the Harmon karmon sound option which I wasn't told about
Bad news: My daughter is getting her drivers licence and thinks it'd be a great car for her to drive
Good news: The engine appears to be good and it is some external issue
Bad news: An E46 engine Swap for me appears will be delayed further.
Good News: To get it running required just a Fuel pump and new intake hoses.
Bad news: Reverse does not work.
Good news: I may have a free 330i transmission available from my brothers Auto to Manual Swap.
Bad news: it's 10 hours away.....
Good news: I have to go there for a wedding anyway.

In other news:
Good news: I am so dedicated (or obsessed) to the can project, I used precious suitcase space to bring my instrument cluster with me on the plane instead of in the shipping container (which will take more weeks to get here)
Bad news: the airlines lost my luggage.
Good news: they found it and delivered it to my house even before I got there
Bad news: been busy with everything else and have not even connected the wires to it again.

Good news: my E36 LS1 started right up when I got home
Bad news: needed new tires and a windshield before passing inspection
Good news: I can finally put on the Staggered M rims I bought
Bad news: the inspection station I used to use that didn't care I had a swapped engine closed while I was gone
Good news: the one recommended by a friend passed the car with the comment "love the headers" and other positive comments

About it for now. I really want to hook up to the Class2 serial bus on my LS1 and listen to it. Soon...

Thaniel

[douglee25]

LOL!

Good post!

Doug

[Soorena]

Very great thread. Just wanted to say that.

Keep up the good work

[nurburgracer]

Alot of Good and Bad news... Sounds mostly good though!

What are the next practical plans for the car and CAN solution?

[Thaniel]

What are the next practical plans for the car and CAN solution?

For the Red E46 the plan looks to be put it back on the road in stock form. For at least one more year. My daughter has taken a liking to the car. She drove it for the first time yesterday (forward only, no reverse yet). She was nothing but smiles.

For the Can solutions. I want to wire up my cluster and the Analog set up to my LS1 and show the gauges running right off an engine. I'll do that soon. Have had more things to fix than expected. But will do that soon. Think I have what I need to hook it up. Also plan to connect to the LS1 ECU using the Class 2 serial bus and decode the stream.

Thaniel

[V8Z4]

For the Can solutions. I want to wire up my cluster and the Analog set up to my LS1 and show the gauges running right off an engine. I'll do that soon. Have had more things to fix than expected. But will do that soon. Think I have what I need to hook it up. Also plan to connect to the LS1 ECU using the Class 2 serial bus and decode the stream.

Thaniel

Sounds good.

[Thaniel]

Update:

Last Saturday Garrett hooked up an interface to my LS1 and attempted to read the Class 2 serial bus. I was affraid that since the LS1 was by itself and not connected to anything else it wouldn't broadcast the messages. But it does. Garrett was able to get a steam of messages that would change depending on key position. Yesterday together we hooked up to it again. here is a sample of the class 2 data stream with the engine running. This is not the polled and responded data. Though we did that too. This is simply listening to the bus with absolutely no sending.

88 1B 10 10 10 FC 11
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
88 1B 10 10 10 BA 4C
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
88 3B 10 03 80 E7
88 53 10 84 E2
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
88 3B 10 03 80 E7
88 53 10 84 E2
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
E8 FF 10 03 B3
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
E8 FF 10 03 B3
88 1B 10 10 10 6F DD
88 1B 10 10 10 B3 B9
88 1B 10 10 10 68 8E
88 1B 10 10 10 AC CF
88 1B 10 10 10 55 45
88 1B 10 10 10 9C 85
E8 FF 10 03 B3
88 1B 10 10 10 59 D9
88 1B 10 10 10 A0 53
88 1B 10 10 10 56 62
E8 FF 10 03 B3

From researching the format is defined as:
Priority, "Destination", Source, Mode, Data bits, Checksum
It appears that it only sends the information if the value has CHANGED. if it is the same it doesn't send it. Or in other words. If I don't touch the throttle the message on throttle position doesn't send until the value changes. That works and makes reverse engineering the messages even easier. So far we have isolated the Throttle position, RPM and maybe Temperature. We didn't spend much time on it last night (1 hour maybe). But this is a summary of what we have found

RPM:
88 1B 10 10 XX YY Checksum
priority is 88, Destination 1B, Source 10 (ECU), Mode 10, then 2 data bits followed by a check sum. Formula to convert to RPM = Hex2Dec(XXYY)/4

TPS:
68 13 10 11 XX Checksum
Formula for % of throttle = Hex2Dec(XX)/255 (then convert to %)

In the data stream there are many more messages. Most of them appear to be the ECU trying to get an answer from other modules that don't exist as the engine is not in the right car. I'd like to hook up to the factory car and listen to see what they say so a message could be sent to get the ECU to quit asking. But it doesn't appear to hurt anything to let it keep sending the messages.

Oh the "E8 FF 10 03 B3" message is the message it broadcasts when nothing else is going on. Is probably a "I'm here" message.
priority is E8, Destination FF, Source 10 (ECU), Mode 3, then a check sum. No data bits. From some documentation mode three might mean "request diagnostic trouble codes" So could be the ECU is asking for trouble codes from the other modules (Trans, ABS etc?)

We can easily isolate the temperature doing as Garrett suggested "hijack the temperature sensor". Or in otherwords unplug it from the engine and hook it to a variable resistor and swing it dramatically and watch which number in the data stream changes. Simple.

So how does this vary from the OBDII PID method that was used to run the IKE of the my rental car. This is just listening. The Class 2 serial operates much slower than the CAN bus requiring us to be more efficent when using VPW format. How neccessary? If my instrument cluster was still wired up I'd plug it in and give it a try and see how slow it would be using the OBDII PID's. Maybe later.

Thaniel

[V8Z4]

Sounds like some good progress. Is there a reason to request anything? The Class2 should automatically send out the information we are looking for (RPM, temp, TP, etc) and we only update as it changes. That would keep the line open with less overhead.

[dgorman1]

Thaniel,

I'm working on a much simpler version of the E46 (and E36) view of fuel consumption. I'm currently using the OBDII kit from arduinodev to make the CAN negotitation easier ( http://www.arduinodev.com/hardware/obd-kit/ ) and have a simple sketch that is getting RPM/Coolant Temp/Intake Temp from OBD Mode 1

It looks like according to the CAN specs that Fuel Usage should be on 0x5E Mode 1, however, based on your data it's on a different ARBID (5?) . I also notice you're putting the whole ARBID in an array and referencing it - is there just a simple HEX I can use (can't seem to figure it out) and reference it directly?

My goal here is to show current fuel consumed in l/h and then eventually log it.


Thank you for all this work - it's been a fantastic read!! I've also been checking out the code you've posted and it's been very helpful - so thank you again!

Dan

Update:

Last Saturday Garrett hooked up an interface to my LS1 and attempted to read the Class 2 serial bus. I was affraid that since the LS1 was by itself and not connected to anything else it wouldn't broadcast the messages. But it does. Garrett was able to get a steam of messages that would change depending on key position. Yesterday together we hooked up to it again. here is a sample of the class 2 data stream with the engine running. This is not the polled and responded data. Though we did that too. This is simply listening to the bus with absolutely no sending.

88 1B 10 10 10 FC 11
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
88 1B 10 10 10 BA 4C
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
88 3B 10 03 80 E7
88 53 10 84 E2
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
88 3B 10 03 80 E7
88 53 10 84 E2
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
E8 FF 10 03 B3
89 32 10 22 4F
A9 24 10 03 82
AB 24 10 05 00 46
C9 FE 10 06 82
8A EA 10 A0 82 00 8A
8A EA 10 A0 84 00 3F
8A EA 10 20 88 00 88
8A EA 10 20 8E 00 3D
8A EA 10 20 8F 00 71
E8 FF 10 03 B3
88 1B 10 10 10 6F DD
88 1B 10 10 10 B3 B9
88 1B 10 10 10 68 8E
88 1B 10 10 10 AC CF
88 1B 10 10 10 55 45
88 1B 10 10 10 9C 85
E8 FF 10 03 B3
88 1B 10 10 10 59 D9
88 1B 10 10 10 A0 53
88 1B 10 10 10 56 62
E8 FF 10 03 B3

From researching the format is defined as:
Priority, "Destination", Source, Mode, Data bits, Checksum
It appears that it only sends the information if the value has CHANGED. if it is the same it doesn't send it. Or in other words. If I don't touch the throttle the message on throttle position doesn't send until the value changes. That works and makes reverse engineering the messages even easier. So far we have isolated the Throttle position, RPM and maybe Temperature. We didn't spend much time on it last night (1 hour maybe). But this is a summary of what we have found

RPM:
88 1B 10 10 XX YY Checksum
priority is 88, Destination 1B, Source 10 (ECU), Mode 10, then 2 data bits followed by a check sum. Formula to convert to RPM = Hex2Dec(XXYY)/4

TPS:
68 13 10 11 XX Checksum
Formula for % of throttle = Hex2Dec(XX)/255 (then convert to %)

In the data stream there are many more messages. Most of them appear to be the ECU trying to get an answer from other modules that don't exist as the engine is not in the right car. I'd like to hook up to the factory car and listen to see what they say so a message could be sent to get the ECU to quit asking. But it doesn't appear to hurt anything to let it keep sending the messages.

Oh the "E8 FF 10 03 B3" message is the message it broadcasts when nothing else is going on. Is probably a "I'm here" message.
priority is E8, Destination FF, Source 10 (ECU), Mode 3, then a check sum. No data bits. From some documentation mode three might mean "request diagnostic trouble codes" So could be the ECU is asking for trouble codes from the other modules (Trans, ABS etc?)

We can easily isolate the temperature doing as Garrett suggested "hijack the temperature sensor". Or in otherwords unplug it from the engine and hook it to a variable resistor and swing it dramatically and watch which number in the data stream changes. Simple.

So how does this vary from the OBDII PID method that was used to run the IKE of the my rental car. This is just listening. The Class 2 serial operates much slower than the CAN bus requiring us to be more efficent when using VPW format. How neccessary? If my instrument cluster was still wired up I'd plug it in and give it a try and see how slow it would be using the OBDII PID's. Maybe later.

Thaniel

[Thaniel]

That would keep the line open with less overhead.

That was my thinking as well.

Did some more computer research reading the SAE specs. Now am able to decode more of the data stream.

Temperature:
68 48 10 10 XX checksum
Temp in F = 9/5 *(HEX2DEC(XX)-40)+32

Vehicle speed:
88 29 10 01 XX Checksum
Speed = HEX2DEC(XX)*0.621

Barametric pressure (what would anyone do with this)
A8 F3 10 11 XX Checksum

There's other stuff. but that's the bulk of the interesting stuff from the stream I sampled.

Thaniel

[V8Z4]

I wonder, is that barameric pressure actually the MAP reading or a reference against which the MAP is referenced? I can't imagine what a person would really use barametric pressure.

What about oil pressure?

Is there any voltage (charging) data? I was under the impression the class2 had a charging voltage signal that was sent to the gauges.

[Thaniel]

I wonder, is that barameric pressure actually the MAP reading or a reference against which the MAP is referenced? I can't imagine what a person would really use barametric pressure.

What about oil pressure?

Is there any voltage (charging) data? I was under the impression the class2 had a charging voltage signal that was sent to the gauges.

If the ECU knows it I'm pretty sure it can be obtained from the class 2 bus. Trouble is I think some of the messages aren't broadcast due to there not being the other modules there or the sensing device is not present on my engine. For instance, fuel level % is reported on the class 2 but since I don't feed the ECU any fuel level info signals the value reported is simply zero. Another odd thing is it keeps trying to turn the brake light on but never gets an acknowledgement from the instrument panel that its on. So keeps trying. And it keeps trying to switch various nodes to "high speed mode" but of course they don't reply. So this is repeated. Having a functional complete car to test would come in handy. Then I could find what responses the ECU wants and mimic them to make it happy and also to supply more information in the stream. Luckily there are lots of GM cars here in the USA so I should be able to find someone that will let me plug into it. Just have to find the right one.

Thaniel

[bimerok]

My guess would be that barometric pressure reading is coming of MAP sensor and is used for adjsting fuel maps based on different altitude changes...

[SeanCollins]

Thaniel, just as a note, GM keeps fiarly close to the OBD2 spec for can etc, more so then other manufacturers. The old class 2 stuff though, have fun, I don't see the value since you can grab pids, which makes your device portable to nearly any ecu supporting standard 0bd2 pids.

[dgorman1]

Thaniel,

Maybe it's easier to figure out the PID for the current fuel usage on 0x545 B1? The pid 0x5E doesn't seem to work - maybe I'm doing something dumb?

ARBID: 0x545 (DME4)
-B0 Check engine light (binary 10), Cruise light (binary 1000), EML (binary 10000). combinations work to get multiple lights
-B1 Fuel consumption LSB
-B2 Fuel consumption MSB. Values just cycle from 0 to FFFF then start over at zero. Fuel consumiption is the rate of change.
-B3 Overheat light (binary 1000, Hex 08)
-B4 Oil Temp [Temp in C = .75 * hex2dec(byte04) - 48.373]

[Thaniel]

My guess would be that barometric pressure reading is coming of MAP sensor and is used for adjusting fuel maps based on different altitude changes...

Probably so. Guess that means we could make our own aftermarket Altimeter or weather station? I can't think of any reason for me personally to know the reading (good for the ECU to know it though).

Thaniel, just as a note, GM keeps fairly close to the OBD2 spec for can etc, more so then other manufacturers. The old class 2 stuff though, have fun, I don't see the value since you can grab pids, which makes your device portable to nearly any ecu supporting standard 0bd2 pids.

Agreed. It has made turning the class 2 data into real numbers quite easy as all the calculations in the class 2 data match the OBDII formula data.

I already did the run the instrument cluster off using OBDII commands and messages on my rental car. Though I do owe you guys a demo doing it connected to the LS1. Maybe this weekend if I can find all the wires? When it comes down to it though, catching the stream of class 2 data is more efficient and therefore faster. And I like faster computers just as much as faster cars. One could say they don't see they point of putting an LS1 into a BMW. The factory engine works . Not saying they are wrong. There is just fun and satisfaction to be had with faster.

Maybe it's easier to figure out the PID for the current fuel usage on 0x545 B1? The pid 0x5E doesn't seem to work

Not all PID's are supported by each manufacturer. There are basic PID's that are probably required and supported by all. But I believe I read fuel consumption is not one of them. And one reason I didn't bother to include fuel consumption in my OBDII program. Take it doesn't work on the LS1? But maybe the LS3? The PID command (0x00) will find out which PID's are supported by the ECU. I'll run that on my and post the results if someone else doesn't first.

I was thinking that if the fuel consumption information isn't readily available from the LS1 a calculation based off the Mass air flow rate (0x10 PID) would make a fair approximation. Not as accurate as the actual fuel flow but face it. We aren't in it for fuel consumption If that fails to work then a calculation based on throttle position would make the needle swing in a nice relative way. Of course we could still sample the actual injector signal to get an accurate reading and make a calculation but I'm assuming in this discussion we are trying to do it all through the one data line.

Thaniel

[dgorman1]

Not all PID's are supported by each manufacturer. There are basic PID's that are probably required and supported by all. But I believe I read fuel consumption is not one of them. And one reason I didn't bother to include fuel consumption in my OBDII program. Take it doesn't work on the LS1? But maybe the LS3? The PID command (0x00) will find out which PID's are supported by the ECU. I'll run that on my and post the results if someone else doesn't first.

I was thinking that if the fuel consumption information isn't readily available from the LS1 a calculation based off the Mass air flow rate (0x10 PID) would make a fair approximation. Not as accurate as the actual fuel flow but face it. We aren't in it for fuel consumption If that fails to work then a calculation based on throttle position would make the needle swing in a nice relative way. Of course we could still sample the actual injector signal to get an accurate reading and make a calculation but I'm assuming in this discussion we are trying to do it all through the one data line.

Thaniel

Thaniel,
In your E46 "query" of the CAN BUS it looks like you saw that it was supported. I would be curious if you could run (0x00) on the E46 (or even better the E36) to see if it's supported. My goal is to log fuel usage on E46 and an E36 from the ECU.

I would really appreciate it...

More background detail:
I'm working on a much simpler version of the E46 (and E36) view of fuel consumption. I'm currently using the OBDII kit from arduinodev to make the CAN negotiation easier ( http://www.arduinodev.com/hardware/obd-kit/ ) and have a simple sketch that is getting RPM/Coolant Temp/Intake Temp from OBD Mode 1

It looks like according to the CAN specs that Fuel Usage should be on 0x5E Mode 1, however, based on your data it's on a different ARBID (5?) . I also notice you're putting the whole ARBID in an array and referencing it - is there just a simple HEX I can use (can't seem to figure it out) and reference it directly?


Dan

[dgorman1]

Not all PID's are supported by each manufacturer. There are basic PID's that are probably required and supported by all. But I believe I read fuel consumption is not one of them. And one reason I didn't bother to include fuel consumption in my OBDII program. Take it doesn't work on the LS1? But maybe the LS3? The PID command (0x00) will find out which PID's are supported by the ECU. I'll run that on my and post the results if someone else doesn't first.

I was thinking that if the fuel consumption information isn't readily available from the LS1 a calculation based off the Mass air flow rate (0x10 PID) would make a fair approximation. Not as accurate as the actual fuel flow but face it. We aren't in it for fuel consumption If that fails to work then a calculation based on throttle position would make the needle swing in a nice relative way. Of course we could still sample the actual injector signal to get an accurate reading and make a calculation but I'm assuming in this discussion we are trying to do it all through the one data line.

Thaniel

Thaniel,
Based on your output of the E46 CAN BUS it looks like Fuel Usage is available. I'm working on a much simpler project to just log Fuel Usage from a E46 and E36 from the ECU using a basic OBD project. I would really appreciate it if one could run the (0x00) against the E46 and E36 to for the Fuel Usage PID.

There may be a double post - apologize as bf.c marked it as needing attention.

Dan

[dgorman1]

Hey Dan, My son Garrett ran the PID query on the LS1 and E46 yesterday. I"ll post the results later when he sends them. Sorry my E36's no longer contain the BMW ECU and were not OBDII versions anyway. So can't help there.

One Thing to note is that the E36 and E46 do NOT use Can bus for OBDII (don't think E36 even does Can bus at all). They use the ISO protocol over the diagnostic bus. Doesn't change what you are going to do but does affect which protocol and chip set is required to do it


I checked the link. What he has done is taken a ELM327 clone and soldered on a serial connection instead of a USB connection. His development post gave me the idea for mine: http://forums.bimmerforums.com/forum...7#post26116557

both still use the MCP2551 chip in the devices but use a ELM327 clone instead of the MCP2515 chip. For Can BUS the MCP2515 chip is much easier to work with. But the ELM327 clone also has ISO, VPW etc built in (but those don't need the MCP2551 chip and uses a different circuit).


OBDII PID's and the ARBID's I post from the data stream are totally different data packets. As mentioned the E46 doesn't do the OBDII over the Can bus but a different bus. Sending an OBDII request over the Can bus will not receive a reply (at least it didn't when I tried it). But sent over the Diagnostic bus (using the OBDII connector) and the proper ISO protocol an answer will be given. The information on the Can bus doesn't mean it is or isn't available on the OBDII. Just depends on what the manufacturer decides to include. I forgot to ask Garrett if the Fuel consumption was on the E46. I did ask about the LS1 and it was NOT included. I didn't think it was. Will post full results later.

Thaniel.

Thaniel,
Wow - so I had almost 0 chance of getting this working without your help, so I REALLY appreciate this effort. Let me know what protocol/chip I should be using to get the fuel usage rate and I will get the appropriate boards/shields.

The E36 I have is a 1997 and technically OBD-II, but my recollection is that it's some simple/lame version of it. So I hope that the fuel usage protocol/chip that works for the E46 will work on the E36.

I look forward to Garrett's check on the data - again - I really appreciate this help. If there is someway I can contribute back that, let me know.

[dgorman1]

Hey Dan, My son Garrett ran the PID query on the LS1 and E46 yesterday. I"ll post the results later when he sends them. Sorry my E36's no longer contain the BMW ECU and were not OBDII versions anyway. So can't help there.

One Thing to note is that the E36 and E46 do NOT use Can bus for OBDII (don't think E36 even does Can bus at all). They use the ISO protocol over the diagnostic bus. Doesn't change what you are going to do but does affect which protocol and chip set is required to do it


I checked the link. What he has done is taken a ELM327 clone and soldered on a serial connection instead of a USB connection. His development post gave me the idea for mine: http://forums.bimmerforums.com/forum...7#post26116557

both still use the MCP2551 chip in the devices but use a ELM327 clone instead of the MCP2515 chip. For Can BUS the MCP2515 chip is much easier to work with. But the ELM327 clone also has ISO, VPW etc built in (but those don't need the MCP2551 chip and uses a different circuit).


OBDII PID's and the ARBID's I post from the data stream are totally different data packets. As mentioned the E46 doesn't do the OBDII over the Can bus but a different bus. Sending an OBDII request over the Can bus will not receive a reply (at least it didn't when I tried it). But sent over the Diagnostic bus (using the OBDII connector) and the proper ISO protocol an answer will be given. The information on the Can bus doesn't mean it is or isn't available on the OBDII. Just depends on what the manufacturer decides to include. I forgot to ask Garrett if the Fuel consumption was on the E46. I did ask about the LS1 and it was NOT included. I didn't think it was. Will post full results later.

Thaniel.

Thaniel,
Wow - so I had almost 0 chance of getting this working without your help, so I REALLY appreciate this effort. Let me know what protocol/chip I should be using to get the fuel usage rate and I will get the appropriate boards/shields.

The E36 I have is a 1997 and technically OBD-II, but my recollection is that it's some simple/lame version of it. So I hope that the fuel usage protocol/chip that works for the E46 will work on the E36.

I look forward to Garrett's check on the data - again - I really appreciate this help. If there is someway I can contribute back that, let me know.

[Thaniel]

In your E46 "query" of the CAN BUS it looks like you saw that it was supported. I would be curious if you could run (0x00) on the E46 (or even better the E36) to see if it's supported. My goal is to log fuel usage on E46 and an E36 from the ECU.

Hey Dan, My son Garrett ran the PID query on the LS1 and E46 yesterday. I"ll post the results later when he sends them. Sorry my E36's no longer contain the BMW ECU and were not OBDII versions anyway. So can't help there.

One Thing to note is that the E36 and E46 do NOT use Can bus for OBDII (don't think E36 even does Can bus at all). They use the ISO protocol over the diagnostic bus. Doesn't change what you are going to do but does affect which protocol and chip set is required to do it

I'm working on a much simpler version of the E46 (and E36) view of fuel consumption. I'm currently using the OBDII kit from arduinodev to make the CAN negotiation easier ( http://www.arduinodev.com/hardware/obd-kit/ ) and have a simple sketch that is getting RPM/Coolant Temp/Intake Temp from OBD Mode 1

I checked the link. What he has done is taken a ELM327 clone and soldered on a serial connection instead of a USB connection. His development post gave me the idea for mine: http://forums.bimmerforums.com/forum...7#post26116557

both still use the MCP2551 chip in the devices but use a ELM327 clone instead of the MCP2515 chip. For Can BUS the MCP2515 chip is much easier to work with. But the ELM327 clone also has ISO, VPW etc built in (but those don't need the MCP2551 chip and uses a different circuit).

It looks like according to the CAN specs that Fuel Usage should be on 0x5E Mode 1, however, based on your data it's on a different ARBID (5?) . I also notice you're putting the whole ARBID in an array and referencing it - is there just a simple HEX I can use (can't seem to figure it out) and reference it directly?

OBDII PID's and the ARBID's I post from the data stream are totally different data packets. As mentioned the E46 doesn't do the OBDII over the Can bus but a different bus. Sending an OBDII request over the Can bus will not receive a reply (at least it didn't when I tried it). But sent over the Diagnostic bus (using the OBDII connector) and the proper ISO protocol an answer will be given. The information on the Can bus doesn't mean it is or isn't available on the OBDII. Just depends on what the manufacturer decides to include. I forgot to ask Garrett if the Fuel consumption was on the E46. I did ask about the LS1 and it was NOT included. I didn't think it was. Will post full results later.

Thaniel.

- - - Updated - - -

Thanks to Garrett here is the Supported OBDII PID list

from my LS1 (2002 Camaro)

PID	Description
1	Monitor status since DTCs cleared. (Includes malfunction indicator lamp (MIL) status and number of DTCs.)
3	Fuel system status
4	Calculated engine load value
5	Engine coolant temperature
6	Short term fuel % trim—Bank 1
7	Long term fuel % trim—Bank 1
8	Short term fuel % trim—Bank 2
9	Long term fuel % trim—Bank 2
0B	Intake manifold absolute pressure
0C	Engine RPM
0D	Vehicle speed
0E	Timing advance
0F	Intake air temperature
10	MAF air flow rate
11	Throttle position
12	Commanded secondary air status
13	Oxygen sensors present
14	Bank 1, Sensor 1:
15	Bank 1, Sensor 2:
18	Bank 2, Sensor 1:
19	Bank 2, Sensor 2:
1C	OBD standards this vehicle conforms to

From my E46 (1999 323i)

PID	Description
1	Monitor status since DTCs cleared. (Includes malfunction indicator lamp (MIL) status and number of DTCs.)
3	Fuel system status
4	Calculated engine load value
5	Engine coolant temperature
6	Short term fuel % trim—Bank 1
7	Long term fuel % trim—Bank 1
8	Short term fuel % trim—Bank 2
9	Long term fuel % trim—Bank 2
0C	Engine RPM
0D	Vehicle speed
0E	Timing advance
0F	Intake air temperature
10	MAF air flow rate
11	Throttle position
12	Commanded secondary air status
13	Oxygen sensors present
14	Bank 1, Sensor 1:
15	Bank 1, Sensor 2:
18	Bank 2, Sensor 1:
19	Bank 2, Sensor 2:
1C	OBD standards this vehicle conforms to

You'll notice there is more information available listening to the cars internal Data stream than the government mandated diagnostic protocol (OBDII).

Thaniel

[dgorman1]

Wow, okay. So knowing that fuel usage is on the diagnostic bus, how would we go about figuring out communications with it and reading values?

This is fantastic work!! Thank you both! Knowing that I'm not wasting time trying to chase and OBD PId saves a bunch of time. If there is some way I can help contribute, let me know

[Thaniel]

Update.

My container from Sweden arrived friday. So now the house is full of boxes. But I do have all my stuff again. Guess I could have shipped my isntrument cluster in the container instead of my suitcase.

I've made it through most of the car and motorcycle repairs on my "to do" list. So doing some proof of concept with my LS1 and E46 cluster is starting to become appealing. Yesterday did some work on the "analog" connection circuit using the Eagle schematic software. Took me a bit to figure out the software out but can work it ok now.

Thaniel