# Software defined radio implementation optimized for nanosatellites

Robinson Carrere, Guillaume Ferre, Bertrand Le Gal, Philippe Cais

► To cite this version:

Robinson Carrere, Guillaume Ferre, Bertrand Le Gal, Philippe Cais. Software defined radio implementation optimized for nanosatellites. FAR 2025 - 3rd International Conference on Flight Vehicles, Aerothermodynamics and Re-entry, European Space Agency (ESA), May 2025, Arcachon, France. pp.1-8. hal-05232579

HAL Id: hal-05232579

https://hal.science/hal-05232579v1

Submitted on 1 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# SOFTWARE DEFINED RADIO IMPLEMENTATION OPTIMIZED FOR NANOSATELLITES

Robinson CARRERE<fnref n="1" />), Guillaume FERRE<fnref n="1" />), Bertrand LE GAL<fnref n="2" />), Philippe CAIS<fnref n="3" />)

## ABSTRACT

This paper describes the ongoing development of a custom radiofrequency front-end using a software defined radio for a NanoSatellite payload. Currently working IoT experimental receiver for direct Earth to Low Earth Orbit (LEO), we needed a spatialized radio device to embed in a 3 Units CubeSat. Software defined radio are really convenient for experimental transceiver thanks to their adaptive nature. In fact, they can be easily reprogrammed after being deployed, which can be useful if embed in a satellite. However, the framework constraints prevented us to use off-the-shelf devices. This leaded us to develop a custom architecture for low power system. The following study explain the engineering choices that were made for the design, the differences with marketed devices and finally the test bench made for validation. Our payload is ISM oriented, but other users could adapt this architecture to various frequency bands for their own applications.

**Index Terms—** IoT, Low Earth Orbit, Software Defined Radio, CubeSat, ISM

## 1. INTRODUCTION

Nowadays, the spatialized technologies and the launch cost of satellites are becoming more and more affordable. The satellite market is growing each year as new users gain access to space devices for services or experiments. Therefore, new solutions will have to be designed to propose specific technologies for new use cases. In fact, different users would need different solutions for various new space applications. To this end, the adaptive nature of software defined radio (SDR) makes them very attractive as transceiver devices for nanosatellite as they can be reprogrammed for multiple purposes. In our research work, we develop an SDR front-end for direct Earth to Low Earth Orbit (LEO) IoT experiment following the work described in [1] and implemented by [2]. However, off-the-shelf devices are sometimes too heavy compared to nanosatellite constraints. Our nanosatellite is part of the NanoLab Academy program by the CNES. This program provide CubeSat platforms to academic space center, easing the access to space experimentation for local laboratory. In this framework we are dependant on certain constraint specific

to this platform, of which off the shelf devices hardly respect. When it comes to SDR transceivers, the price, the consumption, or even the number of interfaces needed can be restrictive depending on the framework. That is especially true when several payloads need to share the system resources. From this observation we wish to share some insight of the development of such a radio frequency circuit board, compliant with space requirement, and suitable to a CubeSat framework. The first part will be an overview of marketed SDR for nanosatellite and some of their characteristics. In the second part, we continue on our framework constraint, and compare it to the previous solutions. We will then explain our design choice, the requirement to export it to other frameworks, and finally the ways we are testing this solution.

## 2. SDR TRANSCEIVERS FOR NANOSATELLITE

Radio communication is a key feature of any satellite, as it is mandatory to drive it and establish services. Modern satellites don't rely anymore on a fully analog based radio system because of their lack of flexibility for the analog system cannot be updated remotely. From this observation, new radio devices including a digital part are developed and adapted for space usage. Consequently, software-defined radio took a place in this new market. However, because of the wide range of applications of these complex radio frequency integrated circuits (RFIC), it can be overwhelming to implement this kind of device. When it comes to CubeSat, which are nanosatellites composed of one or more 10 cm cubic modules, the industry already offers several solutions for SDR based radio system for satellite. These devices mostly implement the SDR on complex custom boards, to be able to program every features. These board can be too big too or expensive for simple uses. Most of uses case would not need such a wide range of application. In fact these commercial board aim to target the largest audience rather than specific services. For instance ones may need only TX features or only to communicate on a narrow frequency band. For those user implementing a transceiver working over 70MHz to 6GHz may be oversized. Moreover, most of the time, the detailed architecture of these commercial products is not available to the public. Consequently, for a standardized CubeSat frame-

