Deconstructing the Lightning: Using AI to Map PIDs for Torque

[mr.Magoo]

So intentionally eliminating the warming phase might lower battery health & longevity over the long term.

Perhaps you misunderstood my sentiment ?
I'm not saying it should eliminate warming up the battery to "safe" temperatures before charging.


What I am saying is that typically what happens is that you come home, plug in, battery is warmed up, it charges to 3-4am or maybe even earlier if you have a 100A charger or is an ABC kind of guy.

When it's finished, the battery is in the mid 40s, but is now left to cool down. How much is obviously down to a lot of factors, but it cools down.

Then 1hr (or so) before your set departure time, it fires things back up to heat your battery to 65F.


IF the charge cycle was delayed so that it hit's your desired SoC 30min before your set departure time:
A) preconditioning would be kind of pointless since the additional range gained from 45F to 65F is small

B) if you for some reason want your battery to be really warm and fuzzy, warming it from 45 to 65 takes less energy (and time) than going from 25F to 65F

Sponsored

 

[P-38]

Perhaps you misunderstood my sentiment ?
I'm not saying it should eliminate warming up the battery to "safe" temperatures before charging.


What I am saying is that typically what happens is that you come home, plug in, battery is warmed up, it charges to 3-4am or maybe even earlier if you have a 100A charger or is an ABC kind of guy.

When it's finished, the battery is in the mid 40s, but is now left to cool down. How much is obviously down to a lot of factors, but it cools down.

Then 1hr (or so) before your set departure time, it fires things back up to heat your battery to 65F.


IF the charge cycle was delayed so that it hit's your desired SoC 30min before your set departure time:
A) preconditioning would be kind of pointless since the additional range gained from 45F to 65F is small

B) if you for some reason want your battery to be really warm and fuzzy, warming it from 45 to 65 takes less energy (and time) than going from 25F to 65F

This is how I read your first post.

I agree the truck is done charging by 3am most days and then it cools (more so this past week) so the battery temp is just above the low mark on the gauge....then while I drive it heats up to the mid point... On days where it is charging til 6am for a 610 departure it's all happy and at the mid point.

 

[galstaf]

The one thing I wish they had is a departure time that didn't pre-condition, but managed the charging window to match your departure. The truck knows the capability of your charger/evse, so let's say you need to charge 80kWh and your EVSE is capable of 9kW, then just start the charge 9-10 hours prior to departure, no energy wasted heating things up and letting it cool, only to heat it back up again.

My issue is the truck is *not* plugged in before I leave in the morning, and I drive *to* the charger. The truck is stone cold when I leave the house (condo). I need the battery at least somewhat warm before I get to work to maximize time of the charge I can put into the truck during my working day.

I just got a higher amperage EVSE (Tesla 80A) yesterday, but the truck didn't like it and would not activate charging, but that may be because I already had 96% in it.
I opened it up and changed the max current to 64A and it started working. Will try again when I run down the charge some more... see if I can get the full 80A out of this thing.



(i am trying to keep the truck topped up to 100% in case we lose power and I need the pro-power)

 

[Zprime29]

My issue is the truck is *not* plugged in before I leave in the morning, and I drive *to* the charger. The truck is stone cold when I leave the house (condo). I need the battery at least somewhat warm before I get to work to maximize time of the charge I can put into the truck during my working day.

I just got a higher amperage EVSE (Tesla 80A) yesterday, but the truck didn't like it and would not activate charging, but that may be because I already had 96% in it.
I opened it up and changed the max current to 64A and it started working. Will try again when I run down the charge some more... see if I can get the full 80A out of this thing.



(i am trying to keep the truck topped up to 100% in case we lose power and I need the pro-power)

You might consider the energy being spent to warm it up. I don't know how much it takes as it doesn't get that cold here, but I'm not sure if you actually get more energy by pre-warming it as you then have to replace that spent energy.

 

[galstaf]

This, but additionally I'd like to see more intelligent charging like on modern phones. Study usage patterns and have optimal juice for the drive, instead of plugging in and immediately charging, delay it so A) no wasted battery heating and B) the battery doesn't sit at a high SOC longer than necessary.

