Category: Txanton’s Status Reports

General Updates
This past week we had our final presentation. I feel that it went well and we got some useful feedback that we can use on our poster and in our final report. Overall our project is looking good and I am happy with the way it has turned out with the constraints we had.

Progress
After the presentation we did some final testing to solidify our conclusions. I also started working on the final poster and starting on our final report. Luckily we were able to use some components of our design report to get us some good progress on the final report.

Upcoming
In the upcoming week I will continue to work on the report and poster for the final public presentation so that we can get our project all wrapped up.

This week we had the discussion with the Eberly center which I felt was pretty productive. We were able to give some feedback which seemed to be well received and we were also able to hear some of the experiences of the other teams.

Regarding the project, this week I helped to interface the overlay code with the beamforming code by receiving the data over UDP.  I also helped to tweak some of the specific values as we were testing in order to make the overlay code better correspond with the constraints of our system. Luckily from our testing it seems to be corresponding with the location of the transmitting device pretty well so I am hopeful that we won’t need to make any significant changes for the final video.

Next week I will continue to help the team test the accuracy and make any future adjustments as we prepare for our final video and report.

This week we had our ethics discussion. I found the meeting to be pretty interesting as before I read the papers assigned I had a very different view of engineering ethics. Typically I thought of issues such as computer vision with biased/non-diverse data sets leading to discrimination, but after reading the papers it opened my eyes to more intentional ethical decisions such the parkways in New York.

Working on our project, I spent this week working on expanding the image overlay code. I started making it so that we can overlay a box after receiving an angle from the beamforming array. What I am doing to attempt this is by dividing the horizontal resolution by the horizontal field of view of the camera. This has been a little difficult to find as most manufacturers only provide the diagonal field of view. After performing this calculation I have an approximation for how many pixels correspond to 1 degree which I can use to then draw a box around that angle that was provided by the beamforming algorithm. Currently this is only in one dimension, however the process should be pretty easy to adjust to make it two dimensional once the antenna array has been formed that way. Since we are testing and I am remote I am not 100% up to date on the accuracy of the beamforming array so I currently have it placing a larger box around the calculated angle that corresponds to +/- 5 degrees in order to account for inaccuracy of the algorithm. The number of degrees for this box is also very easy to adjust so once I fully know the general accuracy of our array I can update that to correspond.

For next week I am going to continue to work with the rest of my team to update these values to make them more actually correspond with our measurements. I will also be doing some I/O in order to receive the angle from our beamforming algorithm as currently they are two separate things and I have been testing my angle based boxes using hard coded values and loops not actual data points. I will also update the code to use 2 angles to affect the box’s vertical size as well if we decide to make our array in that orientation.

This week I worked on reading the OpenCV documentation to get a better understanding of how to capture webcam input in python. I was able to find a Python script that allows us to get the webcam input and display it on screen and am trying to figure out the best way to overlay an image onto it. This will allow us to overlay a heatmap onto the camera input so that we can show where the signals are coming from. I also helped to debug the hardware that we were using. For some reason one of the outputs from the downconverter was quite a bit lower powered than the other and we figured out that when we swapped to the other downconverter we did not have this issue, it leads us to believe that something may be faulty with that board and it took a while to figure that out. Once we switched this board we did additional testing on the correlation/synchronization of the SDRs so to help with this I wrote an additional binary for the STM32 to tell the VCO to output a 150 MHz signal so that we could skip the downconverter in order to work with just the SDR’s.

This next week I will help the team integrate the remaining two SDRs and continue working on overlaying images to the camera feed in Python so that we can start getting to the final stages of our project.