<footnote n="1">1) IMS Laboratory UMR CNRS 5218, Bordeaux INP, Bordeaux France,</footnote>

<footnote n="2">2) Inria, IRISA, UMR CNRS 6074, Univ. Rennes, 35042 Rennes, France,</footnote>

<footnote n="3">3) LAB UMR CNRS 5804 University of Bordeaux, Talence France,</footnote>
work, a simple and adaptive design of an SDR based radio communication device can open new opportunities of services and experiments.

Marketed devices such as the Totem SDR transceiver, provided by Alén space [3], propose a design based on a Xilinx System on a Chip (SoC), using an embedded Linux for control that is also used for baseband decoding. The S2DR 1000 Dual transceiver by Augustus Aerospace [4] company is even more complex, as it integrates two different Analog Devices SDR chained together for RX and TX applications. These SDR are commonly controlled by a Xilinx Z7000 SoC. The CNES's platform called SEED, which is used for the core features of nanosatellite like EYESAT [5] is based on a Z7030 SoC from the same Xilinx Z7000 family. This SoC is used as On-Board Computer (OBC) and is integrated on a custom printed circuit board (PCB). In our case for price and power consumption considerations, we cannot afford to embed another of these SoCs for a single payload. Consequently, we choose to implement a disk partitioning on the OBC and dedicate one of the SoC core to the baseband decoder of our experimental radio receiver. In fact the CubeSat OBC's only use a single core of its SoC to run the CubeSat management tasks. Hence the disk partitioning to take profit of the unused ressource for our baseband decoder. The need to split the radio-frequency front end from the baseband processing system explains our motivation behind the development of such a custom architecture.

Both of the SDR transceiver cited earlier are based on the AD9364 software defined radio from Analog Devices. Indeed, spatialized SDR are not common, and such RFIC must be space qualified as they contained a lot of subsystems that can be affected by single event effects. From the radiation benchmark made by NASA in [6], it appears that the AD9364 offers good performances over the amount of radiation that occurs in low earth orbit. For this reason, the industry tend to use this very same SDR RFIC with the Xilinx SoC family together. Another reason is because of the tools provided by Analog Device. In fact, Analog Device marketed several test boards which can be coupled with a Xilinx Z7000 like the FMCOMMS tests boards series which can be plugged to a Digilient Zedboard, which is based on a Z7020 SoC, through an FMC connector. For a more integrated test device, there is the ADRV9364-Z7020 evaluation board, which can be really convenient to embed into a larger system because of its size. For hardware development, the constructor has developed a Verilog intellectual property (IP) available to the user to develop custom applications. In terms of software to drive these Analog Devices SDR, there are application program interfaces (API) for Linux distribution as well as for No-Operating System (bare-metal) devices to program the SDR more easily. However the hardware IP core do not include every interface mode of the SDR. On the other hand, the software tools are

developped to match the whole Analog Device SDR series to a set of evaluation board. This add an unnecessary layer of complexity to the API that is not needed when aiming for some specific features.

# 3. CUBESAT'S CONSTRAINTS

## 3.1. Payload control

The NanoNaasc is a 3 Units CubeSat fig.4. It is being developed by the Nouvelle-Aquitaine Academic Space Center (NAASC) in the framework of the NanoLab Academy program by the French National Space Center (CNES), which supplies CubeSats platforms to academic space centers. One of its modules is dedicated to the system power supply, orbitography's devices, ground base communication, and to the onboard computer (OBC). As said earlier, the OBC is based on a Xilinx Zynq7030 SoC integrated on a custom PCB. The CNES also provides a custom operating system especially optimized for this platform.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Nanonaasc</figcaption></figure>

The NanoNaasc will include five payloads [7]. Each payload is connected to the OBC through a PC104 data bus. The OBC control the payload using Serial Peripheral Interface (SPI) protocol. In order to allow different teams to easily interface their payload, it was chosen to establish a generic module for the OBC to communicate with the payload. Each payload is then embedding a low power ATMEGA microcontroller to be controlled by, more specifically the rad tolerant version ATMEGA 128S. All of them are connected to the same SPI bus. We have to connect our payload with the OBC using this standardized interface. The OBC cannot generate and send command long enough to programm our SDR. Consequently a short control word sent by the OBC
will be interpreted by the payload microcontroller to load the
right configuration onto the SDR, depending on the operating
mode chosen.

