where to buy :
getting started :
part 1 is HERE
part 3 is HERE
Hi Did you ever find an answer to that question?
Have you read the information in this (long) thread? There is no ssh but there are a few http pages for which the URLs are somewhere in this thread.
If anyone has the time for it, it would be great if they could help improve the pages about The Things Gateway on our Docs by submitting a pull request on Github. That way we can refer these kind of “frequently asked” questions to the Docs.
A bit on a tangent, but I wonder whether I should raise a github issue about the poor range I get from my gateway (max. 550m)?
I would be interested in the Metadata (RSSI and SNR)
I also got a Things GW, but mine isnt working at all - at least yet - as you might read
Yes, thanks, I read most, if not all, the TTN Gateway central 1 thread and participated in it periodically. Some of it, especially in respect to troubleshooting, I haven’t necessarily understood fully.
My particular curiosity about ssh possibilities derived from acquiring an EveryNet TouchTag
http://everynet.com/wp-content/uploads/2017/06/TouchTAG-Product-Brief-V3.0.pdf
after seeing it in the Cayenne list of devices presumably compatible with The Things Network.
The company provided me a DEVEUI, DEVADDR, Appskey and Netskey for the device.
I tried to connect it to an application that successfully provides traffic data to the console and Cayenne using TheThingsNetwork Nodes.
I used ttnctl to issue these two commands using the DevEUI, Netskey and Appskey the company had provided:
ttnctl devices register [Device ID] [DevEUI]
tnctl devices personalize [Device ID] [NwkSKey] [AppSKey]
But didn’t via the console find any signs of data being transmitted. Shaking the device gets me a visible green flash, which looks healthy…
I tried additionally issuing this command using the DevAddr provided by the company
ttnctl devices set touchtag_sr_94 --dev-addr [DevAddr] --override
Wasn’t sure if I should do that since it creates the warning: “WARN Manually changing the DevAddr of a device might break routing for this device”
I thought if I could ssh into the gateway that might help me determine if the gateway is receiving data from the device and forwarding it. I haven’t tried a UART connection, but perhaps I should, with trepidation, attempt that for the first time if that could get me the information and if there’s no simpler route to obtaining it. Any advice would be appreciated. Thanks.
Any data forwarderd by the gateway is available in the console. If you open the console, go to the gateway and switch to “Traffic” you will see any traffic sent by the gateway. If you check /info there is a counter for uplinks that will change if packets are forwarded.
The console will show traffic for all applications (data is encrypted so of no use) and all networks, not only TTN packets,
Keep in mind the gateway does not run Linux or any other full blown OS, so ssh would not get you anything useful.
Wow, thanks. I had just been looking for signs of transmissions within the application’s data page and the particular device’s data page, neither of which show any sign of activity for the particular device.
But thanks to your suggestion, I am now seeing transmissions from the device when I look at the Gateway traffic page.
The fact that I see traffic there but not in the application and device data pages, does that indicate that the packets are being discarded by the handler/server/broker? Is there something I might do to try to fix that?
Packets showing at gateway but not application level means the packets are not deemed to be for your application. Probably the (physical) node EUI/DevID/keys do not match with those registered in the console.
2 posts were merged into an existing topic: Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?
With the node indoor under the roof I measured RSSI’s of around -114 dBm with an SNR of -5 tot -8 dB at distances of up to max. 560 m (with Aurel 868 antenna,).
I have now stuck the antenna out of a window on the second floor and measured -121 dBm with an SNR of -8 at 560 m. Unfortunately the antenna is not in the optimal orientation in the current position, I’ll see if I can mount it upright and take some more measurements.
Guys I’m sorry to say that we’ve had enough of the lack of updates and/or the fact that gateways that we waited patiently for that had delay after delay have been DOA and/or fit for purpose and at the risk of getting/receiving personal attacks for the community on this forum regards this very frustrating situation and the lack of progress, myself along with the local community members will be withdrawing for the lorawan TheThingsNetwork and will be communicating to our followers that the hardware/software at this time is highly unstable and not able to be used is any proof of concept or design.
We had hoped that a device of this nature with certification and the assurance that delays had been incurred for design/quality that device received would work? We in the Newcastle upon Tyne community still would like to understand why devices that have issues are still shipping and why device shipment has not been suspended and/or failing hardware has not been recalled?
NOTE: failing hardware is hardware that has never shown the Lora card and not hardware with the reboot
I had the chance to compare two TTN 915 MHz gateways, one working and one DOA with the reboot issue. Both have the same 1635D4 LoRa module connector. Replacing the module in the connector did not help getting the defective unit to function.
Hope this is helpful information for the TTN team.
@abaretta I have tested a TTN gateway with poor range at a different location and got much better results. Up to 7 km with the standard antenna indoors. The TTN gateway compares in range with a Multitech Conduit, both tested at the same location.
Great work, @Vinduino! Can you please add those details to https://github.com/TheThingsProducts/gateway/issues/1?
Done 
You’re referring to re-seating the very same module, right?
Hi Graham,
I am not related to TTN in any way, but my personal opinion is that anyone in the same position as you (DOA gateways) should now “write off” the equipment and buy another gateway (Laird gateway?).
That way you can draw a line under the cr*p feelings and move on to the good stuff (integrations / apps etc).
Don’t bin the DOA gateway though , sell it, (I’d be happy to buy it for £100 and take a gamble it will get fixed one day- LMK by private message).
At the moment you are (quite rightly) fixating on a broken gateway and the indifference being shown. Just look at it as other priorities getting in the way and its not personal.
Once you have a working gateway, you’ll be happier that the priorities are where they are - on growing the concept and backend network.
Yes I know it sucks to do it - but don’t throw the baby out with the bathwater.
Hope you stay mate - there good stuff to do and a lot of features haven’t been delivered yet - still to be seen IMO
Hi Reinier,
Thanks for the feedback. Were you by any chance also able to test the reverse, ie. the Conduit in the location in which the TTN gateway didn’t perform?
Do you think the issue may be related to interference/noise? I guess a relevant question is whether the TTN gateway is more susceptible to interference than other gateways?
I am planning to buy an outdoor gateway, once I have it I will be able to make a similar comparison.