This week we made some large breakthroughs. Initially we were planning on using an Arduino since we had many available to us and they are relatively easy to program. The only challenge with this is they use 5V logic and the Voltage Controlled Oscillator we are using uses 3V3 logic levels meaning we need to convert them. We attempted to use the Sparkfun Logic Level Converters however the method of switching they use were not fast enough to support the slowest SPI speed of the Arduino. My team members considered using a Raspberry Pi since it uses 3V3 logic levels so I wrote a quick Python script to configure the VCO in case they did end up using the Rasberry Pi. Due to accessibility issues my team members ended up not using the Raspberry Pi but had a Ti MSP430 available to them which uses 3V3 logic levels so we attempted to use that. It looked promising since there was an IDE called Energia which used Arduino libraries to program it so the code I wrote this week should work. Unfortunately we had some issues setting up the development environment for that chip and none of us had experience with the platform so we moved on. My team members were able to borrow an STM32 Nucleo board, a platform with which I am very familiar with, so I rewrote the program to set the VCO registers for this microcontroller and we were able to get it to working and use it with our downmixer.

I spent a lot of time this week writing the code to program the VCO (for multiple microcontrollers) and next week I will start on the heatmap and webcam capture code.

This week I finalized the last few products that we needed to order. After some careful consideration I found the downmixing evaluation board that we plan on using, it features dual channel interfaces meaning we can connect two antennas to it, and it also is 50 Ohm impedance matched meaning we don’t need any additional hardware to prevent reflections on the signal line. We also found some WiFi antennas that seemed relatively directional without sacrificing field of view too much so that we can get sufficient overlap to get meaningful information from each antenna. The last product we ordered were the SMA cables needed to to connect all of these devices. By using these cables we are able to space out the antennas accordingly so that we can perform beamforming.

We also spent some time this week on administrative tasks as we needed to organize our task breakdown in order to make sure we are able to complete everything on time. By making a more detailed breakdown of tasks we will be able to stay more focused and not spend as much time trying to decide what to work on next. This upcoming week we hope to start receiving components so that we can start testing with the actual parts that we will be using. This will allow us to start working on solving any problems that may arise when we start combining these modules.

This week we had design presentation’s which took up some of the time we had planned for this week. Outside of the design presentations I mostly spent this week finalizing the components we plan to use for our RF Front-End circuit. During this time we had a meeting with a CMU Graduate student who is doing research in this area so that we could discuss some of our plans with him to help ensure some of our assumptions were correct. This graduate student was also a valuable resource for helping learn about some other techniques for sampling such as I/Q Demodulation which may be useful in getting information from the radio signals.

Now that we have most of the components selected I plan on drafting the schematic and then scheduling a meeting with Professor Carley, since he does research on RF Circuitry, in order to review the schematic and again helps us identify some possible flaws we may have made so that we can finally go ahead and order our PCB’s. Regarding the schedule I believe that I am slightly behind on the PCB design but do not foresee it taking up too much of our slack so I still believe that our project is on pace.

This I was doing research into what components we need in order to get meaningful data from the antenna’s. In our weekly meeting it was brought to our attention that there was likely additional circuitry needed in between the antenna’s and our ADC. Since specific information was not immediately available to us about this I did some research in order to try and figure this out.

During this research one thing I found out is that we will likely need to use an amplifier to boost the signal. I was not aware that RF signals were as low power as they are so in order to avoid noise and get a higher Signal to Noise Ratio (SNR) we will need to use an amplifier, this will also amplify noise, however it should be to a lesser effect. I also found that some circuits make use of a bandpass filter in order to help get rid of some of this noise and smooth the signal, this is something I will keep in mind as we start to design our circuit.

I was unable to find too much more detail however I will keep looking and earlier in the week we reached out to a graduate student at CMU doing similar research and hopefully they will be able to give some additional insight into some of the challenges.

This next week I will continue to search for circuitry related to antenna’s and will continue doing research so that we can get started on the design of our PCB as soon as possible, since we will not only have to create the PCB but also wait for it to be fabricated and shipped, and then also wait for the components that will be going on it to be shipped as well. In order to minimize the impact of this delay I will try and make sure we can order both parts and the PCB as soon as possible.

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.

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.