**3.2. Power management**

For powering up the SDR, several voltage levels are needed. Power supply noise can highly affect RFIC performances. Indeed, this noise can degrade linearity if the voltage control oscillator (VCO) cannot generate accurately the carrier frequency for the different Phase Lock Loop (PLL), which sets the mixer reference frequency. It is then recommended by the constructor to use Low Drop-Out and switching regulators to generate stable voltages from the main battery coarse voltage. Then we need to implement our own power management block to meet the SDR requirements. The AD9364 can be powered only with a 1V3 voltage supply, but in our configuration, three different voltage are needed :

* 3V3 for general purpose supply. General purpose IO will be connected to the microcontroller to monitor the SDR status. Theses will be read by the OBC as health keeping datas

* 1V8 or 2V5 for the digital data interface submodule supply, depending on the output electrical standard needed.

* 1V3 supply for the analog part of the device. This last voltage must be the less noisy as possible, as it impacts directly the signal detection and return to baseband.

The CubeSat platform can supply three voltages, 3V3, 5V and 6-8V from the main battery. The 3V3 and 5V are generated by the platform to be supplied to the payload. They're limited in current, so it will not be impossible to supply our regulator and other components while powering other payloads. We will generate the voltage needed as shown in Fig.2.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Power supply block Design</figcaption></figure>

In fact, a we would still need to perform our own volt-
age regulations for noise consideration, our payload can use
the coarse battery voltage. As said before, the noise consid-
erations for the 1.3 V analog supply are vital, whereas the

noise considerations for the interface supply and the generals
purposes output are less critical. From the 6-8V battery, we
use a step-down regulator with a fixed 3V3 output and an
adjustable output set to 1V8, for other usage it can be adjust
to 2V5. This 1V8 output is fed to an LDO which generate
the 1V3. This way, we ensure that our critical voltage is well
protected against power supply incertitude and does not add
switching noise to the SDR's voltage control oscillators.

**3.3. Payload interface**

The payload on which we are working is an innovative IoT re-
ceiver for direct Earth to LEO communication named ELIoT.
The core of the experiment is the baseband decoding process,
which will be executed by the OBC. The payload PCB main
goal is to input real-time baseband signals to the OBC after
demodulation from carrier frequency and filtering. The mini-
mum signals needed for interfacing the ELIoT payload to the
OBC are the SPI wires, the power supply and system ground
reference, and finally the outputed baseband signals to be fed
to the OBC. Those baseband signals need to be carried by
high frequency capable inout as we need a speed rate of, at
least, 1MSps (Mega sample per second) to respect the real
time decoding constraint that we are aiming for. We will de-
scribe in further detail the data rate and output mode chosen.
Moreover, due to placement of the ELIoT payload, these sig-
nals are going over tens of centimeters, through several con-
nectors. Therefore, we have to use a differential signaling
protocol, for the signal to be self-referenced, avoiding line
disturbances. To this end, four LVDS interfaces are dedicated
to ELIoT.

4. CUSTOM SDR IMPLEMENTATION

We are constrained to use few In/Out signals, and aiming for
a lower power consumption. As said before, the decoding
process is done by the OBC. In this paper, we will focus
on the SDR based radiofrequency front-end: a custom and
low power architecture with limited interfaces and a low level
configuration. Due to the small resources that are dedicated
to this payload, some engineering choices have been made to
bypass basic configurations. Our application only implements
receiving mode (RX), but the design can be easily adapted for
a transmitting (TX) or transceiving (TRX) use case. Fig.3
shows the block design of the ELIoT system.

Core one is used to host the whole CubeSat management,
including avionic, orbitography system, telecommunication
with ground base using S band transceiver and the payloads
control. As said earlier, it sends command to the payload
through an SPI bus on which every payload is connected. The
payload microcontroller read the command to select the ap-
propriate operating mode to executes, among the presets con-
figurations. One of these operations needs to be a health mon-
<figure><img src="image_4.png" /><figcaption>Fig. 3. ELIOT Block Design</figcaption></figure>

itoring of the payload, collecting information such as the PCB temperature to be sent back to the OBC.

## 4.1. Baseband output

Once the SDR is in listening mode, its outputted baseband data need to be transformed into a unique LVDS signal. To respect the real time processing constraint, our decoder requires to be inputted a 1MSps (IQ samples) speed rate, the decoder being the OBC, used as baseband processor (BBP). From its analog to digital converter (ADC), the SDR output 12 bits for Inphase signal (I sample) and 12 other bits for the Quadratic signal (Q sample). Hence, for 1 MSps we need at least a 24 MHz data rate.

The SDR output is chosen according to four parameters :

* The number of port used : Single or Dual port. The AD9364 include two 12 bits bidirectional interfaces port.

* The interface mode : Half or Full Duplex. Half Duplex mode refers to a communication interface where data cannot be sent and received at the same time.

* The functional mode : Timing or Frequency Division Duplex (respectively TDD and FDD). In TDD mode, the transceiver can send and receive data sequentially on the same frequency canal but on different time slot. In FDD mode, the transceiver used two slightly different carrier frequencies to perform TX and RX communication at the same time on both canal.

In term of speed rate, any configuration fit our need. Moreover, ELIOT being only a receiver, we do not need to input baseband TX data to the SDR, so FDD, TDD, Full

<table><thead><tr><th rowspan="2">Operating Mode</th><th colspan="2">Maximum Data Rate<br>(Combined I and Q Words)</th><th colspan="4">Maximum RF Channel Signal Bandwidth</th></tr><tr><th>SDR (MSPS)</th><th>DDR (MSPS)</th><th colspan="2">Using Minimum Sample Frequency</th><th colspan="2">Using 2x Oversampling</th></tr><tr><th></th><th>SDR Bus (MHz)</th><th>DDR Bus (MHz)</th><th>SDR Bus (MHz)</th><th>DDR Bus (MHz)</th><th>SDR Bus (MHz)</th><th>DDR Bus (MHz)</th></tr></thead><tbody><tr><td>Single Port Half Duplex</td><td>30.72</td><td>61.44</td><td>30.72</td><td>56¹</td><td>15.36</td><td>30.72</td></tr><tr><td>Single Port Full Duplex</td><td>15.36</td><td>30.72</td><td>15.36</td><td>30.72</td><td>7.68</td><td>15.36</td></tr><tr><td>Dual Port Half Duplex</td><td>61.44</td><td>122.88</td><td>56¹</td><td>56¹</td><td>30.72</td><td>56¹</td></tr><tr><td>Dual Port Full Duplex</td><td>30.72</td><td>61.44</td><td>30.72</td><td>56¹</td><td>15.36</td><td>30.72</td></tr></tbody></table>

¹ Limited by the analog filter bandwidth.

<caption>Fig. 4. AD9364 Maximum data rate</caption>

or Half Duplex could be equally used. The AD9364 be interfaced using two electrical standard, LVDS (Low Voltage Differential signal) or CMOS Complementary Metal Oxide Semiconductor). The minimum number of IO (for RX or TX only) being 12 for the LVDS standard and 6 for the CMOS. We will implement a deserializer to convert these signal into the one LVDS peer inputted to the OBC. Our main restriction will come from the choice of this deserializer, which need to be qualified to space condition. The chosen deserializer is the SN65LVDS151 as it is part of a component series that was partially tested under space condition. This deserializer support up to 10 CMOS input bits and can operate at 200 Mbps. Knowing this, the appropriate configuration would be the single port, Full Duplex, CMOS. Under this configuration, the sorting of data outputted by the SDR is described in fig.5.

<figure><img src="image_5.png" /><figcaption>Fig. 5. Receive Data Path, Single Port FDD</figcaption></figure>

We can see in this configuration that the IQ samples LSB and MSB are interleaved. On the BBP side, we will need an FPGA IP to concatenante the Inphase and Quadratic MSB and LSB into memory slots. To properly synchronize this IP a buffered version of the 24 MHz data clock will be send to the OBC. In fact, no intervention from the OBC processor nor reprogrammation of the FPGA should be necessary as it also hosts the whole CubeSat management. We need to make sure that every signal needed to sort incoming data are inputted, so the OBC don't have to generate any signal that depend on the SDR speed rate. Finally with this additional data interface block, we reduced the SDR output to four signals in RX mode, compared to the fourteen minimal signals used in the basic AD9364 /Zynq7020 design, matching the four LVDS peer dedicated to our payload.

## 4.2. Clocking system

The clocking system is an essential part of any radio, wireless, and telecommunication technology. In fact, a radio system need a very low noise reference clock for its modulator /
demodulator to match the carrier frequency in addition to other reference signals to clock the outputted baseband data or others digitals parts.

