Set MAX TX power in LoRaWAN mode

[d.alvrzx]

Hi everyone:

Is there any way to make the LoPy4 default to max TX power (20 dBm in US915) in LoRaWAN mode? I am using ABP and the latest 1.20.2.rc6 firmware from Pycom.

I'm thinking of this possible scenario: LoPy4 cannot hear GW, and GW cannot hear LoPy4 when transmitting at 5 dBm (so no comms at all). If the LoPy4 defaulted to the max TX power, it's possible that at least the GW would be able to hear the LoPy4 (and telemetry packets would be received, which is really all I care about since I'm using ABP).

In this case, you can notice that I would not be able to use ADR because the LoPy cannot hear the GW. So it would be best for me if the LoPy increased its own transmit power.

Any help you could give is greatly appreciated :)

Best,

Dan

P.S. Regarding the much higher current consumption of transmitting at 20 dBm, that is not an issue for the setup I am running.

Edit:

I also understand this has been a recurrent topic in the forum, but unfortunately I haven't found any solutions in the responses. Here's the links to the other posts that look into this:

https://forum.pycom.io/topic/1913/set-tx-power-in-lorawan-mode

https://forum.pycom.io/topic/2059/solution-for-setting-spreading-factor-power-coding-rate-and-frequency-for-lorawan-join-is-mandatory

https://forum.pycom.io/topic/3897/actual-tx-power-different-from-set-tx-power-in-raw-lora-mode

I was wondering if possibly @jmarcelino or @jcaron could pitch in, as I've seen their responses in other posts... Thanks guys!

[d.alvrzx]

Hey, guys. Anybody out there that could pitch in regarding this? I have noted that even when having ADR disabled (both in the server as in the LoPy), the tx power is still stuck at the minimum of 5 dBm. How can I increase it?

[Eric73]

Hi, this is not how lorawan is supposed to work, that's why there's no python endpoint to do this.

First at all, how can you say that your device always send at 5dBm even when you joined network with ADR disabled ?

Are you sure to dont confuse txpower and DR ?

Your device is static or mobile? This can change how you can handle your situation (if it's mobile i hope you have an accelerometer on your board)

[d.alvrzx]

@Eric73 Hi! Thanks so much for your reply :)

Yes, I was presuming that the whole point of LoRaWAN is to have control over your end-devices, and so having them have control over their own TX characteristics isn't a great idea, specially if you have an area with lots of devices owned by different people.

But, it was my understanding that the LoPy should default to its max TX power when ADR is disabled (according to @jmarcelino 's response on this thread) (?)

I've checked it's only transmitting at 5 dBm by using the lora.stats() function, so I'm sure its not being confused for DR... Here's the code running on my LoPy to test this out. You'll see that I always transmit at DR0 because I need to maximize range.

from network import LoRa
import socket
import ubinascii
import struct
from utime import ticks_us, ticks_diff, sleep

# Initialise LoRa in LORAWAN mode.
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915, adr=False, device_class=LoRa.CLASS_C)

# clean all channels
print("Initializing channels...")
[lora.remove_channel(channel) for channel in range(0,72)]
# open selected channels
CH_RANGE = [8,9,10,11,12,13,14,15]
FREQ_RANGE = [903900000, 904100000, 904300000, 904500000, 904700000, 904900000, 905100000, 905300000]
[lora.add_channel(channel, frequency=thisFreq, dr_min=0, dr_max=3) for channel, thisFreq in zip(CH_RANGE, FREQ_RANGE)]

# create an ABP authentication params
dev_addr = struct.unpack(">l", ubinascii.unhexlify('00000005'))[0]
nwk_swkey = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C')
app_swkey = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C')

# join a network using ABP (Activation By Personalization)
lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey))

# create a LoRa socket
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

# set the LoRaWAN data rate
s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0)

# wait for setup
sleep(5)

while True:
    # start timer
    t = ticks_us()

    # make the socket blocking
    # (waits for the data to be sent and for the 2 receive windows to expire)
    s.setblocking(True)

    # send some data
    s.send(bytes([0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]))

    # make the socket non-blocking
    # (because if there's no data received it will block forever...)
    s.setblocking(False)

    # print time
    delta = ticks_diff(ticks_us(), t)
    print("Sent. TX Time =", delta/1000)

    # get any data received (if any...)
    data = s.recv(256)
    print("Received:", data)

    # print stats of last packet
    print("Stats:", lora.stats())
    print("\n")

    # wait
    sleep(5)

On the LoPy, no matter how long I wait, lora.stats() always returns 5 dBm on TX power:

Sent. TX Time = 5002.944
Received: b''
Stats: (rx_timestamp=0, rssi=0, snr=0.0, sfrx=0, sftx=0, tx_trials=0, tx_power=5, tx_time_on_air=371, tx_counter=27, tx_frequency=904300000)

And the uplinks on the server look like this:

My devices are stationary (mostly), they move every couple of weeks from place to place. So I think having ADR enabled wouldn't be ideal, because they could move from a location close to the GW to a location very far away, and the GW would have no way of knowing this.

Basically, then... Should the LoPy default to 20 dBm when ADR is disabled? Or am I mistaken?

Best wishes,

Dan

[Eric73]

@d-alvrzx As i understood source code , the documentation is wrong.
tx_power is not in dBm but in lorawan coding. For US915 regional parameters are defined as following (Table 14: US902-928 TX power table)
TXPower Configuration (conducted power)
0 30 dBm – 2*TXPower
1 28 dBm
2 26 dBm
3 : 13 ….
14 2 dBm
15 Defined in LoRaWAN1

So TW_POWER 5 is 20dBm (maximum EIRP of the sx1276 chip used in pycom hardware)

[d.alvrzx]

@Eric73 Oh wow, that makes sense... So it actually is transmitting at max power, as expected. That's good to know. Thanks so much for your insight!

@catalin @Xykon would you be able to confirm this? If so I think it's important to change the documentation in https://docs.pycom.io/firmwareapi/pycom/network/lora/. Thanks!