Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help me understand Manifold pressure readings #256

Open
AussieMakerGeek opened this issue Jul 5, 2024 · 32 comments
Open

Help me understand Manifold pressure readings #256

AussieMakerGeek opened this issue Jul 5, 2024 · 32 comments
Assignees
Labels
question Further information is requested

Comments

@AussieMakerGeek
Copy link

Hi, I am trying to extract a reading for boost pressure from my car. In general, its working - I can connect, read PIDs ok but for some reason the manifold pressure does not seem to match what it should.

I'm asking here because this is probably the best place to find someone that will have any idea of what I am talking about.

I am reading the below 2 PIDs

const uint8_t ABS_BAROMETRIC_PRESSURE          = 51;  // 0x33 - kPa
const uint8_t INTAKE_MANIFOLD_ABS_PRESSURE     = 11;  // 0x0B - kPa

My understanding is that both of these values are uint8_t

The theory being, I subtract MAP from Baro and get a true reading.
I am mostly at sea level, that should be about 101 kpa. The absolute pressure reads ~101kpa as it does on the 'Car Scanner ELM OBD' mobile app. The MAP sensor reads ~97kpa per the same app (iginition on, engine not running).

However, the library returns a reading of 59kpa in the same scenario.

Now this is where it gets weirder. When I use the torque app, I get a reading of 8.6 PSI, engine off.
59kpa ~= 8.6PSI

I don't understand how the data is somehow being manipulated - Is there some other calibration value that the Car scanner ELM OBD app is using that Torque and the Library doesn't? Or is it the other way round?

@AussieMakerGeek AussieMakerGeek added the question Further information is requested label Jul 5, 2024
@PowerBroker2
Copy link
Owner

Is there some other calibration value that the Car scanner ELM OBD app is using that Torque and the Library doesn't? Or is it the other way round?

I'm not sure, I just used the formula given for the PID on wikipedia: https://en.wikipedia.org/wiki/OBD-II_PIDs. Perhaps the app you're using is actually monitoring a different (maybe proprietary) PID?

@patfelst
Copy link
Contributor

patfelst commented Jul 6, 2024

There are three PIDs (that I know of) commonly used for manifold pressure in turbocharged vehicles. 0x0B, 0x70 and 0x87. See if you get a response to the last two. You'll have to write your own decoder if you do get a response. Let me know if you need help.

@AussieMakerGeek
Copy link
Author

I'm not sure what's going on. From what I can tell, the sensor is probably reading accurate with the engine running. But with the engine off it reads 59kpa in pretty much every app I can find other than the previously mentioned app.

In all apps, and the library I'm using the 'Intake manifold absolute pressure' pid so I have no idea how it's different in the one app, yet that is the one that seems accurate with the engine off.

I'm seeing values from 10kpa decelerating in a low gear (high vacuum) and up to 125kpa on full boost. These values seem reasonable. It's just the atmospheric pressure with the engine off that seems weirdly inaccurate.

@patfelst
Copy link
Contributor

patfelst commented Jul 6, 2024

ok apologies I misread your original problem. I don't know what's going on then. It sounds like one app you found that gives the "correct" atmospheric reading is doing something fancy when it sees RPM is zero (engine off) and atmospheric of 59kPa (clearly incorrect). It's probably assuming 101kPa when it reads 59kPa read from the car.

You could confirm this by plugging your setup into some other turbo vehicles (different models to your car).

Do you really need to read baro (atmospheric) pressure with the engine off? I mean you'll never generate vacuum or boost with engine off. Just put some code in that reads RPM, and if RPM is zero, set the boost pressure display to 0kPa. Then once the engine is running (RPM > 0), you can read atmospheric pressure.

@AussieMakerGeek
Copy link
Author

So I played with it some more - Unfortunately I don't have another Turbo car to try it on but with a couple of NA cars it reads fine. It's something specific to the car I am using it on. The weird thing is, the lowest reading is about right, but the atmospheric pressure reads wrong. Under high vacuum it reads about 10kpa, but when I accelerate, before it comes on boost it reads 59.

In the other OBD app, the pressure reads about 98kpa with the engine off, so it's not making the assumption like you describe.

I'm quite perplexed. Ultimately, it's not an issue with the library, i'll just have to see what i can find that might give me more of an understanding how the app is reading correct, given the fact that it has incorrect (raw) data.

@patfelst
Copy link
Contributor

patfelst commented Jul 9, 2024

Maybe your sensor is faulty. As a last resort, it would be worth trying the other two PIDs I mentioned. The phone apps would try all of these and use the PID that returns a proper response. You never know your luck.

@bear-gha
Copy link

The absolute pressure reads ~101kpa as it does on the 'Car Scanner ELM OBD' mobile app. The MAP sensor reads ~97kpa per the same app (iginition on, engine not running).

Hi, CarScanner profile - ? Sensors name (exact) - ?

@AussieMakerGeek
Copy link
Author

Hi, CarScanner profile - ? Sensors name (exact) - ?

I'm not sure what you mean by CarScanner profile? It's using generic OBDII (EOBD) according to the app. It does not have a specific profile for my car - but that's the one that is working fine.

