devEUI has to match as well, all three need to match AFAIK
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).
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…
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?
1 Like
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…
1 Like
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.
Does the screen shot of your gateway log not indicate anything to you??
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?
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…
@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.
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.
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?
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)
The gateway model is TTN-001-915-1.0 and the concentrator card reads as follows:
LG9271
FCC ID: T9JLG9271
IC:6514A-LG9271
HVIN: LG9271
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:
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 attemptingLGMD: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 
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:
My device log:
