Yes, but look at the RFM95W datasheet, it supports only max 3.9V. 4.2V from a LiPo will destroy it.
Of course . I totally forgot the RFM95W.
I’m powering 2 boards with 4.2V from lipo, and curiously it works (at least it seems and send packet), but I agree do not do that for production or at your own risk, another user also do that and noticed it worked
another (bad but could work idea) could be to consume current until it reach 3.9V (should be relatively fast powering the RGB LED max power) and then start sending only at this time
If you remove the regulator on a Pro Mini, you can indeed power it direct from batteries, however the batteries that are OK are fairly limited.
A single lithium is a no-no, since at full charge its 4.2V and can destroy the LoRa device.
3 x AA Alkalines is too much, when new the batteries are at 1.5V, so a 4.5V supply is not good.
2 x AA Alkalines are OK when new (3.0V) but around halfway through there life the are down to 1.2V, and a 2.4V or lower supply may be a problem for some sensors.
2 X AA Lithium Energizers are good, they are at 1.45V for most of thier life and work down to -40c.
3 x AA Low Self Discharge NiMh are goodalso, they will be at 1.2v -1.1v for most of their life, so a supply of 3.6v to 3.3v is OK for most things.
I’ve ordered some pro minis.
I’ve very new to this, the fun for me is in the learning. I know I could just get “better” hardware and cut and paste some working code. I’m more interested in getting to understand the principles at work.
Plus, I’m a hobbyist. I don’t have a customer to deliver to or any deadlines to meet
Or you can use 1 ER14505. It is AA size, 3.6V and 2400mAh. I have ordered by ebay 4 of them for 12,- Euro.
These battery is also suggested in this thread: LoRA BME280 Environmental Node (with webbased backend)
It would be real good if there was an AAA equivalent
It may work, for some time.
But it’s up to you to determine the length of some time.
Another option is to use Lithium Iron Phosphate (LiFePO4) cells:
Info higher up in this thread: Full Arduino Mini LoraWAN and 1.3uA Sleep Mode
and more here: The BARGAIN basement part 3
Wow. Amazon has them cheap too - claims 2700mAh:
Rechargeable Lithium Iron Phosphate (LiFePO4) cells are missing in your overview.
See above posts for more info.
A single AA LiFePO4 cell will do fine.
Been testing some batteries;
TINKO AA Lithium, advertised at 2400mAhr, 3.6V, 17.1g, £3.15 delivered.
Tested capacity down to 3V, 50mA discharge, 1706mAhr.
is there a protection build in ?
I dont think so.
My own view is that whilst the internal protection can be used to protect against overcharge issues, the standard internal protection circuits let the battery go too low on discharge, 2.4V, for it to be safe to re-use them.
So if your using cells like this then you need to add your own cicuitry that switches the device off when the cell gets down to 3.0V.
I have some of the LiFePo4 AAA and AAs on the way, which although lower capacity should not have the same safety issues.
Hey Charles,
I’m prototyping a first LoRa module - so far based on MKR1000 + RFM95. I was trying to send the battery value using the LoRa specification.
I looked for information on how to use the os_getBattLevel()
function. didn’t find much literature on it, nor succeeded in altering the os_getBattLevel
function in lmic.c file to send an arbitrary value (0xCC for instance).
Any hint?
thx
Hi,
I already done it you need to declare os_getBattLevel()
function in your sketch (like os_getDevEui()
) and provide battery level according to LoRaWAN specification. Here my example but you need to adapt
/* ======================================================================
Function: os_getBattLevel
Purpose : callback for LMIC stack to know battery level
Input : -
Output : VBAT byte in LoRaWAN format
MCMD_DEVS_BATT_MIN = 0x01 // min battery value
MCMD_DEVS_BATT_MAX = 0xFE // max battery value
MCMD_DEVS_BATT_NOINFO = 0xFF // unknown battery level
Comments: once fired this interrupt disable itself
====================================================================== */
u1_t os_getBattLevel(void)
{
// remap VCC betwenn 2.5V and 3.6V to 0x01 => 0xFE
// This is totally my choice, may be adjusted depending on device
u1_t vbat = (uint8_t) map(ulpn.VBatAverage(), 2500, 3600, MCMD_DEVS_BATT_MIN, MCMD_DEVS_BATT_MAX);
#if DEBUG > 1
DebugF("os_getBattLevel(");
Debug(ulpn.VBatAverage());
DebugF(")=");
Debugln(vbat);
#endif
return (vbat);
};
And then comment the existing definition in lmic.c
of lmic library
#if !defined(os_getBattLevel)
//u1_t os_getBattLevel (void) {
// return MCMD_DEVS_BATT_NOINFO;
//}
#endif
Note that not all backend are managing and returning this value, never seen this value returned by TTN
Thanks @Charles, that’s pretty much what I’ve tried this week-end.
So far I don’t see the battery information in the LoRa frame - that’s where I need to check if and how the platform (here Live Objects, from Orange) is handling this data.
I know it’s working woth other professional devices (eg. a field test device from Adeunis) but I don’t know from where is taken the information (LoRa metadata? decoded from the payload?).
Thanks for the explanation though.
Just to be sure, should I see the battery data somewhere in the LoRa metadata (as displayed in the TTN application data log) ?
I implemented a field tester on cayenne for a customer, as far as I remember the battery level is send by the tester in the Payload (may be also on LoraFrame)
To see this in TTN metadata (or elsewhere) we need to ask @johan if it’s implemented.
Hi @Charles
have arrived, your cards ordered on PCBs.io, and I have already made a sensor successfully,
only with Arduino Pro Mini, RFM95 and antenna, without LEDs and other accessory components.
I want to implement the battery reading, via resistive divider on the Analogic A1 input (A0 already used),
I have a doubt.
The sample scketch I found, requires the instruction analogReference (INTERNAL)
but in your pcb, input A0 is used connected to the RESET pin of RFM95,
can the analogReference () command create problems with the operation of the sensor ?
Thanks