Give the state of Ford's software stack for their vehicles, I feel like this could be decades away.

The CEO literally admitted that they just took the lowest bid from each vendor for each module used in each vehicle and as such contractually have zero control over the code that each vendor uses for their modules and how and when it updates.

Seriously.

Ford have no power to force the vendor to allow them to update the code; so you have a bunch of different modules from different vendors with different software... and Ford has no contractual power to force the vendor to allow them to update the module or share the code base or anything.

That's why their vehicles and OTA situation is such a clustrfkk, and their customers are massively frustrated... all to save a couple of bucks per module on the front end, only to end up with a much bigger price tag from customer dissatisfaction and warranty issues.

Maybe Farley should hit up Elon for his microdose Ketamine hookup ... and it help him make better business decisions.

 

[galstaf]

You might consider the energy being spent to warm it up. I don't know how much it takes as it doesn't get that cold here, but I'm not sure if you actually get more energy by pre-warming it as you then have to replace that spent energy.

I did... about 10kWh for a ER pack is what I am reading which is about 8% ish of a charge. It is relatively quick charging once it's warmed up, so it would replace the energy used to heat much quicker than it takes to warm the truck with an AC EVSE to the point where it actually starts charging..
I realize this may use a little more power overall, but my issue is amount of time to charge is limited on some days, so I need to get as much power in there as possible as quick as possible. (at 12c / kWh ;-) )

 

[galstaf]

This is how I read your first post.

I agree the truck is done charging by 3am most days and then it cools (more so this past week) so the battery temp is just above the low mark on the gauge....then while I drive it heats up to the mid point... On days where it is charging til 6am for a 610 departure it's all happy and at the mid point.

Given the software involved, you may be better off with a mechanical 240V high amperage timer that you can have not kick on until later at night. Just play with the charging window until you get what you need.. a nice full warm battery in time for your departure.

The impossible dream!! lol

 

[Danface]

Watching & impressed with what several of your tech geeks can do, carry on!!!!

 

[Danface]

I’ve been working on getting better data visibility for my F-150 Lightning. While FORScan and Car Scanner are the gold standards for seeing what’s going on, they are not always the most convenient tool for long-term logging or custom dashboards. I wanted to move that high-level data into Torque, but that requires knowing the exact hex PIDs and the specific math formulas Ford uses—and the current PID list is inadequate.

To solve this, I used Google Gemini Pro as a data science partner. By feeding the AI raw Bluetooth packet logs and comparing them to live app data, I was able to bridge the gap. We aren't "finding" PIDs that didn't exist—FORScan already sees them—but we are deconstructing them so they can be used in other applications.

The Breakthrough: AI-Enabled Correlation
Typically, matching raw hex values to real-world sensor data requires significant experience in signal processing or software engineering. You have to account for clock drift, filter out thousands of background messages, and solve for linear equations (Scale/Offset) manually.

By using Gemini , I was able to upload the raw .pcapng packet logs and the CSV logs from the diagnostic apps directly. The AI performed the time-syncing and regression analysis automatically. You still have to validate the results, in one instance it switched brake pedal travel and LF brake pressure, but to be honest it also identified that the brake pedal travel PID had unusually high precision. This mistake is not surprising, brake pedal travel and pressure exactly matched (truck was parked) so the plots looked near the same.

Note: While I used a paid Gemini account for the massive context window needed for long logs, you can do this with the free version by feeding it smaller snippets of data.

How to Do It Yourself (Instructional Guide)
If you want to help expand our community PID list, here is the pathway to capture the data.

1. The Sniffer Setup (Windows)
Standard Wireshark on Windows can’t see Bluetooth traffic without help. You need the Microsoft Bluetooth Virtual Sniffer (BTVS).

• Download: Get the "Bluetooth Test Platform" from Microsoft.
• The Shortcut: Navigate to the folder containing btvs.exe. Click into the Address Bar of your File Explorer, type cmd, and hit Enter.
• Launch: In the command window, type btvs.exe -Mode Wireshark. This will open Wireshark and start piping your Bluetooth traffic into it.