The AD9364 uses fractional-n phase lock loop (PLLs) to generate the frequencies needed for the subsystems from a master reference clock. The SDR needs to generate the transmitter and receiver local oscillator (LO) frequencies to match the signal carrier frequency, this is done by the radio frequency PLLs (RFPLL). It also decimates the reference frequency with a baseband PLL (BBPLL) to clock the digital part of the system: data converter, digital filters etc. The reference clock will be supply by the OBC temperature control crystal oscillator (TCXO). As in every embed system, thermal variation is a sensitive matter, the RFPLL and BBPLL should maintain a minimal frequency drift with temperature. It is more economic to use the trustworthy high frequency oscillator, already used for the main S band transceiver device, than embedding another hardware piece local to the payload which would still need to be regulated. Moreover, the best performances should be seen with the highest slew rate as possible. The reference clock will then be supply by the OBC to the payload using LVDS electrical standard. In the payload, it will be converted to CMOS standard then dropped to 1V3 to be inputted to the SDR.

<figure><img src="image_6.png" /><figcaption>Fig. 6. Clock tree</figcaption></figure>

The SDR includes two RFPLL to separately generate RX and TX frequency, both are identical. As we will only use the SDR RX functions, we will not study here the TX clocking tree in further details, the RFPLL would now refer to the RX's one. The best performances are obtained with a reference frequency for the RFPLL in the range of 35 MHz to 80 MHz. The RFPLL maximum recommended phase noise is -90 dBc/Hz at 10Hz from the sideband frequency and -150 dBc/Hz at 100kHz. As an example our experiment use a

125kHz bandwidth centered around the 868MHz carrier frequency. From the datasheet graphic, AD9364 recommend, for our case, a noise power of 10⁻¹⁵ of the total power signal at 868.162 MHz. This will be tested for our use case within the qualification model our of custom front-end PCB. Fig.6 summarize the SDR clocking tree according to our use case.

We can note that the 1V3 voltage, which supply the analog part of the radio, supply the voltage controlled oscillator (VCO) internal low drop out regulator, which finally supply the loop filter and the VCO generating the reference frequency for the demodulator. Hence the noise consideration of this specific part.

# 5. SOFTWARE TOOLS

## 5.1. Analog Device software tools

In order to control the AD936X SDR family, Analog Device developed some driver for Linux operating system or for bare-metal platform. However, using these application interface program (API) is not really optimized for our use case. In fact, these programs are made to match different SDR form the series to several processor to target the widest audiences. Moreover this no-Os environment call several platform specifics drivers and librairy in order to generate SPI command and send them to the device. In the final design there will be no FPGA IP core specific to the SDR, the ATMEGA will program it by itself. Some API's function also perform request to the SDR that are not needed, for instance, asking for the device part serial number or writing to register that don't even exist on our AD9364. Finally from ground base we will drive the payload through the OBC, the control word basically consist in choosing a preset operating mode. Ideally, an operating mode will only correspond to some preset register values stored in the microcontroller memory. Most probably will we still have to adapt and use some of the API specific functions that control sensitive analog submodule of the device. For instance the differences gain table can be fixed, and for the Tx part we do not even need it. The data interface will not change either as the payload is designed to use only a specific device's data port configuration. In opposition the PLL VCO's initialization are much more sensitive as the driver can adjust the varactors values several time, depending on the feedback it get from read command on different status register. In fact, we need to make sure that the applied configurations are accurate, as most of the filters and dividers settings permutations will result in non-valid operating modes. We can also note that the Analog Device software oscilloscope can be installed with some plugins to tune AD936X with a simple user interface. Within this software we can also read or write to register and even perform specific operations using the advanced plugins, like build in self test.
## 5.2. Software tools adaptation

