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 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
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.
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).
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
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?).
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 ?
@Batigolle
What type of battery you will put? Lipo? If so you’re correct you need a voltage divider to read battery but I strongly suggest to use one that can be disabled to avoid current draw (see this one)
You can use another analog pin, A0 is using as digital I/O in this lora node so analog config will not hurt A0 pin.
I don’t know the sketch you’re using and what it’s doing with analog, so it’s difficult to answer.
@Charles,
My battery model it’s 18650 Li-Ion 3,7V 3000mAh
I use a voltage divider with two resistors 1M and 470K and capacitor 100nF in parallel
Very interesting your Battery-Voltage-Measure, I will consider it for the final product
I will try to replicate your circuit with normal components, I can not solder the SMDs
I’m using a basic sketch, with lowpower,
I’ll have to add an accelerometer, I’m building the step-y-step sketch
To read the battery, use the A1 pin with the command analogReference (INTERNAL).
I had the doubt if this command, which sets the maximum level of analogue pins, to 1.1 Volt, can affect the operation of the RFM95 module that uses the A0 pin
Yesterday I did some tests, it seems to work without problems
