Indeed, “all” that’s needed to use the TTN community network is coverage. A device will simply transmit (“uplink”), and hope that one or more community gateways receive its transmission and forward that to TTN. And TTN might tell one of those gateways to send some data back (“downlink”). For both uplink and downlink, every gateway registered to the TTN community network is equal; it doesn’t matter who owns it. And if the radio transmission is forwarded to TTN, and if the settings from TTN Console match those in the device, then you’ll see your data in TTN Console, in the application’s and device’s Data pages.
Even more: regardless if one owns any gateway(s), registering devices is the same for everybody. So, yes: administering devices is always done through an Application in TTN Console, without involving any gateway settings.
Now, coverage might be hard to prove if you don’t own a gateway yourself. If you do own a gateway (or if the owner of a gateway adds your account as a “collaborator”) then you can also see the gateway’s Traffic page in TTN Console, which can help debugging problems. (Like if the secrets are wrong, then one would still see the traffic in the gateway’s Traffic page, but would not see the data routed to the application’s and device’s Data pages. Great for debugging.)
Of course, getting in touch with your local community might help if you need debugging. To get an idea of the coverage, see also https://ttnmapper.org (which shows results of people who explicitly take a device on the road for mapping).
In TTN Console you would create an application, and then add new devices to that. However, a node’s DevEUI is not enough:
-
For OTAA activation, you need an AppEUI, AppKey and DevEUI. You could have those generated in TTN Console and copy them into your node, or the other way around, or any combination; see Registration of node with pre-configured LoRaWAN keys.
-
For ABP, you need an AppSKey, NwkSKey and DevAddr. TTN will generate everything and you’ll need to copy those details into the node.
No, that’s not likely. Indeed, during an OTAA Join Request the DevEUI and AppEUI are revealed in the radio transmission, but lacking access to a gateway you won’t be able to see that. And the secret AppKey won’t be revealed over the air anyway. So you need to get these details some other way. That very much depends on your device: maybe you can read some serial logging of the device, maybe it’s printed in some documentation.
Note that OTAA needs downlinks to work, which adds some extra difficulty in debugging when not having access to a gateway’s traffic. But as soon as the device’s status changes from “Status: never seen” into some timestamp you know that TTN received the OTAA Join Request and accepted it, so the settings in TTN Console and the device match. (If you would have the Data page open at that time, you would also see an orange Activation icon with the details about the newly assigned DevAddr.) If you still cannot see any data in TTN Console after that, then the downlink might not have been received by the device. If you don’t see the status change at all, then either the uplink is not received, or the settings in TTN Console do not match those in the device.
