Posted on

Anna’s Status Reports

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
Posted on

Braden’s Status Reports

Braden’s Status Report for 4/18

Accomplished

This week, I focused on verifying our project is capable of functioning with raw, field-collected inputs instead of the sanitized test vectors used to individually verify each module. I also helped implement the data communication between the FPGA and Raspberry Pi by writing a SPI protocol handler in SystemVerilog.

Progress/Schedule

Our project is currently on schedule, but the punctuality of our completion depends on the number of errors that arise during debugging.

Deliverables/Next Steps

  • Collecting new test data.
  • Verify all other RTL modules

New Tools/New Knowledge

Through this project, I learned a lot more about RF and analog systems. In particular, qualitative measures of success like Signal-to-Noise Ratio and methods of converting and processing analog signals in the digital realm. Understanding how this is accomplished in both hardware and software realms has opened new avenues.

Braden’s Status Report for 4/4

Accomplished

This week, I focused on correcting various errors with our Reed-Solomon error correction module. This involved stripping it down to a “dummy” module that simply passed forward uncorrected data and comparing the attempted corrections against this dummy.

Progress/Schedule

I believe that we are reasonably on schedule, as all the individual components of our project have been completed, but require testing and assembly to form a cohesive workflow.

Deliverables/Next Steps

  • Fix FEC to a functional state.
  • Verify all other RTL modules.

Braden’s Status Report for 3/28

Accomplished

This week, I primarily focused on developing a software solution to our demodulation problem. I worked with GNU Radio to implement a Costas Loop, Gardner Symbol Synchronizer, Root Raised Cosine Filter, Linearizer, etc. This processes our signal and reduces it to the bare binary data necessary for our protocol handler. I also worked on cleaning up the forward error correction to better interface with the other components.

Progress/Schedule

We are slightly behind schedule due to complications with FPGA modulation; however, we have a plan such that we can still decrypt satellite communications. We are focusing on validating our protocol handler such that the received signal is convertible into an image file.

Deliverables/Next Steps

  • Determining feasibility/methodology to demodulate GOES signal within FPGA
  • Connecting protocol handler to display module
  • System-wide testing and verification

Braden’s Status Report for 3/21

Accomplished

This week, I focused on implementing BPSK modulation. I identified two modules necessary for demodulating the signal: a Costas loop and the Gardner algorithm. The Costas loop is necessary for recovering the baseband waveform; it accomplishes this by locking on to the phase and removing the carrier wave from the modulated signal. The Gardner algorithm performs symbol synchronization by detecting and adjusting for symbol timing errors.

Progress/Schedule

Based on the rapidly approaching interim demo, our team has elected to temporarily render the demodulation via Radio GNU in a Raspberry Pi. This will allow us to showcase more of our design pipeline, as the signal must be processed into a binary stream for the protocol handler we designed.

Deliverables/Next Steps

For the purpose of a more complete interim demo, we plan to work with GNU Radio to handle software demodulation of the BPSK signal. Then, we just need to properly connect the different modules of our processing pipeline.

Braden’s Status Report for 3/14

Accomplished

This week, I made progress on the forward error correction component of processing the GOES binary protocol. The packets are loaded with Reed-Solomon error correction codes, which when properly handled, enable a degree of calculated signal recovery.

Progress/Schedule

Our team is reasonably on track, with us winding down work on the protocol handler. Once the protocol handler is complete, work only remains on signal demodulation and image display.

Deliverables/Next Steps

Next week, our team hopes to focus on demodulating the BPSK signal, such that it is converted into a binary stream fed into the protocol handler.

Braden’s Status Report for 3/07

Accomplished

This week, I primarily worked on developing a RadioGNU workflow for capturing and visualizing data from the GOES system. Now that our parts have arrived, we can attempt to interface with the weather satellites. I also made progress on the SystemVerilog for the Reed-Solomon forward error correction technique.

Progress/Schedule

We are behind schedule due to unexpected part malfunctions while field testing. Our SDR was unable to power on; we plan to swap it with a prepared replacement for future excursions. If our equipment functions as intended next week, we should properly receive data.

Deliverables/Next Steps

Looking into next week, I expect to capture field testing data from our antenna. This will allow us to test our RTL with the actual protocol. I will also continue working on the forward error correction algorithm.

Additional Questions

