Preliminary Design of a GNSS Interference Mapping CubeSat Mission: JamSail

Abstract

The JamSail mission is an educational CubeSat aiming to design, develop, and demonstrate two new technologies on a small satellite, tentatively scheduled for launch no earlier than 2026. When launched, JamSail will demonstrate the functionality of two new payloads in low Earth orbit. First, a flexible, low-cost GNSS interference detection payload capable of characterising and geolocating the sources of radio interference regarding the E1/L1 and E5a/L5 bands will be demonstrated on a global scale. The data produced by this payload can be used to target anti-interference actions in specific regions and aid in the design of future GNSS receivers to better mitigate specific types of interference. If successful, the flexibility of the payload will allow it to be remotely reconfigured in orbit to investigate additional uses of the technology, including a potential demonstration of GNSS reflectometry aboard a CubeSat. Second, a compact refractive solar sail will be deployed that is capable of adjusting the orbit of JamSail in the absence of an on-board propellant. This sail will be used to gradually raise the semi-major axis of JamSail over the span of the mission before being used to perform rapid passive deorbit near the end-of-life juncture. Additionally, self-stabilising optical elements within the sail will be used to demonstrate a novel method of performing attitude control. JamSail is currently in the testing phase, and the payloads will continue to be refined until the end of 2024. This paper discusses the key objectives of the JamSail mission, the design of the payloads, the expected outcomes of the mission, and future opportunities regarding the technologies as a whole.

1. Introduction

JamSail is the first in-house-developed-and-launched CubeSat from the University of Nottingham, scheduled to launch no earlier than 2026. The mission will consist of several key phases, described in Section 2, each focusing on a different payload or critical function. Primarily a research mission, the payloads on board target a variety of areas of importance, including Earth observation via frequencies used by safety-critical navigation systems and the demonstration of sustainable orbital manoeuvring techniques for small satellites. The former will be achieved via an in-house-developed payload to monitor, characterise, and geolocate sources of radio interference regarding GNSS frequencies on a global scale; further information can be found in Section 3.1. The latter will be demonstrated via a novel refractive solar sail used to adjust the orbit of JamSail over the duration of the mission, discussed in Section 3.2. Throughout the mission, an outreach campaign will be performed via an amateur radio payload including several external-facing cameras to promote space engineering to communities around the world, as described in Section 3.3. All these payloads are being designed in-house to specifically focus on the research interests and will be integrated into a core bus consisting of commercial off-the-shelf components with flight heritage, as briefly summarised in Section 4. A review of the current mission status and major upcoming milestones is then discussed in Section 5.

1.1. Background

Global Navigation Satellite Systems (GNSSs) provide crucial positioning and timing data for an array of modern technology. A GNSS receiver takes data from a network of satellites, enabling the calculation of the receiver’s 3D position (to a precision as low as centimetres), velocity, and absolute time. GNSS applications range from consumer navigation products to surveying, construction, and disaster monitoring [1,2,3,4,5]. GNSS data are transmitted in the L band, between 1.1 GHz and 1.6 GHz, with the majority of users utilising the E1/L1 band centred at 1.57542 GHz [6]. While these frequencies are formally reserved exclusively for GNSS transmissions, the received power level is very weak, typically −130 dBmW, and is highly vulnerable to interference [7]. This interference arises from two main sources: accidental transmissions in GNSS bands [8] and intentional ‘jamming’ of GNSS signals [9,10]. Accidental interference is usually due to unexpected resonances in antennas transmitting at lower frequencies (harmonics), improperly calibrated transmission equipment, or other important signals transmitted in the same bandwidth (e.g., aircraft landing systems and DME/TACAN on E5a) [11,12]. Intentional jamming of GNSS signals was historically associated with military forces in active battle zones as well as in highly defended areas, with the intention of disrupting the usual operation of an opponent’s navigation and weapon guidance systems [13,14]. However, with the growth of GNSS applications and reliance on GNSS for critical infrastructure, GNSS jamming is now commonly observed across the globe. GNSS interference has been observed previously from GNSS receivers in low Earth orbit (LEO) with space-facing antennas [15] designed for standard GNSS use.

The ‘sail’ aspect of JamSail is pertinent as it represents an advancement in the discipline of solar sailing as a whole; JamSail will represent the first transmissive solar sail operated in space. In contrast to the conventional reflective solar sails, this transmissive sail utilises refraction to accelerate its satellite. Previously, reflective solar sails have demonstrated admirable performance in exploration roles owing to their exceptional net acceleration ($\Delta V$), which, in the absence of satellite malfunctions and optical degradation effects, is theoretically infinite. This is because they do not require an on-board propellant and instead harness ambient solar radiation to accelerate their satellite. Nevertheless, although the first sailcraft launched over 14 years ago [16] and, although the technology is well studied in the literature [17,18,19,20,21,22,23,24], they remain a rarely utilised novelty by the space sector as a whole. There are several reasons for this [25], but the greatest may be the fact that they are ill-suited to performing the preeminent form of a space mission—that of the terrestrial satellite. This is mostly due to their large drag profile, which causes them to experience reduced performance up to about $1000\mathrm{km}$ and renders them inoperable below about $600\mathrm{km}$ [26,27]. In an ideal orbit, a reflective sail must tack with respect to the Sun in order to perform a simple orbit-raising manoeuvre. Conversely, a transmissive sail may perform such a manoeuvre from the minimum drag configuration (see Section 3.2) and is overall much less sensitive to altitude than the contemporary sails [25,28]. Furthermore, some other drawbacks of the contemporary solar sails may be partially mitigated by a transmissive design, including the general rates of acceleration and operational complexity [25]. This technology is also of growing importance due to the prevalence of space debris, which is caused by terrestrial satellites in LEO; a deactivated sailcraft in LEO will rapidly deorbit of its own accord, so the widespread adoption of these sails would naturally curb the rate that debris is generated.

1.2. Mission Objectives

The GNSS interference payload on JamSail aims to monitor the global GNSS interference in both the E1/L1 and E5a/L5 bands via the inclusion of a dedicated nadir-pointing GNSS antenna, which will capture signals originating from Earth rather than the standard navigation signals from GNSS satellites, with the overall objective being to produce geolocated, temporally precise data detailing the global levels of GNSS interference. By recording the frequency and strength of these Earth-originating signals, global hotspots for GNSS interference can be identified. In the case of the detection of intentional GNSS jamming, there is also the potential for determining the type of jamming in use via the analysis of the signal’s spectrum and frequency. Due to the ongoing nature of the experiment, data can be collected until the end of the lifetime of JamSail throughout all the mission phases. The primary impact of this research will be to highlight areas of increased operational difficulty in surveying and construction as well as areas of emerging or continued conflict. This payload is designed to be flexible via the use of a reprogrammable payload controller and multiple antennas, enabling the option for the payload to be reconfigured during the extended mission operations phase to perform additional experiments.

The solar sail payload aims to investigate the behaviour of a prototype transmissive sail that utilises refraction to generate solar radiation pressure. Overall, the objective of this payload is to successfully perform an in-orbit demonstration of this technology for orbit and attitude control. While previous sailcraft missions have focused on exploiting flat, reflective membranes, JamSail will instead focus on the exploitation of patterned refractive membranes. Because it does not significantly diffract sunlight, this system is best described as a refractive solar sail. Of particular interest are the demonstration of the LEO performance during orbit raising and the passive stabilisation that may be achieved by certain refractive patterns. Depending on the performance of the payload throughout the mission, the operations and targets will be adjusted to determine the limits of the technology and to maximise the in-service lifespan of the CubeSat.

2. Concept of Operations

The general concept of operations of JamSail follows a somewhat linear arrangement of payload activation, with an intentional overlap as additional payloads are activated. Immediately post-launch, the initial days in orbit will be characterised by various commissioning and verification phases (T1–T3) in which stowed components are deployed and a stable attitude is maintained. Throughout this phase, the primary communication radio will be continually beaconing to assist in establishing a stable communication link with the ground stations operated by the team. Once it is established that JamSail is in a stable configuration, the GNSS payload will be the first to activate (T4), initially starting with a period of calibration to adjust the configuration of the payload to match the predicted measurements from the known sources, including the equipment used at major airports that emit standard signals at frequencies close to the L5 GPS signals. This calibration phase is important for the operations of the payload as it will ensure that the payload is able to successfully receive signals at the expected power level and use this information to establish a baseline for future data to be measured against. Parallel to this, a payload consisting of a minimum of two external cameras will be initialised and used for further attitude verification and calibration and will begin openly transmitting images for reception in the amateur radio band (T5). Where possible, amateur radio operations will continue throughout the orbital lifespan of the mission, except during short periods of high-priority activities. Following calibration, the GNSS payload will enter its standard operations mode (T6), in which it will autonomously conduct observations of target areas and downlink these data to the team for further processing on the ground. After the initial target period of observations has been completed (NET 1 year after launch, subject to extension), the solar sail will be deployed and JamSail will enter its extended mission operations phase (T7), in which the sail will be used to adjust the orbit of the spacecraft to validate the functionality of the solar sail. Other payloads will continue to operate throughout this phase unless the modified orbit prevents useful operations. Towards the end of the orbital life of JamSail, the solar sail will be further used to deorbit the CubeSat, ending the mission by destructive atmospheric entry (T8). A graphical representation of these phases can be observed in Figure 1.

3. JamSail CubeSat Payloads

The JamSail CubeSat contains several major payloads, each of which serve a distinct research or educational purpose. Of these, the primary operational payload is a GNSS interference detection payload, which will monitor radio interference regarding the GNSS bands from Earth-originating signals. This payload will operate throughout the lifespan of the satellite and will continually produce data where possible. Successful operations of this payload will demonstrate the ability to geolocate sources of GNSS interference from a small satellite, and the technology could be used to develop a dedicated constellation of similar satellites in the future. Towards the end of the targeted operational period of the GNSS payload, the solar sail payload will be deployed, aiming to demonstrate its ability to adjust the spacecraft’s attitude and orbital parameters via the solar radiation pressure (SRP) that is generated by its refractive membranes. If successful, this payload will prove the feasibility of the use of a compact refractive sail for the manoeuvring of a CubeSat, with the potential to significantly improve in-orbit lifespan without being constrained by fuel capacity, and in a debris-neutral manner. Finally, throughout the mission, external-facing cameras will be programmed to capture colour photographs and transmit these via amateur radio frequencies for reception across the world to promote space and radio activities in communities globally.

3.1. GNSS Payload

The GNSS payload on JamSail aims to monitor Earth-originating GNSS interference and produce temporally precise geolocated data of this interference. Two frequency bands will be monitored: the E1/L1 band centred at 1575.42 MHz and the E5a/L5 band centred at 1176.45 MHz. The headline unit specifications of the GNSS payload are provided in

Table 1. GNSS payload specifications.

Parameter	Specification	Note
Frequency band	E1/L1—1575.42 MHz
	E5a/L5—1176.42 MHz
Bandwidth	25–50 MHz	Two-sided
Antenna (s)	Nadir and Zenith, both RHCP
Power consumption	1 W	4 channel mode 50 MHz sampling
Envelope Size	100 mm × 120 mm × 75 mm
Max. Data rate	65.5 kB/s	Spectrum mode
	25 MB/s	Raw data mode
Raw data quantisation	2–12 bits

.

3.1.1. Payload Overview

The GNSS payload consists of a multiple-channel RF Front-End with two active antenna inputs (nadir- and zenith-facing) and an interface board to connect the Front-End with FPGA processing board. The payload operates in two possible modes, output of raw data from the RF Front-End and a processed output from the FPGA after analysing the spectra of the received signals. The raw or processed data are then downlinked at the next availability to be studied on the ground.

Initial conditioning of the GNSS signal will be performed by the RF Front-End, embedded in the NT1065 FMC2 board. This board provides power to the amplifiers in the antenna via SMA connectors, which are also used to receive the amplified and filtered analogue signal from the antennas. The NT1065 chip on this Front-End board is responsible for down-converting the GNSS signals to an intermediate frequency while also filtering and digitising this analogue signal (sample rate of 53 MHz) to enable digital processing in software. Additionally, a custom AGC from the FPGA via SPI interface of the NT1065 has been implemented to account for any variations in the input signal or the gain of the LNA or the Front-End with temperature.

Figure 2 shows the block diagram of the GNSS payload of the JamSail CubeSat. This block diagram consists of three stages. The first stage consists of the two antennas. The zenith antenna receives the signals from the GNSS satellites and the other nadir antenna detects the Earth interference from different sources, such as intentional and unintentional interference sources. These antennas will operate in two frequency bands, L1/E1 and L5/E5a, to be connected to the Front-End device via an RF splitter. L1 and L5 frequency bands for GPS constellations. E1 and E5a frequency bands for the Galileo constellation. The NT1065 Front-End is used for the payload. NT1065 is a four-channel RF Front-End IC for the use of the GNSS signals (GPS, GLONASS, Galileo, BeiDou, NavIC, and QZSS) and also signals of satellite-based augmentation systems like OmniStar at all frequency bands in various combinations: L1, L2, L3, L5, E1, E5a, E5b, E6, B1, B2, and B3. The Front-End will have some features such as a single conversion superheterodyne receiver. Also, this Front-End has 4 independent configuration channels, each one has LNA, mixer, IF filter, IFA, 2-bit ADC, embedded temperature sensor, dual AGC (RF and IF), or programmable gain. Moreover, the Front-End has an SPI interface with easy-to-use register maps. This Front-End will be connected to FMC with an SPI interface. The output from the Front-End will be 8-bit digitised data of the raw GNSS data. Also, there is a clock signal that is intended for clocking all 2-bit ADCs as well as clocking the external correlator engine. It is generated from LO frequency from PLL “A” since channel #2 is used for this payload. The NT1065 features two independent PLLs (Phase-Locked Loops): PLL “A” and PLL “B”. PLL “A” supplies the LO (Local Oscillator) signal to channels #1 and #2, while PLL “B” is dedicated to channels #3 and #4. This dual PLL setup enables greater flexibility and precision in generating different LO signals for separate channels, which is particularly useful in high-precision GNSS applications. For specific applications requiring a common LO source across all channels, PLL “A” can be configured to provide the LO signal to all four channels. This setup enhances signal customization and performance for applications like goniometric positioning and driverless vehicle systems [29]. CLK source and frequency can be customised by the procedure.The FMC is an ANSI standard that provides a standard mezzanine card form factor, connectors, and modular interface to an FPGA located on a baseboard. Decoupling the I/O interfaces from the FPGA simplifies the I/O interface module design while maximising carrier card reuse. This FMC will be connected to the FPGA board.

The second stage is the FPGA board. We are targeting Xilinx Zynq 7030 with two A9 cores inside. The FPGA stage contains five core parts, which are the SPI control, the inbuilt CPU, the interference characterisation module, and UART. SPI is one of the most widely used interfaces between microcontrollers and peripheral ICs such as sensors, ADCs, DACs, shift registers, SRAM, and others. The SPI control will control the communication between the inbuilt CPU inside the FPGA and the FMC. The inbuilt CPU inside the FPGA contains the real-time operating system (RTOS). This RTOS will contain four tasks, which are the communication task, the timer task, the SPI task, and the Front-End task. This built-in CPU part will communicate with the interference characterisation module through the AXI interface. This module will have three main operations, which are the distribution calculation, the noise calculation, and the FFT spectrum calculation. The FFT spectrum calculation part has been implemented using VHDL and FPGA (hardware implementation) and has been validated using the MATLAB simulation (SWRs) in the lab. In order to verify the results of the hardware implementation against the software simulation [30], the output data (32 bits) from the three operations inside the interference characterisation module will be passed into the Front-End task in the inbuilt CPU.

The third stage is managing the memory of the GNSS JamSail payload. The output from the interference characterisation module will be stored in the management memory block and the output from the RF Front-End will be stored in the management memory block. Then, the output from the management memory will be used as input for the external DDR3 memory (1 GByte).

3.1.2. GNSS Interference Scenarios

The manner of obtaining the GNSS interference raw data through the GNSS simulator is shown in Figure 3. The Skydel Advanced GNSS Simulator was used to simulate various passes of JamSail CubeSat over an interference transmitter. This simulator provides two types of raw data, which are RF signal and IQ data (baseband). The RF signal will be received by an RF Front-End device. Then, the digitised output data from the Front-End will be loaded into the GNSS payload hardware, which is the FPGA board, or the digitised output from the Front-End will be loaded into GNSS software receivers such as MATLAB SWRx. This refers to the ground tests, where two approaches—the one with real hardware and the one using advanced simulation with Matlab tools—have been pursued.

The passes from the simulator were conducted at an orbital height of 550 km and various orbital inclination angles relative to the location of the transmitter. The varying closeness of passes allowed the full range of realistic passes to be tested. Continuous wave (CW) interference signals, pulsed signals, and chirp signals were all tested. These are some of the most common types of civilian interference signals that will be encountered. Overall, there was no difference in the way each signal had to be analysed to isolate its Doppler shift and Doppler rate.

3.1.3. Design Decisions

To convert the received data from the time domain to the spectral domain, the FFT was used. Choosing the number of samples to be used in each FFT was an exercise of compromise between the time resolution, frequency resolution, and processing power that would be used. Using a larger number of samples would provide a smaller frequency bin width and thus a higher resolution in frequency. On the other hand, using a smaller number of samples would provide a better resolution in time and use less processing power. The final number of samples was chosen through a process of trial and error by analysing the results of a large number of simulations. The frequency resolution and time resolution both had to be high enough that the signal’s changes in frequency and power over time could be tracked accurately. The final number chosen was N = 2¹⁵ = 32,768 samples, which yielded a frequency resolution of 381 Hz and a time resolution of 2.62 ms at the simulator’s 12.5 Msps sampling frequency. In the hardware process, we tend to use a high sample frequency to make it more flexible and configurable, while, in the post-processing (MATLAB R2023a), we tend to use a low sample frequency to limit the power level. The next FFT was commenced halfway through the current one, following the sequence where the first sample in the n^th FFT was number n∗2¹⁵/2+1 in the total set of data samples. This doubled the time resolution to 1.31 ms. The effect of leakage on the resulting spectra was minimised by applying a window to the sampled data. To be able to identify the signal’s actual frequency, the window’s main lobe should have a minimal width to make the spectral peak as thin as possible. In this case, the size of the sidelobes was unimportant. Three different windows were tested: the Hamming window, the Hanning window, and the Blackman–Harris window. These windows were selected as they all had thin main lobes, thus being good fits for the needed application. The Blackman–Harris window was selected for its superior frequency resolution and its ability to minimise spectral leakage. This window function is known for its high attenuation of sidelobes, which makes it ideal for applications requiring precise frequency domain analysis, such as our task of cancelling the nearest side frequencies. The window’s tapering reduces the leakage of nearby frequency components into the main lobe, improving the accuracy of frequency detection and separation in the processed data. This is particularly important in our case, where minimising interference from adjacent frequency components is critical for achieving accurate results. The SNR of the spectra was increased using averaging. Non-coherent averaging was chosen over coherent averaging as it does not require the time phase of the signal in each set of samples to be the same, which would be impossible to guarantee in this circumstance. As the signal’s frequency moved between the discrete frequency bins over time, only a certain number of averages could be completed before the signal’s power was ‘blurred’ between multiple bins too much. The FFT period was low enough that this effect would only become noticeable if over several hundred FFTs were used per average. Averaging lengths that were powers of two were used as this would be the most efficient way to implement this process on the CubeSat’s FPGA. As shown in Figure 4, averages using 64, 128, and 256 FFTs were tested on a simulated CW jamming signal. They were compared to the same signal that had not been averaged to find the increase in SNR each number of averages yielded. Using 64 averages yielded an increase in SNR of approximately 5 dB. With 128 FFTs, the noise floor decreased by a further $\raisebox{1ex}{$2$}\!\left/ \!\raisebox{-1ex}{$3$}\right.$ dB. Finally, using 256 FFTs, the SNR demonstrated a further increase of only $\raisebox{1ex}{$1$}\!\left/ \!\raisebox{-1ex}{$3$}\right.$ dB. It was clear that using 64 FFTs per average yielded the best increase in SNR (5 dB) for the expected increase in computational power, so this number of averaging was chosen.

3.1.4. Minimum Detectable Power Levels

A simulation of the CubeSat passing from the transmitter’s horizon to its zenith was carried out. The slant range between the interference source and the CubeSat over the pass was calculated. As shown in Figure 5, the slant range decreased from a maximum of 2737 km at the horizon to a minimum of 550 km at the zenith.

The Free Space Path Loss (FSPL) over the pass was calculated. The interference’s frequency was assumed to be 1575.42 MHz. While an actual interference signal may have a different frequency to this, the difference would be so small that the change in FSPL would be negligible. This includes signals in the L5/E5 band. To obtain a basic overview of what Equivalent Isotropic Radiated Power (EIRP) a transmission would have to radiate to be visible to the CubeSat, the FSPL over the pass was taken away from several power levels. This was only a basic overview as the calculation did not take into account other sources of gain and loss, such as the CubeSat’s antenna gain or low noise amplifier noise figure (however, these two values will likely be similar and therefore nearly cancel each other out). The results of this, as well as the FSPL on its own, have been shown with reference to the noise floor in Figure 6. Including the impact of the averaging, the noise floor has been placed at −147 dBm.

The lowest EIRP that was always above the noise floor was 18.1 dBm (64.6 mW). This meant that, if there was a line of sight between the two antennas, the CubeSat should always be able to identify an interference transmission of this power. The weakest detectable transmission had an EIRP of 4.2 dBm (2.6 mW). It would probably be impossible to geolocate a signal with this power as, on the rare occasion that the CubeSat passed close enough to be able to detect it, it would not be distinguishable from the noise for long enough for the geolocation algorithm to work. To determine the interference level, anechoic chamber tests, and measurement power, the knowledge of the antenna patterns will be needed; this will be determined experimentally during further testing the payload.

3.1.5. Tracking of Doppler

The results of an example simulation of a satellite passing over a source transmitting a CW signal are shown in Figure 7. The signal’s frequency was set to 1575.42 MHz and its power was set to 10 dBm. A 20 s simulation was carried out, with the CubeSat crossing the interference transmitter’s zenith at approximately 10 s. The set of spectra resulting from converting the received signal to the frequency domain are shown in Figure 7a and the equivalent waterfall diagram is shown in Figure 7b.

The script to isolate the interference peak was run. Once this had occurred, the frequency of the largest frequency bin in each FFT was recorded. This allowed the discrete frequency Doppler shift to be quantified. The staircase-like graph showing the result of this appears in Figure 8. The truth data (provided by the GNSS simulator) for the Doppler shift were also calculated to validate the accuracy of the geolocation. As the line is slightly unclear over the entire simulation, a two-second extract is shown to clarify its general trend. The discrete curve followed the truth curve very closely, indicating that the result of the calculation was accurate. The point that the CubeSat crossed the interference transmitter’s zenith can be observed at about 11 s. The signal underwent around 10 kHz of total Doppler shift, with 5 kHz of Doppler shift on each side of the zenithal point. Differentiation of the data to find the Doppler rate in this discrete form was not attempted as it would have led to an erroneous result.

After the discrete Doppler shift had been isolated, the next step is to model it as a cubic equation to approximate the continuous-frequency Doppler shift. The result of this is again compared against the truth data to validate the accuracy of the modelling process. This has been plotted in Figure 9. The error between the true Doppler shift and the modelled Doppler shift is shown in Figure 10. The result was very accurate. The modelled cubic equation lines up very closely with the truth data over the entire 20 s extent of the simulation.

The final step that was undertaken was to differentiate the cubic equation to find the interference signal’s Doppler rate. The result of this is shown in Figure 11, where it has been validated against the truth data once more. Again, the result was very accurate, which is 0.13 Hz/s. The error between the modelled Doppler rate and the true Doppler rate was plotted in Figure 12. The error remained very small over the entire simulation, reaching a maximum of approximately 0.35 Hz/s at the beginning of the simulation.

3.1.6. Payload Requirements

The power requirements for the GNSS payload are not only determined by the power consumption of the RF Front-End board but also by the power it provides to the two-patch antenna via the SMA connector. Table 1 at the start of Section 3.1 shows the power consumption and other key requirements of the payload. As shown, the payload has a total power consumption of approximately 0.7 W during data collection, excluding the power consumed by the FPGA to process these data.

3.1.7. Modes of Operation

The GNSS payload has two modes of operation: raw data and spectrum output. In both modes, the RF Front-End will receive signals from both antennas, which are downsampled and digitised before being transferred to the FPGA in real time. When operating in raw data mode, the FPGA will store these digitised signals directly in memory, ready to be downlinked when possible for data processing on the ground. While this mode may only run for a short period of time due to a high data generation rate of 25 MByte/s, it provides an opportunity for more complex signal processing on the ground, including more detailed analysis of interference, as well as navigation and positioning abilities.

Alternatively, when the FPGA first receives the digitised signal in spectrum output mode, the signal is processed in real time, producing a signal amplitude spectrum in the frequency domain once per second. This spectrum output discretises the input signal into 16,384 frequency bins, each with a 32-bit complex value in both real and imaginary planes, providing an effective data rate of 65.5 kBytes/s. This process will run continuously for the full duration of a measurement cycle, resulting in a number of spectra for a specific region. Once downlinked, the spectra can be used to identify the presence of interference as well as determine the type of jamming used in intentional interference.

3.1.8. Safety and Verification of OBDH

FPGAs have been used in space for more than a decade; however, there are some challenges for the reprogramming of the FPGAs due to their sensitivity to involuntary reconfiguration due to single-event upsets (SEU) caused by radiation. Reprogramming FPGA is becoming a very fundamental requirement in CubeSats. It can allow the programming to complete some bug fixing in the system in the last stages of development and also after the launch of the mission. The microchip can offer the CubeSat the highest level of In-Flight reconfiguration by fusing the adaptability of the radiation-tolerant FPGA structure with the effectiveness of the radiation-hardened or radiation-tolerant microcontrollers. We are using a suitable COTS FPGA Zynq 7030, which has been through some radiation testing and has flight heritage.

Microblaze processor that is used for processing the data of the payload provides fault detection feature using parameter (C_FAULT_TOLERANT). These features provide error detection for the internal block RAMs and error detection and correction (EEC) for LMB block RAMs. All the soft errors in block RAM will be detected and corrected once the fault tolerance is enabled. Therefore, this will help to mitigate the chance of failure in space. ECC is automatically enabled in the connected LMB block RAM Interface Controllers by the tools once the fault tolerance in MicroBlaze is enabled. Additionally, the Mircoblaze processor is designed to be implemented in a Triple Modular Redundancy (TMR) implementation. TMR is one of the commonly used techniques in programmable logic designs of the processor. TMR implements three typical designs and then takes the majority vote on the outputs. This voting reduces the potential for a single failure of one implementation [31].

The current design uses a softcore processor to maintain flexibility in the FPGA used and includes a fault-tolerant processor. However, in the Zynq, we also have a dual-core ARM Cortex-A9 processor, which can provide significant processing capability for extended operations of the payload in orbit once the primary mission objectives have been fulfilled, as well as for further development iterations of the payload after the JamSail mission.

3.2. Solar Sail Payload

The solar sail payload can be partitioned into three elements: the sail membrane, the static assembly, and the moving assembly. The sail membrane is a $50\mathsf{\mu }\mathrm{m}$ thick optical film composed of biaxially oriented polyethylene terephalate (BoPET), shown in its deployed state in Figure 13. The majority of this film is unmetallised and embossed with a micro-prism pattern using UV-activated roll-to-roll nanoimprint lithography (R2R-NIL). The patterned moulds used during R2R-NIL were created via greyscale lithography followed by dry etching. The key property of this sail is its ability to generate SRP through the refraction of sunlight rather than the more conventional method of using reflection. This allows it to generate SRP with a significant component that acts parallel to the sail (idealised depiction provided in Figure 14), particularly within a Sun-pointing attitude. In a dusk–dawn Sun-synchronous orbit (SSO) or similar, this would allow the sail to accelerate optimally while within both the maximum illumination and minimum drag configurations simultaneously. This is in contrast to conventional reflective sails, which must sacrifice both their illumination and their drag profiles through tacking in order to align their SRP vector with the desired direction of impulse.

Although attitude control is primarily executed via magnetorquer, it is supplemented by the solar sail. This is principally achieved via an alternatively patterned region around the sail perimeter, wherein the pattern comprises an array of self-stabilising optical elements derived from lightfoils [32,33] rather than micro-prisms. These geometries will cause the sail to naturally oscillate about the Sun-pointing attitude in the absence of active control and expedite the process of converging upon said attitude in its presence. Furthermore, a small section of sail at the anterior edge is metallised; here, SRP is generated normal to the sail through conventional reflective means in order to counteract the torque generated by the micro-prism regions as depicted in Figure 14; this is necessary because SRP that acts parallel to the sail also acts perpendicular to any radial vector drawn from the satellite centre of mass. The effect of this reflective section is that the net torque generated by the accelerating sail is zero in a Sun-pointing attitude, meaning that there is less disturbance torque that the self-stabilising sail sections must counteract.

This membrane is stowed using an origami-inspired folding pattern based on the Miura-ori flasher, as depicted in Figure 15. This membrane is attached to the rest of the payload by way of four flat springs located within the deployment assembly. These are fastened to the moving assembly in turn, which is constrained by the static assembly.

This static assembly serves as the structural interface between the payload and the JamSail bus, houses the membrane, and prevents the moving assembly from being ejected during and after deployment. It is principally composed of a static hub (beige, Figure 16) that is fastened to the satellite bus via screws located at the sail plate above and a reinforcement ring below (blue, Figure 16). This hub also features a membrane cavity, within which the membrane and flat springs are stowed under tension. Furthermore, beneath the static hub lies the compression spring housing (green, Figure 16). This constrains the moving assembly prior to deployment and serves to ‘sandwich’ the four compression springs, which are compressed between the spring dock of the static assembly and the spring moving dock of the moving assembly.

The core component of the moving assembly is the plunger (red, Figure 16), within which the four coiled flat springs are fastened and upon which the membrane rests prior to deployment. This assembly is initially kept static by the aforementioned compression spring housing of the static assembly (constraining it in −x) and by a temporary wire fastening that moors it to the static assembly (constraining it in $+x$). At the start of deployment, these fastenings are severed by way of a thermocutter, causing the moving assembly to rise under the influence of the four compression springs. These act upon the plunger via the four moving spring docks (see Figure 17a). After the flat springs atop the plunger are free of the static housing, they cease to be constrained in the $yz$ plane, allowing them to spring outwards and unfurl the folded membrane. The moving assembly is prevented from being ejected from the satellite by the sail plate, which partially overlaps with the (now extended) plunger at four locations that lie towards the rail attachment points (see Figure 17b).

The moving assembly would be functional with these elements alone. However, several design stressors are placed upon it by the refractive sail membrane. The first is the need to maintain a high degree of sail flatness. A refractive sail has greater sensitivity to solar incidence angle than its reflective contemporaries [25], so an exaggerated sensitivity to wrinkling and billowing may be inferred. Furthermore, unmetallised patterned polymer membranes are atypical of spaceflight, and their tensile performance—particularly under the effects of radiation and vacuum—are not well documented. Greater control over membrane tension is therefore desirable, particularly during deployment and the later stages of the JamSail mission. Both issues can be mitigated through the active control of sail tension. To achieve this, first the sail membrane is segmented into four membranes; during deployment, each membrane segment is only constrained by the single flat spring to which it is attached, allowing it to deploy with theoretically zero tension. In practice, some tension is needed to enable the folded sail to unfurl. The degree of tension that is supplied to the membrane is controlled via nylon rigging that is sewn through the unconstrained sail edge nearest to the flat spring of the neighbouring membrane. It should be noted that the ratio of tension supplied to the sail near the spring tip relative to the spring base cannot be controlled actively and must be determined prior to launch. This is because, despite having several attachment points spanning the flat spring and the neighbouring free membrane edge, each rig is principally coiled into a single coil of wire. It is only by merit of having different lengths that they are able to ‘fray’ into distinct wires with different attachment points. Conversely, the net tension can be controlled actively during a mission by way of a motorised spool. One such wire coil is attributed to each flat spring, and all four share this common spool. Said spool is attached to a single motor, which in turn is attached to the underside of the plunger and rises with it during deployment (see Figure 17a,b). This is so that the rigging has zero motion relative to the moving assembly during deployment; otherwise, sail tension would spike at a critical moment. This motorised spool ensures that tension can be controlled at every stage of the mission and may be used to bring the membrane to failure once a timely deorbit has been guaranteed by the sail, thereby generating useful data regarding unmetallised sail membrane performance in space. However, this configuration comes at the cost of complexity and mass and may be unnecessary during future missions once the relevant literature has been expanded.

3.3. External Cameras

JamSail will include a number of external-facing cameras, including one each on the ±Z faces, pointing nadir and zenith. These cameras serve two main purposes: attitude verification and outreach and will be composed of low-cost, commercial off-the-shelf hardware. The images these cameras capture will be broadcast on amateur radio frequencies unencrypted to be received by anyone with suitable radio equipment.

The attitude verification functionality of these external cameras serves to provide infrequent manual visual confirmation of the ADCS’s ability to orient the spacecraft to the correct attitude. This process will use major identifiable objects and features in the captured images to calculate the visually observed attitude via post-processing on ground and confirm if this is consistent with the attitude reported by on-board sensors. As the ADCS will be aiming to maintain a fixed nadir–zenith orientation for the Z-axis for purposes of the GNSS payload, the images produced by the cameras on the ±Z faces will allow the team to confirm this orientation has been reached and is maintained throughout the operational lifetime of the GNSS payload. If the images produced indicate the spacecraft is oriented differently to the numerical sensor data, adjustments to the pointing algorithm can be uplinked to mitigate against any sensor errors that are identified. Such an attitude verification process is included as a redundant safety feature and is not expected to be used except in cases of suspected errors in sensor data, where anomalous or conflicting values are observed.

In addition, the external cameras will provide important functionality for outreach and education. The images captured by these cameras, both of Earth and of deep space, will be transmitted openly via the radio to amateur radio enthusiasts all over the world, strengthening ties with existing collaborative partners in the local area and building new ties with amateur radio communities elsewhere. Importantly, these images will be transmitted at a suitably low resolution such that a whole image may be received even during short passes where the spacecraft is only visible for a few minutes. By designing the payload in this way, it introduces an opportunity for the educational use of JamSail by schools all over the world, where collaboration with local amateur radio communities can allow schoolchildren to receive their own photos of Earth from space. In particular, specific outreach campaigns will be scheduled throughout the mission, in which specific images of interest are transmitted at pre-advertised times to encourage participation.

Neither of these camera functions requires the camera to be pointed in any specific direction. For attitude verification functionality, they will operate as engineering cameras, providing an independent source of (approximate) attitude detection and verification, which will produce useful data regardless of spacecraft attitude. For amateur radio activities, JamSail will be capturing images as it orbits, and, due to the nature of the activity, it is not designed for taking photos of specific regions. As such, the external camera payload does not produce any requirements or constraints regarding pointing or stability.

