30uA and LoRaWAN

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

[marcozennaro]

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

Thanks!
Marco

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

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

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

[robert-hh]

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

[malachib]

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

[marcozennaro]

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

[beyonlo]

This post is deleted!

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

[marcozennaro]

@beyonlo you are perfectly right!

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