Lithium Titanate (LTO) batteries are a very good choice for outdoor LoRa nodes. Unlike ordinary Li-Ion or LiPo cells, they can be charged at sub-zero temperatures and have a very long cycle life.
There is one important catch, however: their voltage range is completely different from Li-Ion and Li-Pol batteries. A typical 1S Li-Ion battery operates roughly between 3.0 and 4.2 V. A 1S LTO battery has a nominal voltage around 2.4 V and typically operates approximately between 1.5 and 2.8 V.
Both MeshCore and Meshtastic now contain low-voltage protection mechanisms which, with their default RAK4631 configuration, can incorrectly interpret an LTO-powered node as having a critically discharged battery.
The MeshCore Problem
MeshCore added power-management protection for nRF52 devices such as the RAK4631.
The current RAK4631 configuration contains:
#define PWRMGT_VOLTAGE_BOOTLOCK 3300
This means that the firmware can refuse to boot when the measured supply voltage is below 3.3 V. Instead, the MCU enters SYSTEMOFF and waits for the voltage to recover.
This makes sense for a conventional single-cell Li-Ion system.
It does not make sense for LTO.
There is already an open MeshCore issue #1572, specifically describing this problem, including its effect on my Solar Mesh Baseboards used together with LTO batteries.
At the time of writing, the official RAK4631 variant still contains the 3300 mV boot threshold.
MeshCore workaround
For a custom MeshCore build, the boot lock can be disabled:
#define PWRMGT_VOLTAGE_BOOTLOCK 0
Alternatively, it can be changed to a voltage appropriate for the actual power system.
Disabling the firmware protection is reasonable if the battery already has its own proper BMS with undervoltage protection. My LTO battery packs, for example, contain hardware/firmware protection designed specifically for the LTO voltage range.
The MeshCore documentation already mentions configurable thresholds as a planned future improvement. Ideally, battery chemistry or the low-voltage limits should eventually become a user-configurable setting instead of being compiled into the board definition.
The Meshtastic Problem
Meshtastic has a different implementation, but the result can be very similar.
Older Meshtastic firmware contained several predefined OCV (Open Circuit Voltage) curves for different battery chemistries, including LiFePO4, NiMH and LTO.
The LTO curve was:
#define OCV_ARRAY 2700, 2560, 2540, 2520, 2500, 2460, 2420, 2400, 2380, 2320, 1500
These global battery-chemistry definitions were later removed. The intention was that custom hardware requiring a different battery curve should define its own OCV_ARRAY in variant.h.
Without such an override, the default curve is intended for Li-Ion and ends at 3100 mV.
Recent Meshtastic versions also use the low end of the battery curve for low-voltage protection. After repeated readings below the configured cutoff, the firmware can trigger a low-battery deep sleep.
This is discussed in Meshtastic issue #10823. Users report that RAK4631 devices which worked with firmware 2.7.15 can shut down or fail to recover with later 2.7.x firmware.
For an LTO-based system, 3.1 V is obviously not a valid battery cutoff.
Meshtastic workaround
When compiling a custom Meshtastic firmware for an LTO-powered RAK4631, explicitly define the LTO OCV curve in the RAK4631 variant:
#define OCV_ARRAY 2700, 2560, 2540, 2520, 2500, 2460, 2420, 2400, 2380, 2320, 1500
A user testing this solution confirmed that it solved the shutdown problem.
Another temporary option is to stay on an older firmware such as 2.7.15, but I do not consider pinning an old firmware version a good long-term solution.
A note about my Solar Mesh Baseboard
My Solar Mesh Baseboard was intentionally designed to support several battery chemistries, including LTO.
With LTO, a buck-boost converter generates the voltage required by the RAK4630 even while the battery itself operates around 2.4 V. Revision D and newer boards can start the converter with an input voltage of approximately 1.8 V.
Therefore, an LTO battery being below 3.0 or 3.3 V does not mean that the power system is failing.
If an external LTO BMS already provides proper undervoltage, overvoltage and overcurrent protection, a second firmware protection layer using Li-Ion thresholds can actually make the complete system less reliable rather than safer.
Summary
If you are using a RAK4631 with a 1S LTO battery, especially in an unattended solar installation, check the firmware version before deployment.
For MeshCore, the current issue is the 3.3 V PWRMGT_VOLTAGE_BOOTLOCK. A custom build can disable it or set an appropriate value.
For Meshtastic, make sure the firmware uses an LTO-compatible OCV_ARRAY. Otherwise newer firmware can interpret the supply as critically low and enter deep sleep.
I hope both projects eventually expose these settings to the user. Supporting different battery chemistries at runtime would be much more convenient than maintaining special firmware builds for Li-Ion, LiFePO4, LTO and other power systems.