TTNHABBridge

Project TTNHABBridge
A software bridge between TTN and the HAB network
Status	In progress
Contact	bertrik
Last Update	2017-08-02

Introduction

This idea is about using the-things-network as a receiver for amateur balloon telemetry.

Receiving telemetry from amateur balloons is currently typically done on the 434 MHz band using RTTY modulation, where dedicated receivers listen for ASCII strings. The operator of each receiver has to prepare his radio setup for receiving the telemetry, by tuning to the correct frequency at the correct time, setting up a dedicated software client that decodes the RTTY modulation and forwards the data to a central system over the internet. The central system accepts data from many such receivers, performs deduplication, keeps track of who received what and updates a nice graphical map of where each balloon is and where the receivers are.

A network like the-things-network can help a lot, it has a lot of gateways already (in the netherlands at least..), already performs deduplication. Also LoRa as a modulation scheme is much more sensitive than RTTY, is much less susceptible to slight tuning errors than RTTY.

In short, the idea is:

• you attach a LoRaWAN transmitter to the balloon
• the LoRaWAN transmitter is pre-configured with a set of keys generated by the TTN
• the bridge software listens for packets received by the TTN and decodes the payload data into an id, latitude, longitude, altitude of the balloon
• for each packet, we know which gateways received it and where they are. So we can "fake" a client for each gateway and construct an ASCII sentence according to the HAB server conventions
• the HAB server still sees the same messages like it would if there many traditional receivers, so doesn't need any modification.

This way, the entire things network can be used to receive balloon telemetry! There is no longer a need for operators to be present at their receiver at the exact time the balloon is launched, making manual adjustments, etc. The Netherlands is already covered by many TTN gateways, greatly increasing the chance the balloon telemetry will be picked up.

Software

Main process

The main process of the bridge is something like this:

• listen to the MQTT stream of the HAB application
• once we get data:
  • decode the payload into latitude/longitude/altitude, and encode it into a habhub ASCII sentence with correct CRC, see https://ukhas.org.uk/communication:protocol
  • for each gateway that received the data:
    • look up the gateway name/lat/long/alt, through some TTN API (and cache it?)
    • fake a HAB receiver and make it send the ASCII sentence to the habhub server

Tasks

Stuff to do:

• come up with a simple but flexible way to encode telemetry in a binary packet, to be transmitted over TTN.
• figure out how to receive data from TTN, this is an MQTT stream -> pick an easy-to-use Java MQTT client library. Perhaps this one: https://github.com/fusesource/mqtt-client ?
• figure out how to find the coordinates/name of a TTN gateway -> there is no published API for this as far as I understand, alternative: reverse engineer the ttnctl utility?
• figure out the protocol between dl-fldigi and the HAB server -> look into https://github.com/ukhas/habitat-cpp-connector , reverse engineer it and create a Java version. It looks like a couchdb-specific database connection, sending JSON messages!
• implement this (in Java for example)!

Settings

Settings likely needed by the bridge application:

• TTN gateway API settings
  • URL of the TTN gateway API
• TTN MQTT API settings
  • URL of the TTN MQTT API
  • application id of the TTN 'hab' application
  • application username
  • application password
• habitat database settings
  • URL of the habitat server
  • ...