2. The Capture Session

• Laptop Method: Run FORScan and select 5–10 PIDs you want to map. Start your Wireshark capture and perform a specific action (e.g., sweep the steering wheel or plug in a charger).
• Android Method: Enable "Bluetooth HCI Snoop Log" in Developer Options. Run CarScanner or similar, do your test, and then pull the log via a Bug Report.

3. The Analysis
Once you have your logs, you can use an AI like Gemini to do the math. Tell it: "I have a Bluetooth log (hex) and a sensor log (decimal). Match the timestamps and find the hex PID and the formula for [Sensor Name]."

What We’ve Mapped So Far
Through this process, I’ve already moved several high-fidelity sensors over to Torque:

Sensor	PID	Equation	Header
High-Res SOC	224801	(A*256+B)/500	7E4
Brake Pressure (LF)	222B28	(A*256+B)/6.89	760
Charging Power (W)	22484E	(A*256+B)*5	7E4
Energy to Empty (kWh)	224848	(A*256+B)/500	7E4

Call to Action: Let's Build the List
This is just the start. There are hundreds of PIDs available in the different modules. Tons for the IPC, IPMA, APIM, etc. If you have a favorite sensor or trigger in FORScan that you wish you had in Torque, use the pathway above to capture a log (or give me a shout).

Post your logs or your findings here, and let’s see how large of a "community dictionary" we can build for the Lightning.



Torque values extracted (copy to torque csv).
Name,ShortName,ModeAndPID,Equation,Min Value,Max Value,Units,Header
Battery SOC (High Res),SOC HR,224801,(A*256+B)/500,0,100,%,7E4
HV Battery Current,Amps,22480A,(SIGNED(A*256+B))/100,-500,500,A,7E4
Charging Power,Chg Watts,22484E,(A*256+B)*5,0,20000,W,7E4
Battery Energy to Empty,kWh Rem,224848,(A*256+B)/500,0,150,kWh,7E4
Accelerator Pedal Position,Throttle,22F449,A/2.55,0,100,%,7E4
Steering Wheel Angle,Steer Ang,223302,((A*256+B)-7810)/10,-900,900,°,760
Brake Pressure LF,Brk Press,222B28,(A*256+B)/6.89,0,2000,psi,760
Brake Pedal Position,Brk Pedal,222823,(A*256+B)/2500,0,2,in,760
Lateral Acceleration,Lat G,222B0C,SIGNED(A*256+B)/100,-2,2,G,760
Battery Coolant Inlet Temp,Clnt In T,224846,(A-50)*1.8+32,-40,150,°F,7E4

Bet you could bu

I’ve been working on getting better data visibility for my F-150 Lightning. While FORScan and Car Scanner are the gold standards for seeing what’s going on, they are not always the most convenient tool for long-term logging or custom dashboards. I wanted to move that high-level data into Torque, but that requires knowing the exact hex PIDs and the specific math formulas Ford uses—and the current PID list is inadequate.

To solve this, I used Google Gemini Pro as a data science partner. By feeding the AI raw Bluetooth packet logs and comparing them to live app data, I was able to bridge the gap. We aren't "finding" PIDs that didn't exist—FORScan already sees them—but we are deconstructing them so they can be used in other applications.

The Breakthrough: AI-Enabled Correlation
Typically, matching raw hex values to real-world sensor data requires significant experience in signal processing or software engineering. You have to account for clock drift, filter out thousands of background messages, and solve for linear equations (Scale/Offset) manually.

By using Gemini , I was able to upload the raw .pcapng packet logs and the CSV logs from the diagnostic apps directly. The AI performed the time-syncing and regression analysis automatically. You still have to validate the results, in one instance it switched brake pedal travel and LF brake pressure, but to be honest it also identified that the brake pedal travel PID had unusually high precision. This mistake is not surprising, brake pedal travel and pressure exactly matched (truck was parked) so the plots looked near the same.

