I’m using my Solar Node with the latest MeshCore Repeater firmware (v1.18, Oct 2026).
It’s cloudy winter weather here, and the solar panel sees very little to no direct sunlight. Nevertheless, the node seems to charge with the diffuse light: The red LED is on for at least 4 .. 6 hours a day.
But the battery charge went down from 85% to 73% in 8 days. Therefore, the charging power does not appear to be sufficient to meet the daily needs as a meshcore repeater.
Therefore, my questions are:
Who has had similar experiences with the Solar Node?
Does anyone know what the minimum charging current is when the red LED lights up?
Does the firmware affect the charging behavior, apart from power consumption? What I mean is whether the charging circuit can be influenced via software.
As far as I understand, the red LED is hardwired: when it lights up, the batteries are actually being charged. In my case, that would mean that the node consumes more power also during the day than the solar cell supplies.
According to information on the internet, the average consumption should be around 15mA (360 mAh per day).
15mA at let’s say 4 Volts is only 60 mW (0.06). Shouldn’t the solar panel’s output be significantly higher when the charging LED is on? 60 mW is only 1.2% of 5W. So even with a solar output of only 5% of the maximum possible 5 watts, the battery charge should be higher than the consumption.
Therefore, I wonder if this is a firmware problem or a technical one. Or a logical error…
Or the found value of 15mA is completely wrong.
Your practical observation is spot on, but the theoretical 5W calculation doesn’t hold up under diffuse winter conditions. Here is what is physically happening on the bench and in the field:
The Red LED Only Means “Voltage Present”, Not “Net Positive Power”
The onboard charge controller asserts the red CHG LED whenever the solar panel’s input voltage exceeds the battery terminal voltage by a tiny comparator offset (typically ~50 mV to 100 mV).
In overcast diffuse light, solar cells readily produce near-normal open-circuit voltage (VOC), so the charger IC flags that a source is present and lights the LED.
However, the available current (I-sc) in heavy cloud cover collapses dramatically. The panel might only be providing 2 mA to 8 mA, which is enough to trip the indicator LED, but far below the node’s continuous operating draw.
The 24-Hour Energy Balance
A MeshCore repeater must keep its SX1262 radio in continuous RX / CAD listening mode 24/7. That base draw, plus the nRF52840 and board regulators, puts continuous consumption around 12 mA – 16 mA.
In 24 hours, the node burns roughly 300 to 380 mAh.
If your diffuse daylight only delivers an average of 5 mA for 5 hours, you’re only harvesting 25 mAh. You are operating at a net deficit of over 300 mAh per day.
Over 8 days, a drop from 85% down to 73% is consistent with a small, steady daily deficit in winter light.
Can Firmware Influence the Charging?
No. The solar charge path on the Solar Node is managed by dedicated hardware circuitry; firmware has no software-defined control over charge current or MPPT setpoints. This is where a PMIC could help.
The only control firmware has is on the consumption side (e.g., sleep intervals, power profiles, or limiting retransmissions).
Without direct sun (or empirical current measurements using a shunt / inline meter), diffuse winter light simply doesn’t deliver the milliamp-hours required to balance continuous 24/7 LoRa listening.
HTH
GL PJ
Most of these used in the Repeater space or Even 24/7/365 Gateways… Use an External Battery Box and Larger Solar panel, The on board is the Backup so to speak.
Powering via the External USB-C Port (Simplest & Non-Invasive)
The SenseCAP Solar Node has an external Type-C port intended for bench charging and firmware flashing.
How it works:
Connect a 5V regulated output directly from an external battery box (such as a 12V LiFePO4 or SLA box equipped with an efficient 12V-to-5V step-down buck converter) via an IP67/sealed USB-C cable into the node.
What happens inside:
The node’s internal charge circuit treats this as an active USB power source, keeping the internal cells floating at full charge while the external supply handles the continuous ~15 mA load.
Enclosure note:
The USB-C port is under a rubber sealing plug. For long-term outdoor pole/mast mounting, you will need a waterproof threaded USB-C pigtail or a small drip loop with silicone potting/marine sealant to prevent moisture wicking into the port.
Having the same problem currently.. Found out my P1 (MeshCore 1.17.1 fork) went down all the way to 15% (~3.2V) I wonder if recent MeshCore firmware changes increased power usage. Might have to dig through the merged PR’s.
Thank you so much for your reply! I didn’t expect anyone to write such a detailed answer. This should go to some wiki / official doc!
So I wasn’t too far off regarding the average consumption. But I was way off regarding the efficiency of the solar panel in diffuse light, unfortunately.
The red LED lights up quite quickly, even in low light conditions. But that’s probably because the battery voltage keeps decreasing.
But perhaps the charging process becomes more efficient beyond a certain point? What I mean is, without direct sunlight, it’s practically impossible to charge the battery above 80%. But maybe it’s enough to maintain the charge around 3.8V, since the voltage difference between the solar panel and the battery voltage increases as the battery discharges slightly?
Overall, would you say that the charging circuit is quite effective?
While writing my first post, I had the idea of installing a DC-DC converter so that the solar cells could power the board directly via the 5V rail. Essentially as a top-up, as long as the voltage difference isn’t sufficient to charge the batteries. But such a DC-DC converter would probably need to be almost 100% efficient for that to work.
Another idea was to connect the LED output, i.e., the charging indicator, to a free GPIO so that it could be queried as telemetry data.
Or it would be really nice to measure the charging current directly if there were an ADC input…
Unfortunately, the idea of adding an extra solar panel isn’t realistic for me due to space constraints. And the additional installation would also need to be weatherproof.
So at the moment I’m not entirely sure what will happen to my Solar Node installation. Maybe I’ll change the whole thing into an observer; then it’ll need a constant USB connection anyway…
no step up in efficiency like that. the panel delivers what the light gives it, and adding a converter in front would only eat part of that in conversion losses and its own quiescent draw.
But if it’s not charging (e.g. battery full), the panel does nothing → its power is wasted. There’s no path to the 5V rail, hence the node uses battery power instead of solar power…
I think there’s an important distinction in your last point: not having a direct path from the solar panel to the 5V rail doesn’t necessarily mean the solar power is wasted.
Depending on the charging circuit, the panel can still supply current to the battery node while the device is running. In that arrangement, some of the load is effectively covered by solar power even without a separate 5V power path.
I’m not sure whether the P1 Pro is wired that way, though. We’d need to check the actual charger IC and schematic rather than assume it.
A useful test would be to measure the current flowing into or out of the battery while the repeater is operating, first with the panel covered and then under daylight. That would tell you whether the panel is merely reducing the battery drain or actually producing a net charge.
I’d also be careful about drawing conclusions from the battery percentage alone, especially with changing temperatures.
It would be interesting to know which charging IC the P1 Pro uses. That might answer the power-path question more directly than the charging LED does.
under diffuse winter conditions. Here is what is physically happening on the bench and in the field:
PJ 
