Just experimented a little: Values up to 0x7FFFFFFF are OK but 0x80000000 and higher raise an overflow
My guess is that a signed type was used instead of an unsigned type to represent the dev-addr
You can work around this by choosing a dev-addr that is below 0x80000000
Yes I hope so, I reported the problem on the Pycom forum. But at least there is a workaround by choosing your device address when using the ttnctl command as mentioned above. So itās not as blocking as the 1 packet issue.
The LoPy Works. Upgrade to latest PyMakr and firmware from the website and you can use the following example:
from network import LoRa
from time import sleep
import socket
import binascii
import struct
# Initialize LoRa in LORAWAN mode.
lora = LoRa(mode=LoRa.LORAWAN, sf=7, tx_power=14)
lora.BW_125KHZ
lora.CODING_4_5
# create an ABP authentication params
dev_addr = struct.unpack(">l", binascii.unhexlify('XX XX XX XX'.replace(' ','')))[0]
nwk_swkey = binascii.unhexlify('XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'.replace(' ',''))
app_swkey = binascii.unhexlify('XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'.replace(' ',''))
# 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, 5)
# make the socket blocking.
s.setblocking(True)
while True:
#Do you stuff make data and then send in a loop
print("sending")
s.send('hello')
print("done")
sleep(5)
When Iām using the ABP method it always returns true on lora.has_joined(),
Iāve tried to send a few messages with this method but only one actually came through to TTN.
I did also try the OTAA message, in this case the has_joined function does seem to work and messages get through to TTN more often (But after one message I need to reset the board).