The first attempt at a lightweight LoRa tracker was mostly a success, but there are a few things I'm going to change in V2. Most are fairly minor, but in the end I think all of them combined will make a big difference in the performance of V2.

• Floatini V1 uses two ESP32S3 processors, one to handle the radio and sensors, and the second for managing the camera. While the S3 variant supports DFU, one mistake was that I didn't break out the UART pins for the secondary camera processor, so flashing the bootloader was impossible. I never could get it working, however the main processor was fully functional. The ESP32S3 has a lot going for it: plenty of storage and RAM, two cores, and very cheap for the features it offers. However the entire ESP32 platform is very tightly tied into an RTOS, and this is something I'd rather avoid as an RTOS is overkill for what I need. In order to make the software as robust as possible, dynamic memory allocation is something that my firmware will be designed to avoid. The ESP32S3 is pretty power hungry as well, and the sleep modes are not very flexible. Even with the processor speed reduced to 80MHz and WiFi turned off, it uses around 40mA. The internal ADC peripheral is also pretty terrible, even for a 12bit ADC. It has significant offset, non-linearity, and lots of missing codes. While any one of these reasons isn't enough to change my mind, in combination I decided to abandon the ESP32 architecture for this project.
• The boost converter chip I had chosen (MCP1640) gave me lots of issues in this design. When the battery voltage was <2.5V it had serious trouble keeping a steady 3.3V output, even with a modest current draw of 80mA. According to the datasheet, it is specified to operate down to an input voltage of 0.35V, so it was nowhere near the device limit. When slowly decreasing the input voltage below 2.5V, the current draw from the input would spike to 300-400mA, indicating a massive drop in efficiency. It could be that the regulator couldn't handle high current spikes, or that there wasn't enough capacitance at the output. However, it seems that others have had a similar experience with this chip also, so in the future I will avoid using this one.
• The cutdown mechanism consists of a transistor which turns on an SMD heating resistor, which in turn melts the cord connecting the payload to the balloon. In practice, the PCB conducted away too much heat for this method to be a viable option, especially at extremely low temperatures.
• While not technically an issue, another thing I would change is the battery/battery connector. The CR123A battery connector contributed to over half of the weight without the battery. Additional research found there are alternate clip-style connectors that offer a large weight reduction. Floatini V2 will incorporate these instead.
• In an attempt to reduce EMI/RF noise for the GPS and LoRa transceiver, I used an LDO for each power domain of the circuit. Lots of probably unnecessary cost and space was wasted with this approach, and due to the complexity of the design the PCB had to be 6 layers. In retrospect, a single LDO following the boost stage is probably sufficient for reducing meaningful system noise. Another complicating factor the LDO power-on sequence. By mistake, I discovered that driving the interrupt line from the barometer high, caused current to flow through the protection diodes of the sensor. In only a few seconds, the sensor was hot enough to burn my finger from the direct short.
• This design used two RGB leds for status indication, one for the main processor, and one for the camera processor. Separating the status indication into several single-color LEDs easier to read, since it was sometimes difficult to distiguish colors due to imperfect RGB mixing.
• The integrated 915MHz antenna worked well enough, but I never found a combination of matching capacitors that resulted combination with low VSWR. In the next iteration, going with an external antenna connector will allow for more flexibility in this area.
• Deciding to incorporate the camera circuitry onto the same pcb as the tracker I think was a mistake. In the interest of long-term system flexibility, moving the camera to a completely separate PCB saves cost and weight for missions that don't need a camera.

For the most part, V1 is fully functional, and I plan on doing a test launch once the firmware is in a testable state. All things considered, I'm happy that the basic functionality of V1 is operational. Going forward, the main hurdle will be the telemetry protocol implementation, which is still very much proof-of-concept at this point. In the next entry, I'll go over my design process for Floatini V2 and how I arrived at each of my decisions. If this project piques your interest or you have any tips/suggestions, feel free to leave a comment or message me directly!