Posted on

Vrishab’s Status Report for 05/08/2021

Wrap Up

This week I worked on wrapping up the final aspects of our project and on performing validation tests for our final report. These included marking up the room and testing received signal strength at different locations. We also recorded video of our project and took pictures.

Progess Since Last Week

We have finished the final steps of our design and have moved on to validation and documentation.

Tasks for Next Week

We have to create our poster and edit our demo video. Other than that, we are finished with our project.

 

 

 

 

Posted on

Vrishab’s Status Report for 05/01/2021

Integration

I spent a considerable amount of time this week working on the integration between our vision system and the rest of our processing pipeline. The image code interfaces with a web camera and the overlay is produced by opencv. The vision script receives data over UDP that is used to plot the colors for the overlay.

Testing

I developed a final set of tests and benchmarks that we are in the process of performing so that we have some concrete metrics and data to present. Enock and I carefully measured and placed markers around our lab environment so that the data we get can be matched against the position of the transmitting device.

Footage and Documentation

I spent some time this week documenting our testing process and collecting footage that will be used in our final presentation and in our slide deck.

Progress Since Last Week

We have completed the integration of our vision system and have moved into the final testing phase.

Tasks for Next Week

We plan on performing further tests, collecting data and performance metrics, and collating the footage for our final presentation.

Posted on

Vrishab’s Status Report for 04/24/2021

Integration

This week I worked on integrating our vision pipeline with our signal processing pipeline. The vision pipeline consists of software written by Txanton that draws boxes over camera input from OpenCV. The signal processing pipeline comprises all of the beamforming architechture and outputs an angle of arrival (AOA) at which a WiFi-transmitting device is located. The integration is performed by sending the AOA over UDP to a separate computer which receives the webcam input.

Progress Since Last Week

We have finished our signal processing pipeline and have now started on the integration phase per our project schedule.

Tasks for Next Week

We need to finish our integration between the camera pipeline and our signal processing pipeline. We will also measure the true resolution of our system and compare the results with our theoretical calculations.

Posted on

Vrishab’s Status Report for 04/10/2021

Real-Time Signal Processing

In the previous weeks, we have been collecting data on one machine, a Windows surface pro, and processing it on another, a new Macbook Pro. The reason being that the driver software was not supported on mac, but we knew that our Windows computer did not have the processing power to handle our signals in real time. The data was manually transferred using a USB stick which was clearly a stopgap solution. This week Enock and I implemented a server on that processes data — transferred over UDP — from the Windows machine in real time. The addition of this server to our signal processing pipeline has greatly increased the speed at which we can capture data and debug, and it is an integral part of our final design.

Debugging Signal Capture

In attempting to correlate the data collected from two antennas, I noticed that there were some inconsistencies in our results. Sometimes, the correlations looked reasonable, and other times less so. Through extensive testing, we discovered that one of the outputs from our downconverter board was corrupted. We have a spare downconverter which performed perfectly after replacement.

Progress Since Last Week

I have made a lot of progress on the correlation code since last week. That, in addition to the UDP server, has enabled fast (<<1sec) delay calculations between the two signals.

Tasks for Next Week

I will be working with Enock and Txanton on adding two additional RTL SDRs to our system. I will also be implementing angle of arrival estimation, which is a simple equation that will be added to our code.

 

Posted on

Vrishab’s Status Report for 04/03/2021

Signal Synchronization

Quite a lot of progress was made on signal synchronization this week. I was able to achieve coherent signal capture between two RTL SDRs, which was partially completed last week, but the captured signals were too weak. To correct this issue, I incorporated a bandpass filter into our signal capture pipeline and moved testing locations. The combination of these two resulted in a much stronger captured signal which we could correlate between the two receivers.

System Integration and WiFi Signal Capture

Working with Enock and Txanton, we have completed our integration of all the hardware in order to capture WiFi signals using our SDRs. Using my phone hotspot as a WiFi source, we were able to capture the signals from my phone with the SDR and produce a spectrogram of the results.

Progress Since Last Week

We have completed the integration of all our hardware and have captured WiFi signals; this was a major hurdle in our design process that we have now overcome. We are ready to begin our beamforming implementation.

Plans for Next Week

We are going to implement the beamforming algorithm as a separate offline script. Doing the processing offline will render the code easier to write and debug. We can transfer the code to C (using cython/numba or equivalent) to facilitate real-time processing.

Posted on

Vrishab’s Status Report for 03/27/2021

Signal Capture Pipeline Design Changes

Since there was no status report last week due to the midsemester break, we have made some considerable progress — as well as some significant changes — to our beamforming architecture. Based on the feedback from our presentation two weeks ago, we have decided against fabricating our own PCB to convert analog signals from the WiFi antennas to digital signals that we can process. Instead, we will be using an array of cheap SDRs (~$25 each) to capture the downconverted signals and convert them into digital signals. The downconversion will now be done using commodity downconverters, which we have already purchased and are en route.

My role was largely in organizing these changes. I also used two SDRs which we borrowed from Dr. Swarun Kumar to perform beamforming on radio signals in the FM band, which will be close to the intermittent frequency of the boards we ordered. Enock and I also met with one of Dr. Kumar’s graduate students, Atul Bansal, to further discuss possible modifications beamformer implementation, such as synchronization schemes, and to receive feedback on our implementation .

Design Report

As a group, we spent a considerable amount of time writing our design report. My contribution to this was the signal processing portions as well as miscellaneous contributions to the introduction, architechture overview, risk management, etc.

Progress Since Last Report