4. Primary System Bus

4.1. OBDH

JamSail’s data handling system is split into two distinct halves, one primary on-board computer (OBC) for managing the general operations of the spacecraft and a separate payload computer to handle the GNSS payload operations and communications. This dual-system approach was developed due to the contrasting requirements of the various subsystems in terms of processing requirements, availability, storage capacity, and flexibility. The primary OBC is a commercial device, centred around an MSP430 core with several years of flight heritage across multiple missions. Approximately 16 MB of redundant flash storage is available for holding cached payload data for telecommunications in addition to storing configuration and other data to be utilized across power cycles. A barebones custom operating system written in C will be used for the primary computer. Existing libraries with flight heritage and specificity to the exact hardware will be used for the OBC, radio, and EPS. These libraries have been successfully used together in flight to minimise the risk of unforseen compatibility issues.

The software has a deployment mode to ensure that, upon the first boot, the antenna is not deployed until after 30 min and no data are transmitted until after 45 min in order to comply with the CubeSat Design Specification [34]. Outside the one-off deployment mode, the software instructs the radio to transmit a beacon every 60 s, which contains telemetry from the OBC itself alongside telemetry from the subsystems important for determining spacecraft health. Additionally, the EPS will perform a hard reset regularly (exact interval to be determined; currently 48 h) to reduce errors associated with prolonged uptime. In addition to the beacon, the software also regularly checks whether any payload tasks are pending and executes them as required. Tasks can also be scheduled via time-tagged commands; this currently supports delaying a command by a period of time after it is first processed, but the capabilities are planned to be improved to enable more precise time execution with the real-time clock. If the tasks are finished, the software checks a buffer for a new radio command. Certain mission-critical commands such as direct control of EPS configurable outputs will be assigned higher priority so that these can interrupt existing ongoing tasks.

During general function, the FPGA on the dedicated GNSS payload computer will be processing data from the GNSS payload, which will then downlink the data to the ground via the S-band radio. This secondary system has been selected due to the data processing and storage requirements of the payload, which cannot be feasibly achieved via the primary computer. By offloading this processing to a dedicated payload computer, continued operations of the payload can take place independently of any other satellite function, enabling maximum resource utilisation of the payload. Further information regarding the GNSS payload computer can be found in Section 3.1.

4.2. EPS

The electrical systems for the spacecraft will be provided via a commercial electrical power subsystem, with significant flight heritage alongside other core subsystems. It is capable of powering the spacecraft bus at both 3.3 V and 5 V, with a combined 4 A of current. Six configurable outputs are available for controlling the power for specific subsystems, as well as permanent power channels for core subsystems such as the OBC and primary TT&C system. Each of the outputs feature latch-up protection, with a current limit of 2 A per channel. The EPS will automatically shut down any of these protected outputs within 28 ms if the current rises above this limit, and they will remain disabled until the load is reduced or until the EPS cycles automatically. This will continue every 500 ms if the load continues to exceed the current limit. In addition, the EPS incorporates both hardware and software under- and over-voltage protection. The hardware under-voltage protection will activate a kill switch if the battery voltage drops below the critical limit, disabling all output, resulting in a state in which only battery charging may occur. In addition, a software-based under-voltage protection mechanism activates when the battery voltage drops below a critical level, disabling all the controllable outputs to minimise power draw. For over-voltages, the hardware protection will cut off input from the solar panels, preventing further charge, while the software protection lowers the solar panel inputs to only provide the necessary power to match the output load. Overcurrent protection is also handled by the EPS by triggering a hard reset should the battery current exceed a critical threshold. This shuts down all outputs, including those internal to the EPS, for 400 ms before returning. It is also possible to command the EPS to perform this hard reset from the OBC, which will reboot the system.

The EPS has a number of independent methods of protection during ground processing and launch, including both a kill switch and a remove-before-flight mechanism. Three independent kill switches are present on the board, which isolate the batteries from the rest of the circuitry. Any of these three are able to power up the EPS by closing the kill switch, providing both safe handling on the ground and layers of redundancy for activation post-deployment. The kill switch will serve to prevent power flow during launch via the use of deployment switches that only trigger the kill switch in their open position, a state that is only reached after JamSail has been deployed from the launcher in orbit.

In addition, the electrical power system incorporates a remove-before-flight inhibition system, which cuts off the functionality of this kill switch, preventing the EPS (and in turn the rest of the bus) from turning on for as long as the RBF pin is present. This functionality ensures safe handling on the ground, inhibiting all operations until after the CubeSat has been integrated into the deployer, at which point the RBF pin may be removed, with the kill switch taking over its functionality until successful deployment.

Power generation for JamSail is provided via a series of solar panels located on the spacecraft’s exterior body, which are connected by several charge circuits on the EPS, regulating charging to maximise battery life. Connections between the solar panels are configured such that opposite panels are routed via the same charging circuit to maximise the power that can be generated without hitting current limits. While the current design of JamSail uses solar panels mounted directly to the spacecraft’s body, analysis is underway to determine if deployable solar panels are able to reliably generate power if situated aft of the spacecraft, with sunlight passing through the sail first. Should this prove possible, JamSail will have sufficient power generation capabilities to provide redundancy against the loss of any whole solar panel without impacting operations.

4.3. TT&C

At present, JamSail is planning to use two radio systems. For basic telemetry downlink, beaconing, and command uplink, JamSail will use a commercial UHF transceiver, operating at a communication rate of 9600 bps via FSK modulation. This half-duplex radio communicates using an AX.25 packet protocol, generally operating in the UHF amateur radio band (approximately 437 MHz; exact frequency to be coordinated prior to launch).

