CanSat - Beginners Guide

The main objective of this instructables is sharing the development
process of a CanSat, step by step. But, before starting, let's make it really clear what a CanSat is, and what are it's main funcionalities, also taking the opportunity, we are gonna introduce our team. This project started as an extension project in our university, Universidade Tecnológica Federal do Paraná (UTFPR), campus Cornélio Procópio. Guided by our advisor, we developed a plan of action with the intention of getting into CanSats, which meant studying all of it's aspects and characteristics, in order to be able to understand how it works, which in the end would result in the construction of a CanSat, and the development of this guide. A CanSat is classified as a picosatellite, which means its weight is limited to 1kg, but normally the CanSats weigh about 350g, and its structure is based in a can of soda, a 6,1 cm diameter cylinder, 11,65 cm tall. This model was presented with the intention of simplifying the process of development of a satellite, in order to enable the access of universities to these technologies, achieving popularity due to the competitions that adopted this pattern. In general, CanSats are based on 4 structures, that are, the power system, the sensing system, the telemetry system and the main system. So let's take a closer look at each system: - Power system: this system is responsible for supplying the electrical energy to the other ones, according to its needs. In other words, it's supposed to supply the systems the necessary voltage and current, respecting its limits. Also, it can feature protection components, in order to guarantee the safety and the proper behavior of the other systems. Commonly it's based on a battery and a voltage regulator circuit, but many other features can added, such as power management techniques and several kinds of protections. - Sensing system: this system is composed of all the sensors and devices that are responsible for collecting the required data. it can be connected to the main system in several ways, serial protocols, parallel protocols among others, that's why it's really important to master all these techniques, in order to be able to determine the most convenient one. In general, the serial protocol are the ones that are often chosen, due to their smaller number of connections and versatility, by far the most popular ones are the SPI, I2C and UART protocols. - Telemetry System: this system is responsible to establish the wireless communication between the CanSat and the ground control station, which includes the wireless communication protocol and hardware. - Main System: this system is responsible for interconnecting all the other systems, in a way that it also controls and synchronize their sequence of operation as an organism.

Step 1: The Main System

For many reasons we've chosen an ARM® Cortex®-M4F based micro controller, it's a low power MCU, that offers a much higher processing power, plus several features that are not commonly seen in RISK microcontrollers, such as DSP functions. These characteristics are interesting because they enable the increase in complexity of the features of the CanSat applications, without the need of changing the microcontroller (of course, respecting its limits as well).

As long as, the project had several financial limitations, the microcontroller chosen was also supposed to be affordable, so following the specifications, we ended up choosing the ARM® Cortex®-M4F Based MCU TM4C123G LaunchPad, it's a launchpad that just fitted our project. Also the documentation (datasheets and characteristics documentation provided by the fabricant) and the IDE of the MCU were pros that should really be considered, as long as, they helped the development process a lot.

In this Cansat, we decided to keep it simple and just develop it by using the launchpad, but of course in future projects, this will not be an option, considering that several features included in the launchpad aren't actually necessary for our project, plus its format limited a lot the project of the structure of our CanSat, as long as the dimensions of a CanSat are minimum.

So, after choosing the proper 'brain' for this system, the next step was the development of its software, also to keep it simple we decided to simply use a sequential program, that does the following sequence at a frequency of 1Hz:

Sensors readings > data storage > data transmission

The sensors part is gonna be explained later in the sensing system, as well as the data transmission is gonna be explained in the telemetry system. Finally, it was to learn how to program the microcontroller, in our case we needed to learn the following functions of the MCU, the GPIO's, the I2C module, the UART module and the SPI module.

The GPIO's, or simply general purpose input and output, are ports that can be used to perform several functions, as long as they are set properly. Considering that we are not using any C libraries for the GPIO's, not even for the other modules, we were supposed to configure all the necessary registers. For this reasons we've written a basic guide containing examples and descriptions related to the registers of the modules we are using, that are available below.

Also, in order to simplify and organize the code, several libraries were created. So, libraries were created for the following purposes:

- SPI protocol

- I2C protocol

- UART protocol

- NRF24L01+ - transceptor

These libraries are also available below, but remember that we've used the Keil uvision 5 IDE, so these libraries are not going to work for code composer. Finally, after creating all the libraries and learning all the necessary stuff, the final code was put together, and as you might imagine it's also available below.

Step 2: The Sensing System

This system is composed of all the sensors and devices that are responsible for gathering information about the conditions of operation of the CanSat. In our case we've chosen the following sensors:

- a 3 axis digital accelerometer - MPU6050

- a 3 axis digital gyroscope - MPU6050

- a 3 axis digital magnetometer - HMC5883L

- a digital barometer - BMP280

- and a GPS - Tyco A1035D

The choices were based mainly on the accessibility, which meant that as long as the mechanical and electrical (communication protocol, power supply etc) characteristics were compatible with our project, no further parameters were imposed to the choices, also because for some sensors the availability of options was limited. After acquiring the sensors, it was time to put them to work.

So the first one to be explored was the 3 axis digital accelerometer and gyroscope, called MPU6050 (it can be easily found anywhere, as long as it's extensively used in ARDUINO projects), its communication is based on the I2C protocol, a protocol in which each slave owns an address, allowing several devices to be connected in parallel, considering the address is 7-bits long, about 127 devices can be connected at the same serial bus. This communication protocol works on two buses, a data bus and a clock bus, so in order to exchange the information, the master must send 8 cycles of clock (by the way the information must fit a byte, as long as this communications is based on the byte size) either in a receive or in a transmit operation. The MPU6050's address is 0b110100X, and the X is used to call (indicates) a reading or a writing operation (0 indicates a writing operation and 1 indicates a reading operation), so whenever you want to read the sensor just use its address as 0xD1 and whenever you want to write just use its address as 0xD0.

After exploring the I2C protocol, the MPU6050 was in fact studied, in others words its datasheet was read, in order to get the necessary information to put it to work, for this sensor only three registers were required to be configured, the power management 1 register - address 0x6B (in order to guarantee the sensor isn't in sleep mode), the gyroscope configuration register - address 0x1B (in order to configure the full scale range for the gyroscope) and finally the accelerometer configuration register - address 0x1C (in order to configure the full scale range for the accelerometer). There are several other registers that can be configured, allowing the optimization of the sensor performance, but for this project these configurations are enough.

So, after properly configuring the sensor, you are now able to read it. The desired information takes place between the register 0x3B and the register 0x48, each axis value is composed of two bytes that are codified in the 2's complement way, which means that the read data must be converted in order to be meaningful (these things will be discussed later).

After getting done with the MPU6050, it was time to get the 3 axis digital magnetometer studied, named HMC5883L (it also can be easily found anywhere, as long as it's extensively used in ARDUINO projects), and again its communication protocol is the serial protocol I2C. Its address is 0b0011110X and the X is used to call (indicates) a reading or a writing operation (0 indicates a writing operation and 1 indicates a reading operation), so whenever you want to read the sensor just use its address as 0x3D and whenever you want to write just use its address as 0x3C.

In this case, in order to get the HMC5883L initialized, three registers were required to be configured, the configuration register A - address 0x00 (in order to configure the data output rate and the measurement mode), the configuration register B - address 0x01 (in order to configure the gain of the sensor) and last but no least the mode register - address 0x02 (in order to configure the operating mode of the device).

So, after properly configuring the HMC5883L, it's now possible to read it. The desired information takes place between the register 0x03 and the register 0x08, each axis value is composed of two bytes that are codified in the 2's complement way, which means that the read data must be converted in order to be meaningful (these things will be discussed later). Particularly, for this sensor you are supposed to read all the information at once, otherwise it might not work as proposed, as long as the output data is only written to these registers when all registers were written. so make sure to read them all.

Finally, the digital barometer, another I2C protocol sensor, was studied, also called BMP280 (it also can be easily found anywhere, as long as it's extensively used in ARDUINO projects). Its address is b01110110X also the X is used to call (indicates) a reading or a writing operation (0 indicates a writing operation and 1 indicates a reading operation), so whenever you want to read the sensor just use its address as 0XEA and whenever you want to write just use its address as 0XEB. But in the case of this sensor the I2C address can be changed by changing the voltage level on the SDO pin, so if you applly GND to this pin the address is going to be b01110110X and if you apply VCC to this pin the address is going to be b01110111X, also in order to enable the I2C module in this sensor you must apply a VCC level on the CSB pin of the sensor, otherwise it's not going to work properly.

For the BMP280 only two registers were supposed to be configured in order to get it to work, the ctrl_meas register - address 0XF4 (in order to set the data acquisition options) and the config register - address 0XF5 (in order to set the rate, the filter and the interface options for the sensor).

After getting done with the configuration stuff, it's time for what really matters, the data itself, in this case the desired information takes place between the registers 0XF7 and 0XFC. Both the temperature and the pressure value are composed of three bytes that are codified in the 2's complement way, which means that the read data must be converted in order to be meaningful (these things will be discussed later). Also for this sensor, in order to get a higher precision, there are several corrections coefficients that can be used while converting the data, they are located between the registers 0X88 and 0XA1, yes there are 26 bytes of corrections coefficients, so if precision is not that much important, just forget them, otherwise there is no other way.

And last but no least the GPS - Tyco A1035D, this one relies on the UART serial protocol, specifically at the rate of 4800 kbps, no parity bits, 8 data bits and 1 stop bit.The UART, or Universal Asynchronous Receiver/Transmitter, is a serial protocol in which the synchronization of the information is done via software, that why it's an asynchronous protocol, also because of this characteristic, the rate in which the information is transmitted and received is way smaller. Specifically for this protocol the packages must begin with a start bit, but the stop bit is optional and the size of the packages are 8 bits long.

In the case of the GPS - Tyco A1035D, two configurations were required, that were the setDGPSport (command 102) and the Query/RateControl (command 103), all these information, plus more options are available in the NMEA reference manual, the protocol used in most GPS's modules. The command 102 is used to set the baud rate, the amount of data bits and the existence or not of parity bits and stop bits. The command 103 is used to control the output of standard NMEA messages GGA, GLL,GSA, GSV, RMC, and VTG, they are described with details in the reference manual, but in our case the chosen one was the GGA that stands for Global Positioning System Fixed Data.

Once the GPS - TycoA1035D is properly configured, now it's only necessary to read the serial port and filter the string received according the chosen parameters, in order to allow the processing of the information.

After learning all the necessary information about all the sensors, it only took some extra effort in order to put everything together in the same program, also using the serial communication libraries.

Step 3: The Telemetry System

This system is responsible for establishing the communication between the ground control and the CanSat, besides the project parameters, it was also restricted in some more ways, as long as the RF transmission is only allowed in some frequency bands, that are not busy due to other RF services, such as mobile services. These restrictions are different and may change from country to country, so it's important to always check the allowed frequency bands for common use.

There are many options of radios available in the market at affordable prices, all these systems offer different ways of modulation at diverse frequencies, for this system our choice consisted in a 2.4GHz RF transceiver, the NRF24L01+, due to the fact that it already had a well established communication protocol, as long as verification systems such as auto acknowledgement and auto re-transmission systems. Furthermore, its transmission rate could reach speeds up to 2Mbps at a reasonable power consumption.

So before working on this transceiver, let's get to know a little bit more about the NRF24L01+. As mentioned before it's a 2.4GHz based radio, that can be configured as receiver or transmitter. In order to establish the communication each transceiver is got an address, that can be configured by the user, the address can be 24 to 40 bits long according to your needs. The data transactions can happen in a single or in a continuous way, the data size is limited to 1 byte and each transaction might or might not generate an acknowledgement condition according to the configurations of the transceiver.

Other several configurations are also possible, such as the gain towards the output of the RF signal, the existence or not of an auto re-transmission routine (if so the delay, the amount of trials among other characteristics can be chosen) and several other features that aren't necessarily useful for this project, but anyways they are available in the datasheet of the component, in case of any interest about them.

The NRF24L01+ 'speaks' the SPI language when it comes to serial communication, so whenever you want to read or write this transceiver, just go ahead and use the SPI protocol for it. The SPI is a serial protocol as mentioned before, in which the selection of the slaves is done via a CHIPSELECT (CS) pin, that along with the full duplex (both the master and the slave can transmit and receive in a parallel way) characteristic of this protocol allows much higher speeds of data transaction.

The datasheet of the NRF24L01+ provides a set of commands to read or write this component, there are different commands to access the internal registers, the RX and TX payload among other operations, so depending on the desired operation, it might take a specific command to perform it. That's why it would be interesting to take a look at the datasheet, in which there is a list containing and explaining all the possible actions over the transceiver (we are not going to list them right here, because that's not the main point of this instructables).

Besides the transceiver, another important component of this system is the protocol through which all the desired data is sent and received, as long as the system is supposed to work with several bytes of information simultaneously, it's important to know the meaning of each byte, that's what the protocol works for, it allows the system to identify in an organized way all the data received and transmitted.

In order to keep things simple, the used protocol (for the transmitter) consisted of a header formed of 3 bytes followed by the sensor's data, as long as all the sensors data consisted of two bytes, each sensor data was given an identification number starting from 0x01 and following in a crescent order, so each two bytes there is an identification byte, this way the header sequence couldn't be repeated by chance according to the sensor's readings. The receiver ended up being as simple as the transmitter, the protocol just needed to recognize the header sent by the transmitter and after it just storage the received bytes, in this case we decided to use a vector to storage them.

So after accomplishing all the required knowledge about the transceiver and determining the communication protocol, it's time to put everything together in the same piece of code, and finally get the CanSat firmware done.

Step 4: The Power System

This system is held responsible for supplying the other systems the energy they require to work properly, in this case we decided to simply use a battery and a voltage regulator. So, for the battery sizing, some operation parameters of the CanSat were analyzed, these parameters would help the definition of the model and the power necessary to feed the entire system.

Considering that the CanSat should be able to last several hours switched on, the most appropriate thing to do was considering the most extreme situations of power consumption, in which each module and system attached to the CanSat would consume the highest possible current. However, it's also important to be reasonable at this point not to over size the battery, which is also not interesting due to the CanSat's weight limitations.

After consulting all the datasheets of the components of all systems, the total current consumed by the system was about 160mAh roughly, considering an autonomy of 10 hours, a 1600mAh battery was enough for guaranteeing the system the proper working conditions.

After getting to know the necessary charge of the battery, there are further aspects to consider despite the autonomy, such as the size , the weight, the operation temperature (as long as the CanSat is kept inside a rocket), the tensions and forces to which the same is submitted to, among others.

Step 5: The Structure

The structure is really important for the safety of the CanSat, although it was a little neglected in this project (actually there wasn't much of an interest in the development of the mechanical part of the CanSat, due to the fact that all members courses was related to electronics). As long as the project was based in an existing pattern, the CanSat pattern, not much thinking about how it was gonna look like was necessary, so it should be shaped in a cylinder format, with about 6,1 cm of diameter and about 11,65 cm tall (the same measures of a can of soda).

After getting done with the outside structure, the attention was all focused on the attachment system, responsible for holding all the boards inside the cylindrical structure, also enabling the absorption of the accelerations to which the CanSat would be submitted to, after some discussing about it, it was decided to attach both structures by molding high density foam, to the desired shapes.

The outside structure was constructed by using PVC pipes, with the desired diameter, in order to close the structure some PVC pipe covers were used

.

Step 6: Conclusions and Future Thoughts

The CanSat still needs to be tested in action, we're actually applying for a rocket competition (which is going to happen in December), also after going through all the building (kinda, we actually still need to finish some stuff) and development process, some perspectives and notes that we thought it would be interesting to share with all of you were observed, mainly about struggles, tips and even good experiences, so here it goes:

- The beginning of the project, came to be the most prolific period of development of the whole project, sadly the group became kinda disinterested on the project by its deadline, maybe because of lack of immediate results, or maybe just lack of communication, anyways several good stuff came out of the project

- It took lots of effort to get the transceiver to work, since all the libraries, were developed from scratch, also because it takes two different programs and setups to test these kind of stuff

- In our case it was not the best of the ideas to work on micro controllers based on registers configurations, not all the members were able to keep up with the rest of the group, which lead to some problems such as tasks division. There are tons of decent C libraries for the micro controller we were using, so it would have been a much better idea to use those resources, there is also an IDE called Code Composer, that also offer tons of resources for those microcontrolers

- The CanSat still needs lots of improvements, this experience was based on basic techniques and skills, also several issues weren't taken in consideration, so in the future hopefully a top notch version of this CanSat might become reality with more effort and hard work.