Things that Went Well

• The Pyxida could see more satellites on the launch pad than the TeleMega could.

• Configuration lists for the COTS altimeters helped ensure we had the right settings for the TeleMega and Marsa.
• We had Pyxida radio connection at both the away team and the launch line.
• At least one camera was turned on and taking video from Pyxida.
• We got telemetry data from TeleMega at both the away site and launch line.
  • The away team received signifcant amounts of packets across the duration of the entire flight.
• Antennas - We color coded these with tape to ensure they were correctly attached to their corresponding SMA connector that went to the TeleMega and Pyxida.
• TeleMega remained on even after the rocket broke apart.
• A lot of new avionics members were trained and hopefully learned a lot throughout the year.
• New Pyxida hardware was designed and manufactured, and fixes were found and made on all the boards over IAP.
• We made a lot of progress with Pyxida radio and did range testing from the green building twice.
• A lot of progress on the ground station was made, a new mock Pyxida was designed to test it, and we succesfully moved from PySide to PyQt
• Over 100 unit tests and a hardware testing script were created for the Pyxida Firrmware
• PCBs were made to control cameras and sofware was written for them.

Issues and Things to Change

Cameras

The current method used to turn on the cameras is unreliable. It's possibly because the USB connections used when connecting the cameras to the BBC are not very good. Additionally, there is not feedback to whether the cameras have actually been turned on. Furthermore, the cameras have been unreliable when reporting their own battery levels (sometimes that say they're fully charged, but when putting them into video mode, they quickly realize that they are not fully charged and quickly drain.)

Possible Fixes for Cameras

• We should not use the usb connection to turn on the cameras. Instead, we should solder wires onto the board that attach to a locking connector. This locking connector can then attach to the BBC. This solution should work with the current iteration of the BBC.
• We should get an external battery that attaches to all cameras in the rocket so we only have one battery to charge and know the battery charge level reliably. This should be attached to the cameras with a locking connector, not over USB.
  • If we don't do this, we should at least buy a plug with 5 usb ports (or a power strip and 5 usb plugs) and 5 mini usb cables just for the cameras. We shouldn't have to spend time deciding which cameras should be charging prior to flight and swapping them out. This adds extra stress, more things to worry about, and the possibility for something to be uncharged. If we do have separate batteries for each, they should each by plugged into their own dedicated chargers for the entire time before being integrated to ensure they are fully charged.
