Hardware Tests as Run

DOCUMENT SCOPE

The aim of this document is to clearly explain the tests performed during the delevolpment of the subsystem. 

This document is based on current but also previous versions both of hardware and software and as such be followed with care.

ANTENNA MATCHING TEST

Test Description and Objectives

Antenna impedance matching is a crucial aspect in the design and operation of radio frequency systems. Impedance matching involves adjusting the impedance of the antenna to match the impedance of the transmission line or the RF source to which it is connected. The objective of the test will be to determine the length of the quarter wavelength monopole antenna for the satellite.

Requirements Verification

Requirement ID	Description
AMT - 01	The antenna should exhibit impedance values closely matching the specified target impedance across the defined frequency range (868 MHz).
AMT - 02	Return loss values should be high, indicating a low amount of power reflected back towards the source and efficient power transfer.
AMT - 03	The antenna should demonstrate acceptable impedance matching and performance across the specified bandwidth(125kHz).

Test Set-Up

Materials:

• Vector Network Analyzer (VNA)
• Coaxial Cables
• Antenna
• Computer

Setup

• Prepare the Testing Environment
• Connect the Vector Network Analyzer (VNA)
• Calibrate the VNA
• Connect Coaxial Cables
• Position and Orient the Antenna

Pass/Fail Criteria

Parameter	Pass Criteria	Fail Criteria
Return Loss	Return Loss < -10 dB (lower values are better)	Return Loss > -10 dB (indicating poor matching)
Standing Wave Ratio (SWR)	SWR < 2:1 (lower values are better)	SWR > 2:1 (indicating poor impedance matching)
Impedance Matching	Impedance matched to system requirements	Significant deviation from desired impedance
Radiation Pattern (optional)	Symmetrical and aligned with specifications	Irregular pattern, beam tilting, or distortions

Test Plan

Step - ID	Description
AMT\_S-01	Prepare the Testing Environment: Set up the antenna in the desired location and orientation. Ensure that all cables, connectors, and adapters are securely connected. If applicable, use the mounting hardware to secure the antenna in place.
AMT\_S-02	Calibrate the Vector Network Analyzer: Connect the calibration kit to the VNA using appropriate cables and adapters. Perform a calibration using the open, short, and load standards provided in the calibration kit.
AMT\_S-03	Connect the Antenna: Disconnect the calibration kit and connect the coaxial cable to the VNA. Connect the other end of the cable to the antenna or the matching network, depending on your setup.
AMT\_S-04	Measure the Antenna Impedance: Use the VNA to measure the impedance of the antenna. Observe the reflection coefficient (return loss) and transmission coefficient (insertion loss) on the VNA display.
AMT\_S-05	Analyze Measurement Results: Analyze the VNA measurements to understand the impedance characteristics of the antenna. Look for any mismatch or irregularities in the impedance, which may appear as high return loss or standing wave ratio (SWR).
AMT\_S-06	Optimize and Fine-Tune (if needed): Fine-tune the antenna parameters as necessary to optimize its performance for specific frequency bands or applications.
AMT\_S-07	Save and Store Data: Save measurement data and configurations for future reference.

Test Results

The test was conducted in the autumn of 2022, and the outcomes are as follows:

As can be seen in the figure above, the final antenna had RL(dB) = -10 for the operating frequency. Moreover, the bandwidth of the antenna is approximately 15 MHz.

The result obtained from this test, however, is quite surprising: the antenna length must be 3.5 cm, which is much lower than what was theoretically calculated (8.64 cm). The reason behind this result could be the non-ideal ground plane of the monopole.

Anomalies

Obtained antenna lenght is 3.5 cm, lower than what was theoretically calculated (8.64 cm).

Conclusions

Test should be redone with the final version of the PocketQube.

OBC-COMMS BOARD TEST

Test Description and Objectives

The objective of this test is to validate the correct operations of the COMMS layout in the PocketQube with the OBC&COMMS board.

Requirements Verification

Requirement ID	Description
OCBT - 01	Be able to see MISO, MOSI, SCK, SX1262-NSS, SX1262-NRST and SX1262-BUSY signals.
OCBT - 02	Be able to decodify MISO, MOSI and SCK
OCBT - 03	MISO, MOSI and SCK decodification must match expected results of the datasheet.

Test Set-Up

OBC&COMMS with only used pinouts:

If we zoom into the COMMS chip we get the following:

We'll measure the following pins: MISO, MOSI, SCK, SX1262_NSS. These are the only ones available for comparison with the expected values outlined in the datasheet.

