v1.1 Prototypes:

I built three v1.1 prototypes. These are roughly 12.5mm x 30mm (2 layer PCB) and weigh 2.0g. Pretty small and light for what they do. That BMP384 pressure sensor (the metal can with the hole in the top) is only 2mm x 2mm, with 10 pads underneath. It is nearly impossible to solder -- I must create solder bumps on both the BMP384 and the PCB, then slather gooey solder flux over the PCB pads to keep the part in place while I heat it with the hot air gun. That part, and the LSM6DSO32, are the first parts soldered onto the PCB. I then test the connection by verifying the input protection diodes exist between GND and the pads before moving on to soldering the rest of the components. This method is tried and true for me, but is time consuming.

At first, I thought that it would be simpler/easier to purchase a CP2102 USB-to-UART adapter board to interface from the computer/phone. Adding the CP2102N component was expensive, and big, so I outboarded it. A CP2102 breakout board is relatively cheap and available (<$7 at Amazon.) I regretted this decision the moment I saw a potential user attempt to get the Win11 drivers installed on his laptop. The CP2102 adapter was listed as "Other" in the device list and we couldn't get it properly located as a PORT. 

The other issue is that it required a custom harness that wasn't exactly pretty:

I was testing performance either by tossing it by hand a few feet into the air, catching it, and placing it on a desk until it completed the flight. I also attached it to one of my quad copters to get more altitude. The v1 prototype did get a chance to record one rocket flight. It was a pretty large model with a separate payload section having vent holes drilled into it. I expected strange artifacts to appear from unknown sources, but the result was a pleasant surprise:

I don't know why that step in altitude appears at apogee. My suspicion is that the barometer is susceptible to the mechanical shock from chute deployment -- the payload was not very well secured in the payload section and could have dislodged to rattle around. The sample intervals change from 20ms to 1s at 10.8s but there is no visible artifact from that and the descent is tracking nicely without noise. It is hard to make a case for changing any electrical parameters.

v1 Upgrades:

After the first prototype PCBs were populated, there were a few features added to improve performance and/or the user experience:

Firmware Changes:

1. A first-order temperature compensation was applied to the raw pressure data when calculating apogee and landing. The temperature can change dramatically during a flight, especially if the Payload is not enclosed within a separate payload section of the rocket and is exposed to ambient conditions after chute deployment.
2. Every 5 seconds the launch altitude value is updated to prevent drift if the rocket isn't launched immediately after arming.
3. After arming, the PIC collects 500ms of data (10 samples) in a ring buffer. This data is prepended to the flight data to show a complete picture of the launch prior to the detection threshold. The gyro data is just loaded with zeros.
4. Added user selectable parameters: Fast sample data rates (50Hz, 25Hz, 12.5Hz, 6.25Hz), Fast sample rate duration, Accelerometer filter bandwidth, Launch confirmation debouncing.

Application Changes:

1. The application calculates flight parameters (doesn't rely on the PIC's calculations) to yield more accurate numbers.
2. Incorporates the FW changes above into the settings and charting.
3. Created native apps for Android, Ubuntu Linux, Raspberry Pi OS. (Can't do MacOS until I find a willing Mac user.) The Android app doesn't include any graphics -- it's a pretty tiny display anyway -- its primary purpose is to download flight data while in the field and reset the Payload to record another flight (it does, however display calculated flight stats.)

Each significant upgrade was released to Github. At the time of this writing the release is 1.3.0.