@bnjroos Yes, the RX1 and RX2 delay are specified in the LORaWAN regional settings. I did not look that up for every region, but the ones I recall use 5 and 6 seconds for OTAA join, and 1 and 2 seconds for other downlink messages as default.
@harish-kumar Well, you're not sleeping, so you shouldn't need to nvram_save/restore, but you're re-creating the LoRa object (twice!) in your loop, using two different modes (raw LoRa and LoRaWAN), and re-joining each time, so no wonder your frame counters get re-initialised.
I'm really not sure you can use the current LoRa stack like this to achieve what you want. I'm quite certain it would require some extensive changes to the stack, especially if you really want to maintain true LoRaWAN compatibility (i.e. including ADR, MAC commands, etc.).
Only one of my Gateways out of two accepted join request, but still on the terminal I got the message as not yet joined. I saw the device eui displayes in Gateway join request message is APP eui which was false.
I included device eui also in my code(Also I cant be very sure if it is what got my device to join but it worked for me). By the way I used sample code available on pycom docs for LoRaWAN OTAA.
# create an OTAA authentication parameters
device_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF')
app_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF')
app_key = binascii.unhexlify('FFFFFFFFFFFFFFFFF')
# join a network using OTAA (Over the Air Activation)
lora.join(activation=LoRa.OTAA, auth=(device_eui, app_eui, app_key), timeout=0)
# wait until the module has joined the network
while not lora.has_joined():
print('Not yet joined...')
# 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, 5)
# make the socket blocking
# (waits for the data to be sent and for the 2 receive windows to expire)
Have been looking at power consumption and have similar issues to what is reported here have 200mA in main program then 190 to 150 mA for 30 sec before dropping to deep sleep. In first cycle deep sleep current is 200 micro amps. In subsequent cycles the deep sleep current is 30 mA. Have tried turning everything off without change. Have same issue with LTE but don't have a SIM. Agree that things should not be instantiated by default but as required.
We'll make te intervals longer so that we don't breach the regulations.
I understand what your saying, but could you describe how you calcluate the collision rate?
The strange thing is, that almost every time it is a single node who is not recieved well by the gateway. Not always two nodes at the same time. They are indeed close to each other, but we're now testing it with one node, to see how that works.
@misterlisty it's an optional parameter on the LoRa constructor which enables ADR (adaptive data rate), which is a LoRaWAN features which enables the node and network to adjust parameters (the most important being the data rate, but channels lists as well). Some MAC commands sent by the network are only honoured by the LoPy if ADR is enabled.
However @jmarcelino says the network doesn't send those commands anyway, so it may not be useful.
Also note that the current firmware version does not correctly preserve channel masks during deep sleep.