While i can.
I hate car comparisons. But you started: I have a usable camper trailer but the towing car is no more usable and will be replaced. Or technically: The TTN Kickstarter Gateway is simply not state of the art. Never was. The geeky community gives much love on Raspberry Pi’s as base for their LoRa Gateway. Nobody forked TTN GW code for good. Open sourced code from TTN KS GW has zero evolved. Now there is an update where only a expiring certificate will be replaced. With a RPi i can disable WLAN, i can add PoE,i have a console, a Firewall, IPv6, can do crypto, use VLAN and and and… Like the Multitech Gateway i owned long before the TTN GW was delivered. That’s it.
While i can.
But to give it some credit, the kickstarter campaign success took a lot of companies by surprise and made them take notice of a market segment they hadn’t noticed before.
A shame the gateway took too long to get to ‘market’ and is more or less a technical dead end due to the technologies used. Too much embedded knowledge required to build and improve the code where there are easier and cheaper options available.
Purchased a RAK… Here goes nothing…
In one of our ‘The Things gateways’ -that does not pass the stage of 1 led lit and the second one blinking fast- we see the following serial debug output “dump” (see below)
We are wondering if someone can tell what the “DRV PHY init failed” means, since this seems to be different from all dumps seen before. Looking for similar things on google leads to believe it is something to do with the ethernet chip.
Can anyone give a tip/answer/solution?
We did in the mean time successfully reprogram the PIC32 using MPLAB IPE and a PICkit 3, but that did not help…
after running fine from day one (dec’17) my gateway seems to have issues for no obvious reason nor clear indication on ui-side. it’s shown ‘not connected’ in TTN-console since two days. all LEDs are lit up as usual, /info showing this:
uptime counting up (just powercycled), and even ‘packets up’ is increasing if i’m sending something - where the real strangeness starts:
i can see the packet in the device’s data-stream in console, but not in the gateway’s traffic.
since firmware was last updated in may i assume it must be something on the stack side that changed more recently.
one thing that might be worth mentioning: the gateway’s got a 5 character long ID which was possible to assign back in the days - now it seems to be asking for 6+. but since there was no reason to reset so far it’s still that way.
I’ve put off my TTN gw off from the original box, hoping now it works, seems to be updated to 1.0.7 firmware and I have 2 questions:
- is the reboot loop definitively solved? was just a software issue?
- what’s the difference between to bootloader V1 and V2? Do I need to update to V2?
Hello, I’ve been reading posts for a few hours and feel like I’m better understanding the issues surrounding TTN Gateway … and I’m still a little lost. I have a few questions I’m having trouble finding answers for.
Version Info Hardware: v1 Bootloader: r1-7167873a (2017-06-02T13:48:18Z) Firmware: v1.0.0-917719b9 (2017-06-26T17:59:33Z)
I finally got around to booting it up and it connected to Ethernet and showed up on my console immediately! Woohoo!
Is there a Wiki someplace where I can find all of the “pages” available on the device from my local network? Reading various posts I found: http://things-gateway.local/info Are there more?
I see people talking about firmware updates - and obviously mine needs an update - but I’m not seeing a Wiki page or specific instructions on how to force the OTA update they claim exists. Or is my firmware too old to support the OTA? And if I have to use the SD card, where is the Wiki page that explains the process?
I’m fully aware - now - that this is not a real heavy duty gateway, and seems to only sort of work. Seems like most people are moving to other - better supported - solutions. I do want to get the most out of what I have here first, and then move forward to explore what I’ll want to upgrade to.
Thanks in advance.
BTW … how do I get invited to the Slack channel?
I have installed this gateway, which is connected to TTN and fully working properly with my “The Things Node” and test Sketch and also my Raspberry Pi HAT with test python program.
I then fitted an outdoor antenna high on the roof - a Delock Lora 868 omnidirectional antenna fed via about 10 metres of 50 ohm coax.
You can see it perched on the left of the TV aerial.
The gateway continues to work but, having taken the TTN Node for a few local trips, I am most disappointed with the range. Even when I hold the node in my hand, with almost clear “line of sight” to the gateway, the signal strength fades right out beyond a few hundred metres.
OK - it is in an “urban environment” - but LoRa was touted as working over “kilometers” in an urban environment.
Is there a way that I can benchmark test whether the gateway is “getting out” as it should with this external antenna arrangement?
I would be more than happy to provide the gateway ID (suburb of London, England) so that a third party can test access and confirm it is behaving as prescribed.
Any comments or assistance greatly appreciated.
What brand and type of antenna cable did you use? Cheap cable or mismatched cable will result in huge signal losses.
And you will find lots of evidence that this is indeed the case.
But urban areas are tricky, the range can vary significantly from one urban area to another, so just because some people get ‘kilometers’ in an urban area there is no guarantee that everyone will, such are the vagries of UHF propagation.
The only practical method I can think of to benchmark a gateways RF performance is to measure it under open field line of sight conditions, i.e. take it away from an urban environment.
Perhaps you could provide some more details of what ‘almost clear “line of sight”’ is and what is ‘a few hundred metres’ ?
Thank you for your reply.
The antenna cable is a 15m Panorama Antennas CS29 “ultra low loss” cable with pre-manufactured connectors at both ends:
The antenna itself is a Delock LoRa 868 MHz Antenna N plug 2.09 dBi
Hitherto, this same cable (in the same place, even with the same LoRa antenna) has been used to receive ADSB aircraft transponder signals at 1090MHz and has exhibited very good sensitivity (I have picked up signals 200 miles away at 40,000 feet)
I just wanted to check that the TTN Gateway can be used with such an external antenna and whether anyone runs it that way and what results can be expected.
Thank you for your reply.
I will try and provide a more scientific reading.
My “The Things Node” has a Sketch that transmits every 10 minutes so I can read off the RSSI reading using Cayenne. It reads -78 dBm when the node is in the “around the house” and (when it stops raining) I will eyeball the furthest spot I can SEE from where the antenna is and go there to see if the Node will connect literally line of sight. I am on the side of a hill, so that should not be difficult.
I will then post the results (including the exact distance) here.
I may try several places, and I appreciate that the presence of nearby buildings and RF interference may have a detrimental effect.
Of interest to me would be to know if there is any kind of benchmark that can be used.
TTN’s objective as an organisation is (among others) to encourage individuals and companies to deploy gateways in as many optimum locations and configurations as possible. To that end, such individuals would benefit from being able to verify that they have deployed more than a parrot perch!
I mentioned that earlier;
> The only practical method I can think of to benchmark a gateways RF performance is to measure it under open field line of sight conditions, i.e. take it away from an urban environment.
Whilst that sort of testing is actually quite easy and some of the techniques I use are discussed here;
Its way to much work for a lot of people.
Similar comparisions in ‘urban’ areas are quite difficult. The diference in reception distance between true line of sight conditions and what you get in ‘urban’ areas can be vast, 1200:1 or ever more. The implication is that variations between one urban area and another can be significant.
The only alterantive I can think of is if people would first post data and pictures of their gateway locations and setups. Then post pictures from locations looking towards the gateways together with the reception results from the nodes. At least then you have a photo guide to typical scenarios.
I would suggest the TTN antenna’s location relative to the TV antenna is going have a huge influence on its performance. It looks like the active part of the antenna is about the same height as the TV antenna and as a result the radiation pattern of the TTN antenna will no longer be uniform in all directions but distorted and directional. In comparison, the antenna to the right of the TV antenna would work correctly as it’s above the TV antenna.
To explain: if you look closely at the TV antenna you will see the cable is connected to 2 or 3 of the metal elements on the TV antenna (driven elements), the rest of the metal elements are passive. However they have the correct length and location to interact with driven elements to achieve a highly directional pattern to improve the performance of the television.
Now back to the TTN antenna: The TV antenna is going to act as Passive Elements to the TTN antenna and influence its radiation pattern. I realise the distance between the two is quite a few wavelengths and at that distance a single upright pole (like the pole that supports the TV antenna) has very little effect, however the TV antenna is large and will influence the performance of the TTN antenna.
When you conduct your “line of sight tests”, see if you can repeat this in a number of directions and see if you observe the gain is different for each direction.
not that I know
select “Automatically update gateway” in TTN Console
you’d need to request an automatic invite on https://account.thethingsnetwork.org
Hello! Thank you for the reply!
Yes … I read everything on the “documentation” link that you provided, and it only shows someone programming the gateway using a hardware programmer. Yet when I read elsewhere, it says that the gateways are automatically updated via OTA. Mine, after numerous reboots, and days of operation has not been updated. How is the OTA triggered?
I also looked on Github, and read there the README in the firmware directory where, again, it states: “Installing the firmware is usually done using over-the-air updates from our official releases. Here are the steps to install custom firmware:”
So … is there somewhere explaining that I need to do the SD Card update and that OTA is not working?
Thank you for the response!
My gateway recently updated automatically so OTA is certainly working. However there has been an updated firmware with an update for certificates some time ago that might (I didn’t look into it to check) have some impact on the ability to update over the air.
I would suggest you use the SD card mechanism to update to a recent (last 2 months) firmware and see what happens when a new version is released.
Make sure you have ‘Automatically update gateway’ checked in the gateway settings.
Ok … that seemed to work and get me closer! I’m now at v1.06?
Version Info Hardware: v1 Bootloader: r1-7167873a (2017-06-02T13:48:18Z) Firmware: v1.0.6-d8cb4c30 (2019-05-17T07:19:39Z)
Are most people running the “Beta” version to get to v1.0.7?
Also … as a side note …
When booting WITHOUT the SD Card in place, my gateway seems to sit FOREVER and doesn’t appear to want to connect to the Ethernet. (No lights on my hub)
When booting WITH the SD Card in place, my gateway boots immediately, and connects the Ethernet and is off and running.
Ideas on why?