Thread: Ford CAN BUS PIDs

Originally Posted by benrwin

My graduation hinges on my obtaining these codes.

You should proceed carefully on this project. Get an advisor and keep the scope limited if you have no experience in this area.

There are a standard set of PIDs published in SAE J1979. That standard is a copyrighted document so you won't find it on the internet. Try the university library, otherwise it'll cost about $50 at the SAE website. Ford exceeds the basic requirements and also has some of their own enhanced parameters. The membership is $7500 a year for access to the enhanced data, and there's no discount or assistance for university students.

Originally Posted by benrwin

Are Ford's CAN PIDs uniform for all models, or are there different codes for every model?

The generic OBD-II PIDs work on all cars -- but the automaker doesn't need to support everything.

Originally Posted by benrwin

The specific codes I will need are the codes for the MAF sensor and MAP sensor. Any other codes would be neat to have, as well, but the MAF and MAP are the only ones that are vital to the completion of my project.

Under generic OBD-II:

Intake Manifold Absolute Pressure - 0x0B
Air Flow Rate from Mass Air Flow Sensor - 0x10

joeyoravec,
Thank you very much for your helpful response! So one thing that confuses me is that you keep talking about OBD-II, but I thought I was on a quest to monitor the CAN bus and to talk the CAN language. Are you saying that CAN PIDs and OBD-II PIDs are the same?

Also, is it true that we can just "listen" to the CAN bus traffic for this MAF and MAP information instead of sending repeated diagnostic requests? We want to display a "real-time" tachometer-type gauge showing the MAF and MAP data, so we dont want to flood the bus with request commands.

Thanks so much for all of your help so far!! You may have saved me from an extra semester of school!!

-Ben

@ Benrwin:

OBD-II stands for Onboard Diagnostics 2 - it is a specific interface port that you can connect devices to, and the structure/specification of this model conforms to a very strict protocol, or framework.

CANbus stands for Control Area Network, and is ONE of the protocols available to electronic manufacturers to utilize to make this data avaible to other "nodes" on the network. CANbus is electrically based on RS-485 twisted-pair network, this is the physical layer, and then, on software protocol-side, you can either have 11-bit, or 29-bit CAN protocol - at least in Australia, we use the 11-bit CAN protocol, and I suspect it is the same for you guys in the US.

Think of CANbus in terms of a LAN network at your school, it is similar, and utilizes layers 1,2 and 7 of the OSI model (physical, data and application). There is the physical layer, with transceivers to do the physical connection, and then, the pre-agreed communication language, in this case 11-bit CAN, running at 500kbits (data-link layer) and then the application layer.


So, the data from the slaves (ie MAP and MAF) is broadcast on the network, and you can scan that with the device you are planning to build - you will need to establish the initial communications to the Ford CANbus, there is some handshaking and authorisation happening, once this is established, the data will be available for your analysis.

You may gain valuable insight into CANbus by browsing for info on DeviceNET too, which is an Industrial Control Network based on CANbus, the only major difference is the tolerance for the Transceivers are smaller, within narrower parameters if that is the proper expression.

Another thing, you need to cater for the specific Baudrate for the intended victim, our Fords in Australia have a 500kbits speed - your's may be the same, or slower/faster, up to 1mbit....

Hope this is helpful, and I am sure JoeyOravec will correct me where I am wrong - he is a specialist on OBD-II interface, and associated protocols.

Kind regards,
MrBean.

edit: Just another thing: Quite a few Industrial Netowrks are based on the OSI 1-2-7 layers, Profibus (DP) is another one, and interestingly enough, it also makes use of a R-485 physical layer The data-link though is Manchesterbus protocol. There are several Industrial Gateways available allowing these protocols to communicate, ie in practice, we have profibus networks communicating to CAN via Softing Gateways. Interesting topic this one.

Soz for going off-topic, just thought I'd share.

Originally Posted by benrwin

Thank you very much for your helpful response! So one thing that confuses me is that you keep talking about OBD-II, but I thought I was on a quest to monitor the CAN bus and to talk the CAN language. Are you saying that CAN PIDs and OBD-II PIDs are the same?

The above poster is right. CAN is just one of 5 networks that can be used to implement OBD-II. It happens to be the one that all automakers will be using starting this year. Think of it like a wire, like ethernet.... There's nothing particular special except that it's fast, cheap, reliable, and widely used.

Originally Posted by benrwin

Also, is it true that we can just "listen" to the CAN bus traffic for this MAF and MAP information instead of sending repeated diagnostic requests? We want to display a "real-time" tachometer-type gauge showing the MAF and MAP data, so we dont want to flood the bus with request commands.

While technically possible, there still might be a gateway in-between you and the engine's network. Some people go down that route. Honestly I think it's insane to expect to sniff anything from normal communication, because the messages will vary per car. You should expect 55+ commands/sec with request response. Ford has a way to set up streaming and increase that to ~250. Both are quite acceptable.

Ford has a way to setup streaming?

I don't supposed that one's tucked away behind an NDA is it?


Lukeyson

So much mis-information on one page, it's hard to correct it all

J1939 is the standard for CAN in commercial trucking. This has absolutely nothing to do with Ford's HS CAN network

CAN is not built on RS-485, rather ISO-11898.

The Ford HS CAN bus operates at 500 KBaud, not 250KBaud

The acronym "PID" (parameter identifier) is used to define numerically message content that can be circulated as part of OBD or not part of OBD. Ford generally uses the term "PID" to describe information queried in diagnostic mode

Originally Posted by joeyoravec

Under generic OBD-II:

Intake Manifold Absolute Pressure - 0x0B
Air Flow Rate from Mass Air Flow Sensor - 0x10

Hi All,

I wanted to read throttle position but got confused when looked at the PIDs. As we have around 8 PIDs for throttle position.

0x11 - Throttle position
0x45 - Relative throttle position
0x47 - Absolute throttle position B
0x48 - Absolute throttle position C
0x49 - Accelerator pedal position D
0x4A - Accelerator pedal position E
0x4B - Accelerator pedal position F
0x4C - Commanded throttle actuator

Which is the best to read the throttle position? I believe 0x11(might be wrong) but then whats the use of rest of them? When we check for available PIDs, is it possible to have all these available?

Thanking you in advance.
Nirav