Development and Evaluation of a LiFi-Transceiver Module for TMTC Intra-Satellite Communication ^†

Abstract

The use of Light Fidelity (LiFi) can enable the reduction of satellite mass by reducing the wiring harness while avoiding electromagnetic interference. In this paper, a LiFi-transceiver suitable for Telemetry and Telecommand (TMTC) intra-satellite communication is developed and evaluated. The focus of the implementation is on miniaturization and energy-efficiency. First test results with a simple Transimpedance-Amplifier and an investigation of the achievable eff. data rate depending on different distances and Error-Correcting-Codes and the energy-consumption of the developed transceiver are presented. The results show that the LiFi-transceiver achieves a payload data rate of 77.6 kbit/s with Error-Correcting-Code protection and thus can be used for a reliable TMTC communication within the satellite bus.

1. Introduction

The reliable interconnection of subsystems on a satellite platform is essential for ensuring optimal performance, but it also gives rise to complex wiring harnesses that compromise reliability, contribute to increased mass overhead [1] and hinder the flexibility of Assembly-, Integration- and Testing-Phase (AIT) processes [2]. Consequently, research into wireless data transmission for intra-satellite communication between subsystems has been an area of significant interest for many years.

Several studies have explored the use of Radio Frequency (RF)-based methods, such as the Ultra Wide Band (UWB) [3,4,5], demonstrating promising results in CubeSat platforms. However, these approaches also come with inherent disadvantages, including the potential for Electromagnetic Interference (EMI) with other sub-components and susceptibility to interference by themselves, thereby posing a security risk through spoofing or jamming [6].

To overcome the limitations of RF-based solutions, the SatelLight [7] project aims to use wireless communiction through a completely new approach via LiFi [8]. Unlike conventional optical communication methods, LiFi does not require fiber optic cables, and transmission takes place in free space. In addition, it adds no EMI to the satellite, cannot be interfered with or read from outside the satellite structure and offers a high bandwidth for both redundant channels for reliable transmissions or high data rate transmissions.

In addition, the use of LiFi offers further advantages, especially in terms of meeting different requirements, such as the direct connection of external modules without optical–electrical conversion, but it also supports the energy-autonomous operation of micro-components using energy from light (e.g., sensors) [9]. Like RF-based solutions, the elimination of a large part of the harness reduces assembly times and potential problems caused by faulty cabling.

The advantages of the SatelLight approach can be summarized as follows:

• Significant reduction in the harness and thus savings in mass, assembly time and the avoidance of potential sources of error.
• In contrast to RF solutions, LiFi does not emit any EM radiation and therefore does not interfere with electronic components.
• LiFi transmission is completely shielded within the satellite structure and therefore cannot be interfered with or tapped from outside (cyber security).
• Direct integration of external modules (e.g., in docking mechanisms, as described in [10]) without optical–electrical conversion.

In this paper, a first prototype of a LiFi-transceiver module is presented, which is tailored for intra-satellite communications for reliable TMTC communication. The primary requirements were the miniaturization of the module, reliability and energy efficiency of the communication. The conceptual design of a transceiver is presented. The suitability of a TIA for the reception of LiFi signals is simulated and evaluated in laboratory tests. Furthermore, the data transmission is secured by different Error-Correcting-Codes (ECCs). The results show that LiFi transceivers can be implemented in a highly miniaturized form and that data transmission of up to 94.3 kbit/s (no coding)/77.6 kbit/s (Reed-Solomon) is possible, which is already suitable for the transmission of TMTC in satellites.

2. Related Work

The topics of LiFi, OWC or Visible Light Communication (VLC) for commercial applications are extensively presented and explained in [11,12,13]. LiFi is of great interest for the upcoming mobile radio standard 6G, particularly because of its high bandwidths [14]. However, the focus of this work is TMTC intra-satellite communication applications where high-bandwidth is less important but small form factors and reliability are required.