As said before, for safety and accuracy, some of the API function will still be needed. The Analog devices software tools are only designed to match ARM computer processing unit core. Atmel microcontroller are AVR architecture, so we will not be able to run the driver natively. We will use test benches to export configuration files that can be loaded with the ATMEGA microcontroller and to determine which setting are most sensitive and need the API to be set. To be sure of the order in which the register categories need to be set, we will use Analog Devices evaluation boards. We apply some setting to the SDR within the No-Os driver while spying on the SPI communication with a digital logic analyzer. This can also be done by modifying the core functions in the source code of the driver, to print each occurrence of the SPI read/write command. This way we can see the exact order in which command are sent to the SDR. We also see which API function call can result in different values applied to one register, between two programmation of the device. For these submodules, adapting the driver functions to the AVR 8-bit microcontroller we use will be safer and easier. In fact the register map datasheet from Analog Device is given as general guidelines but do not elaborate on every detail as they recommend to use their own drivers for their device's programmation. Some submodule register map are even not described at all, like the ADC configuration. In the end, we wish to be able to generate quickly any configuration usable by the payload microcontroller. To do so, we could develop a simple application with user interface, which will run the needed driver function, pick the appropriate fixed register, and deliver an hexadecimal file containing all the register values to write in the appropriate order.

<figure><img src="image_7.png" /><figcaption>**Fig. 7.** ELIoT EM, CubeSat PCB</figcaption></figure>

## 6. ENGINEERING MODEL

The Engineering Model (EM) is the prototyping phase of the development, it needs to include every feature and be interfaced to the OBC.

In order for every team, to ease the process of the payload integration, a generic module was made to connect OBC and payload together, we do not need to take care of that at this stage. A standardize motherboard have been developed for each payload to host their EM daughter board. Six pin headers have been placed on the side to route the PC104 signals use, in addition to several test points to provide access to the IO signals, and to some general purpose output which used to monitor the SDR status.

The EM functional test can be split into two different test benches. The first bench consists in using a Digilent evaluation board like the Zedboard. This allows us to cut off all unneeded features of the hardware design, keeping only the core IPs implementation from the example project. The

goal of this first stage is to build submodules to replace the AD936X IP core use by Analog Device to connect the Zynq SoC to the SDR. This way we try to program the SDR to with an hardware platform that isn't using analog device IP core. Fig 8 illustrate this process.

Analog Device evaluation tools

<figure><img src="image_8.png" /></figure>

Test bench for custom implementation

<caption>**Fig. 8.** ELIoT EM, test bench</caption>

From this design we can add the BBP interfaces IPs that sort, store, and update data, into two memory slots for the decoder, respectively for I and Q samples. When this is completed, we programmed the SPI control block, to load, tune, and test the SDR configuration by enabling one features at a time using several sets of register values and checking feedback for the AD9364. By connecting a logic analyzer to the tests points, we can monitor the SDR status while trying different configurations. Once these basic functions are validated, the core of ELIoT experiment can be tested. In fact ELIoT decoder will use hardware accelerators IP for calculation, to not overwhelm the OBC capability. The hardware development is done on this test SoC to analyze and optimize the ELIoT decoder occupancy before exporting the IPs onto the OBC.
The second test bench is the Nanonaasc Flatsat illustrate in Fig.9, defined as the main test bench for the whole system features, and driven by the flight software. The Flatsat development have been made by the system engineer team using the standardized motherboards discussed earlier, so each payload just have to plug their EM daughter board to the FlatSat.

<figure><img src="image_9.png" /><figcaption>**Fig. 9.** Nanonaasc FlatSat</figcaption></figure>

This way we interface the OBC to the ELIoT radio receiver. On the representation above we can see the OBC being interfaced with a flex PC104 bus to five generic board. Some payload are heavy, consequently they are placed on the side next to their EM generic board. In this flatsat we will first plug our EM to its motherboard and a Digilent evaluation board on the side to implement the baseband decoder IPs on it and to process received data. With this configuration, the ground base send command to the OBC, the OBC send control word to the EM motherboard, The EM motherboard load the appropriate configuration on the payload EM, the payload EM receive and demodulate incoming data from ELIoT emitter and finally the payload EM send baseband data to the Zynq evaluation board.

Finally, we will need to establish communication between the ELIoT decoder and the OBC. We can briefly say that it will be done with shared memory access between the two ARM core, each running a disc partition to respectively host CubeSat management and the ELIoT baseband decoder. But it is specific to our application and out of the scope of this communication. Once this is validated we can merge the ELIoT decoder IPs within the OBC. In the end this test bench should validate every connection between the receiver, the decoder and the OBC.

## 7. INTEGRATION TO DIVERSE FRAMEWORK

