Ok gang... I'm going to share a few tidbit of information for advance OBDII tinkering.

 

If you happen to have a OBDLink or ELM327 tool you should be able to tag along here. I will have to give a bit of thanks to @Me78569 for getting me started with the Bluetooth terminal on Android. Once I had that I could directly communicate with the OBDLink and pass commands to it. So starting out I passed the command...

 

ATSP0

This basically tells the tool to communication with the detected protocol of the vehicle ours happens to be ISO 9141-2 protocol. After that I passed the command...

0100

Which happens to be PID Mode 01 with the PID 00 which tells the vehicle to report back which ODBII PID are available. It returns back.

41 00 98 3A 80 14
41 00 90 18 80 14

 

At this point the hexadecimal bytes you want are 98, 3A, 90, 18...

 

So now you need to take these 4 bytes on convert them to binary.

 

98 = 1001 1000

3A = 0011 1010

90 = 1001 0000

18 = 0001 1000

 

So now lay it all out in one long string. This is counting 20 hex (32 dec) from left to right.

 

1001 1000 0011 1010 1001 0000 0001 1000

 

So you have counting only the high bit (1's)...

 

01 - MIL Status Light

04 - Engine Load

05 - Coolant Temperature

(11) 0B - Manifold Pressure

(12) 0C - RPM

(13) 0D - MPH

(15) 0F - Intake Temperature

(17) 11 - APPS Sensor

(20) 14 (Unknown yet)

(28) 1C - OBD Compliance should report 05 hex.

(29) 1D - (Unknown yet)

 

NOTE: (number) is decimal... Just for the human side for counting placement. ECM/PCM use the hexadecimal values only.

 

Now if you want to add any of these as a custom gauge.

 

Module/Header: 486

OBD Mode: 01

PID Number: (Any of the above will work use only the Hex number not the decimal)

Priority: Leave on High

Equation: Look it up on Wikipedia at https://en.wikipedia.org/wiki/OBD-II_PIDs

 

 

 

 

Edited May 27, 20168 yr by Mopar1973Man

I got bold and started digging deeper into it. Found out you can call out 0140 and 0180 for more PID and see what's available. As you'll see I called 0140 and got no data. Just check back and see if everything was working yet I called 0100 and got a reply again. So then called out 0180 and got another 2 byte reply which is 90 and 18 hex.

 

So back to conversion to binary...

 

90 hex = 1001 0000

18 hex = 0001 1000

 

So lay it out again long string...

 

1001 0000 0001 1000

 

So PID 81, 84, 8C and 8D are present. Unknown what data they hold.

 

 

I also check the 01A0 and 01C0 ranges and there is no data response for both. I'm sure curious of the data in the 80 range...

 

Ok. So after probing the mystery PIDs...

 

14 - No Data either key on or running

1D - No Data either key on or running

81 - Return 0 no change if key on or running

84 - No Data either key on or running

8C - Returned 0 with key on but then returned 12. So I checked its returning 2 bytes of data. Varies with RPM of the engine. Using (256*A)+B I get a number ranging from about 3,500 to 11,000... 

8D - Return 0 no change key on or running.

 

I'm really curious of what the 8C PID is now.

Edited May 28, 20168 yr by Mopar1973Man

So what's the benefit of tweaking these settings?

Hunting for hidden data that the VP44, ECM, PCM, ABS, SRS, etc might be talking over the bus and being able to read this hidden data. Later on like after 04.5 it seem most OBDII PID data is consistent. Our trucks have a bunch of hidden data and everyone is tight lipped about it. Just for example there is a PID for reading oil pressure. As far as I know I've never seen any OBDII tool being able to read it. Now DRBIII tool can display it which plugs into the OBDII port under the dash. Just like DRBIII tool can see the ABS speed sensors. I've seen another tool that plugs in that can see ABS sensors as well but I didn't get the name of it. This was on my visit to Module Masters to read ABS codes. So I'm on the hunt of the hidden data in the Dodge Ram Trucks. So first thing is to understand how the common data is read and then start probing around looking for data that is readable. Like PID 8C I'm still rather puzzled about a two byte worth of data way out there.

 

Like a simple project creating a boost gauge that is accurate like Edge Juice or Quadzilla has not the funky MAP sensor data I've currently got that worthless.

Edited May 28, 20168 yr by Mopar1973Man

I take it you mean the data for boost on the Scan Gauge. Mine is way out there.

2 minutes ago, dripley said:

I take it you mean the data for boost on the Scan Gauge. Mine is way out there.

 

That was one I want to start with is be able to get corrected data and provide a true boost reading. I know it can be done already just need to figure it out...

Mine idles around 28 or so psi.

 

per the scan gauge that is.

Edited May 28, 20168 yr by dripley

So does mine... Even the OBDLink shows the same. With a little help from Nick I'll get it figured out and be able to display it.

My obdlink got shipped so I should be able to catch you on my end and start digging into the codes.    excited to dive into it.

Alright my obdlink is in the truck and connected.  After work I will spend some time playing catchup.

18 hours ago, Me78569 said:

My obdlink got shipped so I should be able to catch you on my end and start digging into the codes.    excited to dive into it.

 

8 minutes ago, Me78569 said:

Alright my obdlink is in the truck and connected.  After work I will spend some time playing catchup.

 

Fastest shipping times ever!!

Alright I have boost reading accurately for our trucks

 

 

Issue we have with our trucks is

 

early trucks read map values as 0-1023 or 0-5v 

late trucks read 0-255 and the ecm decodes that

 

our sensors read in KPA at least for early truck late trucks may read in PSI.

a KPA

 

Our sensors also do not take atmospheric pressure.  Our ECM takes the KPA from the map sensor then takes baro pressure and minuses it. 

 

 

So to configure on a early truck

 

Name: Boost

Description: Boost

Manuf: Generic

metric units: Units

english units: psi

min: 0

Max: 1023

Metric to english scale: .2

Metric to English offset: 0

header: 486

obd mode: 01

pid: 0B

Priority: high

equation: (A*.145)-16   ****16 is the approx of atmosphere so since I am high in altitude you take 14psi for sea level then add a few PSI for being high.  

 

So to configure on a late truck  ( untested but I think that should work)

 

Name: Boost

Description: Boost

Manuf: Generic

metric units: Units

english units: psi

min: 0

Max: 255

Metric to english scale: .2

Metric to English offset: 0

header: 486

obd mode: 01

pid: 0B

Priority: high

equation: (A*.145)-16   ****16 is the approx of atmosphere so since I am high in altitude you take 14psi for sea level then add a few PSI for being high.  

So close....

 

20 minutes ago, Me78569 said:

equation: (A*.145)-16

 

Changed it to (A*.145)-28 which nearly zeros the gauge out. You math starts out at 26.62 PSI just idling. So after driving with it the values aren't quite right actually boost pressure 5 PSI shows about 8-9 on the OBDLink then it max'ed out at 18 PSI exactly which would be the boost fooler of the Edge Comp.

What happens if you move the min value up on the pid configure and set the -28 back to -16?  the min value from the sensor may be above 0.

 

I would try try min set to 25 to start and then revert -28 back to something that is close to 14psi + 2(your altitude in PSI difference from sea level )

 

http://www.engineeringtoolbox.com/air-altitude-pressure-d_462.html

 

the PID min and max values should match the .5v-4.5v to x-xxx range of the 0v-5v vs 0-255 in a perfect world

Edited May 31, 20168 yr by Me78569

Here is the raw data...

 

Yet more info

 

https://docs.google.com/spreadsheets/d/1-7Ahhgu7fPNAfORWXrjADwHnI8PiozMbrc1AF3RrglQ/edit?pref=2&pli=1#gid=530668887

 

 

I am wondering if the CCD bus is used by the smarty hyper tech DBRIII to do everything.  

 

 

 

HOWEVER back to the scipod code Ed got, Baud 62500 is used to get engine data on the CCD bus... Line 361 in the code.  Attached is the scipod code

dcxfile.c

dcxfile.h

Makefile

Scipod commands.odt

scipod.c

serial.c

serial.h

 

in fact thinking about it I am sure the CCD is used to do all of this.  I remember talking with Ed about this, specificlly the p0602 code that the smarty generated.

 

 

Here's a good thread with lots of info on the CCD

http://thespeedfreaks.net/showthread.php?12585-CCDuino-A-ZJ-Databus-Project/page1&s=8c17270b2ce972a7b99a42d87573cebf

Edited June 1, 20168 yr by Me78569

OK... So now flipping back to ELM327 chips you can set the baud rate for anything you want.

 

Look at AT BRD...

 

 

 

 

 

 

Edited June 1, 20168 yr by Mopar1973Man

round and round we go haha

 

https://www.scantool.net/forum/index.php?topic=9298.msg32595#msg32595

So we are on the right track now. We now just got to poke at the data or sniff the bus and see what falls out next right?

I don't think it will work like that.

 

From the notes of the scipod guy it looks like in order to open up baud 62500 you have to start baud 7812.5 then pass the programmaning command 0x28 then change baud to 62500 to start readng the ccd stuff.  

 

Diagnostics are on the 7812.5 baud.  Ugh I almost dont care enough.

Project log.docx

Hang on a second the basic data like all your gauges... Fuel level, oil pressure, volts, coolant are all on the CCD bus. Like coolant is already part of the diagnostics PID's  already. so that means we should still be able to get basic data yet without all the special stuff.

 

Now if your diving deeper like say timing or commanded fuel now I can see needing the programming mode and jumping over. Again there is a lot of data just on the CCD network we need to fish out first before jumping in deep for the super stuff.