We have finalized our implementation and have ordered parts. We have a working beamformer implementation for signals in the FM band.

Plans for Next Week

Once our parts arrive we will begin integration and testing. Since the ordered parts are development boards, which are designed to be plug-and-play, we should be able to begin testing without delay.

Posted on

Vrishab’s Status Report for 03/13/2021

Presentation

This week, I presented our project progress in our Section C presentations. This took some considerable effort, both in terms of designing the slide deck and performing dry runs of the presentation beforehand. The feedback from the presentation was useful and will help clarify some of the portions of our design review in the coming weeks.

Meeting with Shaun Stevens (Dr. Kim’s Grad Student)

We met with Shaun to discuss the specifics of our antenna design and signal processing pipeline implementation. He gave us some extremely valuable feedback, which has changed some aspects of our design. We are now going to be downconverting the collected WiFi signals from 2.4 GHz to baseband, and we will then sample the downconverted signal at a correspondingly lower rate. Performing these steps will require a voltage-controlled oscillator, the make and model of which we have already identified. Adding the oscillator to our system has incurred a slight delay in our progress, but has actually had the effect of speeding development since we won’t have to sample the signal at 4.8 GHz (which was something that we had planned on taking a week to figure out).

Progress Since Last Week

Last week we stated that we would begin on the PCB design. Txanton has been heavily focused on this, and we are on track to finish the layout and meet with Dr. Carley for review within the coming week. I have been aiding in some aspects of the PCB design, specifically with the selection of some of the components.

Plans for Next Week

We plan to have the PCB layout completed and will meet with Dr. Carley to verify that our design will work. We will then send the specs out to have our board fabricated and shipped back.

 

Posted on

Vrishab’s Status Report for 03/06/2021

Antenna Array Configuration

This week, I spent some time finalizing the configuration — spacing requirements and number of elements — of our antenna array. Through some research on 2.4 GHz WiFi signals, I found that we will need a spacing of 6.25 cm between each antenna. This requirement was determined based on the wavelength of 2.4 GHz WiFi, which is 12.5cm, which must be halved to avoid spatial aliasing. This is done in order to sample the WiFi signal at a rate twice as fast as its fastest frequency — the Nyquist rate.

The number of array elements was determined by plotting the theoretical directional sensitivity for our beamformer, where I increased the number of array elements and until the plot had the directional sensitivity characteristics from our proposal (~3 degrees squared main lobe width). In doing this, I found that 32 array elements satisifed this constraint.

Signal Processing Pipeline Implementation

I began working on a testbed for our signal processing platform in MATLAB. So far, the testbed implements the frequency domain beamforming algorithm from https://academic.oup.com/mnras/article/439/3/3180/1113793. Before implementing on the FPGA, we will feed our data into this MATLAB testbed to verify that we can perform the beamforming to the required specifications. After that, we will compile the MATLAB code into Verilog for use on the FPGA (MATLAB has the ability to do this automatically).

Progress Since Last Week

I have addressed many of the uncertainties in our antenna array design from last week. We are on track with our schedule (from the proposal slide deck).

Plans for Next Week

Per our proposed schedule (see slides), this next week will involve the critical first steps in two of our project divisions: PCB design and part specification. On the PCB design side, most of the contribution will be from Txanton and Enock, though I will try to lend a hand where necessary.  On the part specifcation side, I will finalize the commodity antennas that we will use, incorporating their characteristics to obtain some more concrete theoretical calculations.

 

Posted on

Vrishab’s Status Report for 02/27/2021

Determining Constraints:

This week, I focused on pinning down some of the specifications for our beamformer design. I began by working with Enock and Txanton to identify a specific use case for our project, and we settled on detecting hidden devices within a standard room.  From this use case, we derived several constraints specific to our operational context: the size of a “typical” room was sourced from a report by NIST (see slides for reference); and the typical device size which we aim to detect was sourced from statista (reference in slides).

Establishing Main Lobe Width:

With these constraints fixed, I performed some simple calculations involving the minimum separation between devices within the space of our average room from which the main lobe width of our beamformer was ascertained. The main lobe width can be thought of as how much of our device’s field of view can be seen clearly at one time; the narrower the main lobe width, the smaller the portion of room we can see at once (meaning we have to look at more spots within the room), but the more accurate our results will be — a tradeoff between processing time and accuracy.

Progress Since Last Week:

I have addressed many of the uncertainties in our beamformer design since last week, largely due to the guidance of this paper, https://academic.oup.com/mnras/article/439/3/3180/1113793, which details the implementation of a beamformer architecture that we will follow closely. These specifications have addressed the points that we outlined in last week’s progress report.

Plans for Next Week:

Per our proposed schedule (see slides), this next week will involve the critical first steps in two of our project divisions: antenna design and signal processing pipeline implementation. On the antenna design side, we hope to finalize the configuration of our antenna array, as well as pin down the type and brand of antenna that we will use.  On the signal processing pipeline side, we will finalize our beamformer algorithm which we are in the final stages of adapting from the aforementioned paper.

 

 

Posted on

Vrishab’s Status Report for 02/20/2021

This week I worked on structuring our signal processing pipeline that we will use for beamforming. In particular, I read through several papers on how to beamform wifi signals, as well as implementation details regarding the spacing of array elements. I also met with Dr. Richard Stern to discuss implementation and architectures of beamformers in the domain of audio processing.

Our progress is on schedule in terms of the beamformer design. Within the next week, I hope to have finalized a beamforming algorithm we will use in our design. I also hope to have identified the critical components that we will need (antennas, A/D converters, clocks, etc.) for our beamformer.