Lopy4 does not send messages in DR4 in US915 frequencies
we're are experiencing some problems with Lopy4 and US915 channels 64-72.
Sending a message (ABP mode) using DR4 does not seem to work because the message is sent always using DR0.
Moreover, when we try to use the OTAA join mode, the join request messages are sent using only the channels 0 - 63, never the channels 64 - 72.
From LoraWAN specification, the device "SHALL transmit the join request message on random 125KHz channels amongst the 64 125KHz channes defined using DR0 and on 500KHz channels amongst the 8 500KHz channels defined using DR4".
Below the code we used to perform the test in ABP mode.
from network import LoRa import socket import time import struct import binascii import pycom lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915) for i in range(0, 72): lora.remove_channel(i) lora.add_channel(0, frequency=902700000, dr_min=0, dr_max=3) lora.add_channel(64, frequency=903000000, dr_min=4, dr_max=4) dev_addr = struct.unpack(">l",binascii.unhexlify("xxxx")) nwk_swkey = binascii.unhexlify("xxxxx") app_swkey = binascii.unhexlify("xxxxx") lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey),timeout=0, dr=4) i = 0 s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0) s.setblocking(False) pkt = bytes([i]) print('Sending:', pkt) s.send(pkt) time.sleep(10) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 1) s.setblocking(False) pkt = bytes([i]) print('Sending:', pkt) s.send(pkt) time.sleep(10) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 2) s.setblocking(False) pkt = bytes([i]) print('Sending:', pkt) s.send(pkt) time.sleep(10) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) s.setblocking(False) pkt = bytes([i]) print('Sending:', pkt) s.send(pkt) time.sleep(10) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 4) s.setblocking(False) pkt = bytes([i]) print('Sending:', pkt) s.send(pkt)
The first 4 messages are sent and recieved correctly using DR0 to DR3. The last one is sent (and received by the network server) using DR0 instead of DR4 (see image)
Our device is connected to the Senet network.
Has anyone had the same problem? We need to address urgently this issue.
Thanks for any advice.
Hi @oligauc. Your suggestion to set dr_min=0 for the channel 64 did the trick!
Modifying just that using the same code now the device send four messages using DR0 through DR3 at 902.7 and the last one at DR4 at 903.0
If I go back putting dr_min=4 I obtain the same problem again.
I still need to make other tests using the OTAA mode, but in the mean time I want to thank you for your support.
@oligauc As you can see in the sample code, I send 4 messages one after another setting the DR rate each time from 0 to 4. The first 3 messages are sent using the DR that was specified in the socket option directive (DR0 through DR3). The fourth one is sent at DR0 disregarding the DR4. Since the test code uses ABP there is no join request.
I think that the problem with OTAA mode is related to the same cause, for this reason I did the test with ABP and attached this code. I think that solving the problem with ABP mode will solve the issue with OTAA too.
@_peter When creating the socket you are specifying a datarate of 0 (s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0).
Please see the following snapshots for typical join request and uplink data as seen on the loraserver.
Thank you, @oligauc
I'll try setting the dr_min=0 as you said and changing the frequency.
Beside this, can you explain to me why the last message sent by the code above uses DR0 and is received by the gateway with DR0 instead of DR4? If the problem was in the configuration of the gateway, the Lopy4 should have sent the message at DR4 anyway and the gateway should have not be able to receive it. Instead it seems that the DR4 directive when I create the socket is ignored, no exception is raised, and the message is sent and received using DR0.
Thank you again for your time.
Q1: Most Lorawan gateways support only 1 500KHz uplink channel. You can specify any frequency you wish, the 904.6 MHz was an arbitrary choice, however, this should reflect the gateway configuration.
Q2. You are correct the dr_min should be equal to dr_max = 4. This is just a current firmware requirement, that might change soon.
Q3: We carried out test on the US 500KHz channels and if your gateway and lora server are configured correctly it should work.
I'm not sure to understand the solution you propose. Following are the points that are unclear to me:
1- Why add the channel 64-72 using the same frequency value? And, in addition, why start from 904.6 Mhz instead of 903.0 stated in the LoraWAN regional settings for US915?
2- From the regional settings specifications, the channels 64-72 can only use DR4, why set the channel with minimum DR=0?
3- Our objective with the code attached was not to test the automatic hop between frequencies, but to force the transmission with a specified DR, which worked for DR0-3 but not with DR4
As a side note about the third point, in another test we did adding the channels 0-7 and 64 in the same manner as shown in the code, the device hopped correctly between frequencies using however only the channel 0-7, never the 64 channel. This was the reason we tried to force the DR with the above test code.
I hope I was able to explain clearly my doubts, english is not my first language.
Thank you for your reply and your time.
@_peter If you are going to manually add / remove channels, there will not be any frequency hopping. To send at DR4 you need to remove all the 125kHz channels and add only the 500KHz channels.See below
for i in range(0, 72): lora.remove_channel(i) for i in range (64, 72): lora.add_channel(i, frequency=904600000, dr_min=0, dr_max=4)
Hi @jcaron ,
We tested the code attached with 1.18.2.r2 and the latest legacy 1.20.0.rc13
@_peter For reference, can you clarify which version of the LoPy4 firmware you are using?