Full Arduino Mini LoraWAN below 1uA Sleep Mode

End Devices (Nodes)
136

I have observed rare occasions of undefined behaviour of my node. The node stops transmitting than and a reset does the job to solve it. No problem when the node is on the workbench but what about an almost unreachable location?

One thing could be caused by LMIC. With me LMIC does not have clean track record. It does show undefined behaviour every now and than so: How to keep an eye on LMIC?

I would think of some sort of timer/counter to keep track of transmissions and use the watchdog to reset the ATmeg328. (This seems a nice solution to force a reset from software: https://github.com/WickedDevice/SoftReset)

1 Like
137

Hi Lex,
I have seen that you also use the Mini Lora PCb from Charles. Do you use also the version 1.1 ?
I get all the time the error that the sketch did not recognize the BME 280. I now also connected A4 and A5 with the I2C pins accordingly. I have no glue where is the error.
Any help is appreciated.
Br Peter

138

Hello Peter,
In the V1.1 design the wires to A4 and A5 for the basis Arduino Pro Mini aren’t there because of a routing error. Because Charles uses a different kind of Arduino Pro Mini clone, it didn’t came to his notes. But a other used found it out and Charles fixed it in the V1.1a quickly.

But a few people (including me and you) had ordered the PCB’s all ready. It’s not hard to fixed but takes a little handy work. :slight_smile:

4 Likes
139

Thanks guys,
I already soldered a connection between A4/5 and the I2C pins.
Will try out.
Hope to be able to order the new 1.1a version soon.
I wish you all a relaxing christmas.
I appreciate this community a lot !
Br Peter

3 Likes
140

This is a great subject. With some changes in the PIN mapping I could use the sketch with a Dragino mini dev board. thank you!

1 Like
141

Well you’re not the only one. I share one of my X-files.

For my nodes I use a 3.7V LiCh battery which works perfect for low temperatures. But sometimes 2 of the node start transmitting in a loop without any reason I could know off.

Just a few days ago (not even cold weather) one of the node started transmitting in a loop again and because I was home and use a minimal debug info on the serial port (just a unique char for certain points in the program) I found out that the node kept rebooting after a transmission. At first I thought I made program error, but that couldn’t be because the same code is used in more nodes which work fine.
So Measuring the voltage (for that time 3.3V idle) I found out that when the node transmitted and pulled the 50mA current it needed, it dropped the voltage to 2.3V. It could be a BrownOutDetection kicking in but for these nodes I always use the MiniCore bootloader with a BOD of 1.8V so at that voltage the BOD shouldn’t kick in yet. Strange things.

After some searching I found out that :

  1. I removed the batter from the rebooting node and when I applied a default load of 5mA to the battery, the voltage stays ok (the remaining 3.3V). But when I applied a load of 50mA it drops to 2.3V. :open_mouth:
    A battery from a node which didn’t show the reboot after transmission (same model battery) didn’t show that behavior (ok 0.1V load drop but I can live with that). The difference is that the batteries used in the nodes which show the reboot behavior are from a webshop which sells the battery cheaper then the original batteries which I bought from RS Components. :face_with_raised_eyebrow:

  2. The nodes which show the reboot behavior after transmittion, where all programmed with a ISP programmer and not with a bootloader and serial connection. So maybe there was something wrong with that. To test this, I wrote a test program showing the MCUSR on the serial output and a heartbeat message (showing the loop is still running).
    I flashed a Arduino pro mini with the bootloader with a 1.8V BOD and tested it with a variable power supply connected to the VCC of the Arduino. Starting with 3.3V down to 1.5V. At 1.8V the heartbeat stops and after increasing the power above 1.8V the program showed the MCUSR with the BrownOut flag set. So the BOD 1.8V works. :ok_hand:
    Then I flashed the program by ISP and repeated the test. At 2.7V the heartbeats stop and after increasing the power above 2.7V the Arduino showed the MCUSR with the BrownOut flag set. Showing that when I program the Arduino by ISP the default 2.7V BOD settings are used. Thats a thing to remember and even better, to look into. :open_mouth:

Conclusion :

  1. When you find a bargain for components, check it first before really using it. :blush:

  2. When you use the OmniBoot bootloader, burn the bootloader by ISP with the required BOD setting and upload you’re program by serial. Writing you’re program with ISP will set the default 2.7V BOD setting.

Hope that with the above findings this X-file case is closed.

6 Likes
142

use one of these between your battery and arduino

the problem is mostly the lipo protection kicking in when you are transmitting and the voltage dropped below protection value and shuts the power off shortly.
then after some time the voltage rise and it will reboot/transmit… or not and it gets in a loop.
so my suggestion is set bod to 1v8 and use a dc/dc step up/down… :slight_smile:

143

Unfortunately efficiency of many step up converters and step down converters in practice is not very good.
I have done some tests last year but don’t have the results at hand.
I do remember that step down converter efficiency dropped substantially when Vin neared Vout 3.3V for the switching models that use external coils (and is of course dependant on the converter model).
A good efficient LDO voltage regulator will be better (but will only step down).

Switching converters also have a higher quiescent current than a good LDO regulator which is less suitable for low-power applications.

144

I’d recommend to use a stepdown instead a LDO. One like TPS62740 which has 360nA Quiescent Current.

145

@lex_ph2lb
Thanks for this very interesting debugging, I think your battery is just crappy, what model are you using ?
I always program bootloader with Atmel Studio (because I see exactly what is programmed in term of fuses ) Check picture below (but don’t use these settings, they are specific to ULPNode)

image

I’m using with a real AVRISP V2 programmer, trust me, price worth it

See more here about bootloader

6 Likes
146

@lex_ph2lb good research! thanks!

1 Like
147

I use the Saft LS14500 Lithium Thionyl Chloride AA Battery. Which I first bought at RS-Online (link to 201-9438).

After that I bought a batch at accu.nl (link to product). All the nodes who have problems use batteries from that batch.

https://www.accu.nl/saft-ls14500-aa-3-6v-lithium-li-socl2-batterij

Thanks for sharing the picture and the link to you’re page. I’m going to take a look at that.

Edit : @BoRRoZ, @bluejedi, @moeterbln, interesting idea’s. Worth trying a few experiments with them.

148

hummm, I got the same from RS also, need to try them, but 7.5€ the battery, should works, since you measured 3.3V and battery says 3.6V would be interesting to know at what voltage these batteies are considered as off for “safe operating mode” :wink:

Your battery read 3.3V with no consuption, so regarding datasheet, you’re close to the limit and your battery near empty. A fresh new one should be at least 3.5V :wink:

image

May be not lighting any LED and stop sensors during transmit could save you few mA of peak current, another tips could be to add 100uF/470uF capacitor between 3V3 and GND as reserve for peak current :wink:

2 Likes
150

360 nA that’s a very low quiescent current.

I have looked at these SPX3819 LDO regulators (I made some adapters to use them on a breadboard but have not tested them in practice yet).

It all comes down to the overall efficiency in practical real use, which is difficult to obtain from a datasheet.

151

Have a few spares from the first and second batch, so it’s hobby time this evening. :grinning:

152

Another solution for low-power applications are Lithium Iron Phosphate (LiFePO4 or LFP) cells.

Also see: Battery University Types of Li-Ion Batteries and their properties.

Advantages:

  • Nominal voltage is 3.2V which eliminates the need for voltage regulation circuitry for 3.3V equipment.
  • LFP batteries have a very constant discharge voltage.Voltage stays close to 3.2 V during discharge until the cell is exhausted. This allows the cell to deliver virtually full power until it is discharged.
  • The battery chemistry is much safer (and more forgiving) than regular 3.7V Lithium-Ion and Lithium-Polymer solutions which can catch fire when used/handled inappropriately.
  • LFP has higher current or peak-power ratings than LiCoO2.
  • LFP chemistry offers a longer cycle life than other Lithium-Ion approaches.

Disadvantages:

  • Lower energy density than regular Lithium-Ion and Lithium-Polymer (14% less than LiCo2).
  • Needs charger with lower voltage than regular Li-Ion and LiPo.
7 Likes
153

Hi guys,
sorry for the stupid question: the mappings for Charles MiniLora PCB V1.1 (based on the mappings in the github) must the following (I assumed):

.nss = 10
.rst = 0
.rxtx = LMIC_UNUSED_PIN
.dio = {2,7,8}

when I used this mappings I get a failure:
Arduino/libraries/arduino-lmic-master/src/lmic/radio.c:689

which sounds for me, that the pin mapping is wrong.

Any help is appreciated !

154

hi peter
I’m using

// Pin mapping for ch2i , charles board
const lmic_pinmap lmic_pins = {
    .nss = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = A0,
    .dio = {2, 7, 8},         // Specify pin numbers for DIO0, 1, 2
};
155

Thanks ursm,

I used yours, but the failure still continues.
(FAILURE
…/Arduino/libraries/arduino-lmic-master/src/lmic/radio.c:689)

I will try tomorrow with another board to exclude wrong soldering or whatever.

Happy about any ideas to track the error. (and solve :-))

Br Peter

156

Hi ursm,
checked with two other boards and it runs. So the pin setting is correct. The only thing I am missing now is - the RGB LED is doing nothing.
Thanks for your help !
Peter

1 Like