Materials:

• OBC&COMMS board

• Spectrum Analyzer (we used Saleae)

• Multiple Cable Jumpers
• PC with STM32Cube IDE installed
• Two 4.7K Ohms pull-up resistors
• ST-LINK v2

Setup

We will connect the ST-LINK v2 to a PC for flashing code. The SWDIO, SWCLK, and 3.3V ports of the ST-LINK v2 will link to pull-up resistors shown in the following image before connecting them to their respective pins. Meanwhile, the other ports (GND and RESET) will be directly linked to the board.

Pass/Fail Criteria

To verify the functionality of the COMMS chip, we'll compare the obtained results with the expected specifications outlined in the SX1262IMLTRT datasheet.

The test will be deemed successful if our obtained results align with those specified in the datasheet. If they don't correspond, the test will be considered unsuccessful.

Test Plan

Step ID	Description	Pass/Fail Criteria	Actual	Passed(Y or N)
CS - 01	Prepare the setup explained in the previous step	Flashing must be successful, a "successful message" must appear	We encountered a lot of issues when flashing due to poor connections, after many attemps we successfully flashed	Sometimes, had to repeat multiple times until it worked
CS - 02	Flash code, we used the main program (Project>>Build All + Run>>Debug As>>1STM32C...)
CS - 03	Using Saleae, check all pins of the SX1262 chip, especially MISO, MOSI, SCK and SX1262-NSS	Just after flashing we must see signals in all these pins	Only MISO had a visible signal, the others had not	No, no signal was spotted in MOSI, SCK and SX1262-NSS.
CS - 04	Once we have simultaniously captured MISO, MOSI and SCK, decodify the signal	Comparing with the SX1262 datasheet, the decodification must be the one we expected	Since we only obtained the MISO signal, it has been impossible for us to decode	No

Test Results

We encountered several issues while working on the project. Firstly, we faced weak connections between the board and the computer for CS-01 and CS-02, which resulted in several days of troubleshooting. We had to solder connectors to establish a stable connection, but the board remained fragile, and we couldn’t touch it much.

Moving on to CS-03, we encountered three major issues. The first issue was with the tool we used for decodification. We needed three ports to capture all three signals (MISO, MOSI, and SCK) simultaneously, so we had to switch from PicoScope to a Saleae device. The second issue was the small size of the chip and connections, which made it extremely difficult (if not impossible) to capture all signals simultaneously. We recommend adding testing pins to the board in future versions. Finally, the third issue was with the decodification process itself. We could only observe MISO, SX1262_NRST, SX1262_NSS, XTA, and XTB signals. Since we also needed MOSI and SCK signals to decode the signal, we were unable to do so. We also checked the power pins going to the SX1262 and found no issues.

As for CS-04, we were unable to compare it with the datasheet since we couldn’t decode it.

Anomalies

During the project, we faced several issues. As previously mentioned, we encountered anomalies during the test, including fragile connections, small pins on the chip that made it difficult to check all signals simultaneously, and no signal for MOSI and SCK. Unfortunately, we were unable to decode the signal.

Conclusions

As the COMMS subsystem relies heavily on this crucial test, essential for communication testing, we've opted to temporarily skip it. Instead, we will use a spectrum analyzer to verify if the chip is transmitting signals. If successful, it confirms effective communication between the OBC and COMMS chips. However, if no signals are detected, the issue may lie in the connections/design of the board.

RX-TX TEST

Test Description and Objectives

Due to the outcomes of the OBC-COMMS board test, an alternative method is required to validate ongoing communication between the OBC and COMMS chips. To achieve this, we plan to establish communication between a TinyGS and the OBC-COMMS board, effectively simulating the connection between a ground station and our satellite. Furthermore, attenuations will be introduced later in the process to mimic the conditions present in space.

Requirements Verification

Requirement ID	Description
RXTX - 01	Be able to transmit using a TinyGS.
RXTX - 02	Be able to receive the transmitted data using the SX1262.
RXTX - 03	Possess the capability to respond to specific telecommands by transmitting a reply.
RXTX - 04	Have the capability to initiate communication between the TinyGS and the OBC-COMMS while incorporating attenuations.
RXTX - 05	Possess the capability to process telecommands and provide responses while incorporating attenuations.

Test Set-Up

Materials

• Computer with VisualStudio Code (with extension PlatformIO) and STM32CubeIDE
• STM-32 nucleo board
• LoRa module SX1262
• OBC-COMMS board
• TinyGS (868-915MHz LILYGO LoRa 32 v2)
• TinySA Spectrum Analyser
• BECEN SMA Female to Female 50 ohm Push-Button Step attenuator,Key-Press Attenuator,DC to 2.5GHz (90db)

Setup

For the initial and fundamental phase of our test, the setup is as follows:

One computer will be connected to a TinyGS, while the other computer will have a Nucleo+LoRa module connected to it. This configuration allows us to verify the transmission capability of the TinyGS and the responsiveness of the board (initially represented by an STM32 Nucleo + LoRa module).

The setup for the STM32 Nucleo + LoRa module is the following:

After successfully testing this setup, the next configuration is as follows:

Instead of the Nucleo+LoRa, we will integrate the OBC-COMMS board from the OBC-COMMS board test.

As we advance in the testing process, we will introduce a variable attenuator in either reception or transmission.

Throughout the experiment, a spectrum analyzer will be employed to detect the signals transmitted, while the TinyGS console will be utilized to monitor both sent and received data.

Pass/Fail Criteria

The experiment will be deemed successful if the specified requirements are fulfilled, signifying our ability to transmit effectively using the TinyGS, and the OBC-COMMS board responds as anticipated, both in the presence and absence of attenuation.

Test Plan

Step 1: TinyGS configuration

The initial phase of this test involves configuring and preparing a TinyGS station. Since a similar station has been utilized in previous tests, please refer to the instructions provided in the "ᴾᵒCat Testing >> ᴾᵒCat SSVs >> COMMS Software SSV" section for guidance.

Step 2a: TinyGS transmission

Once our TinyGS is configured we can test its transmission capabilities by sending one of the telecommands shown in the TinyGS console. For checking the correct transmission we will used a spectrum analyser.

Step 2b (optional): TinyGS to TinyGS

If encountering transmission difficulties, we can attempt communication between two TinyGS units. This approach allows us to showcase the capability of our TinyGS in both sending and receiving data. The necessary steps involve configuring a second TinyGS (just like we did with the first one) and issuing a telecommand, with the option to utilize the "p" command for sending a test packet.

Step 3: STM32 + LoRa

Upon confirming the proper functionality of the TinyGS, the next step is to connect the STM32 Nucleo + LoRa module to the computer. Subsequently, we will flash our code into it to activate the reception mode of the SX1262 (LoRa module). Finally, we will initiate transmission using the TinyGS and observe if the STM32+LoRa module responds. For this test we will only take into account the "FLASH" and "COMMS" tasks.

Step 4: Board

After confirming the correct functionality of the code on the STM32 Nucleo + LoRa module, we can proceed to the next stage of utilizing the board. If the preceding tests yield success, but this phase encounters issues, we can confidently conclude that the issue lies in the hardware rather than the software, thereby narrowing down the potential sources of errors.

Step 5: Attenuations

If all the preceding steps are successful, the next phase involves experimenting with attenuators to simulate the conditions our system will encounter in space. Common attenuators and a variable attenuator will be employed for this purpose. The objective of this step is to assess the feasibility of transmission under various influencing factors such as distance, speed, angle of the antennas, and other relevant parameters.

Test Results

Step 1:

The configuration of the TinyGS for transmission and reception at 868MHz was completed successfully.

Step 2a/2b:

The TinyGS exhibits the ability to both transmit and receive data, as exemplified by the successful demonstration using two TinyGS units. In the event of possessing only one TinyGS, we can showcase the effective operation of the ground station by employing a spectrum analyzer and receiving signals from satellites that are using the TinyGS network.

Step 3:

Upon flashing our code into the Nucleo and transmitting diverse telecommands with TinyGS, we discovered that the LoRa module failed to transmit responses to the telecommands as expected. Following a thorough and extensive investigation, we identified the root cause of the issue: during reception, the reception buffer requires slightly more time before decoding to effectively process the incoming packets. To address this issue, we implemented a solution by incorporating a small delay. Following this adjustment, we have successfully achieved the reception and response to telecommands sent by TinyGS, as demonstrated in here:

We will commence with telecommands that do not necessitate a response from the PocketQube. To verify proper functionality, we will insert breakpoints within each of these states for testing.

RESET

EXIT STATE

TLE

ADCS CALIBRATION

STOP SENDING DATA

CHANGE TIMEOUT

ACTIVATE PAYLOAD

UPLINK CONFIG

Subsequently, we will perform tests on all telecommands that necessitate a response from the satellite. To test these telecommands, we can choose to either insert breakpoints or examine the responses from the TinyGS terminal.

SEND DATA

SEND TELEMETRY

SEND CONFIG

We can affirm that all telecommands have been successfully transmitted by TinyGS, processed by the Nucleo+LoRa, and appropriately answered when required.

Step 4:

Following the success of the previous step, we proceeded to integrate the actual OBC-COMMS board. However, the experiment deviated from the plan due to several issues:

• The COMMS subsystem remained in LOWPOWER mode instead of transitioning to RX.
• The antenna seemingly received packets from unknown sources (likely interferences), leading to buffer overload.
• The subsystem failed to switch to TX when required.

While we initially anticipated hardware-related problems, a careful examination of variable values (such as the COMMS state or PacketReceived) suggests a potential issue with the OBC and task management rather than the hardware.

To address these issues, several actions were taken:

• COMMS Subsystem Stuck in LOWPOWER Mode: To tackle the problem of the COMMS subsystem not transitioning from LOWPOWER mode, we temporarily deactivated other tasks, as done in the previous step. This suggests a potential issue with the other tasks, likely originating from the OBC.
• Reception of Unknown Packets: To resolve the reception of multiple packets from unidentified sources, attempts were made to isolate the board and TinyGS in a homemade anechoic chamber. Despite these efforts, packets from unknown sources persisted. The next step involves replicating the experiment in a genuine anechoic chamber to determine if the issue can be resolved under controlled conditions.
• State Machine Not Transitioning to TX: Regarding the state machine's failure to transition to TX, it is believed to be a consequence of the previous issue. The satellite's inability to receive useful packets results in a fully occupied buffer, leading to the observed behavior.

UPDATE: Errors were detected on the OBC-COMMS board

1) Mirroring error in one of the OBC crystal oscillator:

The error has already been corrected in the newest OBC-COMMS PCB design. The clock was removed from the board for this test as 

2) Issue with the transceiver clock capacitors. Both transceiver crystal oscillators were removed as per the transceiver datasheet: "The SX1261/2 does not require the user to set external foot capacitors on the XTAL supplying the 32 MHz clock. Indeed, the device is fitted with internal programmable capacitors connected independently to the pins XTA and XTB of the device. Each capacitor can be set independently, balanced or unbalanced to each other, by 0.47 pF typical steps."

Both capacitors were removed.

After implementing the commented modifications to the board, the testing was resumed:

Step 5:

TBD.

Anomalies

As we've been reviewing the test results, several issues were encountered during the process:

During step 3, an issue arose during the reception process, which was successfully resolved by introducing a slight delay. The issue caused the system to "ignore" the sent telecommands.

In step 4, the COMMS subsystem persisted in LOWPOWER mode, necessitating the removal of tasks to facilitate the test. This indicates an ongoing challenge with the OBC subsystem task.

Another issue in step 4 involved the reception of numerous packets from unidentified sources. To address this, further solutions are needed, and the possibility of conducting tests within an anechoic chamber is being considered for better-controlled testing conditions

Conclusions

The issue pertaining to OBC task management must be tackled, as it seems to be the primary cause of the anomalies we discussed.

Furthermore, we must also tackle the problem of receiving numerous packets, as it hinders the reception of the genuinely important ones.

At the very least, we can affirm that the COMMS code is functioning correctly, and the OBC-COMMS board, equipped with the quarter-wavelength antenna, is capable of successfully receiving packets.

DYNEEMA TEST

Test description and objectives

This test aims to evaluate the chosen Dyneema for the antenna deployment. It involves measuring the time taken for the material to melt under atmospheric conditions.

Requirements Verification

• Dyneema must melt using 3.3V and 450mA in a timespan of 5-15 secs.
• Antenna must deploy correctly as shown in the render

Test Set-Up

Materials:

• Dyneema bought from Decathlon (UHMPE 0.35mm diameter, 26 kg)
• 7.5 Ohm resistor (color code(5 bands): Violet, Green, Black, Silver, Brown)
• Voltage and current source
• Timer

Setup:

• Prepare the source at 3.3V and 450mA.
• Prepare a crossbow knot (explained in ᴾᵒCat Assembly and Integration >> Antenna >> Antenna Refurbishment) on the 7.5 Ohm resistor.
• Add a small weight in the other side of the rope to simulate the pressure experienced by the antenna when not deployed.

Pass/Fail Criteria

If Dyneema melts within the range of 10 to 15 seconds at 3.3V and 450mA, the test can be deemed successful. However, if it takes longer or fails to melt, the test will be considered unsuccessful.

Test plan

• Connect the resistor with the knot to the power source.
• Activate the power source and start the timer.

Test Results (1)

• t = 0s

The knot is connected to the resistor and the power source is connected. We used the weight of the lateral board with the antenna to simulate some pressure.

• t = 11s

The knot starts showing signs of degradation as the temperature of the resistor increases.

• t = 14s

The knot melts and the pressure provoques the antenna to deploy.

Some calculations:

Power (W) = Voltage (V) * Current (A) = 3.3 * 0.45 = 1.485 W

Energy consumed (J) = Power (W) * Time (s) = 1.485 * 14 = 20.79 J

Anomalies (1)

None. After repeating this test, it was determined that it needed to be redone as the dyneema did not burn, but melted instead.

Test Results (2)

• t = 0s

• t = 12s

Anomalies (2)

Possible problems with the EPS. Redo the test.

Conclusions

This experiment will undergo repetition within a vacuum chamber due to the differing thermal properties in such conditions. Dyneema is expected to exhibit a significantly faster melting rate as heat transfer with the absence of air in space is not a factor.

ANTENNA DEPLOYMENT TEST

Test Description and Objectives

The primary goal of this test is to validate the satellite's antenna deployment. This step is mission-critical as its proper function is pivotal for the transmission and reception of data by the satellite.

This test might (if possible) also test the comunications with the deployed antenna.

Requirements Verification

Requirement ID	Description
ADTR - 01	Dyneema must melt in less than 15 seconds in vacUum conditions.
ADTR - 02	The antenna must deploy correctly, meaning that it should remain nearly completely straight after deployment.
ADTR - 03	The spacecraft must be able to communicate with the ground station after antenna deployment

Test Set-Up

Materials:

• PocketQube structure with the OBC-COMMS board and an EPS.
• Lateral board with an antenna and low impedance resistor (7.5 Ohms (color code(5 bands): Violet, Green, Black, Silver, Brown))
• Dyneema bought from Decathlon (UHMPE 0.35mm diameter, 26 kg)
• Computer
• Clean room for low contamination
• Vaccum chamber
• Clean room garment

Setup:

• Prepare the computer and a code to activate the "thermal knife" pin
• Refurbish the antenna as explained here
• Add the PocketQube in the vaccum chamber and prepare all connections
• Prepare vaccum (should take a time)

Pass/Fail Criteria

If the Dyneema melts in under 15 seconds in vacuum conditions and the antenna remains straight post-deployment, we will deem the antenna deployment test successful.

Test Plan

Step 1: Antenna deployment

Prior to conducting a test in the vacuum chamber, it is imperative to meticulously examine the feasibility of the test in atmospheric conditions. While the results may vary, the ultimate conclusion remains the same: if the dyneema melts in atmospheric conditions, it will likewise experience the same outcome in vacuum conditions.

To carry out this preliminary test, a PocketQube with, at a minimum, the OBC-COMMS and EPS subsystems is required. The EPS can be powered either by a direct power source or a battery. The activation of the thermal knife will be done using cables activating the BURNCOMMS pins from the OBC-COMMS board.

Step 2: Installation

The initial phase involves preparing the entire test setup, a critical step that will determine the feasibility of conducting the test under vacuum conditions. For this we will follow the Thermal Vacuum Chamber Operations Manual.

In our specific scenario, the test chamber will accommodate a PocketQube containing, at a minimum, the OBC-COMMS and EPS subsystems. The EPS will include a battery, serving as the power source for the thermal knife.

To activate the thermal knife, control over the OBC-COMMS board will be facilitated through cables.

Step 3: Antenna deployment in vaccum

After placing the PocketQube in vacuum conditions, we can initiate the antenna deployment test. To do this, we will activate the BURNCOMMS pin on the OBC-COMMS board. This pin is connected to a low-impedance resistor, which, in turn, is linked to the dyneema for the antenna deployment.

What we will do once we activate the pin is mesure the time it takes for the dyneema to test. We can later calculate the power consumed and perform adjustments if necessary.

Step 4: Transmission

This step is considered optional due to uncertainties regarding its feasibility in our small vacuum chamber. The objective is as follows: utilizing an additional antenna within the vacuum chamber, potentially a TinyGS, we aim to test the deployed antenna by establishing direct communication between the PocketQube and the auxiliary antenna, simulating a Ground Station. Attenuators may be employed to replicate challenging space conditions. The primary goal is to transmit telecommands and assess whether the satellite can respond as anticipated.