Gateway is ok: http://noc.thethingsnetwork.org:8085/api/v2/gateways/datahive-gw01
Gateway is also ok according to things-gateway.local/info (0 packets up / down though … I don’t know if this is because in my region I’m the only node or if this is sign of something wrong)
Gateway shows 4/5 blue lights (no flashing)
Double checked my appeui and appkey
This device has never been activated before (first time)
Device is 1 meter away from gateway
Tried rebooting uno several times: same result
Click to see the full LOG
-- JOIN
Model: RN2903
Version: 0.9.5
Sending: mac set deveui 0004A30B001BB107
Sending: mac set adr off
Sending: mac set deveui 0004A30B001BB107
Sending: mac set appeui 70B3D57ED0017203
Sending: mac set appkey 8BE021B72550CF689EE15B43ABE314DC
Sending: mac save
Sending: mac set ch status 0 off
Sending: mac set ch status 1 off
Sending: mac set ch status 2 off
Sending: mac set ch status 3 off
Sending: mac set ch status 4 off
Sending: mac set ch status 5 off
Sending: mac set ch status 6 off
Sending: mac set ch status 7 off
Sending: mac set ch status 8 on
Sending: mac set ch drrange 8 0 3
Sending: mac set ch status 9 on
Sending: mac set ch drrange 9 0 3
Sending: mac set ch status 10 on
Sending: mac set ch drrange 10 0 3
Sending: mac set ch status 11 on
Sending: mac set ch drrange 11 0 3
Sending: mac set ch status 12 on
Sending: mac set ch drrange 12 0 3
Sending: mac set ch status 13 on
Sending: mac set ch drrange 13 0 3
Sending: mac set ch status 14 on
Sending: mac set ch drrange 14 0 3
Sending: mac set ch status 15 on
Sending: mac set ch drrange 15 0 3
Sending: mac set ch status 16 off
Sending: mac set ch status 17 off
Sending: mac set ch status 18 off
Sending: mac set ch status 19 off
Sending: mac set ch status 20 off
Sending: mac set ch status 21 off
Sending: mac set ch status 22 off
Sending: mac set ch status 23 off
Sending: mac set ch status 24 off
Sending: mac set ch status 25 off
Sending: mac set ch status 26 off
Sending: mac set ch status 27 off
Sending: mac set ch status 28 off
Sending: mac set ch status 29 off
Sending: mac set ch status 30 off
Sending: mac set ch status 31 off
Sending: mac set ch status 32 off
Sending: mac set ch status 33 off
Sending: mac set ch status 34 off
Sending: mac set ch status 35 off
Sending: mac set ch status 36 off
Sending: mac set ch status 37 off
Sending: mac set ch status 38 off
Sending: mac set ch status 39 off
Sending: mac set ch status 40 off
Sending: mac set ch status 41 off
Sending: mac set ch status 42 off
Sending: mac set ch status 43 off
Sending: mac set ch status 44 off
Sending: mac set ch status 45 off
Sending: mac set ch status 46 off
Sending: mac set ch status 47 off
Sending: mac set ch status 48 off
Sending: mac set ch status 49 off
Sending: mac set ch status 50 off
Sending: mac set ch status 51 off
Sending: mac set ch status 52 off
Sending: mac set ch status 53 off
Sending: mac set ch status 54 off
Sending: mac set ch status 55 off
Sending: mac set ch status 56 off
Sending: mac set ch status 57 off
Sending: mac set ch status 58 off
Sending: mac set ch status 59 off
Sending: mac set ch status 60 off
Sending: mac set ch status 61 off
Sending: mac set ch status 62 off
Sending: mac set ch status 63 off
Sending: mac set ch status 64 off
Sending: mac set ch status 65 on
Sending: mac set ch status 66 off
Sending: mac set ch status 67 off
Sending: mac set ch status 68 off
Sending: mac set ch status 69 off
Sending: mac set ch status 70 off
Sending: mac set ch status 71 off
Sending: mac set pwridx 5
Sending: mac set retx 7
Sending: mac set dr 3
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Now I moved the endpoint further away from the gateway 10 meters and 40 meters and repeated the test. Same result.
The other thing that may be helpful in troubleshooting this is that my gateway is showing 4 received messages and 0 transmitted. To me that indicates that the gateway is getting messages from uno but it’s not transmitting them onwards. (again I seem to be the only gateway and endpoint in my area, so I’m pretty sure these are my messages - don’t know how to be sure)
Also, my gateway has been having trouble maintaining uptime of more than a day. It usually reboots it self anytime between 2 minutes and 1 day (have never seen uptime longer than a day on it). After it reboots it seems to be “fine” according to info page and according to blue LEDs, but not I’m not sure it is. Don’t know if it’s a coincidence or not, but just as I was doing those 10 and 40 meter tests with endpoint, that’s pretty much the same timeframe when the gateway rebooted again. I don’t know if that’s coincidence or if what’s happening is that any time any traffic comes in it causes the gateway to reboot. Will need to do more testing on that.
The gateway won’t transmit unless commanded by the backend network. You should be able to see in the logs that the gateway pushed the received messages across the internet. No idea why it’s rebooting on you, unless there is some kind of power issue. If you can’t see the join requests in the devices part of the console, I’m guessing that there is some kind of mismatch with your device eui, dev key or application key, but that’s a guess since I’m still trying to wrap my head around all these concepts.
Edit:. I’m thinking you should see some activity in the gateway traffic page, regardless of any key mismatches. You have to have that web page open before you try your join. There is no historical ability, only what’s happened since you opened the web page.
My gateway reboots a lot too, often multiple time a day. But the good news is: most often this makes it recover from some error without any manual intervention… Probably unrelated to your problems; see https://github.com/TheThingsProducts/gateway/issues/52
By the way, your gateway status message above shows that 4 messages have been uplinked to the network. I suspect your problem lies in the endianness of your IDs or keys being sent by the node. Are you sure that your device configured through the console is using exactly the same device eui that the node is using?
Update: I did the tests again and I don’t think those 4 messages belong to me. This time I watched the gateway traffic the whole time and nothing showed up. Also after all that testing I’m still showing 4 messages received by the gateway (at least this should have gone up). I don’t mind the reboots (no reboot close to the time I was testing BTW), but I keep thinking my gateway isn’t passing the traffic properly. Maybe I should take a field trip to the next closest gateway and try registering there. I bet it will work from there.
Regarding the endianness of my IDs or keys - I’m not sure what you mean. I know that data representation can be big-endian or little-endian, but I’m not sure how that’s related to what I’m trying to do. I got EUI from device info, registered the app and then copy pasted appEui and appKey from the console and tripple checked it. I will quadruple check it, but I’m not sure what I’m looking for.
Are you sure that your things uno is transmitting on the right frequency band for your region. I’m in the US, but I have found that a great many example programs and default settings lean towards the EU setup and must be overriden. I’ve never used the things Uno so I don’t know how it is configured out of the box. I do know that my allegedly US gateway came setup as an EU ready gateway.
Just chiming in. I have the same problem, but my UNO was working fine, Then I started to get “Join not accepted:denied” But the interesting thing when I go to the gateway console traffic, I can see that the join was accepted.
I don’t know what causes this “slow” mode, and I don’t really know what fixes it. Sometimes the “slow mode” goes away after I press the reset button. Sometimes when I unplug USB and plug it back in. But the more I fight with this, I think it just “fixes itself” after a while until it breaks itself. I can’t find any pattern.
It’s not related to Arduino studio problem because I get the same problem even when connected to it with putty
I tried different USB ports and different computers - same result
I also tried running it headless with help of LED flashes to help me understand what’s happening under the hood, and I think I have the same problem even when I take the serial communication out of the picture entirely.
Am I chasing a red herring with trying to figure out this “slow mode” problem? Even when this “slow mode” isn’t present, join still fails.
I created a brand new application and this time I noticed that the default handler value was incorrect for my region, so this time I selected “ttn-handler-us-west” and I got what looks like a successful registration
As per mwalczak5603 's comment, the join seems to be accepted even though I got the “Join not accepted: denied message”
Thank you all for help … I hope I don’t run into further trouble after this, but I am still scratching my head regarding that “slow mode” weirdness.
If the Join Accept can be seen in the gateway’s Traffic page in TTN Console, but is somehow not received by the node, you’ll still see “denied”. And when not accepted then TTN will not send anything at all. So, “denied” really means that the node did not receive anything.
I will try to do the firmware upgrade to get any other bugs out of the way
Also, for anyone else having the same problem, even though it initially says “Join not accepted”, it shows up in the console right away and then after about 30 repeats of “Join not accepted” it eventually shows “Join accepted. Status 0001” (but that’s only after fixing that TTN handler issue. TTN handler is definitely the root cause from what I can tell - Application TTN handler setting has to match your region)
I’m still working on the firmware upgrade … in the mean time I noticed something unexpected. When I booted my TTN uno this morning it does this
ttn.sendBytes(data, sizeof(data));
Sending: mac tx uncnf 1 01
Response is not OK: not_joined
Send command failed
I’m surprised because all day yesterday I did many reboots of it and it consistently did “Send command succeeded”. (I did have trouble receiving at the console, but at least it didn’t fail outright like now) It appears that I somehow lost registration. I tried rejoining, but I’m back to the join not accepted problem (and no - waiting it out doesn’t help, it doesn’t join even after 15 minutes). How does a node lose its joined status?
