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
5 Likes
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.
- I exchanged the LoRa module in both gateways, and found that the issue swaps with the Microchip LG9271 LoRa module. The defective gateway works after placing the LG9271 from the working gateway.
- Previously I was not able to update the firmware using an SD card on the DOA gateway. After inserting the LoRa module from the functioning gateway, the firmware updated to 1.0.1.
- On the working LoRa module the SX1301 chip is running hot (69C), the microchip PIC is 52C. This is normal according to @nestorayuso. On the defective LoRa module the chip temperatures are much lower.
Hope this is helpful information for the TTN team.
5 Likes
@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.
1 Like
Great work, @Vinduino! Can you please add those details to https://github.com/TheThingsProducts/gateway/issues/1?
Done 
1 Like
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
1 Like
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.
wondering if this could be a sign of incorrect voltage getting supplied to the card circuit ? when hot = correct voltage and cool = low voltage aka brownout ?
has anyone done a voltage check on the faulty cards?
If there are people here who happen to have a Microchip PIC Programmer, please help the @TTP guys test a possible fix to (at least some of) the reboot issues. See https://github.com/TheThingsProducts/gateway/issues/1#issuecomment-372331395
yes, this is want I will be doing and TBH I’m now contemplating not even trusting TTN ecosystem has a communication backend and looking at other options where the LoRaWan gateway is running something simple yet more flexible in terms of design and implementation using Microsoft IoT Edge concepts
IMHO this is yet another kickstarter project that has made promise after promise suffered delay after delay and now has shipped items that don’t deliver anything near the vision stated.
TBH I’d love to see the numbers, gateways infield, active/inactive packet/message sent/received uptime/downtime. % gateways issues
Thanks for you kind offer, but it simply doesn’t feel right for me to take money for something isn’t working (unlike this project) but if you’d be willing to donate to the teenage cancer trust I’d happily give the gateway to you.
Fortunately my gateway and my nodes run very smooth and without any problems. Also I do not care about the design and implementation, for me as an end user this stuff must just work like my toaster does.But I can well understand your frustration. I assume that you asked for refund or replament and shipping of tested replacement gateways. What was your experience concerning refund/replacement?
I’ve asked for a replacement but got no reply, I’ve no even been offered an alternative or any options? IF I WERE offered an exchange it would go along way to MY BIGGEST issue which is that I’ve waited and waited for this and got a faulty device and have NO way of progressing to resolve this problem other that the forums and all they seem to suggest is that it is a reboot issue?
TBH I’d possibly be happy with the reboot issue, at least I would be getting updates on progress of a fix? but my gateway looks to have been a DOA showing ND for the card from day one?
FYI just order 5 of these packages http://sandboxelectronics.com/?product=lorago-port-multi-channel-lorawan-gateway&gclid=EAIaIQobChMIs9jNo5bn2QIVrLDtCh2KCAoFEAAYASAAEgKe5fD_BwE