TTN GATEWAY central 3

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.

I have:

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!

But …

  1. 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?

  2. 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’ ?

1 Like

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.

1 Like

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.

1 Like

Whooho :upside_down_face:

not that I know

select “Automatically update gateway” in TTN Console

you’d need to request an automatic invite on

Did you check the documentation and github site for this device? There you’ll find information on SD card updates.

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?

Does The Things Gateway implement the full US sub-band 2? (channels 8-15 + 65?)

I am trying to figure out why my gateway only appears to receive even frame upload packets from a OneThinx module and OneThinx thought the gateway might not implement channel 65. (I looked at the source from the last time I built the gateway firmware (1.0.5) and it looks like it implements 8+1 channels (8-15 & 65):

       SYS_DEBUG(SYS_ERROR_WARNING, "LORA: use default US config\r\n");
        status = status && configureRXChain(0, 1, 904200000);
        status = status && configureRXChain(1, 1, 905000000);
        status = status && configureIFChainX(0, 1, 0, -300000);
        status = status && configureIFChainX(1, 1, 0, -100000);
        status = status && configureIFChainX(2, 1, 0, 100000);
        status = status && configureIFChainX(3, 1, 0, 300000);
        status = status && configureIFChainX(4, 1, 1, -300000);
        status = status && configureIFChainX(5, 1, 1, -100000);
        status = status && configureIFChainX(6, 1, 1, 100000);
        status = status && configureIFChainX(7, 1, 1, 300000);
        status = status && configureIFChain8(1, 0, 400000, 500000, 8);
        status = status && configureIFChain9(0, 0, 0, 0, 0);

(Hoping someone can save me from having to go through the pain of building a debug image of the 1.0.7 firmware so I can poke around. :wink: )

Thanks, Scott.

I also got the 915 The Things Network Gateway and was looking for any work around to get that Gateway working with US ranges (but in India) just for the test purpose.
Please note: I do not want to connect any India specific LoRa devices to this Gateway. I already have 1 US based LoRa device which I can connect to this Gateway for my test.

By looking at other posts related to the Gateway setup and the India specific bands. I don’t think whatever I am trying is possible but still I am looking for some workaround to get 915 TTN activated and solve my test purpose.

Thanks in advance.

you probably need a hardware modification … if you really need to test another frequency band, best to import a gateway for that specific band imho.

Is there someone still experiencing reconnect issues? I want my gateway connected via WiFi and I was able to make some improvements in the firmware so I went from this:
to this:

Here is my current branch:

I can also provide firmware images if someone is interrested.
There are still some minor issues but it is at least acceptable now.

I’ve also created a esp8266 firmware which captures logs on TTNGW and sends them to my syslog so I have all logs stored on my server like this:
Sep 29 06:50:55 MON: heap usage: 280KB (284KB), free: 58KB
Sep 29 06:50:59 MQTT: Sending status packet
Sep 29 06:51:01 MQTT: Sending status failed
Sep 29 06:51:01 MAIN: MQTT error
Sep 29 06:51:01 MAIN: Leaving state 5
Sep 29 06:51:04 MAIN: Entering state 6
Sep 29 06:51:04 INET: State change to 0
Sep 29 06:51:04 INET: Gateway has WiFi
Sep 29 06:51:04 INET: State change to 2
Sep 29 06:51:04 INET: Connected to a network, waiting for DHCP lease, checking validity with ping
Sep 29 06:51:05 INET: State change to 3
Sep 29 06:51:05 INET: Ping probe
Sep 29 06:51:05 INET: Error sending probe on Eth
Sep 29 06:51:05 INET: Ping response from MRF24WN, set as default
Sep 29 06:51:05 INET: State change to 5
Sep 29 06:51:05 MAIN: Leaving state 6
Sep 29 06:51:05 MAIN: Entering state 5
Sep 29 06:51:05 MQTT: GOT IP:
Sep 29 06:51:05 MQTT: !NET_PRES_SocketIsConnected
Sep 29 06:51:05 MQTT: !NET_PRES_SocketIsConnected
Sep 29 06:51:05 MQTT: message repeated 23 times: [ !NET_PRES_SocketIsConnected]
Sep 29 06:51:05 MON: SYS Stack size: 2833
Sep 29 06:51:05 MON: TCPIP Stack size: 3581
Sep 29 06:51:05 MON: APP Stack size: 2213
Sep 29 06:51:05 MON: LoRa Stack size: 3877
Sep 29 06:51:05 MON: heap usage: 191KB (284KB), free: 148KB
Sep 29 06:51:05 MQTT: !NET_PRES_SocketIsConnected
Sep 29 06:51:05 MQTT: message repeated 7 times: [ !NET_PRES_SocketIsConnected]
Sep 29 06:51:05 MQTT: NET_PRES_SocketWasReset
Sep 29 06:51:05 MQTT: Connection Opened: Starting TLS Negotiation
Sep 29 06:51:05 MQTT: Wait for SSL Connect
Sep 29 06:51:06 MQTT: TLS ready: Connect MQTT
Sep 29 06:51:06 RQLORA: Kick LoRa module with ACK after not acked it for 60s
Sep 29 06:51:06 MQTT: Connected
Sep 29 06:51:06 *************************
Sep 29 06:51:06 MAIN: Gateway bridging
Sep 29 06:51:06 *************************
Sep 29 06:51:15 MON: SYS Stack size: 2833
Sep 29 06:51:15 MON: TCPIP Stack size: 3581
Sep 29 06:51:15 MON: APP Stack size: 2213
Sep 29 06:51:15 MON: LoRa Stack size: 3877
Sep 29 06:51:15 MON: heap usage: 280KB (284KB), free: 58KB
Sep 29 06:51:25 MON: SYS Stack size: 2833
Sep 29 06:51:25 MON: TCPIP Stack size: 3581
Sep 29 06:51:25 MON: APP Stack size: 2213
Sep 29 06:51:25 MON: LoRa Stack size: 3877
Sep 29 06:51:25 MON: heap usage: 280KB (284KB), free: 58KB
Sep 29 06:51:28 MQTT: Sending status packet
Sep 29 06:51:28 MQTT: Report config error: 0600000020
Sep 29 06:51:29 MQTT: Sending status succeeded: 1176


Hi, Great work! It is the first serious attempt outside TTI and Tweetonig I know to improve this firmware. Thank you. As I cannot compile myself I am happy to test and share my experience.

1 Like

Ok guys, here is the latest compiled version for you to try:

Upgrade the usual way: FAT formated SD card with folder “update” and these files in.