Accordingly, to the constraints and engineering choices that have been explained in the previous part, we can limit the prerequisites imposed by our solution. Nevertheless, some of those will depend on the use case. The ELIoT radio frequency receiver need to be powered with a 6V to 8V battery able to supply 300mA. An external reference clock needs to be inputted, the frequency of this signal being in the ranges of 19MHz to 80MHz for better performances. For an easier data sorting on the baseband processor side, after the receiver's serialization, the reference frequency needs to match the input baseband bit rate as a buffered version. In fact, a buffered version of this clock will be transmitted from the receiver to the processor to parse these data. However, depending on the framework capability, it is possible to decimate the reference clock to match baseband bit rate on the BBP side. The output data rate cannot exceed 30.72 MSPs using a double data rate bus, which correspond to a 30.72 MHz speed rate or 15,36 MHz if using x2 oversampling.

<figure><img src="image_10.png" /><figcaption>**Fig. 10.** ELIoT placement</figcaption></figure>

The radiofrequency front end Input signals are described below:

* **IN**: SPI 4 wire interface to the payload microcontroller, an LVDS input clock, the power supply and common ground signal. Finally, one or two RF input port.

* **Out**: The LVDS data out, The LVDS frame clock signal, The LVDS data clock, and an optional LVDS half frame clock (synchronized on the interleaved LSB and MSB of the IQ samples)

The payload occupancy is about a quarter CubeSat unit, in addition to one or two antennas, the AD9364 have two RX
port, connected to the payload using miniatures RF connec-
tors as shown in fig. 10. In our framework we use two RX
ISM patch antennas for us to switch from one to the other
depending on which one is facing the earth. Other user can
easy connect this radio frequency front-end to another PCB
including any custom baseband processor through a PC104
data bus. Within this processor other application could im-
plement a decoder while saving the device ressources used in
marketed devices to embedded a linux or no-os environement
to program the SDR. In fact a unique confiuration is enough
only a flag send by the baseband processor could be enough
to trigger the automatic programmation of the font-end by the
ATMEGA microcontroller.

8. CONCLUSION

In this paper, we choose to communicate on the hardware part
of our experiment, in the hope that new space user would find
interest in it. As explained, the low occupancy that was re-
quired for our team to integrate an experiment, made us real-
ize the lack of diversity for SDR based radio frequency de-
vices and the opacity of marketed devices. This led us to
develop a custom architecture for a spatialized SDR, decor-
related from the baseband processing. Thanks to Analog De-
vice's developement tools we are trying to retro engineer their
solutions to propose a lighter design specific to basic usages
of SDR based front end. The back end processor is left apart
for user to implement their own depending on their frame-
work and their needs. There is still some consideration on
the BBP side that need to be taking care of in order to sort
incoming data but this will be application and platform spe-
cific. We aim to provide a solution adaptable to the whole
ranges of capabilities of the AD9364 with only few adjust-
ments. However for TX application, it is necessary to imple-
ment a module that will feed data to the SDR, this specific
part was not studied here. We finally wish to end on a sim-
ple application that generate specific configurations for this
SDR allowing users to preset their operating modes and not
embed any driver but only the low level mandatory core func-
tion. As example we described here the Nanonaasc satellite
on which the IoT payload is implemented. This CubeSat will
be launched in 2026. Feedback on ELIoT experiments will
follows as well as performance review on this custom SDR
hardware implementation.

9. REFERENCES

[1] G. FERRE M.A. BEN TEMIM and R. TAJAN, “A new lora-like transceiver suited for leo satellite communications,” *Sensors*, 2022.

[2] B. LE GAL L. VOLPIN and G. FERRE, “Efficient lora-like transmitter stacks for sdr applications,” *Proc of ICECS*, 2022.

[3] Alén Space Totem SDR, ”
https://alen.space/products/totem-sdr, 04/20/2025.

[4] Augustus Aerospace Company, “Legacy next gen-
eration sdr,” https://www.augustusaero.com/payload-
systems/next-gen-sdr, 04/20/2025.

[5] CNES, “Eyesat un triple cubesat pour une triple mission,”
https://videotheque.cnes.fr/, 04/20/2025.

[6] Anthony Phan Dakai Chen, Tim Mondy, “Heavy ion test report for the ad9364 rf transceiver,” https://nepp.nasa.gov/files/28554/NEPP-TR-2016-Chen-15-071-AD9364-T031716-TN44752.pdf, 2016.

[7] NAASC NanoNAASC project, ”
https://www.naasc.fr/projet-nanonaasc/, 04/20/2025.