ELM327 & Class 2 Serial Data

[04colyZQ8]

What module is C7 ? External security??

 

[azswiss]

I *believe* C7 is "External Access - Status" (vs. C6 "External Access - Command"). Associated addresses:

C4 Door Locks - Command
C5 Door Locks - Status
C6 External Access - Command
C7 External Access - Status

 

[04colyZQ8]

Ok and what module does that go to?

Bcm?

(Mod edit: Posts merged. You can edit your posts for 10 minutes if you need to add more info)

 

[azswiss]

To determine the specific modules involved you will need to check the Source & Target data in the messages. As an example (apologies for the eye chart!) , here is a data captured from my '03 Suburban as I lock the doors:

Modules present are 40 - BCM; A0 - Driver Door Module; & A1 - Passenger Door Module.
In the first line the Source 40 - BCM sends out a door lock command to Target C4 - Door Locks - Command. The Driver Side & Passenger Side recognize this Command message and respond with acknowledgements. Line 2 is from Source A0 Driver Door Module to Target C5 - Door Locks Status; line 3 is from Source A1 - Passenger Door Module to C5 - Door Locks Status. The BCM recognizes these as acknowledgements.

Edit: I cannot speak to C7 as I do not have specific examples. That said, the process would be the same.

 

[04colyZQ8]

To determine the specific modules involved you will need to check the Source & Target data in the messages. As an example (apologies for the eye chart!) , here is a data captured from my '03 Suburban as I lock the doors:
View attachment 107931
Modules present are 40 - BCM; A0 - Driver Door Module; & A1 - Passenger Door Module.
In the first line the Source 40 - BCM sends out a door lock command to Target C4 - Door Locks - Command. The Driver Side & Passenger Side recognize this Command message and respond with acknowledgements. Line 2 is from Source A0 Driver Door Module to Target C5 - Door Locks Status; line 3 is from Source A1 - Passenger Door Module to C5 - Door Locks Status. The BCM recognizes these as acknowledgements.

Edit: I cannot speak to C7 as I do not have specific examples. That said, the process would be the same.

Yes I wish I had a excel spreadsheet that organized my messages like that!

I understand how it works more or less..lol

But I don’t have a module C7!

I have ,
Pcm 10
Bcm 40
Cluster 60
Abs 28
Sdm 58 ?
Battery module 16
Theft module C0 ?

I have nothing remotely close to C7.
What I don’t understand is how modules seem to have multiple address they send and receive from? Example cluster should be 60 yet seems to receive and possibly send from EA or EB as well. In fact there is hardly any messages to and from 60 at all.

Pcm seems to use 11, 10, and 93.

Could C7 be the onstar module I unplugged? Or the radio? They are the only two modules I’m missing. I have no chimes any more just turn signal sounds that’s it. After removing stock radio.

 

[azswiss]

OBD uses both Physical Addressing & Functional Addressing; C7 is a functional address.

Physical addressing allows a message to be addressed to a specific node or to all nodes or to a non-existent, null node. The information in this message is of relevance only to a particular node, so the other nodes on the bus should ignore the message, except for the case of the "all nodes" address. Functional addressing allows a message to be addressed or sent to one or more nodes on the network interested in that function.

Functional addressing is intended for messages that may be of interest to more than a single node. For example, an exterior lamp "off" message could be sent to all nodes controlling the vehicle exterior lamps by using a functional address. The functional address consists of a primary ID and may include a secondary ID and may also include an extended address.

Check out this link for more in-depth details: Class B Data Communication Network Messages— Detailed Header Formats and Physical Address Assignments

I have attached the Excel file I use for decoding messages on my '03 Suburban (raw data gets entered in cell B2, the rest is all just Lookup). The Lookup tab has a full listing of addresses. Feel free to PM me if you need additional details.

There are additional spec references in the Lookup tab.

 

[04colyZQ8]

Sweet thanks can’t wait to try it

 

[04colyZQ8]

Desperate for a vpw remote start message! Just need a log of a class 2 starting vehicle , when started with remote start.

-These are:
- 2005 to 2007
-Pontiac grand pri
-2005-2009 uplander or Montana
-2005-2008 hhr?
-select Cadillac models from 05-08?

 

[kastein]

Thanks very much for getting so much of this info documented up front. It's definitely helped me get started on my current project. I'm seeing some weird undocumented (at least in the 99 version of the standard... anyone got a later J2178-4 handy?) secondary IDs on more common primary IDs, as well as some things I just thought were interesting.

