New to this world, and at the risk of being flamed myself, but here goes. I have had two18650 batteries die when nrf52840 & L67K power being supplied through usb-c connector, but with a battery connected. The battery connection being made via exqqqquisite soldering to the PCB pads.
The bundle is running meshtastic for a sensor project. Each battery exhibits 0V after a period of hours in this mode.
I had envisaged the nrf52840 and L67K would have a surplus of power for combined needs from the USB connected power source and trickle charge the 18650 at the same time. Not sure if it’s over or undercharrrring in this case but it’s doing a grand job. The first time I put it down to old battery, the second time I woke up. I assume it’s overdischarging due to low level of charging through onboard power circuit. Even a blind squirrel finds an occasional acorn.
Is there a reference standard approach for protecting the battery in this case? Is a TP4056 sufficient between the battery pad connectors and the battery, or are there other approaches to consider.
Thank you.
Hi there,
And Welcome here…
So you will find that battery area is of special concerne to many, Often this type of questions do come up. The 18650 has been used successfully as long as the system profile is sufficient for the discharge time vs charge time and current, Check out the Battery profiler on-line at the Digi key web site, Start there.
ANY post by @msfujino you can take to the bank on power requirements, measurements and consumption. for all the MCU Xiao family.
many threads on the battery subject exist, one or two that match your situation as well.
Post up a picture of this miraculize aperatus
HTH
GL 
PJ 
Thank you for your welcome response. I did track through a number of posts but didn’t find anything that described the death of 18650’s and this group’s recommended avoidance approach in a final solution. I will persist to find the examples you mention.
FYI The use case is an age old one, the ongoing elimination of rattus norvegicus in a semi-pristine avian wilderness sanctuary. 700 traps is a lot to check daily. I’m not paricularly adept in the intricacies of C++ so seeking as simple a solution as possible with off the shelf components and “standard” software. We have volunteers checking traps who are not techies in any sense. I’m using the Xiao Nordic, and a 18015P vibration switch/sensor to detect the demise of ratty, with messaging back to base using SX1262 across Mesh. Pursuing long intervals between battery exchange, as I’m sure everybody else on here is.
Thanks again!
I have noticed the XIAOs can’t really charge my 18650’s fast enough (I use solar daytime that can supply ~800mA).
Since there’s no low voltage cutoff on the XIAOs you may need to either…
- use an “LV protected” cell,
- or add “LV cutoff” circuitry,
- or add code to go to “deep sleep” when the voltage gets too low (~2.5V) - and hopefully get enough charge to eventually allow repowering the device.
Just saw your reply… interesting project.
If you don’t mind a few questions?
What is the acreage of the “sanctuary” requiring coverage? Can a sensor (trap) connect with the “host” without the need for “repeaters”.
Do you have a “sleep” schedule in place - ie sensors sleep until woken by a “rodent” or scheduled timeout?
Thanks.
Hi Gary
We have a beutiful area of dense native bush, with a mix of low and high canopy, but only 120 ha’s (~300 acres) of area. About 2.5km radius, with some steep hills and gullies. We only have 150 houses, being mostly holiday home/chalets. There about 20 permanent (human) residents.
We’ve been trapping introduced pests (non-human) for about 25 years, with very good results. Mostly ship rats, norway rats, mice, stoats, and feral cats. You have to keep on top of them to protect the indigenous birdlife. Our birdlife is spectacular. New Zealand has an ambitious goal to become introduced-predator free by 2050, which is aspirational but worthwhile. Our 700 traps include a number of sophisticated self-resetting traps that don’t require any intervention if a predator is trapped, but the vast majority do and are ineffective at their job until manually visited and reset. They are then a hole in the “defensive shield” we have around our community.
The terrain and compact area lends itself to one repeater situated on the highest point and I have a Sensecap Solar node on order. I walked most of our 40 or so traplines with a home-made meshtastic node texting to the base, and managed a surprisingly good hit rate without repeater. I feel that with the repeater and a central base node this will work pretty well with only one hop via the repeater (no hopping when in sleep mode so just as well).
I appreciate there are “mixed” opinions of meshtastic but a private channel and our remoteness is unlikely to cause the congestion issues many note. The standard meshtastic software allows for nodes to be detection sensors which are in sleep but awake on sensor. My plan is to use a SW-18015P vibration trigger to detect the hefty jolt when the boxed trap is triggered, awaken and text the base. A volunteer can then go clear and reset that trap. That is the main objective of this project.
I’m about to test that setup with a selection of pilot nodes and repeater. I’m a bit rusty on programming and don’t want to leave a mess of spaghetti code for somebody else to inherit one day, so I’m keen to use off shelf items wherever. I’m hoping specific coding will be restricted around the sleep aspect, if meshtastic doesn’t aachive it, and I see many posts and ideas on this resource that will assist.
Hope I haven’t over responded, and you can probably tell I’m happy to answer any questions and share learnings as I go along.
Regards
Richard
Hi Richard,
Thanks for the comprehensive reply - happy to receive any and all additional information.
So, the main issue I was concerned about was the ability of the nodes to sleep without affecting the mesh communications. I think Meshtastic is a perfect solution for this implementation.
While solar support on the sensors is a “nice to have”, the “land of the long white cloud” isn’t always conducive to sufficient solar energy for effective charging. Having said that, the XIAO charge rate (50 or 100mA), isn’t very effective either.
The sneaky part is to determine your “power budget” and “batterify” accordingly, based on a Deep Sleep “Sensor Node”.
Given the remote location and very limited bandwidth requirements (ie Trap Activated and Battery Voltage, etc), you should aim for at least a year on a suitable 18650 (power usage depending).
I have the necessary hardware here so could “have a play” at some stage…
Regards, Gary.
Great to hear your comments. I am very keen to hear your thoughts on the battery budget, if you do get a chance to simulate the setup I mention.
To help define the use case, we see about 25 total catches per day across all our 700 traps so the trigger rate will average around 1 per trap per month currently - though that should rise if we’re clearing them more efficiently under this new approach. Say two wakeups per month per trap.
I’m not currently considering solar on traps, but hoping for min of 12 mths per battery charge. Do you think I will need to take a proactive approach with battery management in the firmware? The Meshtastic close down option doesn’t seem to fit the situation where we will be driving the battery below safe levels while asleep. I’m thinking a 1S BMS card to be included in my node build?
regards
Probably going to look more closely at Meshcore for your particular project… seems a little better suited to the sensor/repeater scenario.
SenseCap Solar is supported (Meshcore) and a great product.
I’ll just build some sensor nodes and see what sleep patterns work. I’d prefer to have a “Sensor Status Update” possibly daily (settable), sending state and battery etc.
Fortunately I’m the only “LoRa dude” in the area so should have a pretty quiet time
Can I ask why you are inclined to the Meshcore option? I have no allegiances whatsoever so interested to understand pros and cons. I’m aware of nodeDB limitations in Meshtastic but otherwise fairly comfortable so far. I will run node-red on a win pc connected to base node via usb, for reporting. We already use trap.nz app for trap management and reporting so will interface to that too via their api.
Regards
… also I plan a battery update daily if I can arrange some sequence that doesn’t flood the mesh. With status reporting in node-red and probably a dark node report.
I love Node-Red
Meshcore seemed a little more “aligned” with your network paradigm, not as “meshy”, more “repeatery”.
I can work with either but thought Meshcore would be a little more flexible with the Sleep etc.
In a large network system, I tend to stagger the node report times, especially with low bandwidth devices (take a long time to report). Since you have a battery, it’s probably worth using a timer of sorts for the scheduling (preferably an RTC).
Each battery exhibits 0V after a period of hours in this mode
I think it is the charging-voltage feeded to the battery. 0V propably means the charger is in CV-state. So I take it as the voltage-difference between target-voltage of 4.2V and the battery. My device always shows 0.00100 V for an almost fully charged and old LiPo-pack. In this situation, the charger is in the CV-state (constant voltage), the second phase of the charging-process. The difference between battery-voltage and charger-voltage is kept (almost) constant to “press” current into the battery. This current is getting lower and lower over time. The voltage is regulated to stay the same in this situation.
AFAIK the charger in the XIAO-board needs a battery with a protection-board. The TP4056 does have protection-mechanisms but is itself an additional charger. I don’t know if you can put two chargers in series this way. Better get some cheap battery-protection boards from china. They are compatible with most Li-Ion-Batteries and LiPo-packs and always do the same: short-circuit-protection, overcurrent-protection, undervoltage-protection and sometimes reverse-polarity-protection.
the XIAO will brown out around 2.7v… if you set your software hault if this happens you can limit drain… but yes… if the unit keeps browning out and restarting it will deep drain the lipo
I’ve bought the battery protection devices you mention and trying them now.
I did that as well, a few days ago. I connected a voltmeter to the output and shorted the cables on purpose. The board stopped output until the short was removed. Very nice! 
Same test with an amperemeter in series revealed: The board’s limit seemed to be 2A. I guess the amperemeter worked as a (very low) resistor for the short-circuit. Hence the protection-board didn’t recognize the short but limited the current to 2A instead. Also really cool!