| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| supervooc [2025/09/17 17:45] – gadmin | supervooc [2026/10/05 18:31] (current) – [Расшифровка записей сервиса healthd] gadmin |
|---|
| * У сервиса vendor.oplus.hardware.charger-V7-service есть еще записи типа read content, но их содержимое пока не расшифровано | * У сервиса vendor.oplus.hardware.charger-V7-service есть еще записи типа read content, но их содержимое пока не расшифровано |
| Наличие нескольких источников разной степени доверия приводят к тому, что данные нужно сопоставлять между собой и становятся видны допустимые неточности в замерах и отметках времени. Так, при сопоставлении времен logcat и тестера приходилось сдвигать показания на секунды, после чего оказывалось, что точность отметок плывет. | Наличие нескольких источников разной степени доверия приводят к тому, что данные нужно сопоставлять между собой и становятся видны допустимые неточности в замерах и отметках времени. Так, при сопоставлении времен logcat и тестера приходилось сдвигать показания на секунды, после чего оказывалось, что точность отметок плывет. |
| | ==== Расшифровка записей сервиса healthd ==== |
| | ^Поле^Переменная^Содержимое^Пример^ |
| | |Уровень заряда в процентах(level)|l|Нелинейный пересчет напряжения аккумулятора в проценты|24| |
| | |Напряжение в миллиВольтах|v|Напряжение на аккумуляторе|3583| |
| | |Температура|t|Температура на аккумуляторе|29.6| |
| | |Состояние здоровья|h|UNKNOWN=1, GOOD=2, OVERHEAT=3, DEAD=4, OVER_VOLTAGE=5, UNSPECIFIED_FAILURE=6, COLD=7, FAIR=8, NOT_AVAILABLE=11, INCONSISTENT=12|2| |
| | |Статус|st|UNKNOWN=1, CHARGING=2, DISCHARGING=3, NOT_CHARGING=4, FULL=5|3| |
| | |Ток в миллиамперах|c|Величина тока. Положительный - ток разряда, отрицательный - ток заряда|78| |
| | |Емкость в миллиампер-часах (full charge)|fc|Константа, текущая емкость аккумулятора в mAh|5920000| |
| | |Число полных циклов зарядки (charge count)|cc|Просто число полных циклов. Может поменяться в процессе зарядки|252| |
| | |Статус зарядки|chg|a - wired, w - wireless| | |
| | |
| | l=24 v=3583 t=29.6 h=2 st=3 c=78 fc=5920000 cc=252 chg= |
| ==== Общие наблюдения за процессом зарядки ==== | ==== Общие наблюдения за процессом зарядки ==== |
| Процесс зарядки можно разделить на нескольк фаз. Начальную фазу, когда идёт согласование протокола можно игнорировать, она длится буквально пару секунд и в логе тип зарядки определяется как cdp/dcp. | Процесс зарядки можно разделить на нескольк фаз. Начальную фазу, когда идёт согласование протокола можно игнорировать, она длится буквально пару секунд и в логе тип зарядки определяется как cdp/dcp. |
| {{:compare_voltage.png?1024|}} | {{:compare_voltage.png?1024|}} |
| Начнём с изучения графика напряжений. У нас есть напряжение, которое создаёт зарядка и напряжение на контактах аккумуляторной батареи. В логах charge_time нет напряжения, будем брать его из логов healthd. Мы помним, что healthd обманывают, подсовывая ему напряжение в пересчете на одну ячейку из двух. Поэтому кроме графика напряжения зарядки добавим на график еще одну линию: половину напряжения на зарядке.И становится видно, что в фазе svooc зарядное устройство буквально следует за напряжением на аккумуляторе. Это сильно отличается от линейных графиков Power Delivery. В реальности зарядка скорее всего отстаёт от напряжения, но пока непонятно насколько именно. | Начнём с изучения графика напряжений. У нас есть напряжение, которое создаёт зарядка и напряжение на контактах аккумуляторной батареи. В логах charge_time нет напряжения, будем брать его из логов healthd. Мы помним, что healthd обманывают, подсовывая ему напряжение в пересчете на одну ячейку из двух. Поэтому кроме графика напряжения зарядки добавим на график еще одну линию: половину напряжения на зарядке.И становится видно, что в фазе svooc зарядное устройство буквально следует за напряжением на аккумуляторе. Это сильно отличается от линейных графиков Power Delivery. В реальности зарядка скорее всего отстаёт от напряжения, но пока непонятно насколько именно. |
| Фаза cdp/dcp малоинтересна. Подаём 5 вольт, аккумулятор показывает 4.4-4.5 вольт, причём после ухода с svooc напряжение слегка снижается. | |
| | Фаза cdp/dcp малоинтересна. Подаём 5 вольт, аккумулятор показывает 4.4-4.5 вольт, причём после ухода с svooc напряжение слегка снижается<del>, потому что аккумулятор перестали пинать</del>. |
| Переключение фаз выглядит вот так: | Переключение фаз выглядит вот так: |
| <code> | <code> |
| 09:32:33.256 2145 2145 D healthd : system healthd: battery l=98 v=4490 t=34.3 h=2 st=2 c=-559 fc=5920000 cc=93 chg=a | 09:32:33.256 2145 2145 D healthd : system healthd: battery l=98 v=4490 t=34.3 h=2 st=2 c=-559 fc=5920000 cc=93 chg=a |
| </code> | </code> |
| | Резюмируем: напряжение в фазе svooc просто следует за суммарным напряжением батареи. |
| | ==== Ток зарядки ==== |
| | {{:compare_current.png?1024|}} |
| | Сравнение токов зарядки и аккумулятора осложнено тем, что с аккумулятора снимается ток с учётом тока потребления. И в целом график это подтвержает тем, что графики совпадают с точностью до провалов на аккумуляторе, которые вызваны активностью телефона. |
| | Видна попытка взять 7 ампер, но это длится буквально секунду. Что не сложилось - неизвестно. Температура, наличие тестера на линии или еще что-то. Дальше видно, что протокол долго сидит на 5A и потом снижает ток ступеньками, причём ступеньки в основном равны 1А и немного 0.5А. |
| | Фаза cdp невнятная: берем 1.1-1.2A c зарядки, до аккумулятора доходит 3.5А. Возможно это потери на преобразовании 5V в 4.6V аккумулятора. |
| | ==== State of Charge ==== |
| | Уровень заряженности устройства в процентах - это простая конструкция с точки зрения пользователя, но имеющая свои тонкости под капотом. Скорее всего уровень является нелинейной (или линейной, но по-разному на разных регионах) функцией от напряжения аккумулятора. Лог charge_time вносит еще один уровень косвенности - честный soc и нечестный уровень наружу ui_soc. Разница между ними в reserve_soc=2 на 100%. То есть ui_soc = soc * (100/(100-reserve_soc)). |
| | Если еще вспомнить, что charge_time ориентируется на ui_soc, то смысл вычисления честного soc вообще неясен. Возможно, что после получения 100% в ui_soc проценты зарядки перестают обновляться, но статус BATTERY_STATUS_CHARGING сменяется после достижения 100% в честном soc. Но, поскольку этого нет в логах, это всего лишь гипотеза. Будем считать, что эти 2% увеличивают жизнь аккумулятора. |
| | ==== Time to full charge (ttf) === |
| | Еще один элемент двойной бухгалтерии - это время до полной зарядки, которое существует в двух переменных: честном ttf и "для интерфейсов" ui_ttf. Почему их два можно догадаться: честный ttf может резко меняться, когда зарядка изменяет силу тока, а ui_ttf меняется консервативнее, единичные выбросы сглаживаются. |
| | Вот несколько примеров значений |
| | <code> |
| | # самое начало, до переключения в svooc. |
| | 08:57:52.598 2337 7247 D charge_time: type=cdp/dcp,reserve_soc=2,soc=4,ui_soc=4,current=-226,avg=1100,ttf=9080(02:31:20),ui_ttf=9080(02:31:20) |
| | # только переключились в svooc, оба времени оптимистично уменьшились |
| | 08:57:54.599 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=4,ui_soc=4,current=-330,avg=2000,ttf=4648(01:17:28),ui_ttf=4648(01:17:28) |
| | # а вот участок, на котором видно, что честное ttf снизилось до реальных значений, а ui_ttf продолжает считать по-старому |
| | 08:58:35.647 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=5,ui_soc=5,current=5078,avg=2522,ttf=3690(01:01:30),ui_ttf=4886(01:21:26) |
| | 08:58:36.647 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=5,ui_soc=5,current=5078,avg=3164,ttf=3017(00:50:17),ui_ttf=4885(01:21:25) |
| | 08:58:37.648 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=5,ui_soc=5,current=5078,avg=3802,ttf=2616(00:43:36),ui_ttf=4884(01:21:24) |
| | 08:58:38.649 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=5,ui_soc=5,current=6916,avg=4807,ttf=2253(00:37:33),ui_ttf=4883(01:21:23) |
| | # и только через пару минут значения выравниваются |
| | 09:00:14.754 2337 7247 D charge_time: type=svooc,reserve_soc=2,soc=10,ui_soc=10,current=4889,avg=4875,ttf=2128(00:35:28),ui_ttf=2128(00:35:28) |
| | # и последний пример, где в завершающей фазе честный ttf начинает выдавать пессимистичные значения, |
| | # а ui_ttf продолжает считать по-старому. В результате ui_ttf накидывает только 3 минуты, вместо десяти |
| | 09:33:48.634 2337 7247 D charge_time: type=cdp/dcp,reserve_soc=2,soc=96,ui_soc=98,current=140,avg=224,ttf=792(00:13:12),ui_ttf=213(00:03:33) |
| | 09:33:49.635 2337 7247 D charge_time: type=cdp/dcp,reserve_soc=2,soc=96,ui_soc=98,current=140,avg=140,ttf=1327(00:22:07),ui_ttf=212(00:03:32) |
| | 09:33:50.635 2337 7247 D charge_time: type=cdp/dcp,reserve_soc=2,soc=96,ui_soc=98,current=211,avg=154,ttf=1196(00:19:56),ui_ttf=211(00:03:31) |
| | </code> |
| | |
| |