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.

 

 

Team Status Report for 02/27/2021

This week we spent a lot of time watching our peers present their own projects which helped us to get a good idea of how other groups were approaching their own challenges and try to find ways we can adapt that to our own.

We did not get as much done this week as we would have liked due to the project presentations, however we still were able to get a solid start on our requirements. Since we decided on cylindrical antenna’s we started to try and address the challenge of how to make sure they stay in a consistent arrangement with proper angles between each antenna. Our solution for this was a 3D printed rigid body in order to keep all of the antenna’s in place. We also did research on different digital beamforming algorithms so that we may start comparing and contrasting them to see if they meet our near real-time constraints and their difficulty in implementation.

Going forward, we plan to focus our attention towards the antenna’s and the PCB that all of the antenna’s will connect to. By focusing on this it will allow us to get prepared to start ordering components so that we may start working on our physical implementation and start prototyping as soon as possible. We will also start organizing our information regarding DSP algorithms so that we can get an idea of how we will implement them. We will also need to make a decision regarding whether or not we will use a Software Defined Radio, such as GNU Radio, or if we will use a FPGA instead as they both have benefits and drawbacks.

Txanton’s Status Report for 02/27/2021

This past week I spent some time preparing for my team’s project proposal presentation which helped me get more comfortable with talking about our project and helped me be able to explain it to others better. It also helped me to reinforce some of the parts of the project that I was previously less informed about.

Regarding moving forward with the project I started to come up with a plan for how we were going to setup the antenna array. I came up with an idea for a 3D printed or machined piece of plastic that would allow us to place specifically spaced holes for the antennas to go through. By attaching the antenna’s to a rigid body we would be able to get them at very specific spacings and angles in order to get the best results for beamforming. It would also allow us to quickly prototype if we needed to make adjustments to the spacings in the future (note: while outside the scope of our capstone project this theoretically means that our overlying system could be adapted to support beamforming with different antenna’s and spacings for other frequencies). Since the antennas would be mounted to this board we would connect them to a custom PCB over individual wires, and then use a larger header on that PCB in order to interface it with either our FPGA or Software Defined Radio system.

While I still need to discuss it with my group after additional research I personally believe that GNU Radio will be more difficult than trying to implement our own DSP functionalities in an FPGA. This upcoming week we will start focusing more on the exact spacing for our antenna and start searching for which specific antenna’s we are going to order so that we can get started with prototyping as soon as possible. I will also get started on doing research into the kind of requirements needed for making a PCB with high frequency RF signals. Some key focuses for that will be trace impedance, trace width, trace isolation (to prevent cross-talk/noise), and I will try and find any other possible best practices.

Team Status Report for 02/20/2021

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.

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.

Enock’s Status Report for 02/20/2021

This week I focused on deciding on what kind of hardware we would try to do some of the signal processing and programming intensive computations. Within the budget and availability I found the Zynq Ultra96 v2 board would be the best in terms of price, size, and ease of use. This board is used in 18-643 so we are hoping to be able to borrow a board if possible. If we use Vivado it will be very easy to use existing IP blocks that will allow for us to use modules that will interface with certain components or that will do certain DSP computations without having to write our own in SystemVerilog. Furthermore the board is an MPSoC which allows for us to write certain parts in C++ and to establish a separate workflow for those who will be working on the programming side and those working on the hardware side (aka Verilog). Aside from this I decided it might be a good idea to focus on LTE signals rather than WiFi since it is more common for devices to be transmitting/receiving LTE than WiFi so from a security standpoint it might catch more users with this frequency. This, however, may limit our testing capabilities since we will have less devices with LTE compared to WiFi enabled devices. I hope to be able to find out if we can use this board in our project as well as if we will have enough testing data to use LTE as our base signal.

Txanton’s Status Report for 02/20/2021

This week I focused on looking into different microcontrollers to see which one would best fit our application. For Wi-Fi it appears the the ESP32 line of microcontrollers by Espressif would work well since it has the ability to both transmit and receive Wi-Fi signals built into it. One concern would be if it lets us get enough data from the signal or if it only gives us the decoded packets as we need raw signal information in order to properly do beamforming. For LTE signals it seems that the NF9160 microcontroller by Nordic Semiconductors would work well as since it has LTE-M and also allows us to use GPS information which may be convenient data even if it doesn’t help us overall with the location of devices or beamforming. Once we solidify our requirements and decide on which protocol we will end up using I will do further research on how to setup and start developing for the microcontroller corresponding to that technology.