I have moved into the second decade of the 21st century with a new v3 gateway and a new device! The gateway is a Mikrotik LoRa 9 kit.
Things are sort of working, insofar as the gateway is seen by the console, and my device is seen by the gateway, and attempts to join, but I keep getting the error “Drop join-request Data rate not found”.
The device is an Ursalink UC1122. The data rate is configurable and I have set it to 2-SF10, but in the console I see:
“settings”: {
“data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 12
Is that the problem?
There is very little I can change in the Ursalink settings. It could be a problem in my gateway, or it could be the device. There are no other gateways nearby, so my device will see only my gateway.
I’m in New Zealand, so in the (Mikrotik) gateway I am using the “Australia 915-928MHz FSB 2 (used by TTN)” frequency plan. My gateway server is au1.cloud.thethings.network.
Everything was working with v2. I realise that I have to upgrade to v3, but I seem to need some help.
In v3 with OTAA on AU915 you need to make sure that your device is set up with the right settings in General Settings > Network Layer. I have a device that worked fine in v2 with MAC V1.0.2 and regional parameters PHY V1.0.2 REV A, but needed PHY V1.02 REV B to work in v3.
Thanks! I’ll try it shortly, but it matches what I was told by Ursalink. The only thing I guessed wrong was PHY REV A. We’ll see.
For the record this is what is recommended by Ursalink for the UC1122 (or probably UC11xx in general).
LoRaWAN version: MAC 1.0.2
Regional Parameters version: REV B
LoRaWAN Class capabilities: Supports Class C
Ensure the UC1122 frequency plan is the same as TTNv3. If you use AU915 FSB 2 (used by TTN), change UC1122 channel index to 8-15.
Next step is to figure out how to get data out. And a downlink (I need to turn a thing on or off from time to time). I am unstoppable! (apart from that one time, just before, when it wasn’t working).
I fixed the “Device won’t join” error. I did a factory reset on the device itself and copied and pasted the IDs into the device fields in the console. Success!
Now I am seeing raw data payloads from my device into the console every 20 minutes, as expected. In v2 I used the Python TTN library to get my raw data out. Unfortunately that has been deprecated. I would get the packet contents, pick them apart, and store them in a database. I guess all the cool kids are using MQTT these days, so maybe that’s what I need.
For the downlink, in v2, I used http integration and captured the http URL for the downlink. Next, I set up curl to issue one of two possible commands via http. They got scheduled, then they happened. All change with v3. I will investigate options now.