Note: While I used a paid Gemini account for the massive context window needed for long logs, you can do this with the free version by feeding it smaller snippets of data.

How to Do It Yourself (Instructional Guide)
If you want to help expand our community PID list, here is the pathway to capture the data.

1. The Sniffer Setup (Windows)
Standard Wireshark on Windows can’t see Bluetooth traffic without help. You need the Microsoft Bluetooth Virtual Sniffer (BTVS).

• Download: Get the "Bluetooth Test Platform" from Microsoft.
• The Shortcut: Navigate to the folder containing btvs.exe. Click into the Address Bar of your File Explorer, type cmd, and hit Enter.
• Launch: In the command window, type btvs.exe -Mode Wireshark. This will open Wireshark and start piping your Bluetooth traffic into it.

2. The Capture Session

• Laptop Method: Run FORScan and select 5–10 PIDs you want to map. Start your Wireshark capture and perform a specific action (e.g., sweep the steering wheel or plug in a charger).
• Android Method: Enable "Bluetooth HCI Snoop Log" in Developer Options. Run CarScanner or similar, do your test, and then pull the log via a Bug Report.

3. The Analysis
Once you have your logs, you can use an AI like Gemini to do the math. Tell it: "I have a Bluetooth log (hex) and a sensor log (decimal). Match the timestamps and find the hex PID and the formula for [Sensor Name]."

What We’ve Mapped So Far
Through this process, I’ve already moved several high-fidelity sensors over to Torque:

Sensor	PID	Equation	Header
High-Res SOC	224801	(A*256+B)/500	7E4
Brake Pressure (LF)	222B28	(A*256+B)/6.89	760
Charging Power (W)	22484E	(A*256+B)*5	7E4
Energy to Empty (kWh)	224848	(A*256+B)/500	7E4

Call to Action: Let's Build the List
This is just the start. There are hundreds of PIDs available in the different modules. Tons for the IPC, IPMA, APIM, etc. If you have a favorite sensor or trigger in FORScan that you wish you had in Torque, use the pathway above to capture a log (or give me a shout).

Post your logs or your findings here, and let’s see how large of a "community dictionary" we can build for the Lightning.



Torque values extracted (copy to torque csv).
Name,ShortName,ModeAndPID,Equation,Min Value,Max Value,Units,Header
Battery SOC (High Res),SOC HR,224801,(A*256+B)/500,0,100,%,7E4
HV Battery Current,Amps,22480A,(SIGNED(A*256+B))/100,-500,500,A,7E4
Charging Power,Chg Watts,22484E,(A*256+B)*5,0,20000,W,7E4
Battery Energy to Empty,kWh Rem,224848,(A*256+B)/500,0,150,kWh,7E4
Accelerator Pedal Position,Throttle,22F449,A/2.55,0,100,%,7E4
Steering Wheel Angle,Steer Ang,223302,((A*256+B)-7810)/10,-900,900,°,760
Brake Pressure LF,Brk Press,222B28,(A*256+B)/6.89,0,2000,psi,760
Brake Pedal Position,Brk Pedal,222823,(A*256+B)/2500,0,2,in,760
Lateral Acceleration,Lat G,222B0C,SIGNED(A*256+B)/100,-2,2,G,760
Battery Coolant Inlet Temp,Clnt In T,224846,(A-50)*1.8+32,-40,150,°F,7E4

Would a possible use case be to build a preemptive problem,"pre DTC" kinda detector?

 

[TaxmanHog]

I charged everyday last week, timed to be within an hour of leave times, the trucks thermal management system still decided it needed to spend energy on warming the battery every charging session, my net efficiency plummeted, normally it's around 92% energy consumed goes into the HVB, while this very cold week had the value drop to 50-60%, and this was not using any departure times.

So intentionally eliminating the warming phase might lower battery health & longevity over the long term.

This week I'm not charging daily, and expect to use ~40% SOC for my week day trips, I will recharge Saturday the 7th to 100% and include intentional departure warming on the HVB for another NH trip.

I expect the savings of lost energy to be worth the change especially at my high utility rates.

