TeslaMate电池健康仪表盘对LFP电池容量计算存在误差问题分析
2025-06-02 00:01:07作者:段琳惟
问题背景
TeslaMate作为一款开源的Tesla车辆数据记录工具,其电池健康仪表盘功能在v1.29.2版本中对锂铁磷酸盐(LFP)电池的容量计算存在明显偏差。这一问题源于系统错误地将适用于镍钴锰(NCM)三元锂电池的计算公式应用到了LFP电池上,导致显示的"可用容量(新)"和"当前可用容量"数据不准确。
技术细节分析
当前错误实现
系统当前对所有电池类型统一使用以下SQL查询计算当前容量:
SELECT AVG(Capacity) AS Capacity
FROM (
SELECT
c.[[preferred_range]]_battery_range_km * aux.efficiency / c.usable_battery_level AS Capacity
FROM charging_processes cp
INNER JOIN charges c ON c.charging_process_id = cp.id
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
AND cp.charge_energy_added >= aux.efficiency
AND c.usable_battery_level > 0
ORDER BY cp.end_date DESC LIMIT 10
) AS lastCharges
这种计算方式基于电池的预估里程和效率参数,适用于NCM电池,但对LFP电池会产生较大误差。
正确的LFP电池计算方法
对于LFP电池,应采用基于充电能量变化的计算方法:
SELECT AVG(Capacity) AS CurrentCapacity
FROM (
SELECT (100.0 * cp.charge_energy_added) /
(GREATEST(1,MAX(usable_battery_level) - MIN(usable_battery_level))) AS Capacity
FROM charging_processes cp
INNER JOIN charges c ON cp.id = c.charging_process_id
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.charge_energy_added >= aux.rated_efficiency
AND cp.end_date >= date_trunc('month', current_date - interval '1 month')
GROUP BY cp.charge_energy_added, cp.end_date
) AS lastEstimatedCapacity
这种方法通过计算充电过程中实际能量增加与电池百分比变化的比值来估算容量,更适合LFP电池的特性。
最大容量计算差异
同样的问题也存在于最大容量计算中:
当前LFP电池的最大容量计算
SELECT MAX(c.rated_battery_range_km * cars.efficiency * 100.0 / c.usable_battery_level) AS MaxCapacity
FROM charging_processes cp
JOIN (SELECT charging_process_id, MAX(date) as date
FROM charges
GROUP BY charging_process_id) AS last_charges
ON cp.id = last_charges.charging_process_id
INNER JOIN charges c
ON c.charging_process_id = cp.id AND c.date = last_charges.date
INNER JOIN cars ON cp.car_id = cars.id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
AND cp.end_rated_range_km > cp.start_rated_range_km
AND c.charge_energy_added >= cars.Efficiency
NCM电池的最大容量计算
SELECT
MAX(c.[[preferred_range]]_battery_range_km * aux.efficiency / c.usable_battery_level) AS Capacity
FROM charging_processes cp
INNER JOIN (
SELECT charging_process_id, MAX(date) as date FROM charges WHERE usable_battery_level > 0 GROUP BY charging_process_id
) AS gcharges ON cp.id = gcharges.charging_process_id
INNER JOIN charges c
ON c.charging_process_id = cp.id AND c.date = gcharges.date
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
问题影响
这种计算方法的错误会导致:
- LFP电池的健康状态显示不准确
- 用户无法正确评估电池的实际衰减情况
- 可能影响用户对车辆维护和使用的决策
解决方案建议
TeslaMate应针对不同电池类型实现差异化的计算逻辑:
- 增加电池类型检测机制
- 对LFP电池采用基于充电能量变化的计算方法
- 对NCM电池保留现有的里程估算方法
- 在UI上明确标注不同电池类型的计算方式差异
这种改进将确保所有Tesla车主都能获得准确的电池健康数据,无论其车辆配备的是LFP还是NCM电池。
登录后查看全文
热门项目推荐
相关项目推荐
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0213
cann-learning-hubCANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。Jupyter Notebook0137
JoyAI-EchoJoyAI-Echo,这是一个独立的、仅用于推理的版本,旨在实现分钟级多镜头音视频生成。它采用了经过蒸馏的DMD生成器、配对的跨模态记忆以及故事级别的一致性。其性能的核心在于,一个跨模态视听记忆库能够在长达五分钟的视频中保持角色外观和语音音色的一致性。同时,一个训练后处理流程将基于记忆的强化学习与分布匹配蒸馏相结合,实现了7.5倍的速度提升,显著增强了视觉质量和对齐效果。00
GLM-5.2智谱开源 GLM-5.2,这是针对长文本任务的最新旗舰模型。相较于前代产品 GLM-5.1,它在长文本任务处理能力上实现了显著飞跃,并且首次在稳定的 100 万 token 上下文中提供这一能力。Jinja00
SwanLab⚡️SwanLab - an open-source, modern-design AI training tracking and visualization tool. Supports Cloud / Self-hosted use. Integrated with PyTorch / Transformers / LLaMA Factory / veRL/ Swift / Ultralytics / MMEngine / Keras etc.Python00
tiny-universe《大模型白盒子构建指南》:一个全手搓的Tiny-UniverseJupyter Notebook03
项目优选
收起
deepin linux kernel
C
32
16
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
468
461
暂无描述
Dockerfile
776
5.07 K
Ascend Extension for PyTorch
Python
756
961
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
872
2.01 K
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
696
1.4 K
昇腾LLM分布式训练框架
Python
183
230
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.1 K
1.14 K
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.04 K
271
Oohos_react_native
React Native鸿蒙化仓库
C++
361
430