Lopy and Matchx usage
-
I have setup a Matchx Gateway and activated it. Now i want to use the example at https://docs.pycom.io/chapter/tutorials/lopy/lorawan-otaa.html but where do i get the app_eui and app_key from? Do i have to use TTN?
from network import LoRa import socket import time import binascii # Initialize LoRa in LORAWAN mode. lora = LoRa(mode=LoRa.LORAWAN) # create an OTAA authentication parameters dev_eui = binascii.unhexlify('10 00 00 00 00 00 00 01'.replace(' ','')) app_eui = binascii.unhexlify('70 B3 D5 7E D0 00 81 BD'.replace(' ','')) app_key = binascii.unhexlify('77 E7 AE FA 56 67 78 3D 5C 2F 4A E0 B9 F2 E3 FC'.replace(' ','')) # join a network using OTAA (Over the Air Activation) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) # wait until the module has joined the network while not lora.has_joined(): time.sleep(2.5) 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) s.setblocking(True) # send some data s.send(bytes([0x01, 0x02, 0x03])) # make the socket non-blocking # (because if there's no data received it will block forever...) s.setblocking(False) # get any data received (if any...) data = s.recv(64) print(data)
-
@jmarcelino Any update on this? or suggestion?
-
@jmarcelino Thanks, we are doing field trials of a product using your Fopy devices and hoping for solution in short time. Let me know if you need anything else...
-
My apologies, I made a mistake and missed there are different start frequencies corresponding to the transmit and receive channels in that region. MatchX is correct: Uplink Channel 1 (915.2) corresponds to an RX1 in Downlink Channel 1 (923.2)
The data rate is also correct. DR2 in uplink corresponds to DR10 in downlink window.
Since the channel and data rate are correct I'm not sure why the LoPy doesn't accept the JoinResponse. I'll try to investigate on our end if there's anything that could cause this. Again sorry for the confusion.
-
Any advice on my current setup, a bit confused on how to proceed further, MtachX is definetly using RX1, MatchX are saying the up/down frequencies should be different but i think you are saying they should be the same. The LoRaWan spec appears to specify they shouldbe different. Hoope i'm on the right track.
-
@jmarcelino Not sure if i have it right but according to MatchX
"As stated in the instructions 1883 is not correct, the downlink is not the same as the uplink frequency, this is due and in accordance with the LoraWAN Australian specifications.
We advise to use the RX at the correct frequency to receive the OTAA join response.
"
-
@jmarcelino Its definitely set to RX1 in application settings and node settings..i suspect they have a bug and not replying to my support requests.
-
@jmarcelino Thanks, what will the frequency be for RX1? I will try your suggestion.
-
@misterlisty
OK glad ABP is working, for OTAA you need to get the downlinks working.If you see the JoinResponse on frequency 923.3Mhz that means it's still RX2. Make sure it's set to RX1 in both places, there's a configuration for the Application and another for the device.--If it's correctly set to RX1 you'll see that the frequency of the JoinResponse matches the JoinRequest.
-
@jmarcelino its set to to RX1 as suggested. I now have ABP working :), OTTA is yet to work...its definitely getting a lora_accept signal but the code doesn't acknowledge this.
-
You're removing channels twice unnecessarily, remove your second part:
> # remove all the non-default channels > for i in range(3, 16): > lora.remove_channel(i)
Also you're sill using RX2, there are two places for this configuration, I think you missed under Application Configuration -> Network Settings. Please set it to RX1 there.
-
OK..here is my status..have updated Fopy to latest firmware ie 1.1.12b
Here is my OTTA code..it appears to work if you look at the logs of MatchX but code says not yet joined still.
from network import LoRa import socket import time import binascii import struct lora = LoRa(mode=LoRa.LORAWAN) print("Lora send::-3") print("DevEUI[",binascii.hexlify(lora.mac()).upper().decode('utf-8'),"]") # create an OTAA authentication parameters dev_eui = binascii.unhexlify('70 B3 D5 49 97 E4 4C 6E'.replace(' ','')) app_eui = binascii.unhexlify('70 B3 D5 7E D0 00 81 BD'.replace(' ','')) app_key = binascii.unhexlify('77 E7 AE FA 56 67 78 3D 5C 2F 4A E0 B9 F2 E3 FC'.replace(' ','')) print("Lora send::-1") for i in range(0, 72): lora.remove_channel(i) # set the 8 channels for MatchX configuration for channel in range(0,8): lora.add_channel(channel, frequency=915200000+channel*200000, dr_min=0, dr_max=3) lora.join(activation=LoRa.OTAA, auth=(dev_eui,app_eui, app_key), timeout=0) print("Lora send::0") while not lora.has_joined(): time.sleep(5) print('Not yet joined...') print('Finally joined...') # remove all the non-default channels for i in range(3, 16): lora.remove_channel(i) # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) print("Lora send::1") i = 0 while True: print("Lora send::1") # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) print("Lora send::2") # make the socket blocking # (waits for the data to be sent and for the 2 receive windows to expire) s.setblocking(True) print("Lora send::3") # send some data count = s.send(bytes([i % 256])) print('Sent %s bytes' % count) print("Lora send::4") # make the socket non-blocking # (because if there's no data received it will block forever...) s.setblocking(False) print("Lora send::5") # get any data received (if any...) data = s.recv(64) print("Lora send::",data) i += 1
-
@misterlisty
It has to go into flash programming mode, it's a very low level hardware feature.Are you sure you are connecting GND and G23 (also called P2 on the pin map https://docs.pycom.io/chapter/datasheets/downloads/fipy-pinout.pdf )
Also when you use an USB adapter what exactly is your setup?
In any case I think it will be easier to use the Pysense.
-
@jmarcelino Will atempt update through pysense board shortly but it not upgrading the firmware if i use an USB adapter, connect G23 & GND...its running the normal code instead of going in upgrade mode..any suggestion here?
-
@misterlisty
Yes you can use the PySense and you don't need the wire anymore.Make sure you update the Pysense firs, follow the steps here:
https://docs.pycom.io/chapter/pytrackpysense/installation/firmware.htmlWhen you have the new firmware on the Pysense load the the Pycom Firmware Update tool and tick the box which says Pytrack/Pysense:
With this setup you don't need the jumper wire as the tool will use the Pysense to put the FiPy into programming mode.
-
@jmarcelino I have connected a wire from GND to G23 and the fopy will not go into upgrade mode. Its connected to a pysense board while i atempt this. It just running my normal code...can i upgrade while connected to the pysense board? Instructions suggest yes.
-
Hi,
We have no record of your board, so I guess you never updated it?
We really recommend always updating all our boards first. The factory firmware tends to be very old - or set to the wrong region as yours was.
In any case if you run the upgrade tool and choose Australia, then it should set to 915Mhz correctly and you can use the code I posted.
The firmware update instructions are at: https://docs.pycom.io/chapter/gettingstarted/installation/firmwaretool.html
Thanks!
-
@jmarcelino Here is my Mac <removed>
How do you know what setting my fopy has? DO you sedn this during firmware update?
-
Yes that’s set to EU868. We need to reset the device in Pycom’s database before you do a firmware upgrade to change the location. Please send me the MAC address of the WLAN via chat or email a request to support@pycom.io.
Thanks
import binascii binascii.hexlify(network.WLAN().mac(),':').decode()
-
@jmarcelino The result is 868000000
Appears like it isn't Australia..i assume i have to reapply firmware?