There are already some works that use OWC technologies for intra-satellite communication. The FOTON-M3 mission and the Venus Express OWLS Flight Technology Demonstrator used and demonstrated an Optical Wireless Links for Intra-Satellite Communications (OWLS)—Controller Area Network (CAN) bus [15]. The OPTOS-Satellite is the first satellite whose communication bus is completely wireless and based on the OWLS-CAN bus [16,17]. OWLS technology should mainly work as physical-layer substitution with zero or minimum impact on the network architecture [15]. In contrast, the presented work in this paper not only deals with the physical layer consisting of components and modulation, but also includes the coding of the data to make communication even more reliable. Furthermore, OWLS is based on infrared, while our work uses visible light.

Similar to our work, Ref. [18] presents an OWC system for intra-satellite communication specifically designed for CubeSats up to 3U. Their main focus is the front-end for high throughput without considering possible control or Forward Error Correction (FEC) mechanisms. They used a Vertical Cavity Surface-emitting Laser (VCSEL) with a ball lens for better diverging light and an Avalanche Photodiode (APD) with integrated TIA, and they measured the BER and the optical power, achieving a data rate up to 100 Mbit/s and a distance of 40 cm.

3. Transceiver-Design

SatelLight mainly addresses LiFi communication for small satellites and CubeSats. For this reason, one of the main criteria is the size and mass of the transceiver. Complexity should be reduced to a minimum but still have the possibility to implement redundancy mechanisms. Furthermore, the power consumption should be minimized.

In this section, we first present the development of the hardware of the transceiver. Following this, the software architecture is shown.

Figure 1 shows a block diagram that provides an overview of the architecture of the developed transceiver module.

3.1. Transimpedance-Amplifier (TIA)

A Transimpedance-Amplifier (TIA) similar to that in [19] or [20] can be used to convert the current produced by a photodiode into a voltage and amplify it.

It consists of an Operational Amplifier (OPA), a resistor $R_{FB}$ and a capacitor $C_{FB}$ in the feedback path and the photodiode, as shown in Figure 2. The feedback resistor $R_{FB}$ determines the gain of the input current to the output voltage. The feedback capacitor $C_{FB}$ is used to stabilize and remove unwanted oscillations. The two resistors $R1$ and $R2$ act as a voltage divider to provide a negative bias voltage to the photodiode anode. A negative voltage on the photodiode anode causes the photodiode to operate in photoconductive mode, which reduces its capacitance and enables a faster response [19,21].

The resulting bandwidth depends on the Gain-Bandwidth-Product (GBP), the feedback resistor $R_{FB}$ and the total parasitic input capacitance from the photodiode and the operational amplifier, and it can be calculated with the following equation [19,22,23]:

$$f_{-3\mathrm{dB}}=\sqrt{{\displaystyle \frac{GBP}{2·\pi ·R_{FB}·C_I}}}.$$

(1)

A first simulation with the OPA355 was performed to determine the frequency response of it. The simulation ran from 1 Hz to 200 MHz. Figure 3 shows the gain in dB over the frequency axis. The −3 dB point of the gain in the simulation is 1.6 MHz. In Figure 4, three measurements were taken with a square wave pulse signal that has been converted into a current source using a resistor to mimic a photodiode and determine the behavior of the OPA in general. It can be seen that although the current at the input is not optimal and is significantly attenuated at higher frequencies, the output still keeps up with the frequency and is capable of amplifying the TIA input signal as soon as it changes its positive or negative sign.

3.2. Implementation

The Microcontroller Unit (MCU) MAX32660 from Maxim is used as a central controller. With the 16-pin wafer-level package, this microcontroller offers a small footprint of max. 1.6 $\mathrm{m}\mathrm{m}\times$ 1.6 $\mathrm{m}\mathrm{m}$. Furthermore, apart from an applied voltage of 1.71 V to 3.63 V and three small capacitors to stabilize supply fluctuations, no other peripherals are required to operate the microcontroller. MAX32660 is therefore suitable for reducing the number of components required in the resulting circuit and, in turn, for reducing the space required. It directly controls the LED to send the data, and it receives the signal detected by the photodiodes. The threshold of the GPIO pin of the MCU is used indirectly as a comparator to convert the analog output of the TIA to a binary signal. On-Off-Keying (OOK) is used as modulation, as this enables an almost optimal use of the available optical power and the required transmitter front-end is significantly simplified [24]. In addition, OOK can be used with existing microcontroller modules such as UART.

