Getting Started - g7kse/CanSat GitHub Wiki
The CanSat project can make use of just about any Micro controller (MCU). The UK Can Sat teaching guide in 2021 makes use of a Raspberry Pi Pico, an Adafruit LoRa transceiver and a BMP280 temperature, pressure and (inferred) altitude sensor.
Basic Electronic Parts
Raspberry Pi Pico
This is a small and powerful MCU that uses a common RP 2040 chip. It has a decent amount of onboard memory (2Mb) and a flexible power system which includes an onboard buck:boost that can accept between 1.8v and 5.5v (see the data sheet for full specs - ). The Pico accepts data from UART, SPI & I2C.
The MCU is quick and competent but will require a particular language to be used in this instance, Circuit Python. This is the only down side as it is less capable that an Arduino for instance but is perfectly capable for our purposes.
RFM96W Lora transceiver
The way we communicate between the CanSat and ourselves (the ground station) is with a low powered transmitter and receiver (transceiver) module that operates in the UHF (433Mhz) band. These LoRa (Long Range) spread spectrum devices are typically used for Internet of Things devices to communicate with each other.This makes them perfect for this job.Ours is from Adafruit and has enough power for 2kM of range where there is a line of sight. They also have plenty of support for programming.
BMP280 sensor
For the basic sensor we use the Bosch BMP280 which has been combined with some extra part to allow it to be easily interfaced with. The datasheet gives a bit more detail of ranges etc. We'll be using this for the primary mission (determining temperature and pressure), we can also use it to infer altitude as the sensor can use the local air pressure (QNH using Aerospace Q codes) as a way of determining height. This is a handy extra feature but needs some careful integration
Deciding on a secondary mission
The secondary mission is something that you can decide on. It could be something as simple as determining altitude as mentioned above, or something more complex that involves GPS or servo's or anything for that matter that isn't the primary mission. Previous secondary missions have been things like guided landing or air quality measurement. This bit is up to you :-) .
Defining Requirements
This is probably the most overlooked aspect of most projects. Defining, at the start, what it is the team planning to achieve. The strong recommendation is that this is done as part of the planning, right at the start of the project. A table is the best way of doing this. The format of the table really doesn't matter but the content does.
| Reference | Requirement | How demonstrated? | Who Responsible | Require for | Status |
|---|---|---|---|---|---|
| R1 | Meet dimensional requirements | Measured as part of design and validated during PDR | A Person | Preliminary Design Review | :x: |
| R2 | Must be 300grams | Indicative weight at PDR. Final weight at FDR | Aother Person | Final Design Review | :heavy_check_mark: |
| R3 | |||||
| R4 |