Improvements to the CanSat kit

[SiboVanGool]

Hello,

I am one of the people who provided technical support for Belgium's 2023-2024 CanSat edition and would like to take this opportunity to provide feedback on how the CanSat kit could be improved.

The main improvement I would like is to add robustness for when the Can not be retrieved. Last year's addition was an eye-opener, since due to extremely bad weather, only 6 out of the 32 cans where retrieved. The cans that weren't retrieved often had limited telemetry because the teams had to do blind pointing with their antenna due to the cans disappearing above the clouds seconds after the launch.

My main takeaways on retrievability of the cans:
- teams that deviated from the standard 433 MHz radio module (and go for e.g. 2.4 GHz module instead) had significantly better telemetry
- teams that included a GPS sensor had more chance of having their can retrieved

I would therefore want to propose the following:
1. Replace the RFM69HCW with the RFM95 LoRa Module. This radio module operates over very large distances (> 2 km), is low power, and operates at 868 MHz, so multiple cans inside the rocket interfere less with each other than multiple 2.4 GHz cans (the higher the modulation frequency, the more frequency separation you need to avoid interference).
2. Include a GPS or other GNSS module. I would preferably want a GNSS module that supports Galileo, since it's the European GNSS system, and it's more accurate than GPS.

Something else that would be useful is the addition of an SD-card module to the kit. That way, if a team has bad telemetry, but their can is retrieved, they still have all their data. There were already a lot of teams that bought an SD-card module last year, so why not include it by default.

Lastly, I'm not a huge fan of the RPi Pico. It is not very powerful (though good enough for most teams) nor reliable (the bootloader can sometimes act up). I think an ESP32-based system would be better. There are many cheap options available. If you do want to spend a bit more money, you could go for Adafruit's ESP32 Feather V2 module, which has integrated 2.4 GHz Wifi antenna + Bluetooth, integrated LiPo connection and charger (so no need for the LiPo boost charger module anymore), and has a large Adafruit ecosystem (“Wings”) for additional functionality. The switch to a new microcontroller is certainly not as critical as the previously mentioned improvements, but I think it will be beneficial in the long run.

Let me know what you think, I would be happy to discuss it!

[Dominique]

Hi Sibol,
Here a former response to your post. Additional information may come later.

... since due to extremely bad weather, only 6 out of the 32 cans where retrieved. The cans that weren't retrieved often had limited telemetry because the teams had to do blind pointing with their antenna due to the cans disappearing above the clouds seconds after the launch.

Difficult to battle against lost of visibility. The RSSI (strenght of the signal) could helps in detecting the best pointing direction for the antenna. However, it is only valuable if you can catch some communication. As mentionned in your post, having GPS/GNSS data in the transmission would certainly helps a lot (see further in this response regarding GNSS).

My main takeaways on retrievability of the cans:
- teams that deviated from the standard 433 MHz radio module (and go for e.g. 2.4 GHz module instead) had significantly better telemetry
- teams that included a GPS sensor had more chance of having their can retrieved

On ground level the 2.4 GHz can probably offers facilities to locate the CanSat. For 433 Mhz (as well as 900Mhz) emitting from the ground, the antenna should be pointing to the sky (best spectrum spread) and the base station located as higher as possible (to get a line of sight to the Cansat antenna).

Notice that lower is the frequency and better is the signal penetration into objects.
Well designed 433 Mhz circuit + antenna would have a better penetration in cloudy weather (compare to 2.4 GHz). LoRa is very sensitive to line of sight (so ground would still be a difficult detection area).
You did also mentioned some RFM95 Lora module (around 868 MHz) which could be a interesting approach (BPS.space do use 900 MHz bandwidth to transmit the rocket telemetry data to ground).

I would therefore want to propose the following:
1. Replace the RFM69HCW with the RFM95 LoRa Module. .....
2. Include a GPS or other GNSS module. ....

1. Indeed, using a RFM95 LoRa Module may be nice. I will consider it for next year.
2. Including GPS or GNSS is not possible (it is not part of "offer inquery"). I would be in favour of GNSS with European Galileo.

I did propose to Mrs Corrieri to include an additionnal "documentation section in the wiki" regarding GPS telemetry. If some budget are available to cover that work I would do it with pleasure.

Something else that would be useful is the addition of an SD-card module to the kit. That way, if a team has bad telemetry, but their can is retrieved, they still have all their data. There were already a lot of teams that bought an SD-card module last year, so why not include it by default.

This is a "non sense", let me explain why.
The Flash memory make 2 MBytes and is large enough for logging telemetry data.
MicroPython allows script to open and manipulate file content. Writing a log file into the existing Flash memory is so simple with MicroPython.
Finally, as the Flash is solder onboard, there is no mechanical contact involved as the SDCard does (So less sensitive to vibration). I should have explain it in the Wiki.

Lastly, I'm not a huge fan of the RPi Pico. It is not very powerful (though good enough for most teams) nor reliable (the bootloader can sometimes act up).

The Pico 1 is a dual core @ 133 mhz. The power easily reach the Pentium 1 computation power.
I do agree with "Arduino Uno is not very powerful" but not for a Pico.
I never seen a Pico bootloader screwed up... (what I already experimented on Arduinos) but I must admit that I mostly do Python development on the Pico (and ESPs).
Notice that performance have seriously been improved with the Pico 2 (but not yet included within this year Cansat kit).

I think an ESP32-based system would be better. There are many cheap options available.

Honestly, I would prefer to support an (almost) European MCU as the Pico which is also super cheap.
The ability to make python developement on Pico is a great advantage for prototyping and experimenting (see the cansat-pico.mchobby.be documentation).
It is also inline with ESA recommendation for education as well as a Belgian recommendation for Education.
From all the langages I do have practiced in 30 years, Python is the best I had used.
Please note that advanced users can still program the Pico in C/C++/Lua/Arduino IDE/... with their favorite development environment.

I had used lot of ESP + MicroPython in the past and moved forward to the Pico + MicroPython.
Regarding your interest in WiFi and Bluetooth connectivity, I should consider the usage of a Pico-Wireless.
I tend to see the WiFi as redundant in the CanSat kit because of the radio transmission module.

If you do want to spend a bit more money, you could go for Adafruit's ESP32 Feather V2 module, which has integrated 2.4 GHz Wifi antenna + Bluetooth, integrated LiPo connection and charger (so no need for the LiPo boost charger module anymore), and has a large Adafruit ecosystem (“Wings”) for additional functionality. The switch to a new microcontroller is certainly not as critical as the previously mentioned improvements, but I think it will be beneficial in the long run.

Former CanSat kit were based on Feather and we did moved forward.
I do know Adafruit products, Feather product line and the FeatherWings ecosystem.
The Feather Lipo circuitery is limited in power (3V 300mA output in my recollection).
The powerboost can deliver up to 5 Watts (5V 1Amp) which is a great power delivery for additional components of any CanSat project.
What would be the interesting FeatherWing for CanSat ?

Cheers,
Dominique