Anna’s Status Report for 4/25
Accomplished
This week, I continued to test the system with real data. The data from the protocol pipeline was then passed onto the file reassembly on the software side to test the image we were able to recreate.
Progress/Schedule
I am on schedule. The next steps are to get ready for the demo and create the project poster and final report.
Deliverables/Next Steps
Next week, I will:
- Finish testing the system
- Work on the poster and the final report
Anna’s Status Report for 4/18
Accomplished
This week, I worked on passing real data through our protocol pipeline. I was able to get a text file with all of the data parsed to pass onto the RPi for further testing. In order to do this, I had to make Python scripts to format the data in a way that the pipeline could read it.
Progress/Schedule
I am on schedule. The team is now working on end-to-end integration with testing to put on our final presentation, report, and demo.
Deliverables/Next Steps
Next week, I will:
- Continue testing our system
- Work on the final report
New Tools/New Knowledge
Throughout the testing portion of this project, I learned how important it is to have an organized workflow, specifically when it comes to testing and debugging. Without a structured approach, tracking down issues in a complex pipeline would have been extremely difficult and time-consuming. To support this, I learned to write Python scripts to reformat and preprocess the data needed for our pipeline, which made the overall workflow significantly faster and more efficient.
Anna’s Status Report for 4/4
Accomplished
This week, I continued working on making the testbench for the protocol handler. I debugged the earlier modules in the pipeline, and am currently working with Braden to debug the FEC module to make sure it passes on the correct data to the VCDU Handler.
Progress/Schedule
I am on schedule. The team is set up to be able to test each section of our project individually, which allows us to think about how we will connect all of the parts together.
Deliverables/Next Steps
Next week, I will:
- Continue to test the protocol handler with the team
- Work on connecting FPGA with the RPi
Verification and Validation
The testbench that was made for the entire pipeline was made last week, but there were a few bugs in the testbench itself with the timing of how the data was getting passed through, specifically from the derand to the FEC module. The bugs in the testbench have been fixed, and it now successfully tests how the data moves through the pipeline (sync -> derand -> fec -> vcdu -> mpdu), and checks after each module we are getting what is expected. Furthermore, there were bugs found in the sync module using a simple testbench that sent in noise, the sync marker, and then more noise to make sure the module was able to detect the marker. I found that the bug was that the length was wrong for the registered packet. I changed the length from 886 bytes to 1020 bytes, and the module was able to pass the testbench. There are currently still some bugs in the FEC module that the pipeline testbench has found that Braden and I are currently working on.
Anna’s Status Report for 3/29
Accomplished
This week, I worked on making the testbench for the protocol handler. There were some discrepancies between how some of the modules are communicating with one another and how they pass on data, so I worked with Braden to fix those issues. Furthermore, the last module has to be tested individually first, so the testbench only tests how the data moves from the Sync -> Derandomize -> FEC -> VCDU Handler.
Progress/Schedule
I am on schedule. The team is set up to be able to test each section of our project individually, which allows us to think about how we will connect all of the parts together. The only thing that has changed on our schedule is how we will approach the demodulation after the interim demo.
Deliverables/Next Steps
Next week, I will:
- Continue to test the protocol handler with the team
- Interim demo
Anna’s Status Report for 3/21
Accomplished
This week, I worked on figuring out how to do demodulation on an FPGA. After researching what modules we would need, Braden and I narrowed it down to the Costas Loop and the Gardner Algorithm. I spent time researching the Gardner Algorithm and met up with Braden to explain my findings. After some discussion, we realized that both of the algorithms were difficult to complete before the interim demo due to timing synchronization issues between the RF signals and the FPGA clock. Because of this, we determined that it would be best for testing the system if we use a Raspberry Pi to do the demodulation for now.
Progress/Schedule
I am slightly behind schedule since we decided to change how we do demodulation for the interim demo. In order to keep on schedule, Braden and I will work over the weekend to get a working demodulation module uploaded and ready on the Raspberry Pi for the next time we meet for class.
Deliverables/Next Steps
Next week, I will:
- Test the recorded GOES data with the demodulation module
- Test the protocol handler as a whole with the team
Anna’s Status Report for 3/14
Accomplished
This week, I worked on collecting data using our RF front end with Braden. Initially, we tried using GNURadio, but quickly realized that it was difficult to tell whether or not we were actually successful in gathering data. We then decided to use SatDump for data collection, as it was much more user friendly and did the data processing through software, making it easier to verify that we would be able to accomplish it via an FPGA. In addition to the data collection, I worked on debugging and testing the data protocol modules that I have been working on.
Progress/Schedule
I am on schedule, as most of the modules in our protocol handler have been tested individually. Furthermore, now that we have collected real data, we can start using that data directly in our pipeline.
Deliverables/Next Steps
Next week, I will:
- Work with Braden on understanding the format of the data we collected
- Design and write up the demodulation module for the I/Q data
Anna’s Status Report for 3/07
Accomplished
This week, I worked on some modules for the protocol decoder. I created the VCDU handler and worked with Stephen on the M_PDU handler. The team also tried to go to the top of the UC garage to collect data, but there was an error with the SDR, so we plan to try again with another SDR that we have access to.
Progress/Schedule
I am on schedule with the protocol decoder. The team and I were able to mostly finish up the initial design of the whole protocol decoder. Next, we will have to test and verify the system and continue trying to collect sample data.
Deliverables/Next Steps
Next week, I will:
- Test and verify the modules I worked on (sync marker, VCDU handler, M_PDU handler)
- Collect sample data
Part A Response
The Satellite Buddy addresses global inequities in weather data access by providing a low-cost, internet-independent solution that can be deployed in developing regions, rural areas, and remote communities worldwide where reliable infrastructure is unavailable or unaffordable. While GOES satellites serve the Americas, our FPGA design can be adapted to receive data from geostationary weather satellites serving all continents, enabling communities globally to access important weather information without dependency on commercial services.
Anna’s Status Report for 2/21
Accomplished
This week, I mostly focused on the Design Presentation as I was the one presenting. I worked on putting together the slides and practicing the presentation. I also worked with Braden and Stephen on building our antenna and the tripod. We brought it out to The Mall (in front of HH), and tried to receive the GEOS satellite data.
Progress/Schedule
I am behind schedule due to the parts just being delivered. Because we have not successfully gotten test data, I plan on working on more of the modules for our protocol handler with Stephen, so that Braden can focus on the data retrieval.
Deliverables/Next Steps
Next week, I will:
- Work on the FEC module for the protocol handler
- Test the data flow from the sync module to the derandomization module to the FEC module
Anna’s Status Report for 2/14
Accomplished
This week I did further research on demodulating the BPSK signal. After doing more research, it is unclear how much work the SDR does and what I/Q data we get. Thus, we decided to take a pause of the development of the demodulator and work on the protocol handler instead. I worked on recognizing the sync marker for the packets we receive. At first, I developed an FSM to detect the sync marker, but later realized that a shift register and a comparer works better as it is less hardware.
Progress/Schedule
I am behind schedule due to the parts not yet being delivered. However, in the grand scheme of things, I am still on time to complete the MVP since we shifted around the schedule.
Deliverables/Next Steps
Next week, I will:
- Set up the SDR to start receiving GOES data.
- Retrieve sample data to test with the demodulation module
Part A Response
Our project addresses public safety by providing real-time, independent access to weather satellite imagery that updates every 15-30 minutes, enabling local emergency managers, rural communities, and disaster response teams to track developing severe weather with minimal delay. Unlike internet-based weather services that can fail during disasters when infrastructure is damaged, our system receives data directly from the GOES satellite via radio signals, allowing access to critical weather information when it’s needed, which allows for preparation and prevention of injury.
Anna’s Status Report for 2/07
Accomplished
This week I started looking into SDR’s that our team could use. We narrowed it down to the LimeSDR Mini v2.2 and the RTL-SDR Blog V4. We ultimately decided on the LimeSDR Mini v2.2 because it was readily available from Braden’s other class. I also started looking into GOES data transmission types. I found that LRIT/HRIT was easier for us to decode than GRB, so we started doing more research on how to demodulate the BPSK signal we get. I also started working with Braden and Stephen on the demodulation module as well to get us started for when we start getting sample data from our SDR.
Progress/Schedule
Currently, I am on schedule and a little bit ahead. The main thing that was planned for this week was to finalize the parts that we needed to order and place the order for them. I also started looking into the protocol documentation for when we start the protocol handler.
Deliverables/Next Steps
Next week, I will:
- Set up the SDR to start receiving GOES data.
- Retrieve sample data to test with the demodulation module