With consideration of environmental factors, our project proposes a low-infrastructure, low-power, reusable, and portable method for receiving weather data. Since our device only receives RF broadcasts (no transmission is necessary), any electromagnetic interference irradiated is kept to a bare minimum. It also provides advance notice to users of any adverse environmental factors, while keeping its own effect on the environment to a minimum.

Braden’s Status Report for 2/21

Accomplished

This week, I contributed to the design presentation by adding quantitative benchmarks for our project goals. We also received our parts near the end of the week, so I met with the group to assemble our antenna and test it in the field. I was able to receive a signal on the antenna and view it via a simple RadioGNU program.

Progress/Schedule

I am generally on schedule now that the parts have arrived. The main focus is ascertaining a satellite signal and collecting data for demodulation.

Deliverables/Next Steps

Next week, I will:

  • Complete the RadioGNU workflow for receiving antenna data
  • Capturing real world data to use as test inputs.

Braden’s Status Report for 2/14

Accomplished

This week, I investigated the layered protocols necessary to interpret the GOES signal. The signal arrives as a binary protocol modulated with BPSK for analog transmission. Deciphering the binary protocol reveals the image data our device wants to display. Hence, I worked on calculating the forward error correction code.

Progress/Schedule

I am mostly consigned to researching methods for accomplishing our project goals until our parts arrive. They are expected to arrive next week.

Deliverables/Next Steps

Next week, I will:

  • Receive the parts for our project.
  • Capture a GOES signal in the field.

Additional Question(s)

In regards to the social impacts of our project, we envision our device as useful to isolated or disconnected communities which cannot rely on traditional broadband resources. Hence, being able to access timely, detailed weather reports provides useful information to potentially disadvantaged communities. Notably, our device provides both benign and crucial weather updates, meaning that while it provides warning for inclement conditions, it also provides practical notifications like incoming rain or temperature fluctuations for users to plan their lives around.

Braden’s Status Report for 2/07

Accomplished

This week I researched the GOES satellite protocols. The primary transmission methods of interest to us were the GOES rebroadcast (GRB) and High Rate Information Transmission (HRIT), where GRB is modulated with QPSK and HRIT is modulated with BPSK. Ultimately, it was decided to focus on receiving HRIT/LRIT signals, since the GRB signal requires a significantly larger antenna dish, which would affect the usability and portability of our device. Following these developments, I looked into specific equipment that would enable our device to receive and demodulate these protocols. Specifically, I found a 1.7GHz GOES antenna and a low-noise amplifier to act as our RF front end.

Progress/Schedule

I am currently on track. The primary accomplishment slated for this week was determining and obtaining the necessary parts for our project. It was of particular importance to secure an SDR and antenna so we could begin capturing satellite data.

Deliverables/Next Steps

Next week, I plan to interface with the SDR to identify how RF IQ data is delivered. This should provide insight into how our demodulation program can be structured. Furthermore, when our antenna is delivered, I plan to capture data from the GOES satellite for testing.

Posted on

Stephen’s Status Reports

Stephen’s Status Report for 4/25

Accomplished

This week I mainly helped Anna and Braden test the FPGA data pipeline. One major observation we made is that we receive data significantly out-of-order from the satellite. This could be due to multiple instruments on the GOES satellite transmitting data at once, or simply due to packets getting reordered while travelling through space. As such, we decided to move the final component of the protocol handler (the MPDU decoder) from FPGA to the Raspberry Pi, as we have a much larger RAM for holding out-of-order packets. I worked on this migration.

Progress/Schedule

We are on schedule to demoing during finals week. Please refer to the section below for my plan next week.

Deliverables/Next Steps

Next week, I plan on mainly working on the demo and the final report. As our project is different from traditional capstone projects, with a large component being interfacing with other systems like satellites, we will think about how to best present our project so that users can easily understand and see our results and work done.

Stephen’s Status Report for 4/18

Accomplished

This week I thoroughly tested and debugged the connection between the FPGA and the Raspberry Pi. I struggled with several bugs involving the SPI protocol, specifically timing issues, as the FPGA and Raspberry Pi operate on very different clock domains (50 MHz on the former versus ~16 MHz on the latter). I was ultimately able to successfully transfer data between them on the MOSI and MISO lines.

Progress/Schedule

We are currently a bit behind schedule, as we are still working on integrating the end-to-end system together. One of our biggest obstacles is the lack of documentation that can be found online regarding GOES-specific values, such as its spacecraft ID. We are working on mitigating these issues.

Deliverables/Next Steps

Next week, I plan to finish integration of the end-to-end system such that we are able to collect live-data from the GOES satellite on the antenna, send that through our FPGA, send this data to the Raspberry Pi, and process it and display various images for the users to see.

Tools/New Knowledge

As this project required interfacing between many existing subsystems, such as the GOES satellite (which communicates via specific protocols developed by SANA, the spacecraft agency), FPGA, and Raspberry Pi, I gained lots of experience finding and reading through specification sheets. This was especially important for designing the protocol handler on the FPGA, as a single mistake would cause the packets to be corrupted, making us unable to receive correct data.

Stephen’s Status Report for 4/4

Accomplished

This week I began verifying the software component, as well as helping Anna write the testbenches for verifying the end-to-end correctness and timing of our protocol handler on the FPGA. In terms of the software component, I wrote a few unit tests in Rust to mainly test edge cases in file reassembly, as well as manual testing on the touchscreen for the user-facing UI component.

Progress/Schedule

I am on schedule, as I have almost completely tested and verified that the software component on the Raspberry Pi is working. We are currently on track for testing the FPGA protocol handler as well, which is our most complex subsystem.

Deliverables/Next Steps

Next week, I plan to continue testing the end-to-end system. I plan to continue working closely with Anna and Braden, who are more in charge of the frontend components, to ensure that the interfaces between each subsystem is working as expected and that our product delivers the required performance and reliability as we initially laid out.

Stephen’s Status Report for 3/28

Accomplished

This week I finished writing the software on the Raspberry Pi. We are now able to display archived images, as well as numerous types of weather information, including wind, fire, raw pictures of Earth, etc. I also finished testing the final component of the protocol handler using SystemVerilog testbenches.

Progress/Schedule

I am now on schedule, as I have finished the entire software backend module this week, including file reassembly, data archival and storage, and controlling the user facing touchscreen. I have tested the software on our Raspberry Pi and touchscreen and made sure response time is below the requirement.

Deliverables/Next Steps

Next week, I mainly plan to prepare for the interim demo. In addition, I will talk with Anna and Braden about coming up with a plan to start testing our system end-to-end by integrating every individual component together. I expect there will be significant debugging effort required, especially debugging how the different modules interface with each other.

Stephen’s Status Report for 3/21

Accomplished

This week I was able to reassemble packets received from the FPGA into complete files on the Raspberry Pi. I have also started working on the device driver for the user-facing touch screen, which is taking a bit more time than expected due to the complex protocols that must be followed (otherwise, the device driver panics).

Progress/Schedule

I am personally slightly behind schedule, as I am still working on the software backend. Anna and Braden are also slightly behind as they have pivoted to performing demodulation in software instead of FPGA for now (see their reports for more details).

Deliverables/Next Steps

Next week, I plan to finish the Raspberry Pi code entirely, and unit test the touch screen as well as software features like changing the type of images displayed and archiving information. I also plan to start testing the end-to-end system in light of the upcoming interim demo.

Stephen’s Status Report for 3/14

Accomplished

This week I finished all the backend components on the FPGA, including the largest module responsible for extracting packets from the serial bitstream received from the satellite. I wrote several SystemVerilog testbenches to ensure correctness and timing. I also started working on the backend software component on the Raspberry Pi, which assembles files in a straightforward manner from the packets received from the FPGA and uses a device driver to display weather images on our user-facing touchscreen.

Progress/Schedule

Now that we successfully received GOES satellite data using our antenna + RF frontend, we are no longer behind schedule. We are on-track to successfully completing the project, as we have the FPGA component of the backend done (in simulation, still need testing with real signals) and I have started working on the software backend.

Deliverables/Next Steps

For next steps, I will continue working on the software side. I aim to finish all the code for the Raspberry Pi by the end of next week. Moreover, I will begin testing the FPGA modules with real data from the GOES satellite once Anna and Braden demodulates it into I/Q samples and passes it through the SDR.

Stephen’s Status Report for 3/07

Accomplished

This week I made solid progress on the RTL for decoding the protocol. I was able to finish the module that performs derandomization of the bitstream, and wrote several testbenches in SystemVerilog to verify correctness of both the output and timing. Moreover, I started working on the hardest part of the RTL with Anna, that is, segmenting the input bitstream into packets and sending these packets to the Raspberry Pi. I am nearly done with this component.

Progress/Schedule

Like last week, we are slightly behind on schedule, mainly due to the difficulties involved in receiving a clear signal from the GOES satellite using our RF frontend. We found that the roof of East Campus Garage provides a clear line-of-sight, and we are in the process of testing reception of the signal there.

Deliverables/Next Steps

For next steps, I will start working on the software side, that is, using the Raspberry Pi to display the image, device drivers for the touchscreen, and archiving historical weather reports in system storage. Anna and Braden will work on the frontend, ensuring that our antenna is able to receive the signal and working on the BPSK demodulation.

Additional Questions

With consideration of cultural factors, this project will likely benefit communities that are reluctant to use new technology. In many lower income countries, citizens are reluctant to use Internet and smartphones as it conflicts with their traditions. However, providing accurate weather information to these groups is still extremely important. This project will enable these groups of people to start receiving accurate, real-time weather reports without disrupting their traditional lifestyle, like the Internet would.

Stephen’s Status Report for 2/21

Accomplished

This week I continued working on the RTL for receiving and decoding the protocol. Specifically, I continued working on derandomizing the bitstream using a static, pseudo-random polynomial using shift registers. I also worked on writing certain sections (Testing & Verification, Quantitative Use Case Requirements) for the design proposal presentation, and worked on physically building, setting up, and testing our antenna + tripod on Friday.

Progress/Schedule

We are slightly behind schedule. Even though we received our antenna this week, we are still not able to obtain a clear, strong signal from the GOES satellite. We think this is an issue with the line-of-sight, specifically, Baker Hall is blocking the signals from GOES when we setup on The Mall. The protocol decoder is going smoothly.

Deliverables/Next Steps

For next steps, we will continue working on the protocol decoder next week (we plan to finish all the design and have all the SystemVerilog code written). Next Monday, we will setup our antenna and test the reception of signals at Schenley Park, where we should hopefully have a direct line-of-sight.

Stephen’s Status Report for 2/14

Accomplished

This week I decided to start designing the RTL for receiving and decoding the protocol received from the GOES satellite. As I had read through the entire specifications of the protocol last week, I explained the details to my teammates. We sketched out a design for the RTL to decode the protocol, and split up the work. I worked on derandomizing the bitstream using a static, pseudo-random polynomial.

Progress/Schedule

We have shifted our schedule due to external factors outside of our control, namely the RF frontend components not being delivered on time (we can pick them up next Monday, and will begin testing them immediately). To compensate for this, we decided to start working on the backend components of the system, specifically the protocol decoder, instead of the frontend components like the demodulator which depends on the I/Q data received from the antenna.

Deliverables/Next Steps

For the next steps, we will test out the RF frontend (antenna + LNA) once we pick up our parts on Monday. We will also continue working on the protocol decoder, which we estimate to take up the majority of the time. For the deliverables, I worked on the use case requirements and testing/verification for the presentation next week.

Additional Questions

In regards to economic factors, our end-to-end system provides a low-cost alternative for low-income, disadvantaged, or remote communities to get real-time, accurate weather reports.  Installing broadband Internet requires a lot of expensive infrastructure and slow bureaucracy from working with government officials. On the other hand, our system requires less than $600 to setup a fully working weather station, thus making traditionally expensive services much more accessible.

Stephen’s Status Report for 2/7

Accomplished

This week I mainly accomplished four tasks: (1) I practiced delivering our proposal presentation scheduled for Wednesday and prepared for any potential questions from the audience, (2) I read a 60-page specification on the LRIT/HRIT protocol used by GOES satellites to transmit information, (3) I designed an FPGA pipeline to receive and decode these packets, and (4) I placed orders of all necessary components (antenna, tripod, LNA, and touchscreen).

Progress/Schedule

We are on track according to the Gantt Chart. This week was mainly focused on finalizing our ideas for the project (via the proposal), obtaining feedback from the professor and the audience, conducting preliminary research to obtain background technical information, and ordering all the parts to ensure they arrive on time next week.

Deliverables/Next Steps

Next week, I will work on writing SystemVerilog RTL to demodulate I/Q data into a bitstream according to BPSK. I have found some references and specifications that I will be looking at to complete this task. After writing the RTL, I will first write testbenches in simulations to test the correctness. Then, I will synthesize this RTL onto our FPGA board and test if it works with real data coming from the antenna + SDR (which Anna and Braden will set up).

Posted on

Team Status Reports

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.