Two Walkie-Talkies

Turn on both walkie-talkies. Tape down the beep button on the one representing the satellite. Now have a friend run around the block as the satellite, and notice when you can and cannot hear the beep.

The range of these walkie-talkies is limited, so you’ll probably find you only hear the beep when your friend is both close and in line of sight (no buildings blocking). It also helps to point the walkie-talkie in their direction.

This illustrates the basics of satellite comm. Everything else is just a fancier way to send more meaningful data than a beep, and to enable you to reply to the satellite. But this exercise does illustrate the core properties we’re dealing with in this book.

Flatsat

Now let’s build a good test setup for prototyping your future satellite build. The key components are a realistic low-powered flatsat or satellite simulator, combined with a laptop-based ground system for doing real data sends and receives. The primary hardware difference between this bench test rig and your eventual final station is primarily in the antenna sizes (small) and transceiver power (not many watts) used in this test rig.

Put simply, add a bigger antenna and more watts in the transmitter, and you may be ready to fly with something similar to the “$50 satellite” Eagle-2 with handheld radio plus the actual satellite, shown here:

Bidirectional Bench Test Hardware

• Arduino with transmitter and receive modules and a simple wire antenna

• Laptop

• SDR dongle attached to an antenna

The Instructables on downloading NOAA satellite images with a laptop is a great start. You can also look up SDR satellites, short for software-defined radio, and find a wealth of always-current articles on this.

Hook up the modules to the Arduino as per these Instructables or BuildCircuit plans. Let’s say you have an Arduino, and a Radiometric transceiver hooked up to the serial lines of the Arduino. Conceptually, a transmitter is identical to a sensor. A sensor (as in Book 3, DIY Instruments for Amateur Space) sends signals that the Arduino converts to digital—either through a protocol like I2C or serial lines, or via the built-in ADCs. Similarly, a transmitter involves the Arduino sending out voltages along the pins expected by the transmitter. Most often, this is via serial lines.

Program the Arduino to send a string like hello world if and only if the receiver gets the string go.

Send the string go from the laptop. Wait for the return message.

If this works, you have a basic working comm system.

Higher Power Licensing

“High power” equals “long range,” so for satellite use, we need high-power solutions. However, you should study the low-power implementations because that is how your test apparatus works. For a given allocated high-power frequency, you can build low-power (unlicensed or commercial) test rigs in your lab for integration and testing. Your high-power licensing is only needed for the main event. I keep coming back to allowed radio frequencies. Your computer’s WiFi router has a specific frequency allocated to it. Your cordless phone has a different frequency, and your smartphone yet another. AM and FM radio stations each have their own little bands of radio frequencies. Meanwhile, broadcast digital TV uses yet another set of frequencies. Airport radar occupies another range of frequencies. The radio spectrum is carved out into different frequency bands and who gets to own or use each band is fiercely negotiated between stakeholders—companies, consumers, emergency services, and amateurs.

The result of all the fighting is that some bands are potentially open for satellite (or drone or hobby or ham) communication, depending on how you plan to share it. For low-power or short-term use, things are easier. Higher power requires more advance preparation and potential licensing.

In this model, though, we are talking about how you get permission for whichever device (ground or satellite) that is transmitting. Just receiving data, it turns out, is easy. Just as you need a license to run a radio music station but anyone can listen, you need a license to run a satellite but anyone can listen to your satellite.

Establishing a Ground Network

You can always receive ANY radio signal without a license. Receiving is passive—you build a box that picks up the signal (see “Are You Receiving Me?”). This means you can use a scanner to listen to police chatter or pirate radio, without fear. More practically, you can (and should!) use your radio gear or laptop plus an SDR to listen to satellites. For example, you can get radio data from NOAA weather satellites to build your own weather maps in real time, before the Weather Channel broadcasts.

Transmitting, however, requires you use a licensed device in the appropriately licensed way. Transmitting means any transmission—from ground to satellite and from satellite to ground are both transmission. In order to send commands to a satellite or receive data from a satellite, you must have both a transmitter and a receiver.

• Send commands: data transmitted from the ground (licensed) is heard by the satellite receiver (unlicensed).

• Receive data: data transmitted from the satellite (licensed) is picked up by a receiver on the ground (unlicensed)

Sending up data from ground to satellite is the uplink. Sending data from the satellite to the ground is the downlink. In both cases, the transmitter must be licensed, but the listener is passive—anything that hears the signal can use it.

Further, for amateur radio, data sent down with IARU (or equivalent) approval must be unencrypted with a data format specified to everyone. However, the data you use for commanding can be private and not provided to anyone.

