PID List to Monitor your Lightning

[Firestop]

I am thoroughly enjoying driving/using my truck, but I’ve also been on a mini-quest to understand how it behaves/performs through data. Quite frankly, prior to owning this truck, I didn’t know what a PID was, nor did I care! That has changed now that I own a rolling computer with its own battery.

I still know hardly anything about this topic beyond what I’ve been able to find from scouring the internet….and, even then, there isn’t a lot out there. I have discovered there are some pretty smart/knowledgeable people who have done some great work.

https://www.f150lightningforum.com/...ing-information-data-in-torque-pro-app.11243/

https://www.macheforum.com/site/thr...nded-pids-for-torque-project.7427/post-295683

https://www.f150gen14.com/forum/threads/torque-pro-custom-pids.14061/

Attached is a Tab-delimited Text file containing all of the Lightning-specific PIDs I have been able to find to date from every source to which I have access. I have tried them in Torque Pro and they appear to work; but, there may be errors as I know very little about this topic….I know enough to make me dangerous.

I know there are many people on this forum smarter than I, and my hope in starting this thread is to compile the best comprehensive list of Lightning-specific PIDs to monitor data from this truck with your help for our community here to use as they wish.

****UPDATED****12/14/2022 @ 1912 hrs PDST

The following is a link to a publically accessible/editable Google Sheet version of the attached text file to help facilitate a collaborative effort to improve the breadth and quality of this project.

Sponsored

 

[Maxx]

For those that like me are clueless and after reading this post still don’t know what PID is, it stands for Performance Information Data and basically is used to look deep into the soul of the machine.

Edit: I would not be surprised if the programmers of the user interface, have a back door to some of this data for Ford engineers convenience or for their own with their own Ford. Like by pressing certain combination of steering wheel keys you get the advance screen. We need an inside man to find out if such a thing exist.

 

[mr.Magoo]

Great initiative !

I just started a similar project, mainly because... well, why not ?
If OK, I wouldn't mind, actually, I'd prefer, if we could include the more basic PIDs as well, i.e. not just the EV specific ones listed in your excel file, but for example things from the ABS module (brake switch, brake pedal pressure, etc.)

It would also be great if you can move the excel file from a desktop file to a google doc file so that it's always up to date and you don't have to re-post / re-attach the latest and greatest file.

I've played around with CarScanner which has a pretty good interface with better ways of creating a clean "dashboard" with the relevant information. The downside is that any logging kind of sucks, you get a CSV file (not bad, formatting isn't ideal) and that's it.
The good thing here is that it contains all ? (most of them anyway) the usable PIDs out of the box.

So I tried Torque (Pro) and it's horrible from every angle possible - except, logging.
I set up a Raspberry PI with Node-Red, Influx DB and Grafana and Torque logs via HTTP requests to the database and can be used at a later stage.

I'm contemplating writing my own OBD interface to eliminate the need for Torque, since I only use it for the logging portion, but I'm not sure how much work that would entail.

The screenshots below are from Grafana, logging a charging session at EA from ~8% to 90%
and the second one is my charging "dashboard" in CarScanner (note the darker gray "sub" information)

 

[Firestop]

Great initiative !

I just started a similar project, mainly because... well, why not ?
If OK, I wouldn't mind, actually, I'd prefer, if we could include the more basic PIDs as well, i.e. not just the EV specific ones listed in your excel file, but for example things from the ABS module (brake switch, brake pedal pressure, etc.)

It would also be great if you can move the excel file from a desktop file to a google doc file so that it's always up to date and you don't have to re-post / re-attach the latest and greatest file.

I've played around with CarScanner which has a pretty good interface with better ways of creating a clean "dashboard" with the relevant information. The downside is that any logging kind of sucks, you get a CSV file (not bad, formatting isn't ideal) and that's it.
The good thing here is that it contains all ? (most of them anyway) the usable PIDs out of the box.

So I tried Torque (Pro) and it's horrible from every angle possible - except, logging.
I set up a Raspberry PI with Node-Red, Influx DB and Grafana and Torque logs via HTTP requests to the database and can be used at a later stage.

I'm contemplating writing my own OBD interface to eliminate the need for Torque, since I only use it for the logging portion, but I'm not sure how much work that would entail.

The screenshots below are from Grafana, logging a charging session at EA from ~8% to 90%
and the second one is my charging "dashboard" in CarScanner (note the darker gray "sub" information)

Great ideas. I have seen the PIDs accessible through Car Scanner, but have been unable to ID the coding be PID addresses and their formulas.

As suggested, I have created a public editable Google Sheet version an posted the link on an edit of my original post.

Your technical skills are much ahead of mine, but I’m eager to learn….so, let’s see where/how this project progresses

 

[MickeyAO]

Most all the PIDs found on the Mach-E forum will work on the Lightning. The one item missing is the second OBC on extended-range trucks.

 

[Firestop]

Most all the PIDs found on the Mach-E forum will work on the Lightning. The one item missing is the second OBC on extended-range trucks.

Yep, that one has been elusive. I’ve seem some discussions about how the two chargers may work together, but nothing concrete….and, nothing on how to monitor the second one. My raw scan using Torque Pro didn’t yield anything promising, nor has Car Scanner (uses the Mach-E profile as a template)

 

[MickeyAO]

I can't do this due to my job...I would have to save guard the PID for our research.

However, I would charge at less than 48 A and see what OBC1 reports. If it is half of the current, then you know that it splits the current evenly between the two. Now look for another PID that matches the OBC1 signal.

If it is the full current, then charge above 48 A. Then look for the PID that matches it.

 

[Firestop]

I can't do this due to my job...I would have to save guard the PID for our research.

However, I would charge at less than 48 A and see what OBC1 reports. If it is half of the current, then you know that it splits the current evenly between the two. Now look for another PID that matches the OBC1 signal.

If it is the full current, then charge above 48 A. Then look for the PID that matches it.

I understand and appreciate your thoughts on the design for the test….something to try this weekend.

One of my many challenges is I’m unable to export any PID info from Torque Pro…some undetermined Android configuration error not recognizing any Filipe management program………

 

[mr.Magoo]

Probably the easiest way to extract PIDs is to use ForScan (free version will do) and a serial port sniffer, for example https://freeserialanalyzer.com/ (not as sketchy as you'd might think by the name/link, it's OK)
Pick one PID at a time and log/sniff each one separately and you'll get the PID and response in the logger. At that point you just have to figure out which format the response is in.

 

[ZSC100]

Probably the easiest way to extract PIDs is to use ForScan (free version will do) and a serial port sniffer, for example https://freeserialanalyzer.com/ (not as sketchy as you'd might think by the name/link, it's OK)
Pick one PID at a time and log/sniff each one separately and you'll get the PID and response in the logger. At that point you just have to figure out which format the response is in.

Mr. Magoo, thank you for actually posting this idea. I've suspected this to be true and a method to easily find out every PID one might be interested in. It makes total sense, and in this case the OBD2 Gateway is actually your friend b/c it's doing the filtering and forwarding for you from the various busy busses. Also, it doing the CAN-FD conversion when necessary b/c most people don't have CAN-FD interfaces. My only worry was that perhaps some kind of translation/conversion would be done to the PID # as it passes back through the Gateway. Regardless it should be easy to see the request and the returned value and easily decipher what's going on.

Is there some reason why someone hasn't data logged the full "initial scan" that FORScan, OBDLink, or any other tool does at the beginning to discover modules and PIDs, then parsed that data into a comprehensive list. I noticed this weekend using the OBDLink MX+ and the OBDLink app on my phone that it discovered around 3000 PIDs during the initial scan, it literally had a progress bar that counted "PIDs Found" on the screen. I am still baffled why the software makers, FROScan, OBDLink, and many more think that such a PID list with relational info like mode, PID #, scale, etc. would be a secret to guard. Livinitup's FORScan Module Configuration Sheets are WAY more transgressional than a comprehensive PID list, right?

 

