Skip to content
New issue

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

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

Already on GitHub? Sign in 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants