Update September 2017: development is on hold; see below.
After a couple of weeks of silent beta testing, we’re happy to present to you our new TTN packet forwarder. It’s now publicly available on Github. The current version is v2.0.1, and v2.0.2 is expected to be released in the coming days.
Please visit our Github page to download the packet forwarder. We have detailed manuals for Raspberry Pis, Kerlink IoT Stations and Multitech Conduits. Also, there is documentation available on how to use the packet forwarder for other gateways.
For those who aren’t familiar with the concept, the packet forwarder is a piece of software that is installed on LoRa gateways. It interfaces with the LoRa concentrator to pull and push packets, while interacting at the same time with the network server.
There are a couple of reasons for building a new packet forwarder:
On the technical side: Most of the packet forwarders are derived from the original Semtech packet forwarder, which is written in C. The C language has a lot of benefits (we won’t try to start a language war here), but it’s hard to deal with C when you’re used to program in higher-level languages.
Our network server codebase is entirely written in Go. Go is a compiled language, which generates binaries for stripped-down Linux distributions (very easily, actually), like most gateways. Using Go means that everyone who contributed to the network can now contribute to the packet forwarder. Using a lighter language also gives us more agility to develop new features, and to adapt this packet forwarder to new gateways and chips that will come along - the design takes into account incoming evolutions to LoRa concentrators.
On the configuration side: Even after ordering and receiving a gateway, the configuration process of a gateway can be challenging. It can also be hard to troubleshoot issues when they arise. We want to make the packet forwarder setup and maintenance easier. The new packet forwarder includes, for Kerlink IoT Station, Multitech Conduit and Raspberry Pis, builds and packaging scripts. We’ll soon be rolling out other features in the console that will make it even more easier to set up a gateway.
On the features side: This new packet forwarder connects using our new gateway protocol. The old Semtech protocol was unsafe (UDP protocol, so didn’t guarantee packet delivery) and not encrypted. The new protocol uses a TCP connection, with native TLS encryption. This means another layer of protection and better troubleshooting. The packet forwarder also implements a JIT queue for the downlinks, leading to a better downlink delivery rate.
There is some confusion arising from old documentation that’s about the old packet forwarder, but that is now linking to the new packet forwarder (since we’re using the same repo as before). If you see any situation like this, feel free to fix it or to point it out!
Just like for the network server, given that it is publicly available on GitHub, this means that you can fork it, and make contributions to it. It can be because you’d like to add a new feature, or because you’ve noticed a bug, or because you’d like to build it for a new kind of gateway…
I want to contribute, but…
I don’t know Go: Go is a language that’s easy to learn. It’s compiled, strongly typed, gives a lot of importance to error handling and to code clarity. If you’ve done some C/C++ programming, you’ll feel right at home. If you’re coming from more higher-level languages, the transition will be smooth. You can start developing just after a few hours of tutorials. The Golang official website has resources that will get you started in no time.
I don’t know where to start: The list of issues and of features planned for the packet forwarder is publicly available on Github. We recommend keeping an eye on the easy label, that has usually accessible issues, and can give some good insight on how the code is conceived!
At the moment I’m writing this, these issues can be interesting for whoever wants to contribute:
- Explore Docker deployment for the packet forwarder (especially if you have a Raspberry Pi-based gateway): more ops-related ; if this leads to an implementation, it would be very useful to Raspberry Pi-based gateway owners.
- Sending temperature in the status message: very accessible issue if you’d like to get your feet wet!
- Better network recovery: this is an interesting issue for anyone who would like to know more on how the network connection with TTN is implemented.
For those willing to discuss the packet forwarder, feel free to do so here, or to join the #gateways channel on Slack!
(If you’re not using Slack yet, get an invite through https://account.thethingsnetwork.org)