From this, we get two models. The design model clearly indicates both the satellite and commanding station need licenses, because they are both transmitting. The user model indicates that anyone transmitting commands needs a license, but you can have people help with receiving data and those users don’t need a license to help with the downlinks.

From the user model, this means you can build a very large downlink network—to get your satellite’s data—among the general public. At the same time, you can legally restrict the number of participants that can actually command your satellite. The uplinkers have to be both licensed (for transmitting at high power) and be privy to your secret command packet format.

Add in that you typically need to send very few command packets, and downlink is your primary communication budget. This is similar to upload/download rates for Earth-based Internet providers: they assume you are taking in a lot of content (streaming videos, web pages, incoming emails, tweets you are following) and sending out proportionally fewer (items you upload to websites, emails you write, tweets you author). For your satellite, you likely have small command uplinks akin to “OK, send me data,” “hey, here’s a new instrument config,” and “here’s where I’d like you to point to next,” and proportionally larger data downloads: “OK, here’s that picture you asked me to take” and “right, here’s the 12 hours of data you’ve been waiting for.”

In summary, a good ground network will have lots of sites to receive data and share or forward it to you, and a much smaller group authorized and given the access so they can issue commands to your satellite. Data down is public, and commands can be private, so the model matches pragmatic use as well.

Breaking International Law

I have had inquiries along the lines of, “Can I launch a picosatellite so people in [oppressed country X] can communicate despite censorship attempts by their local governments?”

Satellites are by default world-spanning. Any country can launch a satellite that then occupies the airspace of other countries. Any communications satellite can be used to allow disenfranchised people to communicate.

Whether you can do so legally is a different matter, and the answer is usually no. If you license via the IARU, you are bound by their laws, which tend to respect the laws of whichever countries you fly over. In practical terms, this means using a satellite to circumvent agreed international radio rules is not recommended.

This is akin to saying that because “X” is legal in your country, you have a right to do “X” in a foreign country. If you wish to use a satellite as a communications station to break the laws of a given country, please consult a specialist in international law. Who knows, your plan might be possible. If a given country doesn’t have a law forbidding your action (as advised by your lawyer), you might even have found a new business niche.

If you get arrested, note I said “consult a lawyer,” and I claim no responsibility. If you succeed and make millions, though, feel free to buy me lunch and thank for me for my advice.

Housekeeping: Bus and Instrument Are Separate

• Temperatures

• Voltages (bus per system, payload per instrument)

• Power levels and battery status

• Data fill rates

• Spacecraft clock

• Last uplink, last downlink (who accessed and when?), buffers

• Smart instrument status details (calibration levels, etc.)

• Attitude (inertial or other)

• Position (inertial or other)

In addition to displaying the value of these Health and safety items, your design should include an assessment of what the valid or good (green) ranges are, when the values are starting to get worrisome (yellow), and when a value or subsystem is in serious danger (red).

For example, if your power bus is supposed to supply “3.5 volts,” what does that really mean? It will not supply 3.5 volts exactly. You need to understand and track the allowable limits. For example, your system might work in the range of 3.3-3.6 volts, but gets flaky below 3.3 volts and above 3.6 volts. At the range of 3.0 volts or lower, or above 4.0 volts, the system may suffer damage and need to power down. So your green limits are 3.3-3.6 volts, your yellow limits are 3.0-3.3 volts or 3.6-4.0, and your red limits are <3.0 volts or >4.0 volts.

Limits Displays: Green, Yellow, Red

An alert is your system notifying you something is out-of-spec. A page is when your system actively tries to reach you tell you about it, via a text or a phone page or a tweet or a robot named Alfred the Butler that walks over and taps you on the shoulder to hand you an urgent note. Software typically sends pages by email or text message to a preselected address if any HK data moves into the yellow or red range. Email is the most common way to send pages. Some missions, such as NASA’s Tropical Rainforest Measurement Mission, developed an iPhone app to push these pages to a phone.

Data Integrity

Regardless of the power and means for transmitting data, there’s a separate issue of data integrity. The core methods to think about include having a verification method, such as checksums, for ensuring your data is complete. Allow for redundant transmission and the ability to retransmit—in essence, expect errors will occur and save some bandwidth to recover from them. In general, assume you have to be able to assemble full data sets from pieces or packets that arrived out of order. As long as each packet is tagged with a timestamp, you can reassemble on the ground in any decent database. Further, use the health and safety data to qualify how good or bad a particular data set is, as a measure of how well the instrument is tuned or in spec when that data was acquired.

Performance Requirements

Your mission is defined and driven by its requirements. A sample list of performance requirements includes:

• Data rate

• Bit-error-rate (BER)