• We should find a way to verify if the cameras are on and taking video. We can find this by probing different parts of the camera boards and finding a camera on/ video on indicator. This wire (or maybe 2, for checking if its on and if video is on), can be attached to the locking connector that attaches to a BBC version 2. (the current BBC probably can't check this).
• Testing every individual camera. We learned that the Firefly cameras are not the same. Each ones has potentially slightly different hardware inside, and testing that one camera works is not sufficient for testing that they all work. This is even more true for the Firefly cameras than most hardware because they literally have different components inside each one.
• Camera configuration list. We had configuration lists for the COTS altimeters and these worked well. We should have one for the cameras that specifies exactly what each camera setting should be.
• Or, we could try different cameras entirely.

Away Team vs. Launch Line Communications

The away team communicated the telemetry data received from the TeleMega and Pyxida, and (maybe?) tried to send a command to Pyxida. This made it take longer to get feedback about altimeter status because the launch line team has clearer hand held radio communications because they are closer, and we don't need to hear the telemetry data from both the launch and away team since they receive the same data. The away team also wanted to hear a countdown over the radio so they could be prepared to track the rocket with the Yagis.

Fixes

• The away team should only report if they have telemetry (not the data, the launch line team can do that).
• The away team should not send commands to Pyxida, and we should try to create a software solution for this (I.E. a button that says I am the launch team that needs to be clicked to allow packets to be sent).
  • Multiple teams sending commands is a recipe for disaster 
  • Luckily we used idempotent commands for turning on the video on and cameras, so additional commands had not negative effect. We should continue using command like this that have the same effect when sent multiple times for this reason, rather than using "Toggle" type commands, even if that's what the hardware is really doing.
• The away team needs a countdown over the radio so they can be ready to track the rocket with Yagis.
• We need to clearly communicate to the away team that their role is record telemetry and let us know if they have it, not the data itself. (We didn't communicate that well).
• Ideally, we should make sure to have an expereinced rocketeer at the away line to help out. (They may have realized reporting redundant telemetry wasn't needed).
• Also, we could create a wifi based hotspot hosted web page that displays the status of the telemetry so the Rocket Team President can look at their phone or laptop and instantly see for herself the status of the altimeters.

TeleMega GPS Lock

The TeleMega GPS took a very long time to find satellites on the pad. We should make sure to turn the TeleMega on before putting it on the pad (when its pointed sideways so it goes into idle mode, not armed mode) and allow it to get a GPS lock when its off the pad. Then turn it back off. Getting this GPS lock could allow it to a warm start on the pad and more quickly get a GPS lock.

Radio Beacons

The radio beacons did not survive the breakup event of the rocket. We need to have a conversation about whether its acceptable for the beacons to not work in case of failures like this, and if not, we need more durable beacons (either design them or buy them.) One way to help fix this could be to use beacons with patch antennas rather than wire whip antennas as they might be more durable.

Software Testing

A lot of progress was made with testing software (over a hundred unit tests were written). But, we need more of a focus on integration testing too. Unit tests are great, but to really test the firmware we need integration tests. I think HOOTL should be a priority for the firmware early next year. We also need more tests of the firmware on the hardware itself.

Avionics Team Structure

As the team orients itself towards a focus on a two stage space shot, the requirements and demands on avionics will become increasingly difficult. Even this year, I struggled with managing the team, learning the diverse set of skills required for avionics to function, training new members, and ensuring that all the requirements were met and tested. I think this is only going to get more difficult, and we might need to restructure avionics for this to work well.

As I see it, avionics has four main competencies needed:

Software (Responsible for design and testing of ground station software and firmware)

• Ground Station - Python and Qt programming skills
• Firmware - Arduino and c++ programming skills
• Platform IO and build tools
• Unit Testing
• Integration Testing (Hootl and more)
• How to use Git

PCB Design (Responsible for design and testing of Pyxida hardware, ground station hardware, other PCBs, and sensors)

• Electrical Engineering knowledge and PCB design skills
• Know how to use Eagle CAD, Kicad, or other PCB CAD software
• PCB Manufacturing (soldering, re-flow ovens, etc.)
• PCB Testing Tools (Logic analyzer, oscilloscope, test points, etc.)
• Basic Arduino knowledge (enough to upload small test scripts to boards to test them and read sensors).
• Digikey

Electronics (Responsible for COTS altimeters, wiring, cameras, and physical placement of these in the rocket)

• How to use CAD software and interact with the team's SVN for CAD.
• Soldering skills (particular for wires)
• Knowledge of different connector types and which to use (when to use locking connectors)
• How to configure the COTS altimeters and understand how they work.
• Design the wiring for the AV Bay and work with Inner Structures to make sure everything is placed in a way to make the wiring easier.
• Buying, charging, and testing batteries.
• Testing the AV Bay (shake test, heat test, etc.)

RF (Responsible for Beacons, Telemetry, and Hand Held radios)

• General understanding of how RF works
• RF tools (Hack RF, analyzers, etc.)
• Helping to design RF components for the Pyxida, Beacons, and ground station
• Understanding the RF environment of the rocket and knowing where to place antennas and what needs to be shielded
• Ham Radio Licenses
• How to configure and setup Hand Held radio, where to get them, and get them ready for launch
• Antennas selection and design (both inside the rocket and on the ground)
• Range testing and output power testing of the radio components.

I don't think we need to break avionics into different sub teams, but I think we might want to internally structure avionics with these main areas in mind. In particular, I think it could be a good idea for next year's avionics lead to appoint "sub-sub" team leads for each of these core competencies. These would be leadership roles and I think we would want to require that these leads help train and recruit members working in these areas, and are responsible for the components of avionics in these areas. I think this has a few advantages.

• It promotes and helps give members leadership skills on rocket team
• It allows people to focus on a set of skills and competencies they need and could help new members know what they need to learn to do work for different parts of avionics.
• It could help ensure that we have multiple people who have these competencies.
  • Currently, we have a lot of our PCB design knowledge leaving the team (Jacob and Shreeyam), and having a lead that helps train new people and rebuild this competency on the team could be important
• It takes some of the pressure off the avionics lead to learn all of this in detail and might help them manage the requirements of avionics better.

Of course, it's up to next year's lead (Luka) to decide if they like this advice, and how to best structure the team next year.