I’m working on getting a boost gauge on my 2018 Ford Fiesta ST with a microcontroller using low level CAN bus communication, and I have some progress but mainly still stuck. I found that some users are reporting these values work with the Torque app, but I’m not sure what the “OBD auto” header would be that they use, or what CAN ID to send this data with. I’ve tried sending via CAN ID 0x700 ~ 0x7f7 with no response seen above 0x700.

Torque PID settings for Ford Fiesta Boost:

PID: 221440
Long Name: Boost (that's what I use)
Short Name: MAP
Min Value: 0.0
Max Value: 30.0
Scale Factor: x1
Unit Type: psi
Equation: (((A*256)+B*0.03625)-BARO()
OBD Header: Auto

So I’ve been sending 07 DF 03 22 14 40 00 00 00 00 00

Just as a test, I can read RPM (CAN ID 0x201) and MPH (0x20F) just fine, although they update normally on the bus too slowly to be useful.

Can anyone tell me what the low level data to send is? Maybe there is some ECU wake up code I need to send first?

I have the Torque Pro app as well, and just bought a Vgate WiFi ELM327 OBD-II Module http://a.co/cXlIZ2k.

Thanks!

you need to send a request 221440 by the address 7E0, but not to the address 7DF

Quote from cintakc on July 9, 2018
you need to send a request 221440 by the address 7E0, but not to the address 7DF

Yep, I tried that but still I just get the 03 7F … response. Do you think this means it’s not supported or does it mean I might have to send some other wake up type command?

Quote from Capp777 on July 9, 2018

There are some late model Ford 6.7 trucks
which were using 22F4xx for mode 01xx
equivalents. I am curious if 0170 returns
a valid response.

I tried the Mode 1 format of 07 DF 02 01 70 and got no response.

I also tried the extended format of 07 E0 03 22 F4 70 and got no response.

When I try something I know works in Mode 1 like RPM, it does work though. If I send RPM from Mode 1 in the extended format 07 E0 03 22 F4 0C I get response 07 E8 05 62 F4 0C 14 07 which is 1282 RPM, my high idle.

It was worth a shot, and I appreciate you sharing this trick. Thanks!

—

I’m also thinking of writing a program that will systematically iterate through all extended numbers 07 E0 03 22 00 00 through 07 E0 22 03 22 FF FF looking for valid responses 07 E8 xx 62 and then log the PIDs that were used. See any problem with that? I don’t think this should modify the system or put the ECU in a bad state. If I could make this determination in 1 second for each PID, that would take about 18 hours, so I’d have to run this while I was driving around over a week or so. Currently I can easily send a new PID request every 200 ms, and wait up to 100 ms for a response, so I could do about 3 per second, shaving it down to 6 hours… but it might be better to try each code like 3 times in a row to make sure the ECU really had a chance to listen for it.

This is actually much slower than it needs to be probably, but also likely more reliable. Maybe I can run a quicker test on the first 0-0x30 high byte PIDs (0-FF low byte) and see if the results match up with most of the known Ford extended PIDs. Then continue the search knowing it should work. http://www.paladinmicro.com/documents/200304PIDs.pdf

Thanks, please send it here: bdub at fxprix dot com

I have a Carloop open source car hacking tool that can probably do the same thing, but it will be nice to start with something known to work. If you are interested, google “carloop” and you’ll find it.

BTW, I got my Vgate Wi-Fi device and it works well enough with Torque Pro. I was having some issues getting it to re-connect to the device a second time, but it seems like it’s ok now.

I was able to get the boost gauge working, but it’s not the extended Ford PID version, just the one built into TP. I need to figure out how that’s done and how accurate it is, but good to have something. I guess if I can’t find the way it’s done in the Torque FAQ/Wiki then I could use the carloop to scan the OBD-II port while the gauge is being updated.