Category: Team Status Reports

This final week was dedicated to integrating the software with the hardware and running tests to report our final metrics to see the difference between our initial goals and our final results. The software system consisted of two parts, collecting the SDR data and transmitting the data, and a receiver which analyzed the data to perform beamforming as well as conducting the overlay. These two parts were done on two different devices and so this process was merged to be performed on one. This was done not only for efficiency in design space on the cart and to preserve data integrity between transfers, but also to alleviate the need for a tedious FPGA setup.

We have also put some significant time into final tests for our system to ensure that the integration has worked without hitches. We placed markers within the lab and used these to gauge the performance of our system. Additionally, we began collecting footage and pictures for use in our presentation for sunday.

We allocated additional time this week to give feedback on the course and to prepare our presentation slides.

This week we worked on HW 1-3 and SW 1-2 from our new schedule made in order to put us back on track in time for demo. We ordered all our parts last week and weekend and were able to receive all the parts on time. Thus, Enock and Vrishab were able to work on testing the individual parts as they came as well as putting them together.

Txanton worked remotely on software programming for the VCO in which he had to write it for Arduino, MSP430, and STM32 since there were many issues with the Logic Level Converter and the MSP board. Txanton was able to zoom in remotely to help write the code in real-time for each of the boards as Enock and Vrishab tried debugging the boards and LLC.

For the hardware aspect the first goal was to set up GNU Radio and sync the SDR board which required some physical manipulation of the PCB’s to get the clocks to sync. Once the FM signals could be seen simultaneously the next step as to check the VCO output to ensure the correct sine wave was seen. After this was done all of the parts ended up coming in tandem and thus we were able to start physically building the entire system.

Fitting the SDR, VCO, LLC, and microcontroller it was seen that the LLC could not switch fast enough for the SPI Interface of the Arduino. Thus the arduino was switched out to the MSP which was natively 3.3V and allowed for us to remove the LLC from the design however, we could not verify that the VCO was working properly and thus we switched to the STM32 which Txanton had extensive experience with. This board worked and so we finally attached the downmixer to the WiFi antenna and tested with GNURadio, a hotspot, and a laptop connected to the hotspot to see that this signal was seen in the waterfall. We were able to see good signal strength when close to the antenna and much weaker when moved away, especially out of FOV and so we concluded that the system worked.

The next steps will be for Txanton to start working on OpenCV code for webcam input and overlay. The beamforming algorithm will need to be configured with GNURadio data from the antennas and will need to be optimized and changed once we see what this data will look like.

Here is part of the system. Antennas and downmixer not shown but attached out of the FOV.

Last Week
Last week we did not have a status report due, as such we spent most of that time writing our design report. In order to write this report we had to make sure our beamforming algorithms were solidified, and we had to make sure our component selection was finished.

Component Ordering
This week we finalized the last of the components that we needed and placed an order for them, as such we expect to receive them sometime next week enabling us to start combining them to work on our minimum viable product. Unfortunately some challenges came up from when we wrote our design report as we originally thought that we had found a reliable source for the downmixing boards that we planned on using, however, they all ended up being shipped internationally meaning that they would not arrive in time for us to properly test and include it into our design. We luckily were able to find replacement boards domestically, however, they were quite a bit more expensive meaning we will need to be careful with our remaining budget in case we need additional equipment.

Advancements with current Gear
We also made a lot of progress with the equipment we have. We were able to use the SDR’s that we got last week to perform beamforming in the FM radio band, as such we feel confident that when the rest of our components arrive we will be able to adapt it to WiFi in order to meet our MVP. The radio signals received are relatively close to the intermittent frequencies we expect to receive from the downmixing equipment meaning it should not be too difficult to adapt our system.

Upcoming
This upcoming week we will continue to tweak and adapt our beamforming algorithm, and start adapting our system to work with WiFi as the components become available to us and we can test further

This week we spent more time narrowing our project design and metrics since the design presentation will be due close to the time this post is up. This week we were able to create our proposed antenna design by settling on WiFi signals as our target signal, the number of antennas, and their array pattern. We were able to decide on the antenna spacing for the array based on the WiFi frequency since we wanted to not only avoid aliasing but losing important signal information.

We have found a beamforming algorithm that we will try to implement and test in MATLAB before having to customize it for the FPGA. Since we have settled on an MPSoC FPGA to use, it will make this process of designing easier. We have also started brainstorming a way to configure the heatmap which is our final output. This will be an agreement between the data output type of the FPGA (which we hope to be pixel values that represent intensity) which will be fed to a microcontroller which will handle composing a heatmap onto the live feed of the camera we will be using.

We are currently on track with our project but should order and start building soon to start doing prelim testing with the PCB so we can start interfacing with the hardware/software.

This week, we worked on identifying the critical components — hardware, software, and theoretical — that we will need in order to move forward with our project. We also discussed the architecture that we will use for beamforming wifi signals, such as the hardware components and their connection to and sampling of the array sensor elements.

The greatest risk that we face going forward are a lack of compatibility between our sensors that the signals we hope to capture. Wifi signals are transmitted at a relatively high frequency, so we need hardware that can sample it at the nyquist rate; this is not feasible using some boards, so we need to be careful which ones we choose. We mitigating this risk by thoroughly researching our hardware before we finalize anything.

We have only started design of our architecture this week, as per our schedule, so there have been no significant architectural changes since last week; our particular project demands some quite specific hardware, and so we are taking our time in planning out our system. Once we have our hardware, the design of our system will adhere closely to existing beamforming architectures, since any deviation from those will greatly complicate the underlying theoretical calculations and will more than likely yield sub-optimal results.