Even though the covid times, the Picoballoon challenge in 2021 was planned on last Monday of June. As in previous year, I've started designing my very own picoballoon probe to participate in the challenge. The rules stayed the same, the probe has to weight below 20 g and has to report at least it's approximate altitude, longest surviving probe wins.
Requirements
Based on previous years experience, I've made several requirements on the design:
- Use LoRaWan to send data payload back to earth (still don't have the HAM radio license, so APRS was not an option)
- Reduce amount of devices on the PCB to bare minimum
- Measure air pressure by the good old MS5607 I've used many times before
- Powered by CR2 battery to allow sending payloads during night
- Use working and low power solution for GPS this year!
- Keep the programming and debug headers on an easy-to-snap part of the PCB so the headers could be removed before launch to reduce weight
- Design a "remove jumper to power-on" solution to allow powering the device on just before the launch instead of soldering battery to PCB few hours before take off.
- Nice web tracked
- Finalize the design in advance to have enough time for proper testing
The design
I've chosen the worst time to start designing a new device, the Covid caused it's almost impossible to get some MCUs and other silicon devices. All of my favorite STM32 MCUs were out of stock everywhere at the time, so I had to dig through my junk boxes to see if there are any parts I could salvage for the picoballon. Fortunately I've found a STM32F051 I've bought for another project some time ago. The RFM95 module was taken from the forgotten prototype of the 2020 probe. The rest was still available and I had a few spare parts from the previous year.
The fundamental design stayed almost same as in the previous year, although it is bit simpler as I gave up on the solar power option. The heart of the probe is the STM32F051 that is reading air pressure and temperature from the MS5607 sensor and Quectel L96 GPS/Gallileo/GLONASS receiver, the gathered data are sent over RFM95 module to LoRaWan The Things Network. The power is provided by a Lithium CR2 battery with nominal voltage of 3 V. This voltage is stepped up to 3,3 V (especially for the GPS module) by the low quiescent current step-up power supply MCP1640. Add few more passives and that's it!
The PCB used has a thickness of 0,6 mm to reduce weight as much as possible, thinner PCBs can be bought but the price grows exponentially with lower thicknesses, so I stayed with the standard 0,6 mm version to cut costs a bit.
Issues
When testing the hardware (remember the last requirement - finalize the design early enough? I've had a semi-working firmware for firsts test like 3 weeks before launch, better to start sooner next year :) ) I've run into issue with very high sleep current of the board. After some lengthy investigation, I've found the problem was the RFM95. Long story short, the SPI pins of the RFM95 need pullups else the current consumption will grow up to around 0,5 mA instead of advertised 0,7 uA... This was easily fixed by soldering some 0603 resistors and piece of wire on top on the PCB.
Another thing that hit me in face 3 days before launch was the GPS time to first fix. This year I used the Quectel L96 module, very nice and small piece of the hardware for a reasonable price. The problem is it never worked as expected. The advertised cool start TTFF is below 1 minute that sounded just marvelous. However when testing with the real hardware shortly before take-off it took like 20 minutes to obtain a valid GPS position and when the module was put into the standby state and woken up again, it took another few minutes for the fix to happen (instead of several seconds stated in the datasheet). I guess the module is damaged, maybe I semi-killed the RF part by ESD or some other crap. So no GPS this year again...
Firmware
Most of the generic code is based on the old one, or to be more precise, it was taken from my AFW project. The code logic is straightforward:
- Initialize the MCU, MS5607 and RFM95
- Read pressure and temperature from the MS5607
- Load latest LoRa TX sequence number and region from persistent memory (flash)
- Based on the sequence number, the GPS might get enabled (it works only every few cycles), if so, the MCU is put to sleep until the GPS fix is obtained or timeout event occurs.
- Based on the GPS position (or recently known position) the LoRa region is selected (there are several frequencies across the globe) - RFM95 has some output filters, but wide enough to tune away from the default 868MHz
- The payload is assembled and sent.
- RTC alarm is set and device goes to power off state, minimizing its power consumption (all devices are powered off before, if applicable)
The LoRa is using the ABP mode to access the network as it's much simpler than the more secure and widely used OTAA mechanism - the ABP has all the keys hardcoded in the device, therefore the payload can be encrypted and sent directly, no authorization to network (therefore bidirectional communication) is required. This greatly reduces time required to connect to network and current consumption and increases change the data will make it through.
Web tracker
This year I had a huge advantage, my GF has been learning programming in python for a while and was looking for a nice project to learn Flask, so I could (or better should have had) focus on the hardware/firmware design and debugging. The tracker is written in python and Flask framework, the data are stored in the sqlite database locally on the server. It has several nice features:
- Responsive design (using Bootstrap framework)
- Info boxes on map points
- Good looking table with data
- Temperature and altitude graphs
- Well tested by unit tests
I'm running it on my private web server in docker container, the nginx web server just redirects all requests to the container that does the processing. The data from the probe are received by the TTN and send to the tracker using a web integration plugins. However this year the TTN is in transition between the legacy infrastructure and new ultra shiny cool new cloud version that's pretty shitty for my purposes as it doesn't provide information about the gateways that received the data, therefore I cannot use it to estimate the probe location when GPS data are not available. I've tried the new cloud version, but it adds several more layers of abstraction and I had a significant failure rate when trying to send the data to this new network, the old one worked well with the same code (just different keys). Fortunately the legacy network won't be shut down until the end of 2021, so this year I stayed with the old one.
Launch
The probe was launched on Monday 28th of June 2021 around 10:45 of local time. The final take off weight was 12,39 g. After launch it slowly ascended to approximately 8500 m. More progress can be found at tracker.