The components must be powered by an external $3.3$ $\mathrm{V}$ power supply. External connectors provide the ability to program and debug (SWD) the MCU and to communicate via a serial interface (UART). It is also possible to read sensors or control payloads. The photodiode VBPW34S [25] is used to receive the light signal. It covers a spectral range from 430 $\mathrm{n}$$\mathrm{m}$ to 1100 $\mathrm{n}$$\mathrm{m}$, and it has a sensitive area of 7.5 mm² and an angle at half sensitivity of 65°. The LED LW VH8G [26] was selected because it is very small and provides sufficiently good illumination in initial tests. In addition, the beam angle of 105° at 50% $I_v$ is relatively high and should therefore enable a high light signal when the modules are aligned at different angles to each other. The OPA OPA355 [23] was selected as it performed well in the initial tests. It requires a power supply of 2.7–5.5 V and has a high gain-bandwidth product of 200 MHz and at the same time a small size of 3.05 mm (L) × 3 mm (W) × 1.5 mm (H). In addition, the OPA can be put into power saving mode when not in use.

A TIA, as described in Section 3.1, is used to amplify the light signal captured by the photodiode. The feedback resistor $R_{FB}$ was set to 30 MΩ, which in initial tests enabled a sufficient signal for a distance of about 20 to 30 cm and thus appears sufficient for Cubesats up to a size of 3U. The photodiode has a maximum capacitance of 70 $\mathrm{p}$$\mathrm{F}$. The parasitic input capacitance of the operational amplifier includes the common mode and differential mode capacitances, which are specified as 4 $\mathrm{p}$$\mathrm{F}$ and 5 $\mathrm{p}$$\mathrm{F}$. The total parasitic input capacitance is therefore $C_I=(4 \mathrm{p}\mathrm{F}+5 \mathrm{p}\mathrm{F})+70 \mathrm{p}\mathrm{F}=79 \mathrm{p}\mathrm{F}$. The bandwidth is therefore calculated with Equation (1) to be $115.891$ $\mathrm{k}$$\mathrm{Hz}$. This bandwidth is well suited for TMTC communication.

The components can be arranged on both sides of a PCB smaller than 9.2 $\mathrm{m}\mathrm{m}$ × 9.6 $\mathrm{m}\mathrm{m}$.

3.3. Software Architecture

The software architecture was divided into the following layers: Application, Control, Coding, Protocol, OWC-Front-End (OWC-FE) and Hardware Abstraction Layer (HAL).

At the bottom is the HAL, which provides the basic functionality for, e.g., controlling the LED and reading the photodiode signal, as well as setting the MCU and the OPA to energy saving mode.

Above this layer, there is a layer for the OWC-Front-End (OWC FE). This is used to directly send and receive individual bits and bytes. Currently, UART configured to 1 Start bit, 8 Data bits and 1 Stop bit without parity (8N1) is used for this.

Since the GPIO control is not carried out via the fast Advanced High-performance Bus (AHB), but via the Advanced Peripheral Bus (APB), which only allows for the slow control of the pins, the use of the UART enables faster transmission, while at the same time, synchronization is carried out at byte level.

Furthermore, a layer for coding as well as a small protocol layer were created. The Hamming (7,4) and Reed-Solomon (255, 223) codes are currently implemented. In case one of these codes is used, the resulting message frame size is greater than 1, which is why in these cases an additional synchronization symbol (ASCII: SYN, DEC: 22) is sent beforehand for synchronization at message level and to recognize the start of a message at the receiver side. Additionally, within the Reed-Solomon code, the length of the message to be transmitted is added at the beginning. This results into a length of 256 bytes, where only 222 bytes are actual information. In the case of the Hamming code, 3 parity bits are added to 4 bits of information. Thus, one byte (8 bits) is split into two half bytes ($2\times 4$ bits) and encoded independently of each other with 3 parity bits each, resulting into $2\times 7$ bits. The SYN symbol can also be represented with 7 bits. Therefore, when using the Hamming code, the UART can be configured to 7 data bits. The overall amount of data to be transmitted results into $3\times 7=21$ bits (1 SYN Byte and 2 half bytes with 3 bits of parity) for 8 bits of information. Due to these extra symbols and redundant information, the coding rates decrease to the rates shown in

Table 1. Used codes and their rates.

Coding	Coding Rate ${\mathit{R}}_{\mathit{code}}$	UART Rate ${\mathit{R}}_{\mathit{uart}}$	Effective Rate ${\mathit{R}}_{\mathit{eff}}$
No Coding	1	${\displaystyle \frac{8}{10}}$	${\displaystyle \frac{8}{10}}=0.8$
Reed-Solomon	${\displaystyle \frac{223-1}{255+1}}={\displaystyle \frac{222}{256}}$	${\displaystyle \frac{8}{10}}$	${\displaystyle \frac{222}{256}}·{\displaystyle \frac{8}{10}}\approx 0.694$
Hamming	${\displaystyle \frac{8}{3·7}}={\displaystyle \frac{8}{21}}$	${\displaystyle \frac{7}{9}}$	${\displaystyle \frac{8}{21}}·{\displaystyle \frac{7}{9}}\approx 0.296$

.

At the highest control layer level, a simple Application Programming Interface (API) for data transmission is provided to the user, enabling function calls like is_data_available(), send() or start_receiving(), as well as configuring the baud-rate and coding.

4. Evaluation

4.1. Test Setup

The evaluation is carried out with two LiFi-transceivers aligned in front of each other. To avoid unwanted external influences, these are placed in a closed box (see Figure 5b). The two LiFi-transceivers are set up at different distances from each other and are controlled by a host PC via the serial interface (as depicted in Figure 5a).

The host PC configures the settings such as the baud rate and code. The test data are written into the buffer of the sender and the receiver is configured with the expected datalength. The test data consists of $3\times 500=1500\mathrm{bytes}=$ 12,000$\mathrm{bits}$. Since the receiver knows the expected number of bytes, it can send a signal to the host PC when these have arrived after successful transmission. Otherwise, there is an additional timeout that can be used if the data are lost during transmission. The host PC then starts the transmission. Following the data transmission, the host PC reads the received data from the receiver and calculates the Bit Error Ratio (BER).

4.2. Bit Error Ratio (BER)

The Bit Error Ratio (BER) is the ratio of erroneous bits to the total number of all bits sent. To obtain this, the received data are compared with the sent data at bit level, and the total number of erroneous bits is counted. With the total number of bits n and the number of erroneous bits w, the BER can be calculated using the following equation: $BER={\displaystyle \frac{w}{n}}$.

4.3. Effective Data Rate

The data rate depends on the baud rate and the used coding. The effective rate $R_{eff}$ is the ratio of the number of information bits to the total number of bits that need to be transmitted. Table 1 lists the implemented codes from Section 3.3 and their rates ($R_{code}$), the rate by the UART ($R_{uart}$) and the resulting effective rate. The effective rate is calculated by multiplying the following two rates: $R_{eff}=R_{code}·R_{uart}$. The rate from the UART is $R_{uart}={\displaystyle \frac{8}{10}}$ in the cases of no coding and Reed-Solomon coding. For Hamming coding, the UART is configured to transmit only 7 data bits, which is why the rate for $R_{uart}$ is ${\displaystyle \frac{7}{9}}$ in this case.

The data rate is finally calculated by multiplying the effective rate and the baud rate. In the following, only the data rate is considered.

4.4. Results

The results of the BER in relation to the eff. data rate for different distances and codings are shown in Figure 6.

Each diagram shows a different distance. The blue curve shows the results for no coding, the red curve for the Reed-Solomon code and the green curve for the Hamming code. For the codings, the results show the BER after the messages were corrected, but the detection of faulty messages is not considered.

