Cannot link Tlera Corp Gnat to The Things Stack

[rbrightwell]

I’m currently trying to implement an asset tracking application on The Things Network using The Things Gateway and a Tlera Corp Gnat developed by @onehorse. I’ve linked the code I’ve uploaded to the Gnat here (Gnat Asset Tracking Code). I’m having issues connecting the end device to the console and wanted some input to see if I’m missing any steps.

Attempted Process:

1. Create application in TTN console.
2. Create end node in console. Set DevEUI, AppKey, and AppEUI to the values flashed to the Gnat. Note that DevEUI is created by pulling EUI of STM32 chip. AppKey randomly generated on console side. AppEUI pretty much just left to the same value as the source code.
3. Configure rest of settings according to LoRaWAN specifications*
4. Wait for connection

Results: End node does not connect, no traffic appears on Gateway log.

Attempted Debugging:
I’ve really tried to narrow in on whether this issue is a physical layer issue (with LoRa itself) or a network issue (LoRaWAN).

Physical Layer
I am getting a signal across on a spectrum analyzer in the 904MHz range, as expected for sub-band 2 of the US_902_915 region, as seen below:

This to me suggests that the physical layer is working at that their must be some issue with the network configuration.

Network Layer
During setup, I debugged the following portion of the LoRaWAN setup:

Serial.println("Now attempting OTAA..");

LoRaWAN.joinOTAA(appEui, appKey, devEui);
Serial.println(LoRaWAN.joined()); 

Resulting in the following debug statement:

Now attempting OTAA..
0

Indicating that there is some sort of issue with OTAA.

On the gateway side of things, I’m seeing pretty much nothing when I try and establish OTAA. This is the only thing I’m seeing when I attempt to perform OTAA:

LGMD:LORA: Accepted packet
MQTT: Sending UPLINK OK
LGMD:Rejected packet (0x11)

I’ve also found that running some of the basic examples provided in the LoRaWAN source code also results in the same issues. I cannot connect to the network.

Troubleshooting on The Things Network support page wasn’t much help. I’ve ensured that my gateway is connected and that I used the same DevEUI, AddKey, and AddEUI that was flashed to the chip.

Next Steps:
This is where suggestions from the community on how to further troubleshoot my device would be appreciated. Based on what I have read, connection should have been much more painless than what it was and I am having difficulty finding forum posts on the same issues.

*The code uses the Arduino wrapper put together by @GrumpyOldPizza that is based on the LoRaWAN 1.0.2B standard (source files can be found here ).

[kersing (Jac Kersing)]

@rbrightwell

On the gateway side of things, I’m seeing pretty much nothing when I try and establish OTAA. This is the only thing I’m seeing when I attempt to perform OTAA:

That is about right. In the TTN console gateway section for your gateway, is there any traffic listed?

Are you using V2 or V3?

[onehorse]

Did you change this line in the sketch to 2 for the TTN?

LoRaWAN.setSubBand(1); // 1 for MTCAP, 2 for TT gateways

[rbrightwell]

I’m on V3.

No traffic listed. All I’ve seen in my console log is the gateway connecting/reconnecting logs

[onehorse]

LoRaWAN.begin(US915);
LoRaWAN.setADR(false);
LoRaWAN.setDataRate(1);
LoRaWAN.setTxPower(10);
LoRaWAN.setSubBand(2); // 1 for MTCAP, 2 for TTN servers

LoRaWAN.joinOTAA(appEui, appKey, devEui);

Works for me using Gnat on V3…maybe the console settings aren’t right?

[rbrightwell]

Yup, I changed it to 2. Would there be any other changes needed to make it work? I used the antenna and patch that you recommended in your Tindie post.

In the debug, it is interesting how there is almost an instant rejection of the OTAA request. After the BM400 calibration I just immediately start streaming data. This is my first attempt at OTAA so maybe that’s just how it normally goes, but it seemed fast. Here’s my full setup debug, in case it helps for any reason.

Serial enabled!
STM32L0 MCU UID = 0xA4737343034343830001D
STM32L0 Device EUI = 383434305137770a
Scanning...
I2C device found at address 0x14  !
done

VDDA = 3.32 V
VBAT = 0.18 V
USB Connected!
STM32L0 MCU Temperature = 34.29

BMA400 accelerometer...
BMA400 I AM 90 I should be 90

BMA400 is online...

x-axis self test = 2503.9mg, should be > 2000 mg
y-axis self test = 2158.2mg, should be > 1800 mg
z-axis self test = 896.5mg, should be > 800 mg
hold flat and motionless for bias calibration
x-axis offset = -86.0 mg
y-axis offset = 292.1 mg
z-axis offset = 41.6 mg
Now attempting OTAA..
0

==End Setup==

LOCATION: NONE
SATELLITES: 0
VDDA = 3.30 V
VBAT = 0.16 V
STM32L0 MCU Temperature = 28.71

[onehorse]

No other changes to the sketch that I know of except I have to use the console generated app Key or something… I did have to set some things in the V3 setup that I didn’t need to do in the V2 one, like LoRaWAN Mac version etc. Maybe this is where the problem lies?

[rbrightwell]

Well it’s a relief to know that it isn’t a V3 issue at least.

