benrwin

I am a Senior at Penn State and I have been assigned a senior project that requires me to build a tool that can read from the CAN bus of a Ford. Unfortunately, I am unable to find Ford's CAN PIDs anywhere! I have tried contacting them, but they weren't helpful. My graduation hinges on my obtaining these codes. 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.

Any help would be GREATLY appreciated!!!

Thanks,
Ben

P.S. Are Ford's CAN PIDs uniform for all models, or are there different codes for every model? I plan on testing my final product on a Rent-A-Car, so if the PIDs are model-specific please I will need to know what model and year they are for.

joeyoravec

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.


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


Under generic OBD-II:

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

benrwin

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

mrbean_phillip

@ 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.

__________________
F6 Tornado Project Log - nearing completion

joeyoravec

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.


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.

Lukeyson

Ford has a way to setup streaming?

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


Lukeyson