OBD Fusion + Bluetooth Scanner = Pretty Neat!

[TJBaker57]

Is there a way I can get misfire info through this system? Ideally, maybe a total count, and then 8 individual smaller counts?

I have OBD Fusion in my corral of apps. My TrailBlazer is older and uses a different OBD2 protocol though. I do have access to a 2018 Chevrolet Express Cargo van that I may be able to check this out on. If I am seeing it correctly OBDFusion has a listing of built-in PIDs you can add to your vehicle profile among these are misfire counts both current and history.

I will let you know what I find.

 

[TJBaker57]

I was successful in displaying current and history Misfire counts for our 2018 Chevrolet Express in OBDFusion.



Everything required was right in the app, I did not need to search the web for PID definitions, etc.

There are GM specific PID definitions in the app. One only needs to import the desired built-in items into the vehicle profile in question then place them in a dashboard.

One quick edit: I did need to remove a trailing "01" from each of the PIDs as suggested within the PID editor. Otherwise the PID failed to retrieve data as seen while using the TEST button..







If one desires more than just the counts displayed in a dashboard the app provides access to mode 06 data in the diagnostics feature.

 

[l008com]

So there is a misfire count in the list of displays. You have to add all 8 one by one which I haven't had the time to do. I don't know if this is going to be what I think it's going to be but we'll see.

Edit: derp the forum just did some sort of glitch and didn't show me all the replies.

 

[l008com]

I have OBD Fusion in my corral of apps. My TrailBlazer is older and uses a different OBD2 protocol though. I do have access to a 2018 Chevrolet Express Cargo van that I may be able to check this out on. If I am seeing it correctly OBDFusion has a listing of built-in PIDs you can add to your vehicle profile among these are misfire counts both current and history.

I will let you know what I find.

Yup I did eventually find those in the app. Although I haven't gotten around to testing them out yet to see if I'm actually getting any data.

Is it clear from you from the description, what exactly the difference is between 'current' and 'history'?
In my app, they are listed as "counts for last/current driving cycles" and "counts 10 trip EWMA"?

Lastly, it looks like you're using a tablet? I'm on an iphone and these boxes are big, I'm not sure I can fit 8 of them on my screen at once. Surely not 16! I'll have to do two pages. The GUI of this app is really annoying. But once you get things working, it is very useful for sure!

 

[TJBaker57]

Lastly, it looks like you're using a tablet? I'm on an iphone and these boxes are big, I'm not sure I can fit 8 of them on my screen at once

No tablet here. In the Android version after placing a display in a dashboard long press the display and an "Edit Display" popup menu appears. I select "Size and Location" and go from there. I set a size and save that and then drag the display to where I want it.

what exactly the difference is between 'current' and 'history'?

I don't have the specifics but my understanding is that the system monitors misfire for certain time periods called a "cycle of misfire data". I do not know how long this 'cycle' is but I do know there are many of these even in a single drive cycle. See here in a Tech 2 display there have been 82 of them at the time of this picture...



When monitoring misfires with Torque, OBDFusion or equivalent I am fairly sure I have seen small values decrease back to zero on occasion. This at the mimimum suggests to me that when monitoring misfire counts with the PIDs we cannot expect to see a cumulative value at for a drive cycle displayed after said drive cycle.

I think the mode $06 data may have more cumulative data on misfires. I would say that the PIDs current and history counts are short term and the Mode $06 data is long term?

 

[l008com]

It took a long time but I was able to do what you said, shrunk down the displays so they all fit, and then make two screenfulls, one for of each kind of the sensors. What I guess we'll call "real-time-ish" and "history-ish".

These values are all stored in the cars computer, correct? As opposed to having the app on my phone monitor and count hte totals? So I'd be able to look up the totals even if I wasn't connected and running the app when I started driving?

Also, how many misfires would be 'normal' and how many would be a problem?
I haven't driven yet since setting all this up. I do have to go for a short drive later, we'll see what I get then.

 

[l008com]

 

[TJBaker57]

These values are all stored in the cars computer, correct? As opposed to having the app on my phone monitor and count hte totals? So I'd be able to look up the totals even if I wasn't connected and running the app when I started driving?

No. These values are transitory. They will exist for a time period then reset to zero, even as you are driving.

That is what I was trying to explain in my last post.

The long term counts might be seen in mode $06 data. I cannot say with this certainty as I don't have access to an 08 GMT360. Our 2018 V6 4.3 has long term misfire data in mode $06 data.

In OBDFusion mode $06 data is in the heading "Report" after selecting "Diagnostics" at the main screen.

Have a look around in Diagnostics for useful data.

 

[l008com]

I went for a drive earlier and of course, no registered misfires. How does the computer know if it misfires anyway? Also how do *i* know that this is actually showing me data at all, and not some unsupported PIDs that are just generic defaults?

After a few weeks if high humidity, it was SUPER dry today and the rest of this week. So maybe this just isn't misfire weather.

Also the engine code was for a misfire on cyl. 5 and that was one of the ones i removed and put back. So maybe just reseating the plug wire helped. I'll see what happens, particularly next rainy day or next very humid day.

 

[Mooseman]

How does the computer know if it misfires anyway?

It uses the crank sensor to sense the slowdown of the crank at each misfire.

 

[TJBaker57]

how do *i* know that this is actually showing me data at all, and not some unsupported PIDs that are just generic defaults?

One benefit of using a smartphone based app like Torque Pro or OBDFusion is for the most part you have more control over operations than you would with a partshouse type scanner. With those you have no idea what is being done in the background. Yes they pull up data but from where and how?

In a phone app like OBDFusion if interested you can go to settings, user defined PIDs, then scroll down to one of the misfire PID entries. Tap on the entry and select "edit". Here you can view the specifics of the PID.

Under the heading "OBD INFORMATION" you will see a 'module/header', an 'OBD Mode' and a PID number as well as an 'equation'.

The Module/Header is header of the message frame to be sent. This determines which in vehicle microcontroller the message is sent to. In your case it may just read "ECM". Just to make it easier for the user, in the background the OBDFusion app will substitute the actual hexadecimal information corresponding to your ECM for your particular network protocol. This is likely to be "7E0" for a CANBUS network. For an SAE J1850 VPW protocol like the class 2 serial data network the ECM/PCM address is usually "10" for a GM product.

The OBD Mode means what service are you requesting from that microcontroller. Our ECM/PCM/whatevers offer a variey of services (previously termed modes). Service/Mode 22 is defined as 'request diagnostic data by parameter ID'. A message requesting this service is going to call that specific service from the module, in this case your ECM.

Service/mode 22 accepts a 2 byte parameter ID as the first argument. That is the PID number. In the case of current misfire counts for cyclinder 5 the parameter ID is 11EA (hexadecimal). The service/mode will return the byte(s) currently stored for that parameter. It will not substitute defaults or anything of that sort. Service 22 is not coded to do anything like that.

OBDFusion takes the returned value and uses that in the "equation" to derive the value it then reports to the display. The data bytes returned by service/mode 22 are converted from hexadecimal to decimal and then 'tokenized' by OBDFusion, first data byte value is represented by "A", second data byte value is "B" and so on.

In the case of misfires the value is a simple 'count' which does not require an elaborate equation. The current count is a single byte value, the history count is a 2 byte value.