Uplink System For High-Altitude Balloons

Most uses of high-altitude balloons are fairly simple: send balloon up, have it beam down measurements and images. While this is indeed straightforward, it is also very limiting. This is why [Dave Akerman] has been working on adding to the HAB balloons he regularly flies. This builds on the work [Dave] did back in 2015 with adding LoRa transceiver RF communication.

Since LoRa transceivers are by definition capable of bidirectional communication, this was very useful for adding simple but essential features such as retransmission of data in case e.g. part of some image or telemetry data is missing. Other interesting things one can do with bidirectional transmission include controlling individual balloons, and having them transmit or relay information between balloons.

A tricky thing which [Dave] describes in the blog post is making sure that both ends of the connection are actually listening using timing settings. The use of encryption is also strongly recommended, unless you want to risk someone hijacking your balloons. This has now all been implemented in the HAB Explora app for Android, as well as the application for Windows.

Header image: Antonino Vara, CC BY 4.0.

10 thoughts on “Uplink System For High-Altitude Balloons

  1. The use of encryption isn’t absolutely necessary to keep folks from “hijacking your baloons”. A command sent entirely in the clear, with a digital signature, would work every bit as well. This is the solution I recommend for Amateur Radio links, where there are rules against obscuring the meaning of a transmission. We generally want to keep encryption off of the ham bands, because ham radio is self-policing and you can’t self-police transmissions you can’t copy.

    In truth, I doubt anyone cares to hijack your balloon. But this is a bit more of a possibility for space satellites. FCC added a rule allowing encryption of control transmissions for them, back in the days when AMSAT built the controller out of discrete logic chips and used exclusive-OR with a constant to obscure the commands. They had no onboard firmware at all, and could boot the computer from a hardware radio modem. These days we have smarter equipment, and encryption isn’t strictly necessary.

    1. Bruce, what would stop someone from listening in on the transmission, copying the digital signature and rebroadcasting with their instruction, that is, if anyone cared enough to try it?

      1. Signatures usually include a checksum of the message, or else it would be useless. That said, a replay attack is still possible, unless you also include a timestamp and have a time limit on messages… But then things are starting to get complicated on the other end as well.

      2. Depending on the number of critical and/or locked commands, this sounds like the perfect application for simple predefined challenge/response key pairs.

        Plus, if I sent a “cut-down balloon” command, it’s only good for one event anyway. So a replay attack would, if anything, help if the balloon didn’t hear me the first time.

        Source: been here, done this. though the up-link was DTMF ;)

        1. Thanks, Just thinking of the upcoming Revere Aerial Mesh Recon and Operational Decision system (RAMROD) and the adversary counters by listening in and sending the ‘cut-down all’ command, fiction but fun. Maybe for the next Jane Bond flick.

      3. Look at how TLS does it. You verify ownership of the key by asking for some new data to be signed with the key. If you’re not negotiating a cypher suite on the fly like TLS it can just be a random number or time stamp sent in the clear to the signing party instead of the whole session startup.

      4. Replay attacks are why protocol design is such a nightmare. You have to keep track of the most recent timestamp and reject older messages. But then you need to get the initial timestamp sync. And unless you have a trusted clock, you generally have to use challenge response.

        My Mega Quarantine Project was an open encrypted protocol called SG1, and it took WAY too much time. Everything network related always seems to need tons of autonomy to be able to get it’s own sync back on track if connections get lost.

    2. Cool! The pure TTL circuits always fascinated me. It’s a bit like an old NES/Famicom that can slightly glitch sometimes, which makes things more life like, IMHO. ;)

      Speaking of the encryption thing – I guess this is why Amateur Radio Service and Amateur Satellite Service are two different services.
      That way, exceptions and special rules can be applied in a sane way without messing things up. :)

    3. “Amateur Radio links, where there are rules against obscuring the meaning of a transmission”

      So use a 915MHz LoRa, not one of the ones in the 70cm ham band? A smaller gain antenna would be a further benefit.

  2. You can take over my balloon if you want but you might be surprised just how many command codes translate to “navigate directly over source of transmission then release ballast”!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.