Cannot link Tlera Corp Gnat to The Things Stack

Do you mean the log of the gateway serial? The UART log I was referring to earlier was coming from the gateway. If so, then I am not seeing anything coming from the UART log apart from what I put earlier. A more extended version of the log during the setup is:

MON: SYS Stack size: 2831
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 283KB (288KB), free: 55KB
LGMD:Rejected packet (0x11)

MON: SYS Stack size: 2831
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 283KB (288KB), free: 55KB
MQTT: Sending status packet
MQTT: Sending status succeeded: 5
MON: SYS Stack size: 2831
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 283KB (288KB), free: 55KB
MON: SYS Stack size: 2831
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 283KB (288KB), free: 55KB
LGMD:Rejected packet (0x11) //Rough time point where OTAA is attempting

LGMD:Rejected packet (0x11)

LGMD:LORA: Accepted packet

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

MON: SYS Stack size: 2831
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 283KB (288KB), free: 55KB
MQTT: Sending status packet
MQTT: Sending status succeeded: 6

Of course, this doesn’t look very different than what I normally see when my device is just sitting around with no signal, such as:

MQTT: Sending status packet
MQTT: Sending status succeeded: 17
MON: SYS Stack size: 2837
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 285KB (294KB), free: 54KB
LGMD:Rejected packet (0x11)

LGMD:LORA: Accepted packet

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

MON: SYS Stack size: 2837
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 285KB (294KB), free: 54KB
MON: SYS Stack size: 2837
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 285KB (294KB), free: 54KB
MQTT: Sending status packet
MQTT: Sending status succeeded: 18
MON: SYS Stack size: 2837
MON: TCPIP Stack size: 3739
MON: APP Stack size: 3292
MON: LoRa Stack size: 3877
MON: heap usage: 285KB (294KB), free: 54KB
LGMD:Rejected packet (0x11)

This was UART collected while the Gnat was turned off. Pretty much the same things showing in both cases. Is this indicating that the gateway is never receiving a join request? The only other log I know is the console data that I showed earlier.

What was on the web console for both the gateway & the device at the time of the OTAA connect attempt you have highlighted?

I’m not familiar with TTG Kickstarter to know what the 0x11 code is, maybe @kersing or @Jeff-UK could comment.

The only thing on the web console was the notices about the gateway connection / disconnections from before :confused:

I meant in the console log

Sorry for such a basic question – what exactly do you mean by the console log? I only know of the UART log and the web console display.

My Gateway Log during OTAA:
image

My device log:
image

Your gateway screen shot doesn’t have any status updates - they are usually every 30 or 60 seconds - is the gateway working?

By looking at both the gateway output and the gateway web console it should reveal more about what is happening with the join request.

One option for simplification is to try ABP to check anything is being heard by the gateway and getting up to the NS.

PS, Basic questions are only basic once you’ve learnt all this stuff.

1 Like

I’ve been thinking, I assume you’re using WiFi for the Internet connection of the gateway? Could you use a wired connection?
I don’t expect wonders but there isn’t a lot left to try.

I’ve actually been using wired connection :grimacing:

My full setup right now is: wired connection to The Things Gateway at my workbench. Down the hall (about 20 ft) my device is hooked up to my computer and trying to broadcast.

I’m going to try ABP and also see if there’s anything with the APIs that’s going amiss… I didn’t realize I am supposed to see status updates on my web log. Currently, based on my readings, I am successfully transmitting the MQTT Uplink for the gateway status… I’m just confused as to why it isn’t received by the web server side.

Status messages are hidden by default. Check ‘verbose stream’ in ‘life data’ (gateway part of V3) to be overwhelmed by messages. :grinning:

Hmmmm… I have the verbose stream going now and 6 packets that have been “sent” over the network since a fresh restart but nothing on the live data (paused and unpaused it too just to try and refresh).

My log (with memory stack info removed for clarity)

MQTT: Sending status succeeded: 3

LGMD:Rejected packet (0x11)