Maybe it is my console? I’m using LoRaWAN 1.0.2B/Class A for my setup, frequency band US902_928(2). From my understanding of how the AppKey and AppEUI work, as long as the console and Gnat both share the same AppKey/EUI they should work. I’m using the STM EUI for my device EUI. There’s no packet configuration /API key or anything that I would need to setup prior to receiving traffic, is there? My gateway configuration was pretty basic, I only had an API key for "Link Gateway to Gateway Server for traffic exchange, i.e. write uplink and read downlink.

[onehorse]

I don;’ think it is the Gnat, but the console info including appEUI, devEUI, and appKey does need to match between device and console settings. Not sure why it is not working for you. In my case, I just followed step-by-step the V3 instructions and it worked the first time…

[onehorse]

devEUI has to match as well, all three need to match AFAIK

[rbrightwell]

Thanks for all the replies. I just tried it with PHY V1.0.2 REVA (I had been using PHY V1.0.2B) but am still getting the same issues. I’ve attached a photo of my network settings as well as my AppEUI / DevEUI across the console and Gnat code.



Where did you pull the device address from? I am not seeing that field on the console (just the 64 bit DevEUI).

[onehorse]

The device address is in the network section of the console, but I don’t think I set this (that is, I think this is set automagically) and I don’t know where it might be used…

[kersing (Jac Kersing)]

OTAA will set the device address when the backend receives a valid join request and answers. Don’t set it manually.

@rbrightwell if you do not see any traffic in the life data view of the gateway in the console your devices transmission isn’t received and forwarded to V3.
Either the device transmits using a frequency not received by your gateway or your gateway doesn’t forward the data correctly to TTN.
Do you happen to have another LoRaWAN device you can use to check the gateway works correctly?

[Jeff-UK]

Make sure there is a decent distance/absorber e.g. walls between node & gw…if very close can saturate gw rf front end and multichannel breakthrough causing errors, MIC check failures etc which will then stop gw forwarding Join req to back end…

[rbrightwell]

Hey everyone,

Thanks for the replies.

@Jeff-UK I tried putting some distance between my device and the gateway, moving the gateway to a lab down the hall and putting about two wall’s worth of distance between. I also tried removing the antennas from both the gateway and the device, running several tests with the device or gateway or both antennas removed and also trying in both short range (on my desk) and long range (lab mentioned above) conditions. I saw no changes or traffic on my gateway.

As of right now, this is the only traffic I’ve seen on my gateway. No traffic is being observed or sent back to the device. Does this mean that the OTAA request being sent out by the device isn’t being received at all? That is that in the link:

Device sends OTAA -> OTAA Request received by gateway -> Gateway links device and sends (something?) back to device to acknowledge

That this process is getting stopped at the first step?

@kersing I’m in the process of ordering a Things Uno and a RAK-7201 to try and test another device on the gateway. I’m using The Things Kickstarter Gateway for this project. You may be right that its a gateway issue.

One thing I also ran across in another forum Migration Procedure | V2 to V3 Update | V3 Steps was the following line:

Create a new application on the v3 stack.
Create an incoming MQTT endpoint wired to the v3 stack for data ingestion into your system.
Start creating new devices on the v3 stack.

This is something I haven’t done, but also haven’t seen any documentation for. Is this specifically a V2 issue, or is there a link to a thread for how to do this? I haven’t been able to find anymore information. I know this is a community forum and I’ve really tried to find my answers on my own, so I hope its not some simple thread I’ve missed, but I do really appreciate the help from all TTN volunteers.

[descartes (Nick McCloud)]

Does the screen shot of your gateway log not indicate anything to you??

@rbrightwell

One thing I also ran across in another forum Migration Procedure | V2 to V3 Update | V3 Steps was the following line:

This is for migrating devices and for that user’s world view - if you use MQTT to get the data from TTS then you will need to set that up. But for now, getting your gateway from turning on & off endlessly would be the first thing to fix.

Have you followed the official documentation to migrate your gateway?

[Jeff-UK]

@rbrightwell

I also tried removing the antennas from both the gateway and the device, running several tests with the device or gateway or both antennas removed

Aarrhh! Please dont do that - put the ants back asap! Running a device without an ant load will cause almost all the RF power to reflect back into the front end risking frying it - you may come away lucky with GW and node that still works depending on how many Tx’s they executed… but be prepared for them to be defective or to see early life failure as a result if over stressed. (search of forum will find many messages saying do not run without ants attached likley also in device documentation there will be high profile warnings against this…

[rbrightwell]

@descartes I should clarify – during my testing, I had to move the gateway between rooms a couple of times. I do get about ~1 dropped gateway connection every 2-3 days, but I’m pretty sure its from the well-documented “reboot loop” caused by a loose Lora chip. By pushing in and rebooting, it always comes back on. I’m planning to strap it in a (hopefully) more permanent method with a ziptie to keep contact.

I was never on V2. I started my gateway and devices on V3. As for setting up the gateway, application, and devices, yes, I have followed the instructions meticulously.

As for the application, at this point I am simply trying to get a packet from the Gnat to the gateway… nothing fancy. I didn’t imagine the MQTT was the solution, but I thought I would at least ask because I really don’t know what the issue is.

[rbrightwell]

Oh!! Thanks for the notice. I only had the antennas off for maybe 10 minutes total, so hopefully I’m fine… I have several Gnats to try with so I will switch to a new one just in case. The gateway… not quite as much. Though it seems to still be operating just as before.

[kersing (Jac Kersing)]

What does the label on the back of the gateway list as the part number? And what information is on the white label on the concentrator card in the gateway?