Monitor SpaceX Rocket Launches With Software-Defined Radio

The amateur radio community has exploded with activity lately especially in the software-defined radio (SDR) area since it was found that a small inexpensive TV tuner could be wrangled to do what only expensive equipment was able to do before. One common build with these cards is monitoring air traffic, which send data about their flights out in packets over the radio and can easily be received and decoded now. It turns out another type of vehicle, SpaceX’s Falcon 9 spacecraft, reports data via radio as well and with some slightly upgraded hardware it’s possible to “listen in” to these flights in a similar way.

Reddit users [derekcz] and [Xerbot] used a HackRF module to listen in to the Falcon 9’s data transmissions during its latest launch. While the HackRF is a much more expensive piece of equipment compared to the RTL-SDR dongles used to listen in on aircraft, it is much more capable as well, with a range from 1 MHz to 6 GHz. Using this SDR peripheral as well as a 1.2 m repurposed satellite dish, the duo were able to intercept the radio transmissions from the in-flight rocket. From there, they were recorded with GNU Radio, converted into binary data, and then translated into text.

It seems as though the data feed included a number of different elements including time, location information, and other real-time data about the rocket’s flight. It’s a great build that demonstrates the wide appeal of software-defined radio, and if you want to get started it’s pretty easy to grab a much cheaper dongle and use it for all kinds of applications like this. Go check out [Tom Nardi]’s piece on the last seven years of RTL-SDR to get caught up to speed.

Thanks to [Adrian] for the tip!

15 thoughts on “Monitor SpaceX Rocket Launches With Software-Defined Radio

    1. Adding encryption typically adds a delay, and for real time telemetry, any avoidable delay is typically avoided.

      There is no FCC requirement for a license that require the telemetry, tracking, or even command communications to be encrypted!

    2. There are three parts to the subject of telemetry and encryption in flight systems; Tracking, Telemetry, and Control (TT&C). What follows is how I think SpaceX should handle this subject:

      1. Tracking

      SpaceX: Do not encrypt downlink telemetry. More observers are better. Less delay is better. In the Red/Black Paradigm [1] the downlink telemetry is Red or Plaintext (PT).

      You track the flight both actively (e.g. motorized antenna with a monopulse tracking feed and beacon/telemetry receiver), and passively (e.g. tracking-recording telephotographic camera pre-programmed to follow the expected flight path).

      Unless you are working with systems that mandate secrecy (e.g. you need to hide the data because it is unique and proprietary and/or you need to make it harder for your enemy to attack your asset), there is no reason to do encryption hampering anyone from obtaining flight downlink data. In-fact the opposite is true; more observers sharing their data provides redundancy and increased perspective and/or resolution. Encryption introduces delay in the data stream. Generally, delay is undesirable in real-time telemetry systems.

      2. Telemetry

      SpaceX: Do not encrypt the downlink telemetry. Like with Tracking, more observers are better and less delay is better. The downlink telemetry is Red or Plaintext (PT).

      3. Control

      SpaceX: Always encrypt the uplink control telemetry. In the Red/Black Paradigm the uplink telemetry is Black or Cyphertext (CT).

      You never want more than one authoritative system controller. Fully redundant system controllers are OK provided they are deterministically identical and only one is active at any given time.

      Quasi-redundant controllers (controllers that may have different opinions of the future system state) are OK provided there is a single authoritative arbiter (i.e. decision maker) that decides who should be in control at any given time. With quasi-redundant controller systems, Kalman Filters [2] are often used to provide predictions of the future system state to the arbiter.

      * References:

      1. Red/Black Concept

      2. Kalman Filter

  1. I wonder if there is also a transmission from the groundstation towards the rocket and if so: what commands are sent to the rocket and what encryption might be used for its packets to prevent others from tampering with the rocket. How long until a rocket is captured and crashed due to tampering with the telemetrics?

    1. It would be odd if ground to rocket commands weren’t encrypted or at least signed.

      Rocket to ground doesn’t have to be encrypted as getting into a position to spoof data traffic captured by multiple directional antennas pointing to the sky, isn’t exactly easy.

    2. I can’t recall where I read this, but I recently ran across a description of the entire uplink data stream. It’s one command, unencrypted, sent over and over:

      “Don’t blow up.”
      “Don’t blow up.”
      “Don’t blow up.”

      If the flight termination system stops receiving that, the rocket blows itself up. Once the rocket starts moving, the rest of the flight control is entirely autonomous (including all the other reasons the rocket can decide to blow itself up). They don’t give a damn about trying to encrypt it, because nobody else stands a chance of transmitting louder than them (and if you tried, you’d get some very pointed questions about the massive parabolic dish you were building near Cape Canaveral).

  2. I wonder if the telemetry includes readings from the landing ,then the premature relaunch and explosion shortly after that. :^) Thank you Mr. Musk, I can only hope I live long enough to see you and your people start asteroid mining. I can dream.

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.