search

meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.36k stars 821 forks source link

TBEAM 0.7 voltage needs to be sensed via the voltage divider, lora32 also #279

Closed geeksville closed 4 years ago

geeksville commented 4 years ago

User reported it claimed 254% full battery. No I2C PMU on that part.

geeksville commented 4 years ago

the battery reporting code should be guarded by "axp192_found".

@slavino would you mind taking a look at this? (No pressure - if not I'll do it, but my queue is pretty full and I don't have a 0.7 tbeam)

Professr commented 4 years ago

Anything that uses battery percentage should check for >= 0. It returns -1 if it can't be computed, IIRC, and it must be getting put into a uint8_t that's wrapping it around to 254 :\

Professr commented 4 years ago

Probably an issue between where it gets computed in power.h and stored in PowerStatus.h

geeksville commented 4 years ago

yeah - I bet it is getting 0xff because there is no i2c device out there giving back real answers.

Professr commented 4 years ago

I'll take a look at the device side. It might be as simple as changing a uint8_t to a signed int so the failure value gets passed through.

slavino commented 4 years ago

@Professr https://github.com/tekk/TTGO-T-Beam-Car-Tracker/blob/122d8efc2ebc57445a80581974c6d5670329dfc0/TTGO-T-Beam-Car-Tracker.ino#L20

https://github.com/tekk/TTGO-T-Beam-Car-Tracker/blob/122d8efc2ebc57445a80581974c6d5670329dfc0/TTGO-T-Beam-Car-Tracker.ino#L66

https://github.com/tekk/TTGO-T-Beam-Car-Tracker/blob/122d8efc2ebc57445a80581974c6d5670329dfc0/TTGO-T-Beam-Car-Tracker.ino#L231

@geeksville I believe I posted this already to some other bug or maybe discourse discussion. But let's rather have it duplicated than have to search for it over ad over.

Professr commented 4 years ago

https://github.com/Professr/Meshtastic-device/tree/issue%23279 The packet structure already uses a signed int, so I just changed powerstatus to match and ensured the percentage is set to BAT_PERCENTAGE_INVALID by default. I don't know enough about the guts of the phone<->device comms to be certain whether or not any of it needs updating, unfortunately. I think on the Android side at least the UI will need to check for a negative percentage to know whether to trust the value or not.

slavino commented 4 years ago

Yes, the Power.cpp and Power.h have AXP192 chip methods quite heavily bound into the logic. Some abstraction would help here as T-Beam 0.7 really relies only on analog read as stated in my comment above.

I can verify what the board does while charging with the analog value but I honestly doubt that there will be any method to read charging state of the battery while the power is plugged in.

geeksville commented 4 years ago

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/alpha-tester-thread-0-8-1-android-code-is-ready-for-test/298/209

geeksville commented 4 years ago

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/question-from-a-new-user-can-yall-help-answer/882/5

geeksville commented 4 years ago

see note from @slavino in #303

tschundler commented 4 years ago

fwiw, on the LORA32 v2.1(1.6) I measured a 75/77 ohm voltage divider bat+ -> io35 -> bat-.

geeksville commented 4 years ago

I've added support for this, but it is disabled until someone with suitable hardware can test. @slavino & @tschundler would you mind changing configuration.h to uncomment the line I added and see if it works for you?

https://github.com/meshtastic/Meshtastic-device/pull/315/commits/6a402b13fa5afea1924af9b01a241ff4638da361

thomslik commented 4 years ago

I know you didn't ask and please ignore if not needed. I uploaded the new code to my tlora-v2-1-1.6, after changing configuration.h as indicated. It seems to be sensing a battery voltage now, but results in a boot loop. This is the serial log: ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒Emitting reboot packet for serial shell ▒▒Hbooted, wake cause 3 (boot count 4), reset_reason=reset I2C device found at address 0x3c ssd1306 display found done Meshtastic swver=unset, hwver=unset Setting random seed 3114421785 Total heap: 265672 Free heap: 238436 Total PSRAM: 0 Free PSRAM: 0 NVS: UsedEntries 88, FreeEntries 542, AllEntries 630 Using analog input for battery level Turning on screen Read RTC time as 4 (cur millis 92) valid=0 ERROR: No UBLOX GPS found Hoping that NEMA might work RadioConfig reset! Installing AES128 key! Initial packet id 2080715845, numPacketId 4294967295 Loading saved preferences Loaded saved preferences version 11 Installing AES128 key! NODENUM=0x91828afc, dbsize=1 Starting meshradio init... Set radio: name=Default, config=3, ch=6, power=17 RF95 init result 0 [D][esp32-hal-cpu.c:189] setCpuFrequencyMhz(): PLL: 320 / 4 = 80 Mhz, APB: 80000000 Hz Battery 4mV 95% Trigger powerFSM 10 Transition powerFSM transition=LowBat, from=BOOT to=SDS Entering deep sleep for 31536000 seconds Turning off screen Writing preferences ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

and quickly repeats.

geeksville commented 4 years ago

at @thomslik thanks that does help. the "Battery 4mV 95%" is because it thinks the battery is so low that it needs to enter deeplsleep. Does your board have a battery installed? If so, this indicates my guess on how the voltage divider would need to work for that board is wrong ;-)

geeksville commented 4 years ago

@thomslik oh I see, battery volatage is supposed to be in millivolts - I'll fix!

geeksville commented 4 years ago

@thomslik I'm pushing a PR to fix this. would you might trying it again? ;-)

thomslik commented 4 years ago

Disregard the previous message. Uploaded the Master branch code and the battery level appears to be working. It doesn't show the charging indication when charging, but just still displays the level. Not sure how accurate it is, as voltmeter shows 4.15 volts, with battery level showing three bars and log showing 73%.

geeksville commented 4 years ago

@thomslik thanks! yeah - the %full for these boards is a super rough linear interpolation based on voltage. Really for a lipo we should be looking up from a table (like what the axp192 does on the tbeam 1.0). But I'm going to call it done for now and turn this on for your board and the tbeam0.7. Someday someone can add a table based lookup to make the %full more accurate.

tschundler commented 4 years ago

Hm. I got the comment about 3mV and boot loop. Then I realized the default branch is post1 (which doesn't have the v->mV fix) not master Using master, it works, thanks! I have a battery @ ~3.7v and it shows 2/4 bars.

But regarding the boot loop - is that really correct low battery behavior? In the log above, it says: Entering deep sleep for 31536000 seconds, but it reboots immediately

geeksville commented 4 years ago

@tschundler yeah - good point, that's not right (and we also enter deep sleep in other cases). It should have stayed asleep until button pressed. What model of board do you have? I'll make a separate issue to track that.