Off Topic follow-up, I only charged at the end of the week for my daily short trips, much less lost energy to battery-conditioning which isn't important for such short hauls. Then saturday I had a long trip to make where full departure time conditioning was used

Improved the overall MPK for the week, to 1.1 with the help of discounted energy from Ionno at 20 cents a kWh as compared to home charging at 35 cents and many commercial DCFC much higher (with-out membership consideration).

I now return you to your regularly scheduled pid discussions.

 

[mr.Magoo]

I did... about 10kWh for a ER pack is what I am reading which is about 8% ish of a charge.

While the heater element itself is roughly 10-12kW (think max energy I've seen it use is 10.8kW), by no means does it use 10kWh to heat the battery. (at least not in the beginning and not even thoughout the charge cycle unless it's pretty cold)

As you can see from the below charge cycle from ~37% to 90% it's only using the heater (shaded green block in the bottom half) during the first 7min to get the battery over 33.8F when it closes the valve (orange line in the bottom chart) that directs the coolant to the battery.

So 7min * 9kW (on average) is only 1.05kWh

I have no idea why they're waiting a full two hours after before they enter some sort of repeatable thermal management mode.

2nd chart is from last year to show the same type of behaviour, so it's nothing new.

 

[TaxmanHog]

While the heater element itself is roughly 10-12kW (think max energy I've seen it use is 10.8kW), by no means does it use 10kWh to heat the battery. (at least not in the beginning and not even thoughout the charge cycle unless it's pretty cold)

Last night in 5° I charged for ~52 minutes, it's very likely that I used 7 kWh to warm the cabin and the HVB temperature during the session.

Notice the discrepancy for the Ford App session details screen while active and the post event record, 66.3 minus 59 net to the battery is 7.3 auxiliary & warming energy.

HVB Thermal Op's Mode timeline during charge session visit, the drop out's are while I was playing the E-HEAT off/on and adjusting the cabin temp goal value the lower you can tolerate the better for the HVB warm up.

 

[Danface]

Yes. I have another thread on building a database of sensor values and how those are displayed.

This is more about getting pid values. I MUCH prefer the app torque for displays and data logging, but it is severely lacking in available pids. This was an attempt to get more pids for that app.

If need be I can build the database, manipulate the data etc etc ... I do that all day long so well versed in how that works.

 

[mr.Magoo]

Last night in 5° I charged for ~52 minutes, it's very likely that I used 7 kWh to warm the cabin and the HVB temperature during the session.

I think you may have misunderstood my sentiment.
I wasn't saying that it is impossible for it to use 10kWh under any circumstance in absolute terms,
I was meerely trying to point out that a 10kW heater is not the same as 10kWh and that the heater is using a lot less than that.

I'm sure the behaviour is different on DCFC / L3 chargers (it's been a while since I logged one in the cold) but it is also different when the truck is left on (which I assumed the guy doesn't since he's charging at work).

If the truck is on/running when charging/plugged in, it will heat the battery to 68F, at least on L2.
Chart below is from yesterday, it wasn't plugged in from 1.30 to 5.30
Granted, it was only 20F out, but it heated the battery from 32 to 68F in 25min or roughly 3.75kWh

Plus if your cabin heat on then, yeah, it will obviously use more energy / the heater more than it would if it wasn't.

 

[Danface]

https://www.f150lightningforum.com/...ance-efficiency-via-custom-pid-logging.34523/

Might take you up on helping designing it out. Right now I'm trusting Gemini to build the data into a DuckDB instance.
So far it seems to be working fairly well, but it's so hard to tell with these AI assisted tools. In fact I'm basically scrapping everything right now because of the way it was constructed the first time. Not so much because of issues, but because the structure was convoluted and I couldn't retain a mental map of how it was setup

Just keep the data, it can,be structured in a way that makes it easy to use.

In Oracle, CSV files can be made directly into external tables and queried and manipulated on SQL. I've written a lot of interfaces that translated/transform/cleanup data along with UNIX shell scripts so I'd be happy to take a look if you want to share some data files

Sponsored