30uA and LoRaWAN
-
Hi Pycom community,
I am developing an application where I try to optimize battery life. While I get low power consumption (30uA) with a basic example, I cannot get below 100uA when using deep sleep after using LoRaWAN (on TTN) as per the code below. I am using a LoPy4 with the latest firmware powered with 4.8V on the Vin pin and no additional board.
Any suggestion on how to get lower power consumption?
import machine import pycom import time import network from network import LoRa from network import WLAN from network import Bluetooth import binascii import struct import socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR,0) s.setblocking(False) s.send(bytes([1, 2, 3])) print("Going to sleep") machine.deepsleep(20000)from machine import UART import os import network from network import LoRa from network import WLAN from network import Bluetooth import pycom import struct import binascii import time uart = UART(0, 115200) os.dupterm(uart) pycom.heartbeat(False) pycom.rgbled(0x007f00) print('Switching off WLAN') wlan = network.WLAN() wlan.deinit() print('Switching off Server') server = network.Server() server.deinit() print('Switching off Bluetooth') bt = Bluetooth() bt.deinit() print ("Starting LoRa.....") lora = LoRa(mode=LoRa.LORAWAN) dev_addr = struct.unpack(">l", binascii.unhexlify('XXXXXXX'))[0] nwk_swkey = binascii.unhexlify('XXXXXXXXXX) app_swkey = binascii.unhexlify('XXXXXXXXXXXXX') lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey)) while not lora.has_joined(): machine.idle() print('Network joined!') time.sleep(5) -
@marcozennaro The difference of 70 µA is equivalent to 47kOhm load to 3.3V. So it could a signal with an pull-up resistor which is held low, like the SX1276 CS at GPIO18.
-
Thank you @robert-hh. What do you suggest to do to get back to 30uA?
Thanks!
Marco -
@marcozennaro That is hard to tell. As a blind shot, I would set the GPIO pins used for Lora/Sigfox to input. For P5 to P7 this is easy. For the other Pins at GPIO17, 18, and 23 this is not supported. These are internal Pins and not accessible through machine.Pin. And for GPIO17 it might be not recommended anyhow. AFAIK, this is also used for SPIRAM Clock.
-
@marcozennaro Unrelated, but note that you'll probably save a bit by using
pycom.wifi_on_boot(false)rather than "manually" disabling WiFi and Bluetooth. -
Another thing you may try: set the socket to blocking to be sure it's finished sending before going to sleep, and/or add a (long enough)
time.sleep. -
@jcaron Not likely, because the sx1276 takes 20-120 mA when sending, and about 10 mA when receiving.
-
Just curious, does your application call for receiving any LoRa packets? Or just sending [1, 2, 3] on start?
-
@malachib it is just sending. As I use ABP I don't have to wait for an acknowledge from the gateway.
-
This post is deleted! -
@marcozennaro said in 30uA and LoRaWAN:
@malachib it is just sending. As I use ABP I don't have to wait for an acknowledge from the gateway.
Using ABP do not means that node will not waiting for a possible ACK from the Gateway. Both, ABP and OTAA always waiting a time (are two DOWNLINK slot times) after sending data, for a possible ACK from the gateway, that is standard. The difference is that OTAA needs an authentication (that will use a DOWNLINK too) before to sent any data, ABP doens't.
-
@beyonlo you are perfectly right!
-
@beyonlo said in 30uA and LoRaWAN:
@marcozennaro said in 30uA and LoRaWAN:
@malachib it is just sending. As I use ABP I don't have to wait for an acknowledge from the gateway.
Using ABP do not means that node will not waiting for a possible ACK from the Gateway. Both, ABP and OTAA always waiting a time (are two DOWNLINK slot times) after sending data, for a possible ACK from the gateway, that is standard. The difference is that OTAA needs an authentication (that will use a DOWNLINK too) before to sent any data, ABP doens't.
You are missing different things.
First, Gateway never send ACK, it is done by the LoRaWAN Network Server when requested by the device.
ABP and OTAA are activation modes and handling encryption keys. ABP itself doesn't generate any air traffic, keys exchanged out of LoRaWAN. OTAA is a way to generate keys but it has nothing to do with authentication.
Whether node will wait for downlink and when is independent of activation mode, it depends on Devics Class 'A' or 'C', 'B' is not supported by PyCom and most of other devices.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login