The Sensor is 0x0B - Intake manifold absolute pressure

I did find that there is a separate MAP sensor PID 0x87 but my car does not respond to this.

@bear-gha
Copy link

@AussieMakerGeek I think this is not 0x0B in CarScanner, if you select this sensor in Sensors list. You can do this - select only this sensor in filter as active, wait 1 min, export log from settings - adapter menu. Attach here (cut log only to this session, by date and time).

@AussieMakerGeek
Copy link
Author

AussieMakerGeek commented Jul 23, 2024

Thanks for your your effort to help.

So here is a cut down version of that log. It as you can see, it is using 010B.

7E803410B3A Is the response

7E8 = FrameID
03 = Byte length
41 = 65?
0B = Requested PID
3A = 58*

*58 is the value that is being reported in other apps.

But somehow, the app is reporting 97.8, which for the purpose of the experiment, is close enough to the baro reading at 100-101 but I have no idea how the app is calculating it.

logMod.txt

@bear-gha
Copy link

@AussieMakerGeek with that cut log i can't help. Need log as i said.

@AussieMakerGeek
Copy link
Author

AussieMakerGeek commented Jul 23, 2024

The only thing i have cut from the log is the hundreds <Actually 3526> of identical entries of:
>010B1 7E803410B3A

You did see the attached file?

@bear-gha
Copy link

@AussieMakerGeek yes, in log 58, if in sensor filter only "Intake manifold absolute pressure". Value in kPa. This PID in App do not use any formula, except scaling (if not kPa choosen).

@AussieMakerGeek
Copy link
Author

I completely agree, the PID should return the pressure in Kpa but it's not in my car for some reason. I don't know how the app is doing it - It can't even be the built in pressure sensor in my phone because that reads different too. Are you the dev of the app?

I would blame the ELM but when I do direct CANbus with an MCP2515 module, it reads the same.

I am beyond confused.

@bear-gha
Copy link

bear-gha commented Jul 23, 2024

@AussieMakerGeek No, not an app developer, just a researcher. Can you go again in Sensors, then select active profile - OBDII, same value? Value also check only on Sensors page.

@AussieMakerGeek
Copy link
Author

I can't see the setting you mention. It's EOBD ISO 15765-4 if that's what you're asking?

@bear-gha
Copy link

bear-gha commented Jul 23, 2024

@AussieMakerGeek Settings -> Sensors -> On the top right, click on profile "Basic OBDII" -> On the left click on loupe (filter) and write "Intake manifold absolute pressure" -> Same value with ID 11 sensor?

And when you get 58, what value in App?

@AussieMakerGeek
Copy link
Author

Sorry, when I go to settings -> sensors, there is only settings in top right, then the option to disable unsupported sensors.

@bear-gha
Copy link

@AussieMakerGeek Not like this? And for value question is open.
Screenshot_20240723_142227

@AussieMakerGeek
Copy link
Author

Ah, I see, I had to click on 'all' then it gives me those options. Still says ID 11 for map regardless

@bear-gha
Copy link

bear-gha commented Jul 23, 2024

@AussieMakerGeek With "all" you can see values from other profiles, not only from Basic OBD, need click on Basic and compare value with log, also write value from ID 11 App Sensors screen and log.

@AussieMakerGeek
Copy link
Author

Yeah, it's all the same regardless of profile. Same 97.8kpa

@bear-gha
Copy link

bear-gha commented Jul 23, 2024

Can you change this kPa, with new value, and give value from log? Need another pair. (need full string from log, not only 1 element).

@AussieMakerGeek
Copy link
Author

I'm not sure what you mean

@bear-gha
Copy link

If you change this parameter, there will be a different value of the line in the log, you need a new pair to analyze.

@AussieMakerGeek
Copy link
Author

You mean just log a different PID?

@bear-gha
Copy link

No, I mean do something to the car to make it give a new value with same PID.

@AussieMakerGeek
Copy link
Author

lognew.txt
Unmodified log - Engine off, then engine idling for a while, couple of free-revs, back to idle and then off again.

@bear-gha
Copy link

But we also need values from App screen => pairs. 1 log + 1 screen.

@AussieMakerGeek
Copy link
Author

AussieMakerGeek commented Jul 24, 2024

Ok, so this value table should be the equvalent data exported from the app over the same time period.
2024-07-24 17-07-49.csv

@bear-gha
Copy link

For some reason in the program the value of the last byte is multiplied by 1.686274509803921. Why, you can think about it yourself or make a correction in the code to take this into account.

@AussieMakerGeek
Copy link
Author

That's an interesting finding. I did have 2 sets of data, one from a simple ELM log and the dump from the app but I had no way of correlating the data since they were captured separately. I didn't know the separate raw log was available from the app at the time.

I can't think of the significance of that number, where it might come from, or how the app knows to use that scaling factor. I'll see if that is any part of a subset of OBD data somewhere perhaps.

It's somewhat annoying that this is the case as although I can modify the code to just allow for this, it means the code is no longer generic (which it should be able to be!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants