30uA and LoRaWAN

[marcozennaro]

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?

main.py:

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)

boot.py

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)

[bmarkus]

@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.

[marcozennaro]

@beyonlo you are perfectly right!

[beyonlo]

@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]

This post is deleted!

[marcozennaro]

@malachib it is just sending. As I use ABP I don't have to wait for an acknowledge from the gateway.

[malachib]

Just curious, does your application call for receiving any LoRa packets? Or just sending [1, 2, 3] on start?

[robert-hh]

@jcaron Not likely, because the sx1276 takes 20-120 mA when sending, and about 10 mA when receiving.

[jcaron]

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]

@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.

[robert-hh]

@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]

Thank you @robert-hh. What do you suggest to do to get back to 30uA?

Thanks!
Marco

[robert-hh]

@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.