This is all relating to a 03 Savana 3500 with an LQ4, at least that's what the engine came from. No other modules on bus, only VCM. OS ID 12593058.
Some interesting messages I see:
88 53 10 04 C4 (appears to be engine status, runstatus, 04 = not running? plus checksum)
88 53 10 84 E2 (appears to be engine status, runstatus, 84 = running? plus checksum)
- I think those two basically just use the msb of the secondary ID to indicate engine running or not.

68 EA 10 0A 09 46 (I see this very regularly in my log. From discussion in this thread I think it's PRNDL indicator position... but this VCM was converted to manual by hptuners, so who knows how it configured the transmission segment, this may be insane data that doesn't match any factory OS bus message.)

49 92 10 01 BE (vehicle security message of some sort. VATS is disabled on this VCM, I have no idea what the rest of this data means.)

68 13 10 11 00 00 66 (throttle pedal position. Appears to report infrequently but all I did was idle it during this log.)

88 09 10 22 41 BE (engine torque. Unknown secondary ID. Last byte and csum vary. Maybe torque contribution per cylinder???)

8A EA 10 A0 *3bytes*
8A EA 10 20 *3bytes* (displays, unknown secondary IDs, data varies. I would love to know what these are, just because I'm curious.)

88 1B 10 10 0E D2 6B (engine rpm, but secondary ID of 10 doesn't show in my pdf, what format are the next two bytes? I was idling at 500-750ish RPM so I doubt it's just plain RPM, doesn't seem to be ignition events per minute either since that would be 948rpm for a 4stroke V8.)

The great news (at least for me) is that engine oil pressure, fuel level, coolant temp, vehicle speed all report accurately per SAE J2178-4 tables, and that's most of the way to what I need for my custom dash project, so aside from RPM this is mostly academic for me. If you want more data from more donor vehicles, I've attached a copy of the log I took... but be warned it's from PuTTY w/o timestamps not the android app you use.

 

[TJBaker57]

88 53 10 04 C4 (appears to be engine status, runstatus, 04 = not running? plus checksum)
88 53 10 84 E2 (appears to be engine status, runstatus, 84 = running? plus checksum)
- I think those two basically just use the msb of the secondary ID to indicate engine running or not

Correct. From memory I think what you are speaking of is called the "Q Bit". Been a while since I have read up on that so I may be off.

68 EA 10 0A 09 46 (I see this very regularly in my log. From discussion in this thread I think it's PRNDL indicator position... but this VCM was converted to manual by hptuners, so who knows how it configured the transmission segment, this may be insane data that doesn't match any factory OS bus message.)

Yes, the trans range selector position. As you say, once tweaked by a tuner it is essentially useless.

49 92 10 01 BE (vehicle security message of some sort. VATS is disabled on this VCM, I have no idea what the rest of this data means.)

In factory settings there is a dialog between the PCM/ECM and the BCM working out the details and status of the vehicle security. This message you quoted looks like a status request for secondary ID $01 from a PCM.

You seem to be on track gettings these dialed in.

The reason many are not in the pdf is manufacturers are free to create their own secondary IDs where the "standard" SAE documented IDs differ from what the manufacturer desires. Things such as resolution, units etc.

 

[TJBaker57]

8A EA 10 A0 *3bytes*
8A EA 10 20 *3bytes* (displays, unknown secondary IDs, data varies. I would love to know what these are, just because I'm curious.)

These are for displays generally for the IPC. Mainly warning lights. $A0 will be a light ON, $20 will be a light OFF. Like 8A EA 10 A0 8C 00 is the cruise control light ON and 8A EA 10 20 8C 00 is cruise control light OFF for early TrailBlazers.

88 1B 10 10 0E D2 6B (engine rpm, but secondary ID of 10 doesn't show in my pdf, what format are the next two bytes? I was idling at 500-750ish RPM so I doubt it's just plain RPM, doesn't seem to be ignition events per minute either since that would be 948rpm for a 4stroke V8.)

For my vehicles I divide the 2 byte value by 4 for engine rpm here. Both inline 6 and V8 engines. Same secondary ID should be the same definition. So your example should be 948.5 rpm.

 

[TJBaker57]

Thanks very much for getting so much of this info documented up front. It's definitely helped me get started on my current project. I'm seeing some weird undocumented (at least in the 99 version of the standard... anyone got a later J2178-4 handy?) secondary IDs on more common primary IDs, as well as some things I just thought were interesting.

This is all relating to a 03 Savana 3500 with an LQ4, at least that's what the engine came from. No other modules on bus, only VCM. OS ID 12593058.
Some interesting messages I see:
88 53 10 04 C4 (appears to be engine status, runstatus, 04 = not running? plus checksum)
88 53 10 84 E2 (appears to be engine status, runstatus, 84 = running? plus checksum)
- I think those two basically just use the msb of the secondary ID to indicate engine running or not.

68 EA 10 0A 09 46 (I see this very regularly in my log. From discussion in this thread I think it's PRNDL indicator position... but this VCM was converted to manual by hptuners, so who knows how it configured the transmission segment, this may be insane data that doesn't match any factory OS bus message.)

49 92 10 01 BE (vehicle security message of some sort. VATS is disabled on this VCM, I have no idea what the rest of this data means.)

68 13 10 11 00 00 66 (throttle pedal position. Appears to report infrequently but all I did was idle it during this log.)

88 09 10 22 41 BE (engine torque. Unknown secondary ID. Last byte and csum vary. Maybe torque contribution per cylinder???)

8A EA 10 A0 *3bytes*
8A EA 10 20 *3bytes* (displays, unknown secondary IDs, data varies. I would love to know what these are, just because I'm curious.)

88 1B 10 10 0E D2 6B (engine rpm, but secondary ID of 10 doesn't show in my pdf, what format are the next two bytes? I was idling at 500-750ish RPM so I doubt it's just plain RPM, doesn't seem to be ignition events per minute either since that would be 948rpm for a 4stroke V8.)

The great news (at least for me) is that engine oil pressure, fuel level, coolant temp, vehicle speed all report accurately per SAE J2178-4 tables, and that's most of the way to what I need for my custom dash project, so aside from RPM this is mostly academic for me. If you want more data from more donor vehicles, I've attached a copy of the log I took... but be warned it's from PuTTY w/o timestamps not the android app you use.

I loaded your logfile into the shared Google Sheet here...

https://docs.google.com/spreadsheets/d/1DtvyKBt29qUzLqqC2Rh3KTBtRg90yuzIMkW9baULp3I/htmlview

It should be viewable in a browser from this link. The sheet is not documented so feel free to ask questions.

 

[T56Tahoe]

Well this thread has been quite a read. Thanks to all who have taken the time to share for the benefit of others.
Like Kastien I am trying reconcile the aftermath of an engine swap.

I have a 2002 Tahoe with a E-ROD LS3 6.2 that only communicates with CAN. So using this forums information and others; am intending to build a protocol converter between CAN and J1850VPW.

If anyone knows of such a device I would love to hear about it - here.

As the LS3 comes from Chevy completely tuned and smog legal, it runs and drives fine. I am however left without a functioning dash, ABS and HVAC.
I built an analog to digital converter board to add a bunch of extra senders and some redundant so I can report things outside of the CAN interface. I'll add outputs to control the HVAC later.

If I make progress, I hope to post my project details in hopes of helping others.

 

[AmpOverload]

I have a 2002 Tahoe with a E-ROD LS3 6.2 that only communicates with CAN. So using this forums information and others; am intending to build a protocol converter between CAN and J1850VPW.

If anyone knows of such a device I would love to hear about it - here.

Welcome to the forums!

Unfortunately, I don't know of any pre-built VPW/CAN protocol converter device, but it sounds like you have the skills to design one.

About a year ago I designed a PCB (Printed Circuit Board) to implement VPW protocol, for use as what I call a "Hardware Vehicle Simulator" (HVS). In case that sparks your interest, I posted about it here.

Of course, that would only be about half of the needed hardware/design.

But since that hardware has proven incredibly useful with my VXDIAG VCX Nano (SAE J2534 hardware) and Tech2Win software, I've been thinking about designing & building another "HVS" but one that speaks CAN protocol. To that end, I recently bought a CANbus "shield" (daughter-board) for an Arduino board. Haven't even begun to pursue that yet, but I have the hardware to play with, eventually!

I know that your intended device and my device are differently purposed designs, but there would certainly be some overlap, so this is just some "food for thought", in case that helps spur your ideas and/or forum discussion.

I would very much like to hear more about your efforts, whenever appropriate. Good luck!

 

[T56Tahoe]

I saw your post on the board and have not had a chance to go through it yet. As this is almost the same project, I'll be glad to collaborate in helping us all out. You have been doing a mountain of work helping everyone on this forum so once I get a bit smarter, I'll try to contribute back.
I have a big pile of CAN, Arduino and related DIY resources and am trying to drill down to the most elegant, achievable and focused bits to make progress. I am really struggling to understand the problem and all the programming involved.
I'll keep reading here and everywhere and maybe I'll learn something.
Till then Cheers

 

[AmpOverload]

You have been doing a mountain of work helping everyone on this forum [...]

I fear that you may be confusing me with @TJBaker57. He has truly done a ton of work and made countless posts, generously sharing what he's learned. I'm a relative newcomer here (but a long-time SAE J1850 experimenter, both VPW and PWM, with a tiny smattering of CAN experience mixed in). I try to share what I've learned too, though.

It sounds like this could be the start of an interesting adventure, for all involved. I'd better start learning Arduino and get that CANbus shield's headers soldered on sometime soon!

 

[T56Tahoe]

I did indeed have the two of you blended in my head when I wrote the prior post. But a content contributor you so - "Right On Man"

I'm making a little progress but I keep falling in rabbit holes - like - watch out:
Automotive Linux

You didn't click on it did you - Now fellow tinker's we are in the same marsh up to our. . .

Hey Rocky let me pull another rabbit out of my hat. Hey Bullwinkle, that trick never works!
A local club arranged a dyno tuning training seminar so I'm in getting ready for a drive with people I have never met. What could go wrong?

My old road tripper never gets entirely finished

 

[T56Tahoe]

So my 2002 Tahoe has a 430 hp Connect-&-Cruise 6.2 with a Magnum 6-sp and 4:88 TrueTrack. It runs great but the only gauge I have is the:
UltraGauge
This is a real cool OBD2 gauge - But it's very tiny

Oh well it runs super good and is reliable - but I'm not feeling good on how long it is taking me to figure out how to hack the drivetrain and BCU busses together.

 

[AmpOverload]

I'm making a little progress but I keep falling in rabbit holes - like - watch out:
Automotive Linux

I'm a big fan of Linux. It's really all I use, for well over 20 years now. All of my OBD2 utilities (to gather and analyze vehicle data, typically for diagnosis) run on Linux desktop/laptop PCs. I'd heard of 'Automotive Grade Linux' but haven't really spent any time looking into it, so thanks for mentioning it -- another rabbit hole, indeed!

 

[T56Tahoe]

I got my first copy of Linux on 10 5-1/4 floppy's. It has always amazed me for all the barriers it has broken down in owning our computers. The other amazing thing is how resistant some are to giving it a try.

I'll set it up on virtual machine and a Raspberry Pie 4+ and at least see if I can understand it enough to get it going and try to interface a few analog inputs.

I'll probably have something to report in a week.

 

[santon]

Does anybody know the serial commands for the PRNDL display of the instrument cluster? My VFD PRNDL display is old and dim, so I am thinking about building an additional LCD display for the PRNDL. I know that command AE 18 FF FF 00 00 00 00 tests the PRiNDL by moving the cursor through all the letters, but I don't know the commands for the P, R, L, and so on.

 

[azswiss]

Definitely a question for @TJBaker57!

 

[TJBaker57]

Definitely a question for @TJBaker57!

Here is a brief video where I show sending messages to the IPC manipulating the PRND321 display...

In my 2002 Trailblazer the PCM sends messages to the IPC in this format:

68EA100AXXCS where "68EA10" is the 3 byte header, "0A" is the secodary ID for the PRND321 display, and "XX" is one of the following...

01 is P
02 is R
03 is N
09 is D

The "CS" is just the checksum byte.


I will have to look up the rest as these are the ones I remember.

To drive a separate display you would need to monitor the serial bus for messages with the header of "68EA10" followed by the secondary ID (4th byte) of 0A and then decode the 5th byte for the shift position.

Edit: I can almost see the needed hexadecimal values for the "3", "2", and "1" positions in the video, but I am on a phone screen and can't quite make it out.

Another note: I have occasionally seen a "00" value but I do not know the reason for that value. If memory serves I have seen it show up in P(ark) sometimes.

 

[kur4o]

Hi to everyone,
We have some small program that will analyze vpw traffic. It is not perfect but can be improved over time, with payload decoding. It is open source and anyone can contribute.
Analyzer can be opened from utilities->logger
https://github.com/joukoy/UniversalPatcher/blob/master/UniversalPatcher-Full.Zip

 

[AmpOverload]

Hi to everyone,
We have some small program that will analyze vpw traffic. It is not perfect but can be improved over time, with payload decoding. It is open source and anyone can contribute.
Analyzer can be opened from utilities->logger
https://github.com/joukoy/UniversalPatcher/blob/master/UniversalPatcher-Full.Zip

Welcome to the forums!

(I recognize your nickname from the PCMHacking.net forums, which I sporadically read.)

I haven't run Universal Patcher in almost 3 years, mostly because I run Linux, and (at least back then) it would not run under a Linux-hosted WinXP VirtualBox VM. But I was impressed by what the authors/contributors (JoukoY, yourself, etc) have created and would encourage others on this forum to look into using it too. And I'm sure it's come a long way in the last 3 years, so I need to try it again myself sometime!

I have a lot of experience decoding VPW-protocol traffic, but I'm not a C# guy and all of my stuff runs under Linux, so I cannot easily contribute to Universal Patcher. If the VPW analyzer was a C library, that might be another story.

Anyway, glad to see your post and hope others will give Universal Patcher a tryout sometime too!

 

[kur4o]

AmpOverload,
Thanks for the support.

It should run fine on xp SP3 on, as long as it have the latest microsoft .net, version 4.xx something. I don`t think vm will do anything on the way.

Actually C is much faster and reliable and will be much more suitable for analyzer, since it lacks speed now. We got some support fo C dlls, and if you have some code we can port it for sure.

On another subject, I am trying to tune up the GM through speakers warning messaging.

The baddest design ever. It engage the amplifier and there is some loud hiss from speakers all the time. Does anyone hacked a 2002 radio to not run the amplifier full time.
I ripped some config data from radio, mode 3b, but it is hard to guess what to change.

 

[santon]

In my 2002 Trailblazer the PCM sends messages to the IPC in this format:

68EA100AXXCS where "68EA10" is the 3 byte header, "0A" is the secodary ID for the PRND321 display, and "XX" is one of the following...

01 is P
02 is R
03 is N
09 is D

The "CS" is just the checksum byte.

This information is correct! Regarding the "3", "2" and "1" gears:

08 is the 3d gear
07 is the 2nd gear
06 is the 1st gear.

I am building a small setup with an OLED display - a gear position indicator. Attached is the picture of the setup. Here is the video of the gear indicator in action. The final version will be smaller, and I am going to put a display in some visible place on the dash.

 

[santon]

Does the PCM transmit the ATF temperature on serial bus? Or should we send a "request" in order to get the ATF temperature?

 

[azswiss]

There is a Transmission Fluid Temp PID. Easier to query using Torque but you should be able to query using the serial terminal though you will have to decode HEX. Settings for Torque below:

PID: 221940
Unit: deg F
Equation: ((A-40)*1.8)+32
Header: Auto
Scale Factor: 1x
Minimum: 0
Maximum: 225

 

[santon]

@azswiss, thanks! Sorry for the stupid question: how can I decode this 221940 PID to the HEX command for the ATF temperature request? I want to send this request once in 30-60 seconds (not from Torque) and get the ATF temperature.

 

[azswiss]

I *believe* "A" is going to be the first data bit in the response. I do
not have access to my PC so I cannot find my refs on message format, sorry. Will check my refs once I get back home and forward details. Will also check on my truck as well.

As a check, try first with the trans at ambient to confirm the analysis.

Let us know the responses you get.

(Edit: Google "HEX to decimal decoder" to convert the two character HEX value into decimal)

 

[azswiss]

Got an error when testing via Serial Terminal on my '03 Suburban. Need to go to the expert on this one!
Calling @TJBaker57! Question: How to query Trans Fluid Temp using Serial Terminal?

 

[azswiss]

Update: Found an error in the command sequence. Reran the test and got the identical temp value as shown in Torque. Here is the command sequence & the responses received:

ath1
OK
>
ats1
OK
>
atal
OK
>
atsh6c10f1
OK
>
22194001
6C F1 10 62 19 40 5B FD

The key data byte is "5B"; it comes right after "19 40" (PID). Converting 5B from HEX to Decimal yields 91. Putting this value for "A" in the equation above yields a trans fluid temp of 123.8F

 

[santon]

@azswiss, thanks! As I understand, the command "atsh6c10f1" is for sending a header "6C 10 F1"?

 

[azswiss]

@azswiss, thanks! As I understand, the command "atsh6c10f1" is for sending a header "6C 10 F1"?

Yes

 

[TJBaker57]

Does the PCM transmit the ATF temperature on serial bus? Or should we send a "request" in order to get the ATF temperature?

Coming in a bit late as I am otherwise busy and haven't been checking in here so often.

It may be that your PCM is reporting ATF fluid temperature in normal operation.

I did a quick search of my data collection and here we see transmission fluid temps reported as defined in SAE J2178.

The following shows the relevant messages from my 2002 Trailblazer in February of 2023. At startup the trans fluid temperature is reported as $20 which decodes to -8 °C or 17.6 °F. This clip ends with the temperature having risen to 38 °C or 100.4 °F some 13 minutes later. (The last entry in the clip is from a later file/ignition cycle.)



As you did with the PRND321 example, here you will need to scan for:

C83B1010XXCS

where C83B10 is the 3 byte header, "10" is the secondary ID, and XX is the transmission fluid temperature (hexadecimal) in centigrade with an offset of 40 °C. (The offset is used as a simple way to have negative values which are not easily expressed in hexadecimal)

As before "CS" is a checksum.

To convert the value of "XX" to the fluid temperature in centigrade convert the value of "XX" to decimal then subtract decimal 40.

 

[santon]

@TJBaker - thanks!
The ATF temperature (in centigrade) is already displayed on the small OLED together with the selected gear - please see attached picture. It would be great to add the engine coolant temperature to the left side of the screen. Correct me if I wrong, but it seems that the message reporting the engine coolant temperature command should contain "48" or "49" as a second byte. For some reason, I don't see such a message in my scans.

 

[AmpOverload]

My VFD PRNDL display is old and dim, so I am thinking about building an additional LCD display for the PRNDL.

A too-dim VFD "PRNDL" display is a common issue on some GM vehicles. I fixed it on a 2004 Buick Century by de-soldering 4 resistors inside the instrument panel and replacing them with 4 new ones. Not sure if that applies to your vehicle, but might be worth a look.

Having said that, I still think you have a cool, useful project going there!

Correct me if I wrong, but it seems that the message reporting the engine coolant temperature command should contain "48" or "49" as a second byte. For some reason, I don't see such a message in my scans.

Since TJBaker57 might still be busy, I'll jump in here with some advice.

Depending on how you're searching your scans, you may not see what you're looking for, even if it's there. More specifically, you don't want to search for a specific value for the 1st byte of the reply, "C8" in TJ's example above. That byte contains a "Priority Level" which can vary.

Basically, a reply from the PCM reporting the vehicle's current ECT (Engine Coolant Temperature) should be something like this:

#8 49 10 10 xx cs

'#' is any of these hex values: 0, 2, 4, 6, 8, A, C, E

The '8' in the lower part of the 1st byte decodes into something that you don't really need to worry about, but it means:

• Msg Type: 'Function Command/Status'
• IFR Not Allowed (GM)
• Functional Addressing

'49' is the "Status ID" for ECT under functional addressing (which is what we're talking about here)

'10' (the 1st occurrence) is the replying node's address (10 = PCM)

'10' (the 2nd occurrence) is the "Secondary ID"; when associated with the Primary ID of 'ECT' ($48/$49), it means "Fluid Temperature"

'xx' is the value for vehicle's ECT (in degC, formula is 'A - 40')

'cs' is the message checksum

Here's an example from a 2004 Buick Century:

68 49 10 10 85 4F

If you look through your scans for "49 10 10" and don't find anything that fits what I've described above, then it's probably not being sent via periodic transmission and you'll have to query it manually, with a Mode $01 or Mode $22 command.

 

[santon]

If you look through your scans for "49 10 10" and don't find anything that fits what I've described above, then it's probably not being sent via periodic transmission and you'll have to query it manually, with a Mode $01 or Mode $22 command.

I believe there is a message running on the network since the instrument cluster has the coolant temperature gauge.

Where can I find the detailed info on all of the bytes of the serial commands? I found this website but it is not so detailed (or I don't understand this info enough).

 

[santon]

OK, an update -I finally found the messages 68 49 10 10 XX CS. Thanks!