Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add device_battery_num_cells #640

Closed
wants to merge 1 commit into from
Closed

Add device_battery_num_cells #640

wants to merge 1 commit into from

Conversation

fifieldt
Copy link
Contributor

Currently in firmware we hard-code NUM_CELLS (usually to 1), and our code for calculating battery charge uses this variable in ways like "voltage = v / NUM_CELLS;"

If the battery voltage is one cell around our 4V normal, that works fine.

However, as reported in meshtastic/firmware#5360 it's not uncommon for solar installs that have multiple batteries set up in a way that looks like 1 cell at 12V to our current code. So, battery charge % is always 100%.

Allowing num_cells as a configuration option will allow those users to specify how many batteries they have and receive accurate readings.

Currently in firmware we hard-code NUM_CELLS (usually to 1), and our code for calculating battery charge uses this variable in ways like "voltage = v / NUM_CELLS;"

If the battery voltage is one cell around our 4V normal, that works fine.

However, as reported in meshtastic/firmware#5360 it's not uncommon for solar installs that have multiple batteries set up in a way that looks like 1 cell at 12V to our current code. So, battery charge % is always 100%.

Allowing num_cells as a configuration option will allow those users to specify how many batteries they have and receive accurate readings.
@thebentern
Copy link
Contributor

IMO this is a pretty specialized thing that should be handled in DIY variants, since it is most likely involving its own set of other logic potentially for chemistry curves and voltage

@fifieldt
Copy link
Contributor Author

I have no strong opinions, just trying to close a bug ;)

If the variant approach is sufficient, then we've already addressed this with the ability to
#define NUM_CELLS

in variant.h

@fifieldt
Copy link
Contributor Author

@fabrizio-zellini - what kind of variant are you using at the moment? Would defining the cell count in the variant work for you?

@thebentern
Copy link
Contributor

@fifieldt I was thinking this could be an interesting userPrefs macro, as we could integrate our future tooling around building it easily

@fifieldt
Copy link
Contributor Author

Yes, custom firmware flasher candidate for sure

@garthvh garthvh closed this Dec 26, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants