SRAD Live Video System

The video pipeline mission is to convert analog video coming from the Run Cam Split 4’s into a digital format to receive and decode at a computer. The process begins at the Run Cam Split 4’s which output a NTSC analog video format. This feeds into the TVP5151 video decoder chip which converts NTSC to YUV422, a digital video format. The ESP32P4 DVP interface copies outputted YUV422 into ESP32P4 memory which is then fed into a JPEG Hardware encoder. After encoding, data packets were formed and sent over SPI to the LR2021 to be transmitted over 434 MHz to EAGLE which receives the data through an LR2021 and feeds it to the ESP32P4 MCU chip. The MCU then prints data through a USB-C connector onto the serial monitor of a PC connected to EAGLE which is running a python script that continuously reads the serial monitor and reconstructs data into images which is then shown using OpenCV.

Developing a live video system in a small form factor with affordable COTS components is a greatly difficult endeavor. Managing big data sets within constrained space led us to scratch our heads every single meeting. However, there were three main challenges we encountered.

Compression of video

Many attempts were made creating video compression software for our live video system as we overlooked the datasheet for the accepted ESP32P4 H.264 Hardware encoder data format. Our initial plan of using the hardware encoder failed as we attempted many solutions such as using the LCD & CAM Controller to convert YUV422 to YUV420 format and then feeding that data into the H.264 hardware encoder. However through implementation of the LCD controller and analysis of the data formats being outputted through python scripts and of the datasheet we determined that the order of the YUV format that is outputted from the LCD Controller is not in the correct order that the H.264 hardware encoder accepts. Making an attempt to flip the bytes unfortunately did not deem any success nor using the H.264 software encoder. After being stumped we came across a JPEG linux driver which we determined could work on the ESP32P4. We decided to try implementing the JPEG hardware encoder compromising speed for a functional system. This decision deemed the ESP32P4 unnecessary for our application. Although for a small compact system like this one H.264 encoding is the most practical, we ultimately decided on JPEG encoding as it worked for our application.

Developing Drivers for JPEG, DVP, UVC, and TVP5151

Although the selected electronics were capable of being very powerful, limited documentation made developing custom software for the live video system particularly challenging. When creating the TVP5151 driver, I did extensive analysis of its datasheet and took inspiration from the general structure of C++ drivers. With few examples for the interfaces we needed to implement, our team went through multiple iterations of flashing and testing code to evaluate different features and verify their behavior. This iterative process allowed us to gradually understand how to create software for the hardware.

Avionics Bay Integration

After weeks of finalizing the live video system with the new LR2021, we had a reliable and functional product ready for testing at our high-power Summer Friends of Amateur Rocketry (FAR) launch. However, during rocket integration of the rocket and system testing, we encountered several unexpected issues involving the RunCam cameras and I2C buffer chip. Because we hadn’t tested the system with other cameras, including the ones integrated into the avionics bays, we encountered compatibility issues that affected video output. The video we were getting was corrupted, however the recorded SD card video looked fine. We suspected the issues were related to camera wiring. We also found that certain pairs of cameras interfered with one another, with some combinations functioning correctly while others “corrupting” each other. Despite attempts to isolate the cause this we never figured out.

The avionics bay architecture also made troubleshooting difficult because physically swapping the Run Cams was challenging. Additionally, the architecture limited how tightly the SMA connectors could be secured, dropping the TX power output. Ultimately these issues prevented the live video system from operating during the 2026 FAR Launch.