How can I achieve 2uA current when processor is idle? Quick test with the demo app (LoRa_End_Node) shows 50-100uA. This is during idle period, not including duty cycle. What needs to be done to achieve 2.1uA?
I’ve tried with disconnected debug probe and UART, disabled logging. Still averaging around 50uA during idle period. Demo app joins LoRaWAN network and sends small packet every 30 seconds.
When I look closely, I see peaks to 400uA every 10ms or so, see the picture pls. Average is then almost 50uA. What might it be?
I’ve found what the problem was: floating RX pin of UART. Since I use only TX for logging during debugging, RX is not used at all. When I initialized it as analog, consumption stays at 2.2uA, as it should be:
I found it by creating empty application which goes directly into Stop2 mode and never comes back. Current consumption was about 1.6uA. Then I was adding devices one-by-one in MX, recompiling, flashing and checking current consumption again. I could quickly isolate UART as a problem.
For the low consumption everything has to be physically disconnected from the module/board: debugger interface, UART etc and no pins have to be pulled up or down, unless it is strictly dictated by schematic. Device has to be power cycled after flashing - reset is not enough: it can leave device in a strange state with relatively high consumption, not sure what it is.
I am developing my own firmware, based on STM32CubeWL Firmware Package. I already optimised it further to 1.3uA by switching off bunch of GPIO’s I do not really need.
AT slave firmware will never be able to get there because UART is always on. STM32WL has also low power UART (LPUART), I do not know how much it consumes. I assume more than 2uA. Baud rate is limited to 9600.
It is also possible to make custom AT-slave firmware with a wake-up GPIO pin: when it is low, it goes into STOP2 mode where it will consume like 2uA and when high, it wakes up and ready to communicate via UART.
I’ve read the specs and it seems they’ve implemented some kind of low power mode in AT slave firmware. Key point to me is RX pin (looking from LoRa-E5 side) should not change during sleep, ie it should not be floating. They do not say anything about 9600, so it does not seem to be LPUART. Probably they just switching between using RX pin for UART (wake-up mode) and GPIO external interrupt in sleep? May be look via scope what is happening on RX pin when you send AT+LOWPOWER=AUTOON?
5mA seems like radio is always on. Did you switched to Class A device? What other devices are connected to your board? Any LED is on maybe? or a sensor. Even connected debugger probe sucks some current, but not 5mA
yesterday I used stdio chip , and power from USB port, when it I working it wa 15mA at deep dropped to 5mA, today I texted powering the module directly without ftdi, now at deep sleep mode 0.5mA draws, still this is too high.
also now I cannot get out of deep sleep mode seems they AT command dent work , AUTOOFF hex format FFFFFFFF61742B6C6F77706F7765723D6175746F6F66660D0A. is this in command lit written should get out of the deep sleep mode but doesn’t ,do you have any experience?
Unfortunately, I do not have much experience with AT-slave firmware and do not have any device around to test. According to specs any activity on RX pin should wake up the module. Which makes sense to me.
Seems like you have an issue with power supply. Check your wiring and supply voltage - it has to be in the range from 2V to 3.6V. Also if it is too noisy or cannot handle sudden current changes without significant voltage changes, then MC can go into random state and ‘freeze’. If voltage is ok - may be add a decoupling capacitor? 1uF or higher - the higher the better
0.5mA is what I would expect with UART staying always on, but they seem to switch UART off in deepsleep. This is what I make from reading their specs. Do you have a scope? To look at the power line and RX pin - how much noise is there.
on deep sleep mode UART sis off but you can send command by adding four " 0xFFs" to the beginning of AT command, this is written on “AT Command List” file page 49. voltage is correct with capacitor. I was monitored current drop after I sent the deep sleep command.
how did you test this module with such low current usage ? also is it possible to get help from you by telegram or Skype?
Hi
I am new to the Lora-E5, and wondering as your code is using the HAL, are you reprogramming the Lora-E5 module? If so do you need to get re-certification for this?
I wrote custom firmware, based on STM32CubeWL Firmware Package. I’ve also designed my own PCB width Lora-E5 module. It is mostly a breakout board for the module, just connectors and antenna matching.
I know only so much about certification, you have to ask authorities in your country if you have to certify or not. The way I see it that hardware is certified, not the software. So, any change to HARDWARE requires certification if you want to sell it to end customers. There are some exemptions, but you have to verify with people more knowledgeable in this matter than me. Point being that software is not that much relevant. Otherwise you have to go through certification each time you release new firmware, also bugfixes. Doesn’t make sense to me. Again, this is not an advice, just my own opinion.
Experience so far with the device: 97% of the batteries, voltage is above 3.1V on 2 fresh AAA batteries, device is outside of the building (low temperatures). I have to say that from power consumption point of view this is the best device I’ve built so far. TI-based ZigBee devices (cc2652rb) draining batteries faster.
Hi Alexader
Many thanks for your reply, much appreciated. It makes total sense what you are saying regarding have to recertify after every software update, just doesnt make sense.
I have used STM32Cube for many projects, and carried out a lot of projects with the STM32, but none with Lora. Can you give me some pointers on how to write the code along side the Lora firmware?
For me it was straightforward and it was my first STM32Cube project. I think I’ve started with LoRaWAN-End-Node example and tweaked it until the firmware did what I wanted it to. I’ve also looked at the firmware provided by Seeed, but it is based on the older version of the firmware package, so I didn’t wanted to use it as a starting point.
I’ve got first example application working end-to-end, including TTN part - I could send packets from the device and I could see them coming into my TTN account. Then by taking small steps at a time I gradually came to the end result, which is really simple:
Send LoRaWAN packet once the contact becomes open (GPIO interrupt)
Every 1 hour send a packet with the current battery level, also to be sure that device is still functional
That’s it. Power consumption was the biggest concern, but actually I am more than satisfied with the result.
Firmware itself is well organized and easy to follow, so for me it was not a problem to figure out how to tweak it the way I wanted it to.
Hi,
I also trying to achieve power consumption couple of uA during sleep mode while using default firmware with AT commands.
But in both scenarios (sleep and deep sleep mode) module power consumption is about 650uA.
I tried different state (1, 0, highZ) of UART pins in host controller but consumption didn’t go lower.
Has anybody manage to achieve power consumption couple of uA during sleep mode with default firmware with AT commands?
Hi,
today I finally put LoRa-E5 module in sleep mode (power consumption couple of uA during sleep) with AT command “AT+LOWPOWER”.
It was hardware problem on host board. LoRa-E5 module works fine.
Hi Arvid_Blaser,
hardware problem was on my host board. One of the sensors (for temperature) wasn’t in sleep mode and it drains ~600uA. After putting it in sleep mode, board current consumption was couple of uA when LoRa-E5 module was in sleep mode.
Okey, thank you for the answer, to bad for me it is not the same issue then.
I’m programming the lora e5-mini with cube mx and powering it through the 3.3volt pin. I think most unnecessary things (LEDs and so on) are turned off (I’m having a bit of trouble disabling the usart pins and still compile the code). I’m running almost identical code on the nucleo board for the stm32wl and there I’m getting the sleep current down to 2.1uA even with logs enabled so I am a bit confused what I need to do in order to get a better sleep current on the Lora e5-mini. Do anyone have some more suggetions for me?
My guess is that it would be something with the usb-voltage regulator but since I’m connecting directly to the 3.3pin that should be bypassed right? And in my understanding people are getting a low sleep current without modifying the module?
@Arvid_Blaser: Maybe current goes into usb-voltage regulator? If you say that LoRa-E5 works fine on other host board, maybe could be a problem in host board and not in LoRa module.
My configuration is LoRa-E5+MSP430F5340 with direct 3.3V power supply. Current consumption of whole thing should be couple of uA in sleep mode, but there was weird thing going on in UART bus which get me 70uA in sleep mode. When added pull up to UART bus, current consumption is couple of uA. This solution is quite weird. Since I know, UART shouldn’t need pull-up’s.