[mr.Magoo]

Mr. Magoo, thank you for actually posting this idea. I've suspected this to be true and a method to easily find out every PID one might be interested in.
...
Is there some reason why someone hasn't data logged the full "initial scan"

It all depends on what you're trying to accomplish.
The downside of doing them one by one is that, obviously, it'll take a LOOOONG time to get 'em all if that's your end goal.

The OBD "protocol" is pretty well defined and straight forward, there's many publications out there showing how it works and what commands to use (if you're creating your own app).
What you need to know is which module it's from and what the PID# is, that's it.
You then issue the ATSH command "ATSH0007E4" to swap / activate the module, followed by the PID request command "224845" and in response you'll get the "handshake" information plus the data.

FORScan does this for you and if you log each module as you switch them you'll see/get the module number / address as well, plus at this point you'll see what FORScan thinks the value is which will make your conversion easier as the formula to convert the HEX response to an actual number isn't published by the module / initial scan itself, so you'll still have to go through them one by one and trying to figure out what's going on.

Many PIDs exist across multiple modules, and a lot of PIDs have status bits in them utilizing the same PID# for multiple "sensors", so your list of 3000 PIDs will boil down to about 800 unique addresses.

The list published in this thread is pretty "complete" from a "what you might need" point of view.
I'm only using a few additional ones in my "flight recorder" and I planned on adding them to the list once I get a bit more structured. Although I have an ER truck I have not been able to locate anything specific to the 2nd OBCC, the system still only reports one module (at least for me).

The most disappointing discovery is that the on board GPS status have very low resolution so you can't use it for position tracking. This could be for two reasons I suppose.... A) they don't want people to be able to use OBD for GPS tracking (privacy / security) or B) it requires a bit of data to get all of it through.
Additionally, I have not been able to locate one that represents the GOM reading of estimated range. There's two "distance to empty" PIDs (calculated vs. displayed) but both always returns zero / null.

 

[ZSC100]

Are you saying this spreadsheet is pretty complete: " link to a...."

You are just meaning "complete" in relation to the BEV aspect, correct? I'm curious as to why Ford chose to make/name the Secondary On Board Diagnostic Control Module(SOBDM) the (Battery Charging Control Module (BCCM). Seems ridiculous to call a module with as specific a function as a battery charger SOBDM, should've been simply BCMA, BCMB, etc. And I don't see this module in Livinitup's config spreadsheet, why? Is there anyone we can ask for this data?

I'm beginning to understand OBD2 stuff a bit better, I've dealt quite a bit with CANOpen which is CAN in the industrial world, but not automotive CAN stuff, they are very similar and I've even found they are identical as far as the lower layers of the OSI model, addressing and 8 bytes in a PGN. or PDO as we call them in CANOpen. The part I'm just now understanding is that PID refers to a single parameter that may or may not utilize multiple bytes in a PGN. So for instance in the spreadsheet listed above:

0x224808	HvbTR	HVB Temperature Range	(C-50)*1.8+32
0x224808	HvbAve	HVB Temperature Range Average	(D-50)*1.8+32
0x224808	HvbMaxT	HVB Temperature Range Maximum	(A-50)*1.8+32
0x224808	HvbMinT	HVB Temperature Range Minimum	(B-50)*1.8+32

All of these PIDs are values contained in the single PGN 4808 just different data bytes, A, B, C and D as referenced in the equation column. So, my question is now: Does the vehicle report the available PIDs, names(text), and equations to the OBD2 scanner initially when a "scan" is done or is the scanner simply asking what PGNs are available and getting a yes/no answer, then referencing a dataset to relate the PID info to the PGNs available. Sorry this question is getting very technical, but I want to understand it well enough to add my own modules to the vehicle.

Last question, are the PGNs that are available/known by an OBD2 scanner all that are used in the vehicle, or are there PGNs that are totally off limits to be requested by the OBD Gateway and can only be seen by tapping a particular bus directly?

Sponsored