Chapter 2. Radio
Transceiver Concepts
Communications hardware is the same concept as sensor hardware from Book 3, DIY Instruments for Amateur Space. Sensors read in energy—light, electric fields, temperature, vibration, any source of energy—and convert it to an analog voltage, which is then digitized by your computer chip. Comm transmission runs this the other way. It takes a digital data value, converts it to an analog voltage, then pumps it out through an antenna as energy—in this case, as radio waves.
Receiving signals is even easier. A comm receiver is just a sensor. It picks up radio signals and converts them to data. The only difference between a general radio wave sensor and a comm antenna/receiver setup is that the comm setup is tuned to only pick up specific radio wave frequencies, and that the data that comes in has a prespecified format that carries more information than simply radio wave was here. There is no additional complexity in terms of hardware or use.
Sensors require (a) a sensor and (b) some connection, be it serial, I2C, or other port, to hook it up to your CPU. Radio comm requires (a) a transceiver and (b) some connection, usually a serial port, to hook it up to your CPU.
A transceiver is a radio device that both transmits and receives, hence the name: trans + receiver = transceiver. We’ll cover some standard devices out there. You can get and use separate transmission and receiver devices. In principal there is no difference between using separate chips versus a single chip transceiver. However, given that two chips require twice the wiring, twice the power, and twice the time to integrate, we recommend considering this carefully. We will discuss dual-band use shortly.
One area where people often use just a remote transmitter is for model rocket recovery. Companies sell tiny battery-powered transmitters that send a constant low-power signal so you can find a model rocket that flies into trees or out of sight. In that scenario, you manually start the transmitter just before launch, and manually turn off the transmitter when you have recovered the rocket. Similarly, high-altitude balloons usually use low-power radios that transmit their GPS coordinates to a ground station, without expecting a return. In such cases, a transmitter-only setup is acceptable.
For satellites, both regulations and simple common sense require that you be able to turn off your transmitter if it is overlapping or causing interference to other radio users. Therefore, you need a way to receive signals on your satellite, if only to be able to fulfill the requirement of telling your radio to start and stop transmitting.
As with sensors, there are a variety of different makes and models for transceiver chips. The primary issue for you as a satellite builder is a matter of ensuring you choose the right part, one that is well documented, so you can integrate it into your setup.
Wavelength and Frequency
Radio signals are specified by either their frequency (for example, 433 MHz) or their wavelength (for example, 2 meters). You can calculate any frequency given a wavelength, and vice versa, via their relationship: frequency multiplied by wavelength equals the speed of the signal. In the case of radio, that speed is the speed of light (radio signals are photons, remember), which is 3 x 108 m/s, and is commonly abbreviated by the letter c. Using simple algebra to move the terms around, we see that (frequency = wavelength / c and (wavelength = frequency / c.
Wavelengths are usually bundled into bands, with a given comm network or hardware set described by its band range:
-
S-band = 2025-2300 MHz
-
Ka-band = 18.1-32.3 MHz
-
X-band = 7145-8500 MHz
Dual Band and Modulation
A single transceiver both sending and receiving can be full duplex or half duplex. Half duplex means it can send or receive, but not both at the same time, sort of like a walkie-talkie or old NEXTEL push-to-talk phone. Full duplex means it can simultaneously send and receive, like a phone. On the ground, you should always be able to both talk to and hear your satellite, either with a full duplex transceiver or by using two separate radios—one to listen, one to send.
Onboard the satellite, whether to go with a full duplex onboard transceiver, a half duplex transceiver, or two separate transceivers is a decision that has to made on the basis of several factors, including the frequencies you are using, the amount of power available, and the hardware you can build to fly. One common operations design is to have a chosen frequency (such as 440 MHz) and have a single transceiver on the satellite that is set to listen at all times, then transmit only when ordered. An equally common design is a satellite that is more or less constantly transmitting on one band, while always listening for possible commands on another band.
The two bands—sending and receiving—can be the same frequency, or different frequencies. For example, your satellite might be sending data at 437.505 MHz for downlink while listening at 145 MHz for uplink. To complicate matters, a given frequency may be using different modulation methods, such as FM for receiving versus Single Side Band (SSB) for transmitting. Both methods use the same frequency, but modulate the signal differently, and require your hardware be capable of handling that particular choice of modulation scheme. SSB is common because it provides better power efficiency relative to FM for a comparable signal. At a simple level, you need to ensure that your hardware on both ends is matched—if the satellite transmits in SSB, your ground station receives SSB. While you can go deep into modulation theory, at this stage, just consider it (like frequency) a toggle that you decide on based on your allocated frequency and satellite hardware available.
Doppler
The number one most important concept that differentiates satellite communications from terrestrial (ordinary) radio communication is the satellite is moving, fast. First and foremost, this means you may have to point your antenna in the right direction, and keep moving it. The second most important effect of this movement is the Doppler shift. From a physics point of view, the Doppler shift is the change in frequency from a transmitter to a receiver based purely on the relative line-of-sight motion between the two. If the two objects are moving towards each other, the frequency shifts higher; if they are moving away from each other, the frequency shifts lower.
This is why an ambulance siren appears to rise in pitch as it approaches, then drops in pitch as it departs. The Doppler shift affects any wave, including sound, radio, and light. Since we are communicating using radio waves from a rapidly moving satellite (7 to 11 kilometers per second for most orbits), any transmission from your satellite will deliver a Doppler shift as it moves towards you (from the horizon towards directly above) then away from you (from directly above to the horizon). This will change the broadcast frequency, depending on the mission, anywhere from 1 KHz to 5 Mhz in frequency.
In theory, this means you need to constantly tweak your ground station hardware to be sure you are listening at the exact predicted frequency the satellite signal has. In execution, this means using software to handle the calculation for you. An excellent discussion of Doppler is in The ARRL Satellite Handbook from the National Association for Amateur Radio, subtitled “Explore, track and operate ham radio satellites.”
You should buy that book as a companion to mine. The focus of their book is not building and operating satellites, but understanding and using existing amateur ham radio communications satellites. Table 2-1 is a sample table of a typical LEO Doppler shift for a satellite transmitter broadcasting at a steady 145.800 MHz, as seen from the ground.
Remember too that your “steady” ground transmitter will experience a Doppler shift from the point of view of the satellite, exactly equal to the Doppler shift in the other direction. Doppler doesn’t care which object is moving. Therefore, your station broadcasting at (for example) 145.800 MHz will be heard by the satellite with the same frequency shifts seen below (from the ARRL Satellite Handbook).
| Time | Azimuth (degrees) | Elevation (degrees) | Frequency (MHz) |
|---|---|---|---|
03:57 |
307 |
0 |
145.804 |
03:58 |
350 |
10 |
145.803 |
03:59 |
0 |
8 |
145.800 |
04:00 |
11 |
9 |
147.798 |
04:01 |
20 |
5 |
145.797 |
04:02 |
30 |
0 |
145.795 |
Note the Doppler shift is not linear, but changes more rapidly as the satellite is in the middle of the pass (above you). It is also not the same for each orbit; as the satellite has different peak heights ranging from above you one orbit to it peaked to the left of me next orbit, so the exact Doppler will be different. Again, when using bands in the 145-435 MHz range (2 m to 70 cm bands), the typical maximum shift will be +/- 3-10 kHz, depending on frequency, and that can frequently be handled by hardware with a sufficiently wide bandpass. At higher frequencies—1 to 10 GHz—the maximum Doppler increases from 30 kHz to over 200 kHz.
The ARRL Satellite Handbook goes on to show other cases, such as high- elevation passes, and discuss them in depth. Your communications design must be able to handle the Doppler shift between your satellite and ground station. Modern transceivers are very flexible in terms of having a broader range of sensitivity, and software-driven communications can be set to the expected shifted frequencies.
One axiom of good radio practice is to never use more broadcast power than you need. With regards to Doppler, for receiving, using a wide bandpass is fine. When transmitting to your satellite, however, you will need to better control your radio usage. You should broadcast as close to the appropriate frequency as possible when commanding, because you are sending radio signals out and too wide a bandpass on your broadcast can disrupt other users. For uplinks and commanding, then, correct for Doppler. Doppler correction (for transmission and receiving) can be handled by many software packages.
Interference
Although you may worry about radio noise from cell phone towers, WiFi networks, commercial FM radio, fluorescent lights, or other things that put out some radio signals, it is unlikely any of these will interfere with your satellite communications. Commercial devices each are assigned a frequency range, specifically so they don’t interfere with other devices. This is why using a Bluetooth device in your car won’t ruin your FM radio reception or block the GPS signal to your navigator, for example.
Electronics of any sort do have a tendency to create radio signals because any moving electric field or current can induce a signal in a long antenna-like wire at a distance. This is the reason for the little FCC tags devices have, as proof that the manufacturer built the device well enough, grounded enough, with an appropriate case, so that the device will not be an accidental source of radio signals or interference. Even devices like microwave ovens (microwaves are a form of radio!) are FCC-approved to not spill signal outside of the device itself.
Interference is not just accidental, but can occur when your legitimately functioning device nevertheless conflicts with an existing system. For example, the Tropical Rainfall Measuring Mission satellite has to partially power down its active radar instruments while over Australia, because they overlap the frequency reserved for civil use in that country. CubeSats and other nanosatellites have to be careful, since they often are broadcasting at the same (or similar) frequency as other CubeSats. When that happens, one CubeSat’s legitimate signal is interference from the point of a view of a nearby CubeSat. In such cases, depending on priority and negotiation, one satellite may have to power down to allow the other to communicate.
Part of your final hardware build must be designed to not create interference between your transceiver and your payload, and between your payload and any nearby objects, or your transceiver and any nearby objects. Designing is not enough, so you also need to test your final design to ensure it is not creating interference or static while operating. A “noisy” satellite is not just less effective, it is a licensing violation and can result in your mission being ordered to shut down.
ADC
To talk to other humans via radio, you can just use a speaker and a microphone. To talk to satellites, you need to digitize the radio data you’re sending. This requires analog to digital conversion (ADC). Radio waves, like sound waves, are analog—they carry data in a mix of waves, each with amplitude and frequency, that overlap to form the signal you hear. Digital data is a series of 0s and 1s that samples the analog signal and makes its best discrete approximation to it. If radio is analog and we are using it to send digital data, we need an ADC (and its counterpart, a DAC—digital to analog converter). With good hardware, this approximation is darn good—think of the high quality digital pictures your camera can take.
Early ADC used a terminal node controller (TNC) that included a modem to convert radio tones into digital data. Some rigs use your computer’s sound card inputs to receive the radio, since sound cards already include a microphone in jack that you can plug your radio into. In both cases, you have your radio transceiver, which converts radio waves to sound and vice versa. The TNC or sound card (plus software) converts that sound to a digital representation (and vice versa). You can consider both a black box that magically handles the transceiver-to-computer interface.
Newer radios now include USB cables that often do the ADC within the transceiver, converting the radio signal directly to digital without having to run it through a speaker as sound. These plug (obviously) into the USB port of your computer, and are just the latest iteration of a black box to handle the ADC step. You can also buy USB radio dongles, small radio receivers that plug into your USB port and serve as both radio receiver and ADC together.
For TNCs and sound card usage, and radios with USB cables, you use the system as a two-step process. You still tune to your chosen frequency using the radio itself; the computer serves just to handle the data packets. Packets (which we’ll get into later) are bursts of information that your radio sends, that include encoded data (instead of voice). Unlike voice, listening to a packet just sounds like random tones, but those tones can be decoded by anyone at the other end who also has a radio with a TNC, sound card, or USB connection.
Most packet formats send ASCII text, kind of like the SMS or tweet of the radio world. Anyone receiving it can decode the packet to reveal both sender and message. You need software to encode or decode packets. Some radios (especially handhelds with digital displays) have the software built in. For your home PC, there are several software packages available depending on the make of your radio and what you need to do.
Packets
In general, your satellite data feed will start with plain data from either the bus (recording HK data) or the instrument/payload (science data). To this you add a timestamp so you can sort and use your data later. Then you encode it, optionally compress it, apply any encryption and/or authentication, then add in checksums for error checking. Each step adds to the data size, but also makes the data more usable. This creates your data packets.
The difference between raw data and data packets is the same as the difference between a random binary file of numbers and a jpeg image, or a web page, or a PDF file. The first is just raw data, the second is usable data. Data packet formats exist to provide a universal standard for ensuring that your satellite’s collected information is readable from the ground.
Packets are defined as chunks of data containing up to 256 characters. They include the callsign of the sender as well as a callsign or address for the intended recipient, and optionally they include error checking. Error checking depends on the packet format you use, and can be as simple as a checksum or something more involved. The purpose of error checking is to let the recipient tell whether the packet received is whole and complete. An example of a simple checksum for a string of data is the parity bit. You add the parity bit to the end of the data, and it’s either 0 or 1. Since digital data is a series of 0s and 1s, the parity bit method counts the number of 1s in the data and sets itself to either 0 or 1, depending on whether the number of 1s was even or odd. When you receive a message, you recompute the parity bit for the received message and compare it with the parity bit that was transmitted. If they don’t match, if this last bit doesn’t match the data, you know there was a transmission problem and at least one bit got flipped. More robust error detection methods exist and are part of the different packet formats.
Historically, ham modes have included the early radioteletype (RTTY) standard and, later, the trio of AMTOR, PACTOR, and G-TOR. These modes are supported by most software. The *TOR modes use automatic repeat request/query (ARQ) for error control, a method that basically has the transmitter retransmit until the receiver finally indicates it received the data without error. PSK31 is an HF digital mode that is often used for the sound card–PC method of connection. Slow-Scan TV (SSTV) is a mode specifically designed to send pictures.
Just as Internet data tends to use the TCP/IP format, most satellite data uses either the AX.25 or CCSDS packet format. These packet formats include some degree of timestamp, identifier, and checksums. As openly published standards, this means your data probably will work with existing ground software if you use either standard. Standards improve efficiency and interoperability. In DIY terms, this means you should always use an established data packet standard unless you happen to be an expert in the field. If you’re reading this book, that probably translates to use an established data packet standard.
Any packet format is just like an envelope to send a letter. It doesn’t matter what the contents of the letter are, only that it (a) fit into the envelope and (b) has an address and return address so recipients know where it came from and who should get it. The current default digital packet format, especially for satellite and high-altitude balloon (HAB) use, is AX.25. Being a standard, this is also what most software supports. Each AX.25 message includes the call sign of the sender (or satellite) plus the call sign of the destination station, so each message can be uniquely identified and, if needed, relayed to the appropriate user.
In addition to AX.25, there is CCSDS, a new standard that is being promoted especially for satellite use. CCSDS is more accurately the CCSDS Space Packet Protocol, as CCSDS stands for the Consultative Committee for Space Data Standards. The blue book at ccsds.org defines the exact packet format. CCSDS packets are specifically defined for space use, allowing for the space equivalent of FTP connections (called FDP), for retransmission of data, and for effective data transmission along the often noisy, lossy radio channels.
When would you use CCSDS instead of AX.25? If your software supports it. For example, CCSDS has tools such as the CCSDS File Delivery Protocol (CFDP), which lets you treat your satellite just like a remote directory from which you you can uplink or downlink data.
Packet data transmits at rates of 1200 bps to 9600 bps, so it is not very fast, but it is efficient and it is the fastest connection that can be supported by the radio frequencies and hardware used. Put another way, you could optimize a new packet format that yielded higher bandwidth than AX.25, but then you would no longer be compatible with any existing software or with other users.
As you may gather, AX.25 and, optionally, CCSDS are the primary items you should focus on. The terminology can be tricky; for example, AX.25 is the protocol for the packet mode of communication, which can be used on a variety of HF and UHF frequencies, and is independent of how your hardware actually modulates the signal. So you’ll read an item like (from Wikipedia’s SkyCube entry) “the SkyCube radio emits periodic beaconing pings which contain 120-byte messages from the Kickstarter backers. These pings are transmitted at 915 MHz, using the AX.25 protocol at 9600 baud with BPSK modulation, with a callsign of WG9XMF.”
By now, hopefully you can parse that out as the satellite transmitter hardware is using the frequency of 915 MHz, and likewise the radio hardware is using BPSK modulation in sending the signal. Once your ground station receives this, the data itself uses the AX.25 packet format, and the data rate is 9600 baud, loosely 9600 bps (though baud != bit, but let’s not get into that here). Having translated the data into human-readable format, each data item contains the callsign WG9XMF so you can identify that they are from SkyCube, and the actual information inside each message is likely 120 ASCII characters (assuming they are using ASCII, where 1 letter = 1 byte). That’s our three layers—hardware (frequency and modulation and data rate), data (data rate and packets and protocols), and user (informational content sent or received).
More to the point, you shouldn’t have to deeply understand either AX.25 or CCSDS in order to use them. They are akin to the GIF versus JPEG formats when sending images—the user doesn’t need to know the detailed workings, only the software needs to support it. Your software should understand the format, and you need to ensure your satellite’s processor is formatting the data properly. In short, the data packet spec matters to the code, but does not fundamentally change your operations or your design. Much as you would choose either TCP or UDP when making an application to connect two devices over the Internet, then use a software library to handle the actual conversion, you should pick AX 25 or CCSDS, then use the appropriate software and libraries to manage your data for you.
APRS
The Automatic Packet Reporting System (APRS) is one of the most brilliant aspects of ham radio. APRS is a worldwide networking of radio users, automated stations, repeaters, relays, and the Internet that serves to capture and relay APRS-identified packets to anyone, in near real time.
If your satellite (or high-altitude balloon) is transmitting an APRS packet, you in essence now have a worldwide ground station that you can access via Internet, without even owning a radio yourself. APRS uses 144.39 MHz (in North America), 144.80 MHz (Europe), 145.175 MHz (Australia), and 145.825 (Space). APRS is intended to provide local information including status, weather, location, and other relevant information. Details are at http://www.aprs.org, and you can see archived messages in the APRS-IS (APRS Internet System) database at http://www.findu.com.
As written by APRS founder Bob Bruninga, WB4APR, “It is a two-way tactical real-time digital communications system between all assets in a network sharing information about everything going on in the local area. On ham radio, this means if something is happening now, or there is information that could be valuable to you, then it should show up on your APRS radio in your mobile.” APRS uses AX.25 packets with specific protocols and formats, which differ depending on whether you are sending (for example) weather data, GPS coordinates and a position report, or other data.
Previous CubeSats such as PCSAT-1 and 2 and BricSat have used or intend to use APRS to report their location, status, and basic data such as temperature or electric/magnetic field measurements. Further details are at USNA CUBESAT Notes and the Cubesat Comms Design Page.
One fun aspect of APRS is that, even without a radio, you can access the data via the APRS-IS databases. In addition to the above resources, visit the APRS Satellite Tracking and Reporting System (ASTARS) to track and predict existing satellites as well as view their APRS messages.
Software-Defined Radio
Software-defined radio (SDR) is perhaps the most relevant hardware innovation for receiving satellite information. The long and short of SDR is that you can buy an off-the-shelf $20 USB dongle, and get performance equal to $500+ hardware radios of yesteryear.
An SDR dongle is a radio receive that covers a wide band—typically 24 MHz through 1.7 GHz, which includes most satellite bands. The unit plugs into the USB port of your computer, and you must provide a driver and software to use it. You also plug an antenna into it—the better the antenna, the better your reception.
Anyone can use an SDR and you do not need any license to receive any signal a satellite transmits. SDRs are a cheap way to make any laptop or USB-equipped tablet serve as your satellite scanner to listen for data. While this isn’t a base station if you wish to command a satellite—that requires transmission capability, and a Ham or other license—SDRs are awesome for getting into listening to satellites.
To buy one, search on your favorite search engine or on eBay for SDR USB RTL and you can find viable units under $25US. The unit includes both an ADC (analog-to-digital converter) to translate from the antenna RF signal to computer digital units, and a tuner to allow you to sub-select which frequencies to look at. A typical unit might use an RTL2832 ADC chip for the former, and an R820T or similar tuner. The primary issue when buying an SDR is to check whether your computer supports it. The general spec is the RTL282 chip, which most Windows, Linux, and Mac computers can support.
The tuner itself usually covers a range of 3.2 MHz, which means that, for example, you can pick up a 145.00 MHz signal as long as it is broadcast in the range of 143.4 to 146.6 MHz. This is useful because satellites are moving, and in the Doppler section we noted that motion induces frequency shifts. A decent span means that, even if the frequency is shifted, you can use this to capture it without having to manually adjust your frequency.
The trade-off of a large bandpass such as 3.2 MHz with a core central frequency of 145 MHz (for example) means that you risk catching other stations in your listening. By analogy, a typical bandpass for a home FM radio is about of 0.5 MHz. Radio stations in metropolitan areas should keep at least 0.5 MHz apart from each other: a station like 98 Rock in Baltimore, which transmits at 97.9 MHz, should not have any neighboring station between 97.4 and 98.5 MHz. Below 97.4 or above 98.4, a nearby station will not interfere with 98 Rock.
This could be a problem with an SDR’s larger bandpass. Tuning into 97.9 with a 3.2 MHZ bandpass means you’ll not only be receiving 97.9, but every station between 96.6 and 99.5.
Fortunately, satellites using similar frequences are rarely near each other. In that case, a wide bandpass means that you can catch your one satellite even if it experiences Doppler shifts as it broadcasts, because ideally it is the only item in the sky in the direction you are pointing. If multiple satellites exist in the same zone of the sky as you are pointing, all using similar (but slightly different) frequencies that differ only due to Doppler broadening, you likely would not be able to distinguish them even without Doppler. Satellites are unique items, and we rely on this in listening. So, an SDR with a wide bandpass is an ideal tool for listening.
Flexible hardware implementations for stand-alone radio gear that you wish to integrate with your computer also exist. AMSAT notes a computer sound card can handle +/- 24 KHz sampling around a frequency (a 48 KHz bandpass) that typical hardware provides (QST magazine, April 2014, ARRL, pg 33, ‘A Tiny Python Panadapter”). The key trade-off is that a stand-alone radio receiver will have higher signal and lower noise, but with typically a smaller bandpass, compared with the tiny USB SDRs mentioned.
SDR only listens; to date none of them transmit signals. You can use an SDR to receive, but still need a ham set (even a handheld Baofeng) plus the appropriate licensing, to transmit to your satellite. SDR is also available as an Android app for use with tablets, smartphones, and other devices, using software such as SDR Touch or SDRAnywhere. SDR is constantly dropping in price and improving in performance and in software availability, and is the easiest way to get started (at the very least) listening to satellites from your laptop.