It can be seen that the BER increases with an increase in the eff. data rate, which means that more bit errors occur. A $BER>50\%$ results from data loss.

In most cases, the BER is zero for lower data rates, followed by a second area with alternating $BER=0$ and $BER>0$ at some points, ending with an area with $BER>0$ at all points. The maximum eff. data rate with $BER=0$ in the first area is denoted as the “worst case” and the maximum eff. data rate with $BER=0$ in the second area (which is the maximum eff. data rate with $BER=0$ overall) is denoted as the “best case”. These points are extracted and shown in Figure 7 in relation to the distance.

In the case of no coding the maximum eff. data rate at the best case is almost always the highest, while the maximum possible eff. data rate in the case of the Hamming code is always the lowest. This reflects the effective rates calculated in Section 4.3.

It can also be seen that in the worst cases, the maximum eff. data rate for no coding and the Hamming code are more reduced than that of Reed-Solomon in comparison to the best cases.

The possible eff. data rate is reduced with shorter distances. The highest eff. data rate is 94.3 kbit/s (no coding), 77.6 kbit/s (RS) and 28.4 kbit/s (Hamming) at a distance of 20 cm. At the distances of 5 and 10 cm, the eff. data rate reduces to a range of 100 bit/s.

When configured as a transmitter (OPA off, LED on), the power consumption of the transceiver is 32.6 mW. Configured as a receiver (OPA on, LED off), the transceiver requires 38.7 mW. In case where not much processing is needed and the MCU can enter sleep mode, these values are reduced to 19.7 mW and 31.2 mW, respectively.

5. Conceptual Integration into the Satellite Architecture

For general TMTC, satellite subsystems typically use reliable and redundant fieldbuses like SpaceWire, MIL-STD-1553, or CAN for intra- and inter-subsystem communication. These buses offer a low bandwidth (kbps) but ensure high reliability and real-time capability [27]. We have already shown that the required bandwidths are possible with LiFi. Reliability and real-time communication are possible using, e.g., TDMA MAC protocols [28]. The wide spectrum of light also offers further redundancy on the PHY layer, increasing fault tolerance. Wired bus systems can be replaced on the link layer. Hybrid operation is also possible, as subsystems can communicate transparently with each other on the network layer.

6. Discussion

We observed the strongest reduction in the maximum eff. data rate with no coding or Hamming code in the worst case in relation to the best case, as compared to the Reed-Solomon code, which may be due to the enhanced correction capabilities. It is also worth mentioning, that by using the Reed-Solomon code, in every case where $BER>0$, it was recognized that the message was faulty. This emphasizes the increase in reliability by using the Reed-Solomon code in relation to the other two configurations. However, the max. eff. data rate without coding with $BER=0$ is still higher than with coding. This may result from the overhead and thus smaller eff. rate. Nevertheless, when using the faster transmission rate without coding, one could not be sure that errors would not happen.

The fact that the achievable transmission rate decreases at shorter distances may be the result of saturation due to the higher light signal and thus overloading of the operational amplifier. Reflections could also have a negative influence on the transmission rate. This can be improved by reducing the gain for shorter distances and adjusting it to the specific setup requirements where satellites are an ideal environment due to the static setup.

7. Conclusions

Wireless intra-satellite communication based on LiFi provides reduced harness and more flexible AIT, and it offers advantages over RF-based solutions in terms of EMI and security aspects (spoofing and jamming). In this work, the first developments and evaluations from the SatelLight [7] project were presented. A TIA for a LiFi receiver was simulated and a LiFi-transceiver based on that was implemented for the TMTC communication of small satellites. The transceiver can be highly miniaturized to a size smaller than 9.2 mm × 9.6 mm and a maximum power consumption of 38.7 mW. In the future, LiFi can be used in addition to TMTC communication with low bandwidths due to the large and unregulated spectrum of light for various interfaces within the satellite, which was successfully demonstrated in this paper.