• End-to-end delay (E/E)

• Link availability

• Anti-jam (A/J) capability

• Multi-path needs

• Security: COMSEC and TRANSEC

• Standardization

• Backwards compatibility

• Spacecraft orbit drivers

• Spacecraft mobility

• User-terminal characteristics

• Anti-jamming requirements

Security & Anti-Jamming

• COMSEC: Communications security, encryption

• TRANSEC: Transmission method (e.g., spread-spectrum or frequency hopping)

• Anti-jamming:

  • Blocking friendly accidental interference (e.g., RFI)

  • Blocking intentional electronic warfare

• Multi-access comm theory (FDMA, TDMA, CDMA, etc.)

• Standardization and compatibility and user terminals (obvious)

Spacecraft Orbits

Key mission-driven requirements, including:

• Coverage area (what the spacecraft can see)

• Slant range aka line-of-sight distances visible

• Elevation angle limits

• …all leading to viewing time

Frequency Allocation

• Limited by hardware

• Regulated by government agencies:

  • FCC (Federal Communications Commission) for industry and amateurs

  • IRAC (Interdepartmental Radio Advisory Committee) for military

  • For other countries, their FCC equivalent

• IARU (International Amateur Radio Union) for amateurs

• ITU (International Telecommunications Union) sets standards

• World Administrative Radio Conference (WARC) advises on standards

Physical Constraints

(aka hardware limits)

• Antenna size

• Transmit power

• Cost

• Channel constraints (air, wire, fiber, space)

• Atmospheric absorption

• Ionospheric attenuation

• Rain attenuation

• Foliage (!)

• Dust attenuation (and volcanoes)

• Solar activity

Architecture Choices

• Single ground station to spacecraft (s/c) (e.g., NASA White Sands)

• Linked ground stations (e.g., NASA’s Deep Space Network (DSN) of ground antennas)

• Both: One or multiple ground stations using satellite repeaters

• Crosslink network or constellation of comm providers (e.g., Iridium)

• Multi-access: Multiple ground→Satellite→multiple s/c (e.g., NASA’s TDRSS system)

How do you choose from all these checklist items? You take your mission inputs—options, requirements, existing infrastructure, and experience—as your input data. These all lead into your feasibility analysis, the result of which is the set of operational, technical, schedule, and cost limits. You analyze these and generate outputs (aka solutions) that in sum yield your objective architecture.

NASA’s Tracking and Data Relay Satellite System (TDRSS)

• Eight satellites currently in service; three geosync.

• TDRS available for NASA use providing; 24-hour coverage for any satellite.

• Primary ground station is White Sands Complex (WSC) with Network Control Center at Goddard Space Flight Center (GSFC).

• Each TDRS has an S band, Ku band, and Ka band (second and third generation only), forward, return, and telecommunications (source: TDRS homepage).

• Can support 32 satellites simultaneously!

• Over 300 Mbits/sec capability; 2-48 Mbit/sec avail to ind. missions (S-band only is <6 Mb/s; both S- and Ku-band > 6 Mb/s)

TDRSS cost information is available at the Federal Register and at Instructables, with rates from $10-$131 per minute. This requires a TDRSS-suitable transponder, which tend to be too large and power-hungry for CubeSats. 2015 data indicates TDRSS will phase out per-minute rates in favor of percentage-of-use.

NASA’s Deep Space Network (DSN)

• Trio of Goldstone, Madrid, and Canberra ground stations, linked to JPL’s Deep Space Operations Center (DSOC).

• Each has a 70-meter and 26-meter antenna, and multiple 34-meter antennas.

• Can support two satellites at a time (simultaneously).

• Currently limited to 6 Mb/sec downlink and 25 Mb/sec internal, upgrading to 150 Mb/sec downlink (3-band) and 100 Mb/sec internal. Uplink rate is 2 kb/sec (!) (source: Space Policy Online) (see also ESA’s ESTRACK, the Soviet DSN, the Indian DSN, and the Chinese DSN).

Near Earth Network

• NASA ground stations plus some commercial partners

• Maintained by GSFC

• Part of NASA’s Space Operations Mission Directorate (SOMD)

• Located at Wallops Island (VA), McMurdo (Antarctica), Merritt Island (FL), White Sands (NM), Svalbard (Norway)

The NEN provides these services to customers with satellites in low Earth orbit (LEO), geosynchronous orbit (GEO), highly elliptical orbit (HEO), and Lunar orbit and to missions with multiple frequency bands. Customers are both national and international, government and commercial entities, NASA (Earth Science, Space Science, and Human Explorations missions) and non-NASA (source: Space Comm and Navigation).