Team Status Report for 4/25

Progress

This week, we continued testing the final end-to-end system, integrating all subsystems we had individually tested before. We continued collecting more data from the field with our antenna dish, and ran this through our FPGA and Raspberry Pi data processing pipelines. We also tested the file reassembly and display functionalities on the Raspberry Pi, i.e. the components the user sees.

Risk Management

We believe the majority of risks have been addressed, as we have been able to test with real, field data through our entire, end-to-end integrated system. As such, no significant risk stands.

Updates to Design/Schedule

We are on schedule for demo day. Next week, we will mostly prepare for demoing and ensuring users are able to understand the different components of our system and see the end results.

Testing

Below are the unit tests/ overall tests we performed:

• Critical path of the FPGA modules
• Software latency (response latency for Rust software on Raspberry Pi 5)
• SNR
• Correctness of FPGA data pipeline
• Correctness of demodulation on Raspberry Pi
• Correctness of software data pipeline

Some interesting observations we made during testing are: (1) the satellite ID of GOES is different from that reported on official websites, which are most likely outdated – as such, we had to modify parameters in our data processing pipelines accordingly, and (2) our Rust software is running much faster than expected, with an average latency of 50ms, well under our target of 200ms – this may also be due to our Raspberry Pi 5 being very powerful.

Team Status Report for 4/18

Progress

This week, we focused on testing and validating our project with data collected from the field. This involved starting with the raw IQ data and sending it through our various pipelines to ensure the outputs from each were as expected.

Risk Management

With our project as it is, we believe the majority of our risks have been addressed. Mainly, we will be focusing on preparing our project for a demoable state, especially since much of our data requires pre-processing.

Updates to Design/Schedule

We are now on schedule. With next week being final presentations, we feel that our project is in a good state. However, we plan to collect more complete data in the field before the demo.

Team Status Report for 4/4

Progress

This week, we focused on testing and validating each individual section of our project (RF front end, Hardware back end, Software back end). Braden worked on the RF front end, Anna worked on the hardware back end, and Stephen worked on the software back end.

Risk Management

There are two risks: (1) we have only tested individual components, and not the entire end-to-end system, which means we may have to spend significant time debugging once we integrate the individual components, and (2) we have not worked on the connection between the FPGA and RPi yet, thus we must spend time to research and implement those connection before we do end-to-end testing.

Updates to Design/Schedule

We are now on schedule. After discussing as a team and with TAs, we have decided that we will keep the demodulation on the RPi, as it still aligns with our use cases, but it allows us to stay on schedule as well.  With the remainder of the time, we will work on verification and validation.

Verification and Validation

(1) The demodulation has been tested against the Satdump reference to make sure that the data will be output correctly. (2) The protocol handler is being tested with assertions to make sure that each module is outputting the correct data (Check Anna’s report for more details). (3) The software on the Raspberry Pi is being tested with unit tests written in Rust (for the file reassembly module) and manual testing on the touchscreen for the user-facing UI.

Team Status Report for 3/28

Progress

This week, we focused on finalizing each individual component for the interim demo. Stephen focused on finalizing the last module of the protocol handler and writing the software for the Raspberry Pi, whereas Anna and Braden worked on demodulation on the Raspberry Pi and testing each individual module of the protocol handler on the FPGA.

Risk Management

There are two risks: (1) we have only tested individual components, and not the entire end-to-end system, which means we may have to spend significant time debugging once we integrate the individual components, and (2) we still need to implement demodulation on the FPGA, which is extremely tricky and we cannot find many resources on it.

Updates to Design/Schedule

Similar to last week, we are pushing back implementing demodulation on the FPGA as it is quite tricky to get the timing right. Therefore, we are slightly behind schedule. However, we hope our experiences implementing demod on the Raspberry Pi in software will help guide our hardware implementation.

Team Status Report for 3/21

Progress

• Researched Costas loop and Gardner algorithm implementations for BPSK demodulation.
• Investigated methods of transferring data between systems, e.g. Raspberry Pi, SDR, FPGA 
• Reassembled file packets within the Raspberry Pi from the FPGA data

Risk Management

While researching how to demodulate the BPSK signal, we found that implementing a Costas Loop (removing baseband signal) and Gardner Algorithm (symbol synchronization) requires specialized RF hardware and precise timing configuration. To prepare a working prototype for the interim demo, we plan to temporarily manage demodulation with GNU Radio to present a more complete pipeline.

Updates to Design/Schedule

As mentioned above, we are adjusting to demodulate the BPSK signal with GNU radio for demonstration purposes. We still hope to handle demodulation within the SDR as we continue progressing.

Team Status Report for 3/14

Progress

