Wow, between not securing the board and removing the antenna, I think I need to take your gateway in to protective custody - anything could be happening to the electronics if it’s wiggling so much that it drops the connection that often and whilst it’s busy doing that, I doubt it has a chance to hear any uplinks.
But nice red-herring screen shot! But maybe not.
You’ve established the serial log says it is trying to join and you’ve got a trace for the RF. So the potential possibilities are:
The gateway isn’t hearing anything - possibly due to the wobbly board?
The gateway is hearing signals but not relaying them due to CRC errors - is there a log on that gateway you can look at?
Or some sort of default channel setup clash - Tx OK but gateway not listening on that join channel(s)
Thanks for the reply and the ideas. On your points:
I do think that the most likely issue is that the gateway isn’t hearing anything. I’ve ordered a Things Uno to see if I can get any sort of connection to the gateway to try and test this out. For the record, the gateway has been just sitting on a flat surface for debugging its entire lifecycle. It doesn’t wobble
I did try to check the UART log (see Network Layer) from the board as the join OTAA signal was being sent from the Tx device, but saw nothing out of the ordinary.
My gateway and my device are both set to US915 SubBand(2). Here’s a (non-red-herring ) screenshot of my full device settings.
Really - so it connecting and disconnecting several times over the space of a few seconds in the console log, what’s that then??
Yes, good, I was referring to the log the gateway produces. As that will tell you instantly if the gateway hears the Join Tx. And no Uno’s will be harmed in the debugging.
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:
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.
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.
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.
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).
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.
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
Set up gateway in V3 console. Set to frequency plan that transmits in desired range (in my case, 915 SB2.
Create API key for "Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink.
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 ( ), the gateway will send heartbeat status updates that appear as:
MQTT: Sending status packet
MQTT: Sending status succeeded: 5
in the UART display (), and, if verbose stream is activated, said updates should be appearing on the live data screen ().
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 ).
Add device with OTAA (or ABP). Join request should appear on gateway traffic (). At this point, the device should begin to be able to send traffic to the application server over a gateway in range () and traffic should begin appearing on network ().
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.
), the gateway will send heartbeat status updates that appear as:
).