MQTT: Sending status packet
MQTT: Sending status succeeded: 3

MQTT: Sending status packet
MQTT: Sending status succeeded: 4

LGMD:Rejected packet (0x11)

LGMD:Rejected packet (0x11)

MQTT: Sending status packet
MQTT: Sending status succeeded: 5

MQTT: Sending status packet
MQTT: Sending status succeeded: 6

LORA: Kick LoRa module with ACK after not acked it for 60s

MQTT: Sending status packet
MQTT: Sending status succeeded: 7

Strange. My gateway using the same transport protocol (the things gateway is in its box in the attic, sorry) shows status messages in the life data feed.
I can’t explain this.
The ‘kick lora’ message is worrying, it might be a good idea to remove the module and reseat it.

1 Like

Hey everyone, thanks for all the responses.

Given the situation, I’m going to guess that this is a gateway issue. I did want to publish my full process one more time before going to buy a brand new gateway just on the off chance that there is some very basic step I’ve missed. In particular, the only other hypothesis I have left besides my gateway being broken is that my information is not being accepted on the server side because of some issue with my API key.

Goal:

Get basic packets from an end-device node, across a Things Kickstarter Gateway, and onto a The Things Network Community Edition (V3) console.

Process:

Gateway Activation

  1. Set up gateway in V3 console. Set to frequency plan that transmits in desired range (in my case, 915 SB2.

  2. Create API key for "Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink.

  3. Activate The Things Kickstarter Gateway following instructions here. In advanced settings, add API field collected in step 2.

At this point, gateway should be connected to console ( :white_check_mark:), the gateway will send heartbeat status updates that appear as:

MQTT: Sending status packet
MQTT: Sending status succeeded: 5

in the UART display (:white_check_mark:), and, if verbose stream is activated, said updates should be appearing on the live data screen (:x:).

Adding Devices

  1. Create application following steps here.
  2. Add device following steps for manual addition here. Check settings to make sure they correct LoRaWAN, a frequency plan in the same subband as the gateway, physical revision, and class are chosen (confirmed with device manufacturer :white_check_mark: ).
  3. Add device with OTAA (or ABP). Join request should appear on gateway traffic (:x:). At this point, the device should begin to be able to send traffic to the application server over a gateway in range (:x:) and traffic should begin appearing on network (:x:).
  4. Since I do not need to further integrate the data with another web service at this time, I do not need to link any other client MQTT servers. Then, I am done with my activation process.

Again, I know this is a somewhat redundant check, but I just wanted to be absolutely certain I have the correct process before I go invest more money when I may have a working gateway now. If so, I’ll chalk this up to a bad lot and we can close out this thread.

As I don’t have a KS gateway I can’t comment, but before someone who knows about these things, it would be honest to own up to the wobbly poorly seated card.

As someone that designs, builds & ships microprocessor systems for security applications, I’d be rather suspicious of the integrity of the radio board …

PS, production manager has just hit me, she says she builds & ships, I just sit in the corner fiddling with Eagle & breadboards.

1 Like

What value are you using for the account server?

I’m using [Gateway ID]@ttn for the gateway ID and https://nam1.cloud.thethings.network for the account server.

Looks like the right values. May-be @htdvisser knows that we’re missing? Probably something so obvious we won’t find it in a 100 years.

Those settings indeed look okay to me, and if your gateway ID is swri14, then it was actually connected yesterday.

If the gateway wasn’t receiving LoRaWAN traffic, I would indeed suspect the “wobbly poorly seated card” that @descartes already mentioned in his comment.

1 Like

Thanks everyone. I tried one last test just to see if it was a WiFi thing. I was trying to run the gateway on an enterprise WiFi network and I thought that maybe there was a chance that, despite being “connected,” traffic across that channel was being blocked. However, it didn’t work on a personal network either. So it really is probably just the gateway.

Ordering an MTCAP gateway and starting afresh. Might find a nice, tall building to throw this current gateway off of…

Thanks again for all the help!

Please recycle responsibly :grin:

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.