Mark Adams.

 

According to Ultra gage support it is expecting Grams per Second (g/s) in values between 0 and 655; I'm seeing values between .06 and .61 read from the OBDII by both the UG and my other code reader.

 

Correct, because it is showing a value of 61 in the B variable, and being divided by 100.. (61/100 = .61)

the raw reading is 61, but I'm not sure this makes sense to still be in g/s

I believe the max range I saw was 122.. still low for what our engine should be pulling

 

I sent this to UG:

Date: 10-01-2014 00:30:43 Name: Phil Warner Message:
Some additional information from a fellow on the Land Rover Discovery 1 forum. landroverforums.com/forum/discovery-i-39/how-test-mass-air-flow-sensor-69240/page2/

"Our trucks don't report the "A" element in the equation ((A*256)+B) / 100). A is always 0 on our trucks so it shows B /100. A and B are byte values returned from the ECU regarding the MAF sensor (took me a bit to figure this out) Each byte is a value between 0 and 256 so A appears to be an overflow for B's value? Basically we never get a raw value, we get the value the ECU reads and decides to give us. In theory they could be reporting cfm, or gpm, or who knows what.. would take a rover tech or engineer to determine this."

I replied:
According to Ultra gage support it is expecting Grams per Second (g/s) in values between 0 and 655; I'm seeing values between .06 and .61 read from the OBDII by both the UG and my Actron CP9580 code reader.

And he replied:
"Correct, because it is showing a value of 61 in the B variable, and being divided by 100 (61/100 = .61). The raw reading is 61, but I'm not sure this makes sense to still be in g/s. I believe the max range I saw was 122. still low for what our engine should be pulling."

This may make more sense to you than it does to me, but the apparent meaning is that the ECM is applying some scaling to the MAF values (dividing by 100?) but is not reporting the scaling(?) or not reporting in a way that UltraGage expects or understands. In any case I believe this exception should be added to the list on your web site of vehicles and functions that do not work correctly with the UltraGage.

I still plan to try calibrating the MPG, but have not yet driven far enough, given the low fuel usage values reported, for the UG to accept recalibration. I guess I need to re-fill the tank, zero the calibration, and take a long trip.


And they replied:

Date: 10-01-2014 05:35:33 Name: UltraGauge Message:
All that equation says is that the data is 16-bits wide. A*256 means move the A byte to the upper 8 bits.
So MAF= A,B = A[7:0],B[7:0]= AABB

Best regards,

UltraGauge Support
www.ultra-gauge.com
Support is available Monday, Wednesday and Friday, 9-5pm Central Time


Like out first amateur american president, I don't write code so this is a bit out of my comfort zone, but I do think they need to add our trucks to the list of vehicles that don't play well with UltraGage so others will know what it will and won't do before plunking down big bucks. I personally wanted the MPG and DTE gages as well as the code reporting as I am used to relying on these in our Chrysler mini-vans.

 

heh..I'm curious about someone with a newer rover, I Think they change MAF to MAP for newer ones so this isn't an issue?...


Regardless this is one feature that is broken, the rest do seem to work OK? This is a general OBD2 issue not a specific one to the ultragauge

 

The fuel useage is the only mal-function I've noticed so far and it affects anything having to do with fuel such as MPG, DTE, GPH, fuel tank level, ect. and the metric equivalents.

UG support says the ECM does not report MAF values in compliance with the OBDII standard and/or does not report any scaling of the values reported. I assume the discrepancy affects 96 to 98 D1s since I think 95 had OBDI and I haven't heard about later D2 models (anyone with a D2 have this problem?). UG suggests there might be a "firmware upgrade" from Land Rover, but the nearest dealer has not yet responded to my question.