# ᴾᵒCat: VGA Payload

# Subsystem Description

## Document scope

<div align="justify" id="bkmrk-this-document-aims-t">This document aims to give insight into the design choices taken in the development of the P/L 1, a video graphics array camera (VGA) conceived originally to monitor the deforestation of the Indonesian rainforest, but later repurposed to collect data of ice levels in polar regions as well as take pictures during the deployment of other artificial satellites.

</div>## Camera selection and requirements

### Camera selection

<div align="justify" id="bkmrk-aligned-with-the-ori">Aligned with the original goal of this payload the camera selected was one which could, first of all, be interfaced with the OBC and offered a resolution higher than 640x480 pixels. Therefore an array of cameras were considered:

</div><center id="bkmrk-name-resolution-%3E%3D-6"><table><thead><tr><th>NAME</th><th>RESOLUTION &gt;= 640x480</th><th>INTERFACE</th><th>CHANGEABLE FOV</th></tr></thead><tbody><tr><td>GalaxyCore GC0308</td><td>Y</td><td>USB 2.0</td><td>Y</td></tr><tr><td>CMT-0.3MP-MK0806-R016</td><td>Y</td><td>USB 2.0</td><td>N</td></tr><tr><td>SC13MPA</td><td>Y</td><td>TTL, RS232, RS485</td><td>N</td></tr><tr><td>SC03MPA (VGA)</td><td>Y</td><td>TTL, RS232, RS485</td><td>Y</td></tr><tr><td><span style="color:blue">PTC06</span></td><td>Y</td><td>TTL, UART</td><td>Y\*</td></tr><tr><td>SCB-1</td><td>Y</td><td>TTL, RS232</td><td>N</td></tr></tbody></table>

Table 1: Camera comparison.

</center>\*Through manual adjustment <div align="justify" id="bkmrk-highlighted-in-blue%2C">Highlighted in blue, the selected camera was the PTC06 manufactured by Putai Electronic Technology, Ltd., as it could be interfaced with the OBC, offered the aforementioned resolution and, as a differential factor, it provided serial JPEG compression and data transmission. The datasheet of the PTC06 is provided [here](https://www.mouser.com/datasheet/2/737/adafruit_english%20camera-1217461.pdf), and further information provided by the manufacturer can be found [here.](https://www.putal.com.cn/556/617/32) A rudimental translation can be downloaded here [Translated PTC06](https://wiki.nanosatlab.space/attachments/413). Some relevant specifications are provided in the following table:

</div><center id="bkmrk-specification-value-"><table><thead><tr><th>**SPECIFICATION**</th><th>**VALUE**</th></tr></thead><tbody><tr><td>Size</td><td>The camera module size is 20x28x9 (not counting the connector height) mm.</td></tr><tr><td>Resolution (pixels)</td><td>VGA (640x480), QVGA (320x240), QQVGA (160x120) but we will preferably use the VGA.</td></tr><tr><td>FOV Diagonal</td><td>64°</td></tr><tr><td>Distortion</td><td>0.38%</td></tr><tr><td>Relative illumination</td><td>&gt;53%</td></tr><tr><td>Operating conditions</td><td>The camera will work in the range of -20°C to 85°C.</td></tr><tr><td>Weight</td><td>3g</td></tr><tr><td>Operating voltage</td><td>The camera can work from 3.3V to 5V.</td></tr><tr><td>Current consumption</td><td>The operation current will be 100mA.</td></tr><tr><td>Data format</td><td>JPEG, stored as an array of HEX bytes.</td></tr></tbody></table>

Table 2: PTC06 Main Specifications

</center>### Requierements

<div align="justify" id="bkmrk-a-list-of-high-level">A list of high-level requirements was elaborated so as to determinate clear guidelines within which the camera payload must operate in order to achieve reliable and quality performance.

- S-CAM-0010: Interface with OBC.
- S-CAM-0020: Minimum #pixels (640 x 480).
- S-CAM-0030: Changeable FOV\*.
- S-CAM-0040: Lens made of glass.
- S-CAM-0050: Temperature range -20 to +60 °C.
- S-CAM-0060: SNR of the images larger than 45dB.
- S-CAM-0070: The resolution should be good enough to notice 100m differences.
- S-CAM-0080: Camera works with 3V3.
- M-CAM-0010: Robustness of the camera in the PCB.
- M-CAM-0020: SNR images larger than 45 dB.
- M-DATA-0010: Acquire 2 images per day.

Due to the selection of the PTC06 some criteria are already successfully meet. The following table provides more insight into the matter:

</div><center id="bkmrk-requirement-status-s"><table><thead><tr><th>**REQUIREMENT**</th><th>**STATUS**</th></tr></thead><tbody><tr><td>S-CAM-0010</td><td>Successfully interfaced through UART</td></tr><tr><td>S-CAM-0020</td><td>Implemented, further testing required</td></tr><tr><td>S-CAM-0030\*\*</td><td>Small change is achieved, but causes bad focalization, further testing required\*\*</td></tr><tr><td>S-CAM-0040</td><td>Met</td></tr><tr><td>S-CAM-0050</td><td>Met, environmental testing required</td></tr><tr><td>S-CAM-0060</td><td>-</td></tr><tr><td>S-CAM-0070</td><td>Not meetable</td></tr><tr><td>S-CAM-0080</td><td>Yes</td></tr><tr><td>M-CAM-0010</td><td>-</td></tr><tr><td>M-CAM-0020</td><td>Met</td></tr><tr><td>M-DATA-0010</td><td>Many more can be acquired although not sent due to the data budget bottleneck</td></tr></tbody></table>

Table 3: Camera Requirements Status

</center>## Communications protocol

<div align="justify" id="bkmrk-the-communication-pr">The communication protocol used to transfer data between the camera module and the OBC is UART *(Universal Asynchronous Receiver-Transmitter).* In concordance with its name, there is no clock usage on the protocol, which means that the communication is simplified as a Serial Communication Scheme. A serial communication consists of transmitting all the information only using two cables, RX-TX and TX-RX.  
In general, the main characteristics of UART protocol are:

- Due to its simplified structure, it can be easily implemented.
- The protocol does not depend on any clock.
- The protocol uses only two wires.
- As with any serial communication, the information is transmitted between the TX-Transmitter pin to the RX-Receiver pin and vice versa.

</div>#### Interface

<div align="justify" id="bkmrk-the-transmitting-uar">The transmitting UART is connected to a controlling data bus that sends data in a parallel form. From this, the data will now be transmitted on the transmission line (wire) serially, bit by bit, to the receiving UART. This, in turn, will convert the serial data into parallel for the receiving device.

The UART lines serve as the communication medium to transmit and receive one data to another. Take note that a UART device has a transmit and receive pin dedicated for either transmitting or receiving.

For UART and most serial communications, the baud rate needs to be set the same on both the transmitting and receiving device. The baud rate is the rate at which information is transferred to a communication channel. In the serial port context, the set baud rate will serve as the maximum number of bits per second to be transferred. The used baud rate in our communications is of 11520 bps.

[![uart.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/ZqOuart.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/ZqOuart.png)

</div>#### Data transmission

<div align="justify" id="bkmrk-in-uart%2C-the-mode-of">In UART, the mode of transmission is in the form of a packet. The piece that connects the transmitter and receiver includes the creation of serial packets and controls those physical hardware lines. A packet consists of a start bit, data frame, a parity bit, and stop bits.

![captura.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/captura.png)Our data frame will be of 8 bits, and it'll include a parity bit in order to ensure more reliable communications.

More information about the UART protocol can be found here: [UART.](https://wiki.nanosatlab.space/attachments/412)

</div>## System Description

<div align="justify" id="bkmrk-the-obc-is-the-main-">The OBC is the main transmitter who sends the information from the STM32 to the camera, and the camera responds to this information. The camera is expected to receive a command and will act depending on the command it receives. The camera has different functions:

- Capture image.
- Read image data length.
- Read image data.
- Stop capture.
- Setting image compressibility.
- Setting image resolution.

The commands are different for each function. Here is an example of a communication between the OBC and the camera with the function “Reset”. The OBC sends a command to the camera saying that it wants to use this function, the command that will be sent is: 0x56 0x00 0x26 0x00. If the communication is correct and the camera has received the command properly, it will send another command to answer the OBC that he has done it, and to make sure that it has worked. The command that the camera will send the OBC is: 0x76 0x00 0x26 0x00.

</div>#### Command Protocol (Hex format data)

<div align="justify" id="bkmrk-for-each-function-th">For each function there are different commands, so in order to understand which is needed to be sent and to be received, a summary is presented in the following table.

</div><center id="bkmrk-function-transmitted"><table><thead><tr><th>**FUNCTION**</th><th>**TRANSMITTED COMMAND**</th><th>**RECEIVER TRANSMITTED COMMAND**</th></tr></thead><tbody><tr><td>Reset</td><td>0x56 0x00 0x26 0x00</td><td>0x76 0x00 0x26 0x00</td></tr><tr><td>Set image compressibility</td><td>0x56 0x00 0x31 0x05 0x01 0x01 0x12 0x04 0xXX (\*)</td><td>0x76 0x00 0x31 0x00 0x00</td></tr><tr><td>Set image resolution</td><td>0x56 0x00 0x31 0x05 0x04 0x01 0x00 0x19 0xXX (\*\*)</td><td>0x76 0x00 0x31 0x00 0x00</td></tr><tr><td>Capture an image</td><td>0x56 0x00 0x36 0x01 0x00</td><td>0x76 0x00 0x36 0x00</td></tr><tr><td>Read image data length</td><td>0x56 0x00 0x34 0x01 0x00</td><td>0x76 0x00 0x34 0x00 0x04 0x00 0xXX 0xYY</td></tr><tr><td>Read image data</td><td>0x56 0x00 0x32 ... 0x0A</td><td>0x76 0x00 0x32 ... 0x00</td></tr><tr><td>Stop capture/Clear image cache</td><td>0x56 0x00 0x36 0x01 0x03</td><td>0x76 0x00 0x36 0x00 0x00</td></tr></tbody></table>

Table 4: Command Protocol

</center><div align="justify" id="bkmrk-%28%2A%29-the-0xxx-is-the-">(\*) The 0xXX is the value of compression that will be set to the image. The range of values that are available are from 0x60 to 0XFF. The 0x60 refers to the minimum compression, and the 0xFF to the maximum compression.  
(\*\*) The 0xXX is the value of resolution that will be set to image. This variable can only take three values: 0X00, 0x11 and 0x22, where 0x00 refers to the highest resolution (VGA) of 640x480p, 0x11 offers a QVGA resolution of 320x240p and 0x22 the minimum possible resolution (QQVGA) of only 160x120p.

The camera offers other functions such as sending its version, modify it's baud rate and others, but due to their relevance and memory constraints it has been decided not to implement them. More information about these functions is found on [Translated PTC06](https://wiki.nanosatlab.space/attachments/413).

</div><center id="bkmrk-figure-1%3A-ptc06-v3.1">[![](https://wiki.nanosatlab.space/uploads/images/gallery/2024-11/scaled-1680-/image-1731570634488.PNG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-11/image-1731570634488.PNG)

Figure 1: PTC06 V3.1 Camera Module

</center>

# Hardware Design

The VGA Payload differs from P/L 2 and P/L3 greatly, both in purpose and development. As previously stated the VGA camera itself is a COTS component, meaning no development of the actual instrument is done as a part of the hardware design. Despithe this, in this section will be explained the basic components of the camera module as well as the connections with the PCB it's placed on.

Due to the simplicity of the system the design choices of the only componenty are explained on the subsystem description page.

## Schematic Design

The schematic design of the VGA PCB consists of the vertical connectors that run through the stack as well as the VGA camera itself:

<center id="bkmrk-figure-1%3A-vga-pcb-sc">[![VGASchematic](https://wiki.nanosatlab.space/uploads/images/gallery/2024-10/scaled-1680-/image-1730143643092.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-10/scaled-1680-/image-1730143643092.png)

Figure 1: VGA PCB Schematic

</center>## PCB Design

The VGA camera is fitted so that the lens is placed on the middle of the PocketQube. The resulting PCB model representation corresponds to:

<center id="bkmrk-figure-2%3A-vga-pcb-re">[![VGASchematic](https://wiki.nanosatlab.space/uploads/images/gallery/2024-10/scaled-1680-/image-1730144013332.PNG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-10/scaled-1680-/image-1730144013332.PNG)

Figure 2: VGA PCB Render

</center>## Reverse Engineering

The PCB Reverse Engineering task was started with the goal of creating a PCB of the camera that would be inside the PocketQube. After making the first measurements of each element, it was discovered that, to find out some of the connection lines, it was necessary to remove the thin green layer that the camera has. This green layer works as an insulator and makes it difficult to measure properly.

Since it was not possible to measure the connections well, it was decided to remove the camera to see if we could work better that way. However, due to some of the components, such as the lens, being hidden by the manufacturer, there was no access to them, so knowing which pin the camera connected to was not possible.

<center id="bkmrk-figure-x%3A-open-vga">[![OpenVGA](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/re.jpg)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/re.jpg)

Figure x: Open VGA

</center>Doing the PCB Reverse Engineering became an unsolvable problem. There was no way to figure out where the connections went because there was no information about the components. So, it was decided not to continue with this process. What will be done is directly connect the device to the PocketQube trying to take as less pace as possible from the device so that it does not cause problems.

# Software Design

## Code structure

- **COMMANDS:** This part specifies the different commands used to transmit the data between the OBC and the Camera. These commands are specified on the datasheet, and are sent using the “Basic” functions. These commands are declared on the camerav2.c file, and a more detailed explanation can be found there.
- **ADDRESSES:** The directions of the camera where the data is stored. It is stored the data itself, the resolution and the compressibility in the memory. Actually and due to the implementation structure, the camerav2.c uses the 0x082000 address, which has been selected by the OBC team.
- **“BASIC'' Functions:** These functions are the ones which directly communicate with the camera and the OBC. These functions are the ones which execute the command directly with the camera, and these functions are used internally inside camerav2.c . One example would be reset, which sends the information directly to the Camera.
- **“COMPOSITE” Functions:** These functions are the main ones, which the OBC will use on the program. These functions are composed of BASIC functions. These functions are InitCam and GetPhoto. These functions, due to its importance, will be explained after.
- **“CORRECTION” Functions:** These functions are used to check if the OBC correctly receives the photo from the camera, and what to do if the error occurs. They are checkACK() and errP(). These functions, due to its importance, will be explained after.
- **“EXTRA” Functions:** These functions are used during the full code, which are used mainly for storeData, either the infoBuffer or the FlashMemory. These functions will be explained later.

Taking into account these summary of the functions, a detailed explanation of each case will be explained.

## Summary of functions

A summary of the functions developed is presented now:

<center id="bkmrk-function-type-descri"><table><thead><tr><th>**FUNCTION**</th><th>**TYPE**</th><th>**DESCRIPTION**</th></tr></thead><tbody><tr><td>bool reset(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Executes reset command.</td></tr><tr><td>bool getVersion(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Executes getVersion command.</td></tr><tr><td>bool setResolution(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Sets the resolution from the user.</td></tr><tr><td>bool setCompressibility(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Sets compression from the user.</td></tr><tr><td>bool startCapture(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Executes startCapture command</td></tr><tr><td>bool getDataLength(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Obtained the length of an image.</td></tr><tr><td>bool getData(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Obtains an image.</td></tr><tr><td>bool stopCapture(UART\_HandleTypeDef huart)</td><td>BASIC</td><td>Executes stopCapture command.</td></tr><tr><td>bool initCam(UART\_HandleTypeDef huart, uint8\_t res, uint8\_t comp, uint8\_t \*array)</td><td>COMPOSITE</td><td>Initializes the camera.</td></tr><tr><td>uint16\_t getPhoto(UART\_HandleTypeDef huart, uint8\_t \*infoarray)</td><td>COMPOSITE</td><td>Executes the getPhoto structure, obtaining the photo, length and storing the photo inside Flash Memory.</td></tr><tr><td>uint16\_t storeDataFlash() *might be removed*</td><td>EXTRA</td><td>Stores the data inside Flash Memory.</td></tr><tr><td>void storeInfo(uint8\_t info)</td><td>EXTRA</td><td>Stores info inside array.</td></tr><tr><td>bool checkACK(UART\_HandleTypeDef huart, uint8\_t c1, uint8\_t c2, uint8\_t c3, uint8\_t c4, uint8\_t c5)</td><td>CORRECTION</td><td>Checks ACK from camera.</td></tr><tr><td>bool err(UART\_HandleTypeDef huart)</td><td>CORRECTION</td><td>Executes error protocol.</td></tr></tbody></table>

Table 1: Designed Software functions

</center>#### <span style="text-decoration: underline;">**Basic functions**</span>

As explained before, we have the commands which are sent to the camera, and the commands expected. Anyway, there should be a function which sends that information to the camera using the UART protocol. The STM32 has a native library which implements this (HAL\_UART\_Transmit, HAL\_UART\_Receive). In this case, a specific implementation of this function for each command has been done.

A general view of these functions is presented below:

<center id="bkmrk-figure-1%3A-basic-func">[![Sin título.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/f2usin-titulo.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/f2usin-titulo.png)

Figure 1: Basic Functions Block Diagram

</center>This scheme can be used for each basic function besides the getData function, at this current point in time., varying the state and the transmit data Buffer and the receive data buffer.  
It is known that a general buffer for all the information received can be implemented, but it can also generate numerous problems on the implementation. As it is not necessary to implement and it will complicate the code, different buffers are applied for different data.  
The infoBuffer and state variable purpose will be explained in detail in other parts of the documentation.

##### getData

The getData function complexity severely differs from other basic functions due to the implementation of [circular DMA](https://wiki.nanosatlab.space/attachments/416). In contrast to other functions, and due to the structure of the ones used to store data in the flash memory, two relevant buffers have been created in order to store and manage data before flashing. The use of DMA requires callbacks in order to flash data without losing parts of it. In these callbacks, executed when the first buffer is half full and when it is full, will cause an interrupt (not desired but necessary) where the flashing will occur. Here we will make use of an auxiliary buffer in order to copy the second half of the first buffer onto it in order to not cause overlap or flashing of repeated data.

Note that the callbacks are not called when all the data or half is received, they are called in response to the fullness of the buffer (as long as its length coincides with the amount of data specified in the HAL DMA functions). To solve the problem and know how much data shall be received and DMA stopped we make use of the prior fuction, getDataLenght, which will provide us with the total length of the picture. As callbacks are executed, an index will be increased and through comparisons of it, the current callback and the length it'll be determined when to stop the DMA and the execution of the function.

A comprehensive slightly simplified scheme is provided next:

<center id="bkmrk-figure-2%3A-getdata-fu">[![getData.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/getdata.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/getdata.png)

Figure 2: getData Function Block Diagram

</center>##### <span style="text-decoration: underline;">**Composite functions**</span>

These functions used different basic functions in order to follow the protocol from the mentioned datasheet.

##### initCam

The initCam function initializes the camera with the resolution and the compressibility:  
In this case, the initCam is implemented using the huart, the resolution and compressibility needed, and an array in which errors will be stored.  
A general scheme of the code is shown below:

<center id="bkmrk-figure-3%3A-initcam-bl">[![Sin título.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/iAssin-titulo.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/iAssin-titulo.png)

Figure 3: initCam Block Diagram

</center>##### getPhoto

The getPhoto function is implemented using an UART and an info array attribute. This array is where the buffer of errors will be stored. This function is in charge of executing the order to take the photo, taking it, storing it, and executing the order to stop the camera. A general scheme of the code is shown below:

<center id="bkmrk-figure-4%3A-getphoto-b">[![getphoto.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/scaled-1680-/getphoto.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-03/getphoto.png)

Figure 4: getPhoto Block Diagram

</center>

# Subsystem Verification

## Camera testing

### How to take and extract an image

In order to take a photo the PTC06 and a STML4, which will be replaced by the OBC-COMMS board in due time, must be connected appropriately. The camera must be provided with a voltage of at least 3.3V to be in working conditions yet it'll work under 5V. A picture of the set-up is provided as well with a diagram which indicates connections to the board.

[![WhatsApp Image 2024-04-04 at 10.52.07 AM.jpeg](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/scaled-1680-/whatsapp-image-2024-04-04-at-10-52-07-am.jpeg)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/whatsapp-image-2024-04-04-at-10-52-07-am.jpeg)

The following connections must be made between the PTC06 and the STM32:

[![nucleo_l476rg_morpho_left_2017_4_21.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/scaled-1680-/nucleo-l476rg-morpho-left-2017-4-21.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/nucleo-l476rg-morpho-left-2017-4-21.png)

[![nucleo_l476rg_arduino_left_2017_4_21.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/scaled-1680-/nucleo-l476rg-arduino-left-2017-4-21.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-04/nucleo-l476rg-arduino-left-2017-4-21.png)

Now that the 4 terminals are properly connected the next step is to open the STM32 IDE, and debug the project. <span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Before resuming the debug process it is heavily suggested to check for the variable *'imlenght'* in the expression viewer as well as *'camState'* in the variable expression viewer, so as to know if the process is done.</span></span>

<span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Resume the debugging and wait until the camera state goes to 'CAM\_STOP\_CAPTURE', now check the hex length of the picture (indicated by the value of the variable *'imlenght'*</span></span>) and exit the debug session. Now open ST-LINK Utility and enter the address where the pictures is stored (0x08040000, per default in our code) and the size of the picture (should be something along the lines of 0xAAAA). Then connect to the device and save the data as a jpg file. Note that the data should have a D8 byte in the first line and a D9 in the last one.

<span id="bkmrk--4" style="font-weight: normal;">![](https://lh7-us.googleusercontent.com/slidesz/AGV_vUcUyAfOOhv1f57nfUHNK9sZ949C_DDcL2XGG1-EJZdvUYwc8G6rUSqY3VVnbTGzp4BYDDtYuXfjoCbTjPbfZ3icK4-WtbNS6IAaZ9oRLWNz21aT5K1RYydk1nwXXTqthoKbTrkNrd4D_7JPmud72sUCkFuCJJY9-sWQrYX01lCBKXrPk636_ec=s2048?key=XEANkX_j5944bsUwkcukmw)</span>

Obviously this is not an appropriate process to extract pictures from the payload, as it should be done remotely. As of today images can be extracted via COMMS following a Rx-Tx, but this is out of the scope of this document, as taking the picture and storing it appropriately is our only concern for now.

## TEST 1: Image size-quality evaluation

As is to be expected it is necessary to evaluate the trade-off between picture size and quality of an image. So, the goal of this test is to find the most appropriate resolution/compression values considering power and data budget constraints, as we probably won't be able to send full high resolution pictures in a single pass.

<span style="color: rgb(0, 0, 0);">Memory size with different values of resolution and compression:</span>

[![Untitled Diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/untitled-diagram.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/untitled-diagram.png)

[![0000.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/0000.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/0000.JPG)

[![Untitled Diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/Puzuntitled-diagram.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/Puzuntitled-diagram.png)

[![00FF.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/00ff.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/00ff.JPG)

[![Untitled Diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/Q3Iuntitled-diagram.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/Q3Iuntitled-diagram.png)[![e43untitled-diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/0ILe43untitled-diagram.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/0ILe43untitled-diagram.png)

[![11FF.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/11ff.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/11ff.JPG)

[![1100.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/1100.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/1100.JPG)![Untitled Diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/oNZuntitled-diagram.png)[![Untitled Diagram.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/CCwuntitled-diagram.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/CCwuntitled-diagram.png)

[![22FF.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/22ff.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/22ff.JPG)

![](https://lh7-us.googleusercontent.com/slidesz/AGV_vUcqEKuviBnK9FlLqYFRjaXgieVlzEX4P8kk_6mrBPoNSwUM_kKS27romDO5MHMsJG44WKoOa415ra0CBpY-LygQvlKawKX3vo2qZK5c4pELYS5SVo_e2zOs4USQPKDimpkx3XDF1nYx9PILQng81s9Kw1TottO5OD3gxMO5z8v-mDaHsHgVGQ=s2048?key=XEANkX_j5944bsUwkcukmw)

It is complex to assign optimal values to resulution and compression as both can be situational depending on the enviroment that is going to be photographed. Despite this, the trade-off between compression and size is noticeably interesting in higher resolution images. When resolution decreases increasing compression seems to have a less impactful effect, both in image quality and in image size.

It is proposed to adjust both of these parameters according to the situation via telecommands.

## TEST 2: DMA IMAGE TAKING

### Test Description and Objectives

The objective of this test is to verify the implementation of Circular DMA in the data acquisition system of the camera.

### Requirements Verification

<div class="page" id="bkmrk-requirement-id-descr-5" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column"><table id="bkmrk-requirement-id-descr-6" style="width: 99.6296%; height: 165.356px;"><thead><tr style="height: 30px;"><th style="width: 22.4627%; height: 30px;">Requirement ID</th><th style="width: 77.5645%; height: 30px;">Description</th></tr></thead><tbody><tr style="height: 47.5875px;"><td style="width: 22.4627%; height: 47.5875px;">DIT- 01</td><td style="width: 77.5645%; height: 47.5875px;">Run the proposed code without errors.</td></tr><tr style="height: 30px;"><td style="width: 22.4627%; height: 30px;">DIT- 02</td><td style="width: 77.5645%; height: 30px;">Take the highest quality image possible by the camera.</td></tr><tr style="height: 57.7687px;"><td style="width: 22.4627%; height: 57.7687px;">DIT- 03</td><td style="width: 77.5645%; height: 57.7687px;">Extract the data successfully from the flash memory of an STM32 Nucleo.</td></tr></tbody></table>

</div></div></div></div></div></div></div></div>### Test Set-Up

##### Materials

<div class="page" id="bkmrk-nucleo-l476rg-%2B-lora" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column">- Nucleo L476RG
- PTC06

</div></div></div></div></div></div></div></div>##### Setup

Prepare the set-up as explained in \[1\].

### Pass/Fail Criteria

If the stipulated conditions are fulfilled, specifically, the image is taken without the appearance of significant artefacts the test will be considered successful.

### Test Plan

##### Step 1: Debug and run the code

It is expected to save the image in the specified address and extract the length of it during this process.

##### Step 2: Extracting the image

Using ST-LINK Utility we extract the corresponding image using the aforementioned length.

##### Step 3: Inspect the image

Inspect the image for possible artefacts and other errors.

### Test Results

##### Step 1:

The image was not flashed in the memory in first instance. This was due to the complexity of flashing the data using another task while DMA doesn't stop receiving until a transaction is done or half done. The work-around for this issue was to implement a new data-flashing function which didn't rely on the FLASH TASK of the OBC and didn't need the copy the data stored before we started flashing.

##### Step 2:

The image was successfully extracted.

##### Step 3:

Sometimes the images appear to have significant artefacts, heavily impacting low resolution images, yet this error has been found to be random, as without any change of parameters an image is taken successfully in one run and quite affected in another one.

![wXA00ff.jpg](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/wxa00ff.jpg)Example of a high resolution image taken when errors occur.

[![11A0.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/11a0.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/11a0.JPG)

Example of a medium resolution image with artefacts.

[![11FF.JPG](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/Bni11ff.JPG)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/Bni11ff.JPG)

The same image taken instants later without any modifications.

### Conclusions

DMA transfer has been successfully implemented as images can be taken without the appearance of significant errors. Despite this, it is true that some impactful errors do occur at random. Further revision into this phenomena is required as well as the implementation of a more reliable EDAC.

During the test it has been uncovered the difficulty to flash images into the memory using the FLASH TASK. We do have to remember that this task was designed and implemented to avoid memory overflow when no more stack size could be given to tasks, and as overflow hasn't occurred, the implementation of the new function might not be detrimental or needed to revisit.

## TEST 3: VGA PCB - NUCLEO

### Test Description and Objectives

The objective of this test is to verify the implementation of Circular DMA in the data acquisition system of the camera.

### Requirements Verification

<div class="page" id="bkmrk-requirement-id-descr" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column"><table id="bkmrk-requirement-id-descr-1" style="width: 99.6296%; height: 165.356px;"><thead><tr style="height: 30px;"><th style="width: 22.4627%; height: 30px;">Requirement ID</th><th style="width: 77.5645%; height: 30px;">Description</th></tr></thead><tbody><tr style="height: 47.5875px;"><td style="width: 22.4627%; height: 47.5875px;">VPN- 01</td><td style="width: 77.5645%; height: 47.5875px;">All connections are well made, both inside the PCB and to the Nucleo.</td></tr><tr style="height: 30px;"><td style="width: 22.4627%; height: 30px;">VPN- 02</td><td style="width: 77.5645%; height: 30px;">Take an image with the camera.</td></tr><tr style="height: 57.7687px;"><td style="width: 22.4627%; height: 57.7687px;">VPN- 03</td><td style="width: 77.5645%; height: 57.7687px;">Extract the data successfully from the flash memory of an STM32 Nucleo.</td></tr></tbody></table>

</div></div></div></div></div></div></div></div>### Test Set-Up

##### Materials

<div class="page" id="bkmrk-nucleo-l476rg-vga-pc" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column">- Nucleo L476RG
- VGA PCB
- PCBite Kit
- Multimeter

</div></div></div></div></div></div></div></div>##### Setup

Prepare the set-up as explained in \[1\], but with the connections from the VGA to the Nucleo done with a PCBite Kit or soldering. Other approaches might also be taken.

[![image.png](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/image.png)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/image.png)

Image of our setup

### Pass/Fail Criteria

If the stipulated conditions are fulfilled, specifically, the taking of an image, the test will be considered passed.

### Test Plan

##### Step 1: Connect the PCB to the Nucleo

Making use of a PCBite or other means of connection it is checked that all pins, both from the PCB and from the VGA are successfully connected.

##### Step 2: Take an image

It is expected to save the image in the specified address and extract the length of it during this process.

##### Step 3: Extract the image

Using ST-LINK Utility we extract the corresponding image using the aforementioned length.

### Test Results

##### Step 1:

All the connections were tested with a multimeter successfully.

##### Step 2:

The image was successfully taken.

##### Step 3:

The image was successfully extracted.

[![testpcb.jpg](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/scaled-1680-/testpcb.jpg)](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/testpcb.jpg)

Image taken by the P/L.

### Conclusions

The PCB is working normally, without any potential issues and the P/L is functional. The test is considered successful.

## TEST 4: VGA-COMMS (+VGA-OBC)

This test is explained and performed in the COMMS SSV Section the of the wiki. Passed successfully. This test was performed with an individual PTC06, and will be tested with a PCB as integration advances.

## TEST 5: VGA-OBC-EGSE 

### Test Description and Objectives

The objective of this test is to take an image integrating the OBC, VGA and EGSE systems.

### Requirements Verification

<div class="page" id="bkmrk-requirement-id-descr-2" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column"><table id="bkmrk-requirement-id-descr-3" style="width: 99.6296%; height: 117.75px;"><thead><tr style="height: 30px;"><th style="width: 22.4627%; height: 30px;">Requirement ID</th><th style="width: 77.5645%; height: 30px;">Description</th></tr></thead><tbody><tr style="height: 30px;"><td style="width: 22.4627%; height: 30px;">VOE- 01</td><td style="width: 77.5645%; height: 30px;">Take an image with the camera.</td></tr><tr style="height: 57.75px;"><td style="width: 22.4627%; height: 57.75px;">VOE- 02</td><td style="width: 77.5645%; height: 57.75px;">Extract the data successfully from the flash memory of the OBC.</td></tr></tbody></table>

</div></div></div></div></div></div></div></div>### Test Set-Up

##### Materials

<div class="page" id="bkmrk-obc-comms-pcb-vga-pc" title="Page 86"><div class="layoutArea"><div class="column"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="page" title="Page 91"><div class="layoutArea"><div class="column">- OBC-COMMS PCB
- VGA PCB
- EGSE (FlatSat)

</div></div></div></div></div></div></div></div>##### Setup

Prepare the set-up as explained in \[1\], but with the connections from the VGA to the Nucleo done with a PCBite Kit or soldering. Other approaches might also be taken.

### Pass/Fail Criteria

If the stipulated conditions are fulfilled, specifically, .

### Test Plan

##### Step 1: Connect the PCBs to the FlatSat

##### Step 2: Take an image

It is expected to save the image in the specified address and extract the length of it during this process.

##### Step 3: Extract the image

Using ST-LINK Utility we extract the corresponding image using the aforementioned length.

### Test Results

##### Step 1: Connections appear stable

##### Step 2: Image is not taken by the camera

No communication is established between the OBC and the P/L.

##### Step 3: -

![](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/embedded-image-hnzqaagw.png)![](https://wiki.nanosatlab.space/uploads/images/gallery/2024-07/embedded-image-gsicwplj.png)

### Conclusions

The test has failed, as an image hasn't been able to be extracted. It has been found that the PTC06 on the VGA PCB used was not working properly and the test has to be redone with a new one resoldered. The previous test written before this one was made with a new resoldered camera and this test remains to be redone.