Wow @Charles. This is very similar to what I’m working on, and my next challenge is dropping the current down to a manageable level.
I’m using a Nano clone with RFM95, BME680 sensor (minus gas sensor - too much current heating the plate, and needs to run too long to get meaningful readings). Running nicely through to Cayenne. I’ve got all the code into about 29k without losing the bootloader yet.
I will look through this thread in more detail when I get my new gateway working!
A Nano is very inefficient for low-power applications. Most use an (low-power inefficient) AMS1117 voltage regulator and have a (separate) USB to Serial adapter chip that eats power.
More ‘standard’ would be an Arduino Pro Mini (compatible).
These don’t have USB to serial chip/functionality on the board and need a separate USB to serial adapter for programming.
They do have a voltage regulator but more low-power friendly than an AMS1117 on the Nano.
You will still have to remove the power LED (or cut traces) on a Pro Mini for low-power applications, like with most boards.
Some even remove the on-board voltage regulator for ultra low-power. But I would not feed a 3.3V device directly with ‘3.7V’ (sounds like Li-Ion or LiPo which first start at max 4.2V and then go down).
Feeding a 5V Arduino may work with 3.7V but I don’t have experience with that. Powering a 3.3V board on the 3.3V input directly from Li-Ion or LiPo can damage the board (in that case better use the on-board LDO voltage regulator).
Pro Mini’s are available in 3.3V and 5V versions. 3.3V is most common these days as most sensors etc. use 3.3V.
Hmm, if I had a look at the datasheet of the ATMega328, which is used on the Arduino Pro Mini boards and this µC operates with voltages between 1.8V and 5.5V. In my opinion, it shouldn’t be a problem to directly connect the battery to the VCC pin and power the Arduino Pro Mini with it.
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 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).