PixelSat I Software Part 1: Comms System<br>| Project Pixel OrbitalPixelSat I Software Part 1: Comms System

by Ashwin Naren, Vinayak Vikram, Aadish Verma

Welcome to the first post in a series about the PixelSat I software stack.<br>In this series, we will explore both what we built and also how we arrived there.

PixelSat I is a 3U CubeSat designed entirely by students at Stanford OHS and is scheduled to launch no earlier than March 2027.<br>Because we are a student team working under tight budget, power, and time constraints, nearly every part of the spacecraft has had to be designed with commercial off-the-shelf parts.

A satellite can have great software, a capable payload, and a carefully designed avionics stack, but without a reliable radio link it is effectively inaccessible once it leaves the ground. The communications system determines how much data we can return, how confidently we can command the spacecraft, what sort of ground infrastructure we can rely on, and even which regulations we have to design around. In many ways, it sets the operational envelope for the entire mission.

This post focuses on how we chose our radio stack and why we ultimately committed to a low-cost LoRa-based approach. We will walk through the constraints we started with, the modulation schemes we considered, the hardware options we evaluated, and the framing decisions that define the current system.

Constraints

When choosing a transceiver, there were a few constraints we absolutely had to satisfy.

Firstly, the transceiver could not be expensive. Ideally, it had to cost under $500 after discounts.

Secondly, we needed something with a large link budget. Due to the nature of our satellite, we cannot guarantee precise orientation.

Thirdly, we needed something with a relatively low power draw. We needed a transceiver that could run at around 8 V and draw no more than 200–300 mA.

Lastly, the transceiver had to physically survive in a CubeSat: it needed to be small and able to handle radiation and temperature cycling.

UHF

UHF is the ideal band for communications at this scale because of its low power requirements, ease of manufacturing (which implies lower cost), and decent bandwidth.

Compared to VHF, UHF is less affected by the ionosphere, has a smaller antenna footprint, and offers much more bandwidth.

S-band and X-band do not have cheap, readily available COTS transceivers, and their power draw is also higher to compensate for signal loss.

Our UHF antenna will be a deployable “tape-measure” antenna transmitting in the 435 MHz band.<br>The antenna is generally omnidirectional, but pointing it towards the ground increases the link budget significantly.

LoRa vs GMSK/GFSK

LoRa

LoRa operates by transmitting each symbol as a frequency sweep (described as a “chirp”). Because of this, LoRa signals are very resistant to interference and can transmit over long ranges. However, the occupied bandwidth of a LoRa signal is quite large, which means its spectral efficiency is low. LoRa’s data rate is also much lower than that of GMSK/GFSK.

GMSK/GFSK

FSK (frequency shift keying)

FSK simply switches the frequency of a carrier wave between a set of discrete frequencies. For example, in BFSK (binary FSK), we might have a specific frequency for 0s and another for 1s, and the receiver determines which frequency is present during each symbol period and decodes the bit.

GFSK (Gaussian FSK)

GFSK simply applies a Gaussian filter to the input data before frequency modulation, smoothing transitions between symbols. This reduces out-of-band emissions and occupied bandwidth compared to plain FSK while maintaining the same basic modulation scheme. The resulting signal is more spectrally efficient and supports higher symbol rates in a given band.

GMSK (Gaussian minimum shift keying)

GMSK is a special case of GFSK in which the modulation index is minimized while still allowing symbols to be distinguished easily. Relative to plain GFSK, it still requires a bit more processing.

Handling Doppler shift

Doppler shift is the apparent carrier-frequency shift due to the velocity difference between the transmitter and the receiver. If the transmitter is moving toward the receiver, the received frequency appears higher than the transmitted frequency, and vice versa.

Because LoRa uses chirp spread spectrum, it is generally more tolerant of Doppler-induced frequency offsets than GMSK/GFSK, which rely on detecting small frequency changes around the carrier wave. Therefore, GMSK/GFSK requires accurate knowledge of the satellite’s position and velocity to decode the signal reliably.

Due to Doppler shift and our design constraints, we eventually settled on a pure LoRa communications stack.

Timeline

We considered an inordinate number of transceivers throughout this project before settling on the EByte E22-400T30D LoRa module in May 2027.

GomSpace AX100

The GomSpace AX100 is a UHF/VHF transceiver used in many CubeSat missions. It operates with GMSK/GFSK,...