• Finished protocol handler and completed most of the testing for the individual modules
• Collected data from the GOES satellite with our antenna using SatDump
• Began researching the connection between the FPGA and Raspberry Pi

Risk Management

We wanted to make sure that we were getting clear enough data from our RF front end for our FPGA to process the data. Rather than use GNURadio, which was the first program we tried using, we decided on SatDump, which allowed us to easily see if we were able to collect data from the GOES satellite. This helped us eliminate risks revolving around the data collection, since SatDump has tools that display the antenna gain and whether we are pointed in the right direction for the satellite. From this, we were also able to collect the data by recording it on  SatDump for later testing on our FPGA.

 

Updates to Design/Schedule

There are no updates to the design. We are on schedule as we have finished up most of the debugging and testing of our protocol handler. Thus, much of the backend data processing will be ready to test as a unit by next week. We are still working on the demodulation via FPGA. Anna and Braden will work on that in the following week while Stephen works on the software interface of our project. 

Team Status Report for 3/07

Progress

• Finished the project design report.
• Continued designing the RTL for the protocol decoder.
• Developed RadioGNU workflow for capturing test data.
• Attempted testing of the reception of the GOES satellite signal.

Risk Management

While attempting to communicate with GOES from the East Campus Garage, we were confronted with a malfunction with our SDR, which was not powering on. While the excursion was somewhat fruitful in that we used our antenna system in the field, we were unable to capture data without the SDR working. However, we have a backup SDR, which we will use for future testing. We will also be looking into potential fixes for our SDR.

Updates to Design/Schedule

There are no updates to the design. In terms of the schedule, we are slightly behind on receiving signals from GOES. This is primarily due to hardware malfunctions with our CotS parts. Until we can test again, we will focus on simulating our SystemVerilog code. Additionally, we will attempt field testing as soon as we are able.

Additional Questions

A was written by Anna, B was written by Stephen, C was written by Braden.

Team Status Report for 2/21

Progress

• Finished and presented the project design presentation.
• Continued designing the RTL for the protocol decoder.
• Physically built and set up the GOES satellite antenna.
• Started testing the reception of the GOES satellite signal using our RF frontend.

Risk Management

When we were testing the RF frontend on The Mall, we realized that the signal from the GOES satellite was being blocked by Baker Hall, which prevented us from obtaining a clear signal. To mitigate this risk, we can move to a location with a clear line-of-sight to the satellite. Therefore, early next week we will test the RF frontend at Schenley Park.

 

Updates to Design/Schedule

There are no updates to the design. In terms of the schedule, we are a bit behind on receiving signals from GOES. To help us along, Braden will focus on figuring out the GNU radio software over the weekend to start receiving the GOES data before our hardware backend is ready. Anna and Stephen will continue to work on the protocol handler and take over some of the modules that Braden was going to work on to make sure that the team does not fall behind.

Team Status Report for 2/14

Progress

• Wrote Project Design Presentation
• Began developing protocol handler

 

Risk Management

One risk is that the RF front end has not been developed yet, due to the parts not being delivered yet. We have not been able to receive and test sample data from the GOES satellite. While we are behind on the development of the RD front end due to external factors, we have started to work on the protocol handler ahead of schedule to compensate for the wait. 

 

Updates to Design/Schedule

We are still waiting for the parts to get delivered.  While we wait, we decided to work on the protocol handler before developing the demodulator since we need to be able to test out and understand sample data before we can start the demodulator. Shifting around the schedule allows us to still keep on track even though we do not have all the parts yet. 

Additional Questions

A was written by Anna, B was written by Braden, C was written by Stephen.

Team Status Report for 2/07

Progress

• Ordered all starting parts (SDR, FPGA, LNA, Antenna, Tripod, Touchscreen)
• Identified and conducted research on all necessary protocols (BPSK/HRIT).
• Began writing SystemVerilog for demodulating BPSK on our FPGA.

 

Risk Management

Our antenna may not be able to pick up signals from the satellite clearly. Although we currently have an LNA to amplify the signal, we are unsure if the gain is sufficient for our SDR and FPGA. Our contingency plan is to buy a bigger/more expensive antenna with our remaining budget of over $300. Once our antenna is here (early next week), we will immediately test it out to see if it can receive signals from the GOES satellite, to determine whether further action is necessary.

 

Updates to Design/Schedule

We initially wanted to receive the GRB signal from the GOES satellite, however, after doing more research on the modulation of that signal, we realized that it is harder to demodulate. Moreover, receiving the GRB signal requires a large antenna, which is not portable for our user. Therefore, we decided to receive the LRIT/HRIT signal instead, which is simpler to demodulate and requires a smaller antenna. No updates to our schedule.