The transceiver will be connected to a partnered phasing block that will be used to multiplex its single output into four RF separate outputs, which will each be fed to the appropriate antenna monopole. This system is interfaced with the rest of the bus through a PC/104 adapter board to minimise the communication complexity with other subsystems. The phasing block outputs are connected to an auxiliary board at the extreme end of the spacecraft, where the RF cables terminate in ring terminals connected to monopoles. The antenna and antenna deployer designs will be upgraded designs from similar successful missions (SERPENS and HumSat). The primary antenna is a turnstile with four monopoles and a gain of 2.0 dBi with circular polarisation and omnidirectional radiation. Prototypes of these antennas have been manufactured and are currently undergoing testing and verification of performance prior to final assembly.

For high-volume data downlinking from the GNSS payload, a secondary S-band transmitter will be used to provide a dedicated high-throughput channel for bulk data downlink from the payload. This transmitter, also a commercially available product, will be integrated into JamSail via a direct electrical connection to the payload. As the downlink rate will serve as the bottleneck in data handling for the payload due to its large data volume, utilising this higher-rate system for the GNSS payload enables the team to obtain more experimental data from a multitude of observation locations, which will be invaluable in validating the payload’s functionality.

The primary ground-based communication facilities for the mission will be served by a dedicated ground station situated at the University of Nottingham (Figure 18), which is capable of autonomous tracking and communication in both the UHF and S-band frequencies simultaneously. Secondary ground station facilities will be provided by partner organisations where available, and the communication protocol for UHF transmissions will be publicised in advance of the mission to enable the reception of the beacon and housekeeping data via the open-source ground station network SatNOGS [35].

4.4. ADCS

JamSail will, at the time of writing, utilise a three-axis magnetorquer as the primary attitude control system, supplemented by a series of attitude determination sensors, including Sun sensors embedded in the solar panels, a three-axis magnetometer, and a three-axis gyroscope. Such systems were selected due to their theoretical ability to achieve the pointing requirements of the various payloads; however, this is subject to further hardware-in-the-loop testing prior to launch.

The development of the attitude determination and control system is ongoing. The proposed algorithm, which uses principles of Extended Kalman Filters (EKFs) and B-dot PID control, has started development, and early stage testing has commenced. The ability of the EKF to smooth sensor inputs has been simulated in early-stage testing, as well as the capacity for control of the detumbling and pointing algorithms. Further improvement of these algorithms and systems remains an active area of development.

Further studies are ongoing with respect to the attitude determination and control of JamSail should the system discussed above prove to be incapable of meeting the mission requirements. In particular, the team is investigating the possibility of implementing star trackers for finer attitude determination should this be required, or the addition of reaction wheel(s) to serve as a primary attitude control method where magnetorquers are incapable of maintaining a specific attitude.

Additionally, extended mission operations may investigate non-standard methods of attitude determination and/or control; however, these will be treated as experimental functionality and not considered sufficiently reliable as a mission-critical system. As outlined in Section 3.2, attempts to demonstrate passive attitude control via the selective patterning of the solar sail payload will be undertaken late in the mission. The purpose of this experiment is to determine if such a sail design can be manufactured such that it is self-stabilising in the absence of external attitude control, which could provide significant benefits during future missions. Furthermore, extended mission operations late in JamSail’s concept of operations may investigate if it is possible to determine the attitude of the spacecraft using the two GNSS antennas on opposite sides of the satellite, either via calculating the difference in the calculated position between the two receivers or via observation of known sources cross-referenced against the expected received intensity at varying attitudes. While each of these experimental attitude determination or control methods may be performed on JamSail, none will serve as a primary or backup system due to their unknown performance and reliability.

5. Current Mission Status

At the time of writing, JamSail is in the final stages of design development, and testing has commenced for some subsystems. Significant progress has been achieved with the development of the GNSS payload; the results of the preliminary testing are shown in Section 3.1, with further testing continuing to evaluate the performance characteristics of the software. In addition, work has been underway to perform extensive testing of the payload using a hardware-based GNSS simulator to feed realistic RF signals into the payload to further evaluate its performance. In parallel, additional work to implement software features including obtaining a GNSS position solution is underway and being tested with the same hardware simulator, and efforts to compact the payload to fit a PC/104 form factor have also commenced.

The solar sail payload continues to remain in active development, with the aim for a prototype to be produced by the end of the year in preparation for the preliminary testing. The manufacturing techniques will be a key focus of the tests to identify any difficulties that may occur in the manufacture of a full-size, space-worthy sail. Additionally, the characterisation of the optical properties of the sail will be tested in order to accurately model the expected in-orbit performance of the sail, and to determine the feasibility of situating solar panels aft of the solar sail. Further design work surrounding the deployment mechanism remains, and testing of prototype models will be performed in the coming months.

The core bus and structure are at varying stages of design and testing, with prototypes of the structure completed to perform a fit check with the relevant bus components. These components have also been tested, both individually and stacked together, throughout the software development phase. At present, the core software framework has been developed; however, additional work is required to fully integrate scheduling functionality for timed tasks, as well as long-term testing-in-the-loop to identify unforeseen issues prior to launch.

At the current rate of progress, it is tentatively predicted that JamSail will be ready to launch no earlier than Q2 of 2026; however, delays to this timeline should not be unexpected pending further results of the component and payload testing. Once launched, the initial operational phase is estimated to last for a period no shorter than 12 months; however, this is expected to be extended on the condition of the optimal performance of all the systems.

6. Conclusions

This paper has discussed the aims and objectives of the JamSail mission and provided a summary of the primary payloads to be demonstrated during the mission. Launching NET 2026, JamSail will serve as an in-orbit demonstration of a GNSS interference mapping payload and a refractive solar sail, becoming one of the first CubeSats to demonstrate such functionalities. The early results from the payload development suggest that the payloads will operate successfully and can be a useful technology in future operational missions. The work to develop the payloads and core system bus continues, and integrated testing of the subsystems and payloads is being performed to validate the design choices. In particular, this includes the continued development of the software for both the primary computer and GNSS payload computer to configure them both to perform the required functionality in a range of expected states while continuing to perform their intended purposes in the event of other subsystems failing. As the testing of all the components continues, the design of the spacecraft hardware and software will be optimised based on the results observed in order to maximise the mission success, flexibility, and duration.