My next flight (depending on wind predictions) will be to try to relay a chat session between 2 remote locations (one in Northern Ireland the other in England) via 2 balloons one launched at each location, with all communications via LoRa transceivers, something that is impossible without relaying because of lack of line-of-sight:
LoRa Possibilities
I’ve previously used LoRa to repeat telemetry between balloons, but all (3) balloons were fairly close to each other having been launched at the same location albeit with 30-60 minute gaps. I’ve also used it to provide a bidirectional data link with a Telnet-like terminal program on the ground and a Telnet server at the balloon. So this flight extends these ideas, greatly increasing the distances involved and having data from the ground relay via both balloons and down to a remote ground location.
TDM
As with both of those flights, all trackers and gateways will use the same frequency, taking turns to transmit. For my Telnet flight I used the gateway uplink to tell the tracker when it coulld transmit, but with 2 gateways and 2 trackers that’s not the best plan, so instead (and like the 3-balloon repeating flight) I used Time Division Multiplexing with the trackers using their GPS receiver for timing. Time slots are static and written into the code for each tracker; during non-Tx periods, each tracker listens for packets from other trackers and from the gateways.
I set the frame time to 6 seconds, which conveniently divides exactly into 1 minute and gives an acceptable total transmission time from one gateway to the other and back again, making the system responsive enough for use. The slot allocation is as follows:
- Tracker 1 sends short sync packet; gateway 1 responds with uplink
- Tracker 1 normal transmission (including uplinked chat text if present)
- Tracker 2 repeats Tracker 1 transmission
- Tracker 2 sends short sync packet; gateway 2 responds with uplink
- Tracker 2 normal transmission (including uplinked chat text if present)
- Tracker 1 repeats Tracker 2 transmission
Here’s the system shown in an SDR waterfall:
The yellow packets (lower power) are from my gateways which currently have no aerials connected.
As you can see, the channel utilisation is quite high, and of course it gets higher when chat messages are being sent. The available time slots limit each chat message to 40 characters before signals start to overlap; I’ve set a max of 32 characters for this flight.
Comms Protocol
Messages entered at the terminal program are queued within the program, and then passed to the gateway when it is ready (i.e. when it knows that the previous message has been received at the remote location). The gateway then sends the message to its own balloon, which includes the message in its regular transmission, which is then received and repeated by the remote tracker and then received by the remote gateway. Messages are acknowledged when they have made the full journey, and this acknowledgement than follows the reverse route.
The system copes with any missed packets, retrying until acknowledgement is received.
Chatty Man
Each chat terminal queues up its own messages (marked with a “-” when queued, “*” when in transit), and shows messages received from the other side:
Each gateway broadcasts transmitted and received messages on its local network, where they are received by a “web feeder” program which forwards them to a server program. This web feeder is generic, receiving UDP packets from several ports and forwarding them to the web server. As you can see, that includes packets from my weather station so that I can show local weather data on launch dashboards (for furture flights, not this one):
The server is a small Delphi program running under Ubuntu in an Amazon EC2 instance (I can’t run a server from home as I don’t currently have a public IP address because we’re now using a NATted 4G connection). That web server then feeds the data to browsers running a web dashboard, which looks like this:
You can see a short video of the web app in operation here; note the green/blue highlights showing when normal/repeated transmissions have been received from the trackers, and when the gateways are uplinking:
Note: The web app has changed design since the testing.
Here’s a video showing how the chat works in real time: