Thanks !
@lex_ph2lb When I used your code I found that the downlink timing for RX 1 and RX 2 was delayed up to seconds. Because of this no downlink message are received from the network. Have you observed the same behaviour?
I think it will be because of the delay(1000) on line 416.
I haven’t used the downlink in this solution.
1 Like
Ok, I have moved back to my original code and added the sleep functions in a non intrusive way. now downlink works fine.
I wanted to have my node lorawan compliant as much as possible (for as far as that is possible with LMIC 
) and allow ADR to work.
1 Like
Hi, I have managed to go down to 5,5 uA on my node. To get there I had to remove the 5V regulator, the power LED, and add some of the code I found in the code of @lex_ph2lb. Particulary the Rocket scream code is powerful.
The only observation I have now is that the transmit cycle takes more than 3 seconds. I would expect it to be close to 2 seconds because of class-A behaviour of the node. Has anyone looked in to this?
1 Like
LMiC implements a safety delay in which it assumes the gateway was actually sending a downlink for the node in RX2, but the node just failed to pick it up. The idea is that in that case sending too soon makes no sense as the gateway won’t be listening.
Earlier versions of LMiC would even delay EV_TXCOMPLETE for that; recent versions still have that delay before one can transmit again, but fire the EV_TXCOMPLETE after about 2 seconds.
So: is LMiC up to date?
1 Like
The library I use is 1.5. How to see if the version is up to date?
Hi Lex,
what is the $apikey for a key defined in ttnlora_env_vars.php ? Its not the googlemaps api key I assume. Is this apikey related to the http integration into ttn ?
Thanks Peter
You could peek into lmic.c to see if it has the changes.
It seems @matthijs did not update the file library.properties, so I guess one cannot tell from the Arduino IDE, or maybe one cannot even install a recent version through the IDE, unless one uses the ZIP file from GitHub.
2 Likes
Indeed, When you look at the code LoRaWAN_TTN_Env/ttnlora_env.php at master · ph2lb/LoRaWAN_TTN_Env · GitHub
on line 16 and up. You see a commentout section which should work with that apikey.
I haven’t used it. I couldn’t figure it out to work it correctly so I left it out for now. The idea is that you add a “secret” api key in the header in the http integration to prevent false data upload by people who want to do bad things. (a.k.a. crackers).
I updated lmic according to the suggestions and it reduced the on-time while keeping downlink functionality. great!
2 Likes
What code are you guys using to get it down to uA?
Im using this https://github.com/tkerby/minilora-test and the lowest I can get to is 0.15mA. When sleeping it’s varies between 0.35 and 0.15mA. The only thing I have changed in the code is the keys.
The hardware I have is only the Arduino Pro mini without voltage regulator and LED and the radio module. I haven’t solder the BME280 sensor yet. I have solder the 4.7k ohm pullup resistors for the I2C and the 10uF capacitor.
Any idea how to get it lower than this?
2 Likes
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
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
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. 
4 Likes
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
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
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 :
-
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.
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.
-
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.
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.
Conclusion :
-
When you find a bargain for components, check it first before really using it.
-
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
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… 
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.