Replies: 9 comments
-
|
I am really excited to potentially see the last item, 'Support upcoming feature request: Battery Capacity'. This would make battery capacity calculation not only easy, but very accurate. |
Beta Was this translation helpful? Give feedback.
-
Voltage curve now are pretty accurate, including a Coulomb meter seems a bit overkill for a project like this, but it's easy and would take a couple of minute to implement it, I Just don't have time right now. For the other points there are things suggested that I don't like, like exposing some too advanced thing to the final user. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah battery chemistry seems like a compile time option, not a user managed one. |
Beta Was this translation helpful? Give feedback.
-
|
Would you explain why you think adding these options as a user-setting is a bad idea? If we enable device battery voltage to be read from an INA sensor then we cannot assume the voltage being read will be li-ion. As of 2.2.23 the firmware supports reading battery voltage for different chemistries (at least at some level)). That tells me there is community support for the concept of using different battery types. Why wouldn't we make it easier for people to configure their solar node? Otherwise, you're talking about creating a firmware variant for each battery chemistry and configuration. I've seen members in the community build solar nodes with:
If you just consider 1S and 2S that's 8 unique variants just for a RAK. That seems less practical than allowing the user to choose their chemistry and configuration in the app. |
Beta Was this translation helpful? Give feedback.
-
Most user have no idea what they are using and what changing parameters do, yourself said that "This name could confuse users who might think they should count ..." . Generally speaking the battery configuration, including series, parallel and battery chemistry are advanced options that are not meant to be exposed to the average person. Battery capacity could be inserted and exposed, as it could be used for estimate the remaining battery life time.
Yes, I implemented multiple curves so it can be adapted to different boards and someone that will make it's varian can in a couple of minute just put it's configuration and compile it's firmware variant.
Code space is limited doing everything at runtime would use more space and slow things, this is not a BMS and to me it doesn't need to act like one.
You can just compile and install the version you need, there is no sense in pre-compiling each variant for each possible combination of all the parameters ... I think there is a need to do a cost/benefit comparison, if out of 1000 people just 3 people need that specific configuration, is really worth it to add those at runtime or the 3 person could just wait 2 minute to compile the version for their specific use case? Just keep in mind that the battery informations from the boards are just for display purpose, any safety manner, like over discharging, over charging, unbalancing, ecc... should be done from a BMS with an hardware protection, nrf52/esp32 and so on are not battery monitoring and protection ICs . |
Beta Was this translation helpful? Give feedback.
-
|
I would clarify that none of these features were requested so they could be used in place of a BMS. The purpose of this request is so users can see the correct battery voltage and percentage in the app. That's it. If nothing else is implemented, getting the INA voltage reading to display as device battery voltage is the primary request. Some work has already been done to support this. The other requests are related to displaying the correct battery percentage. An LTO battery (which could range from 1.5v to 2.8v) will always display 0% when a li-ion voltage profile is applied. That's what we're trying to fix by understanding the battery type and configuration. When we know battery type and configuration (1S, 2S) then we can apply the correct capacity-voltage curve to get the battery percentage. That's the only thing these features would impact. That's why I don't understand how these would cause problems if exposed as user settings. If the user messes up these values it only impacts what they see as their battery percentage. |
Beta Was this translation helpful? Give feedback.
-
But you can already do that, just select the battery configuration you want to use, it's not something you change every day, it's one time only.
I forgot on key-point, most board have a battery port but don't have a bms or any battery protection IC, so the only protection done by the firmware (as most don't use a BMS and have no idea what it is) is to "shutdown" the board in case an undervoltage is detected. |
Beta Was this translation helpful? Give feedback.
-
|
What do you mean by "select the battery configuration you want to use"? Are you talking about selecting the firmware variant to flash? It sounds like you don't have any objection to reporting INA voltage as device battery voltage. Is that correct? Because that's the main thing. It would be a huge win for a lot of people if we just had that. |
Beta Was this translation helpful? Give feedback.
-
|
I'd also like to see this feature added so that voltage can be viewed on Keith's solar kit devices. Meshtastic currently does not correctly display the voltage of the LTO batteries when used in Keith's hardware configuration, because the batteries are not directly connected to the RAK board. Therefore it's not possible for Meshtastic to read the voltage for battery monitoring purposes, and the voltage coming to the board isn't relevant for this scenario. Can we perhaps focus on the monitoring aspect, rather than charging/battery control? This feature ideally would have no impact or functionality related to the connection between the RAK board and the BMS, so the fire concerns shouldn't even be a possibility. Proposal: Maybe there would be a way to show "N/A" for regular battery voltage, and display a secondary percentage for something like "External BMS Battery Voltage" in the scenario where an INA is both detected and enabled within the user settings. This secondary display would not show up in the menu otherwise. This way we can receive the important info, but not interfere with anything Power module related. |
Beta Was this translation helpful? Give feedback.
-
Platform
NRF52, ESP32
Description
This request seeks to round out the Power module by tying up loose ends and by fully supporting various battery chemistries and configurations. This will primarily benefit solar nodes. More people are building solar nodes with battery chemistries and configurations that are not a 1S Lion.
Finish adding support for INA voltage to be reported as Device Battery Voltage
When power.device_battery_ina_address is set, report the voltage reading as the device battery voltage. This should be used for device battery voltage sent over the mesh (to other nodes) as well as battery voltage reported in the apps/clients. When set, this should entirely ignore voltage readings from the device itself (ADC, AXP, etc).
Support INA Sensors With Multiple Channels
When an INA3221 sensor is set in power.device_battery_ina_address we need the ability to select which channel should be used for the device battery voltage. Create a new user option that can be set in the apps/clients for "Device Battery INA Channel", power.device_battery_ina_channel. The options could be: 1, 2 or 3. Voltage readings from the selected channel will be used as the device battery voltage.
Select battery chemistry
Extend the functionality of the recent work by @Gabrielerusso in #3216 so battery chemistry is added as a user option in the Power module. It could be called Battery Type (power.device_battery_type). Battery Type would be the same options added with #3216. The firmware would use the selected battery type to choose the correct capacity-voltage curve (for example, how it defines CELL_TYPE_LIFEPO4 or CELL_TYPE_LEADACID). If we support device battery voltage coming from an INA sensor we can no longer expect battery voltage levels to be the same as a Lion. Nor can we expect a particular board variant to always use a specific battery type. This should be a user option and not tied to a particular variant.
Support battery configuration: number of series
To fully support #3216 and external voltages reported by an INA, we need another user options to define how many cells in series their battery is configured for: Number of Series (power.device_battery_num_series). The current variable used in #3216 is "NUM_CELLS". This name could confuse users who might think they should count cells they have in parallel (for example, the user might have 1S2P and mistakenly put 2 for this value. That's why we include "series" in the option name). There should be little risk exposing these options to users since it only impacts battery percentage reported and does not have an impact on actual charging voltage.
Support upcoming feature request: Battery Capacity
Create another user option in the Power module for Battery Capacity (power.device_battery_capacity). This value is the mAh capacity of the connected battery bank. Users can enter the mAh capacity of their battery bank. Battery capacity is important to know for a future feature request. It will be used to determine the remaining energy in the battery at a particular voltage. (Knowing the battery capacity has other benefits and could support other enhancements like expected runtime at current usage.)
Beta Was this translation helpful? Give feedback.
All reactions