Lots to talk about - been busy over the past few months and made a lot of progress.

Around the beginning of 2020, I finished up the structural attachments for the parachute and nosecone. I'm using a dual-deployment configuration with a 120 inch main (Cd 2.2) and a 60 inch drogue (Cd 0.97), both from Rocketman Parachutes. I used OSCALC to help with the sizing. I'm not a "rule of thumb" person so instead of using extreme lengths of oversized shock cord, I wanted to take more of an engineering approach, partially based on inspiration from this post. I ended up designing the cross-shaped bracket for the main to handle around 1000 lbf and the drogue to handle 200 lbf but I plan to beef up the drogue load capability (see below).

The nosecone is held in place during flight by two #4-40 nylon screws. I found various references on the shear capability of nylon screws but there was too much variability in the information I found so I set up my own shear testing rig with weights. My testing showed a #4-40 nylon screw fails between 40-45 lbf in single shear so two of them provides 90 lbf of retention. The design bay pressure for my pyroless recovery device is 7 psi resulting in 198 lbf of force when it pops the nosecone. Tests showed somewhat less than that due to leaks which I was able to partially address (including sealing connectors). Once I settled on a stable configuration, the nosecone has deployed reliably in 25+ ground tests. Instead of using a separate pressure transducer to monitor the pressure in the pyroless recovery device, I turned the entire pressure vessel into a transducer by mounting strain gages on the outside of it. This saves weight and has one less place for the compressed air to leak out.

A few weekends ago, I was able to complete combined drogue and main deployment testing using a truck with the rocket mounted on the back. A 3D printed surrogate nosecone allowed repeated testing without damaging the real nosecone. On the first two runs, I was trying to slow down the main deployment with a slider ring but it got hung up and the main failed to inflate. After removing the slider ring and changing the taping method, I got 6 successful combination deployments in a row. The pyroless recovery device pops the nosecone and ejects the drogue. A retention mechanism based on the pyroless recovery device is used to hold the main inside the deployment bag and inside the recovery tube. The mechanism uses the same double-D flat gear motor and bearing arrangement as the pyroless recovery device and acts as a cable cutter, just without pyro. I was targeting drogue deployment at around 50 fps and the main at 33 fps based on initial OSCALC data. However, based on stability data from RASAero and OpenRocket, I expect the drogue release will need to be tested at a higher horizontal speed at apogee due to weather cocking off the rail.

I had performed some preliminary fin sizing last year and I thought I had plenty of flutter margin but taking a closer look showed the fins were too large with excessive stability and a tendency to flutter over the expected flight profile based on FinSim calculations. This particular rocket has a couple of issues - it has a low thrust to weight at liftoff (3.7) and it is also long and thin which tends to reduce stability at high angles of attack. I didn't originally intend for it to be that long but there's not much I can do about that at this point. As a result, it will likely need to be restricted to 10 mph or less crosswind at launch otherwise the resulting weather cocking and gravity turn will generate excessive horizontal velocity at apogee that the drogue will have to handle without damaging the parachute or airframe. Launching downwind may help if the winds are stable and can be characterized on launch day. I did notice that RASAero predicts almost 2x the horizontal velocity at apogee vs. OpenRocket.

A task I was finally able to work on is telemetry link testing. There was enough time between the 5 Hz transmit frames that I was able to add bidirectional communication between the ground and rocket along with some automatic retries using the Digi XTend RF modems on each end. This will allow ground deployment override commands to be sent in case the flight computer fails to deploy as expected. I found two hills about 4 miles apart and with 1 W transmit power on each end, I got stable communication with an RSSI of -70 dB. The modems are supposed to work down to -100 dB at 115k baud so there is plenty of margin. It should be better ground to air so I may be able to reduce the power. The primary TM link from my flight computer uses the Digi XTend at 900 MHz and the backup link uses an AltusMetrum TeleMetrum on the 70 cm ham band. I had an interesting experience with the TeleMetrum though. When I first got it, I was performing combined RF testing with it and my 900 MHz solution but after a few hours of testing, the TeleMetrum failed with a sensor error (accelerometer) at startup. I sent the board back for repair and the new board failed in the same way after a short time. I can only conclude the high power 900 MHz transmitter I'm using for the primary TM link is somehow damaging the ADXL375 MEMS accelerometer on the TeleMetrum. As a workaround, I was able to recompile the TeleMetrum firmware to disable the accelerometer and make it just use the onboard barometer, similar to their other devices with less capability. I also increased the "on" time of the TeleMetrum pyro outputs from 50 ms to 2 seconds to be compatible with the gear motors I'm using in my recovery arrangement. The deployment outputs from my flight computer and the TeleMetrum are wired in parallel using optoisolators with a separate 1.5V AAA battery for the gear motors.

There was an intermittently occurring problem that would cause my flight computer to reboot occasionally when enabling the power for the valve servos. This was one of those problems that would go away for months, then show up repeatedly for an hour before going away again, just the kind of problem that likes to show up on test day. I traced it to a flaky connection in the Molex SL cables between the power and CPU boards. Looking at it on an oscilloscope showed a power dip just below the brownout reset voltage so I replaced the cable and added a dedicated ground strap connection between all the boards in the stack.

I acquired a 3D printer along the way and it has become indispensable for making small parts like brackets. I'm using Taulman Bridge Nylon for most of the brackets in the avionics and recovery bays which is much more flexible than ABS and doesn't crack, perfect for bridging between structural members that can potentially move relative to each other.

I had been worried about potential overheating of the avionics in the sun so I did some hot soak testing. The I2C baro sensor has a built in temperature sensor but I added thermocouples to the CPU module and the power supply heatsink for comparison. In full afternoon sun with an outside temperature of 99 degF, after an hour or so, the CPU module reached 147 degF, the power supply heatsink reached 139 degF, and the baro sensor (located on the CPU board) reached 136 degF. The TeleMetrum located in the recovery bay reached 144 degF. I didn't consider these temperatures to have enough margin so I added a small 12 VDC 70 mm fan to blow over the CPU board which dropped it about 25 degF. White paint apparently makes a big difference so I'll probably paint the avionics and recovery bays along with the skin around the LOX tank at a minimum.

The vehicle has been reassembled and leak checked so the major work remaining is to properly secure all the cables and tubes. I still need to cut holes in the skins for the tank vent, fill, and drain outlets along with the burst disc outlets. The tank skins are non-removable so they will be the last pieces to be installed. I also need to integrate the launch rail guides. There's a fair amount of software work remaining including the apogee detection algorithm and recording to the onboard SD card.