Michael’s Status Report 3/16/2024

What did you personally accomplish this week on the project? 

For this week, I got the Wi-Fi transmission code working on the ESP32. I have tested it and we are able to reach about 17 Mbit/s. The 17 Mbit/s is more than what is needed to stream 240p video, which is our project’s initial requirement. However, this may actually be limited by the iPhone hotspot that I am using to serve as an access point. Since I don’t have an actual Wi-Fi access point to test with, I will have to accept that 17 Mbit/s is the speed of the ESP32. The transmission code did take significantly longer than I expected. In the beginning I kept running into issues associated with the iPhone’s hotspot. It turns out that you have to be on the hotspot screen to have the hotspot be actually visible when there is no one actively connected. After this, I ran into more issues regarding sending packets at a high rate or large packets (>1000 bytes). The ESP would complain that it was running out of memory and return a failure code. After debugging it for a long time, it turns out that there was a misconfiguration in the ESP SDK and the station power saving mode was too aggressive. After these issues were resolved, the ESP was finally about to hit the aforementioned 17 Mbit/s.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Currently on schedule

What deliverables do you hope to complete in the next week?

For next week, I hope to finally finish porting the JPEG code over. I stopped working on it this week since the Wi-Fi portion hasn’t been explored at all and we were not sure if there would be hidden issues. The delay from the debugging Wi-Fi ate up any time that was left over for JPEG porting

Neelansh’s Status Report for 16th March, 2024

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours). 

This week I worked on setting up the ESP32 data access points and ensuring that the code I have written in the IDF environment works. This included connecting an ESP32 to my computer, setting up the entire toolchain, figuring out the necessary dependencies and writing code to set up the data access points on the ESP32. 

After that, I started to transfer data. At first I wrote code to check if I can open a simple webpage saying “Hello World” based on some online tutorials, and after that I started sending more and more data. I tried to measure the data transfer rate of the ESP32 by sending in large amounts of data in the range 65535 bytes and upwards since that would be what we will be sending in the final product.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule? 

The project is still on schedule.

What deliverables do you hope to complete in the next week?

For the next week, I plan on finishing up the receiver module by setting up the data access points completely and finding the thresholds of the data transfer rate, also work on other aspects of the project such as the drivers and encoders needed to transfer the data to the FPGA on the receiver node.



Team Status Report 3/9/2024

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc. 

 

Being a technology product, EyeSpy can present a challenge to use for people who are not very tech savvy. However, our design goal of plug-and-play operation should make it easy to use even for people that are not very tech savvy. EyeSpy is also fully compatible with all wireless regulations globally as it uses the internationally standardized 2.4 GHz ISM band. Since EyeSpy doesn’t require an electric grid connection to work, varying grid voltage and frequency shouldn’t be a hindering factor

 

Part B: … with consideration of cultural factors. Cultural factors encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people. 

 

Our product doesn’t necessarily have a high cultural impact, and does not offend / attack any particular rules set in any culture. Our camping security system can help people when they are doing religious prayers or ceremonies and need to have a sense of the surroundings, and thus continue the religious proceedings in peace. Our product does not break any existing laws as such, as long as it is used for the right purposes and not for anything illegal. 

 

 Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

 

Our product does have some environmental factors. Some of the main concerns are with how it will interact with wildlife. It could be harmful to wildlife if they decided to try to eat or play with the remote camera nodes as they contain harmful chemicals and other items such as the camera, the battery, etc. The main concerns relating to natural resources is the sustainability of sourcing material for the remote node. The main concern for this is the battery and how often will the health of the battery remain. Batteries are also very expensive in terms of manufacturing and the environmental impact that comes with it.

 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward? 

 

No major changes have been made to the design of the system yet.

 

Provide an updated schedule if changes have occurred.

 

There are no major updates to our schedule as of yet and no changes have occurred.

Varun’s Status Report for 3/9

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I worked on quite a lot of the work required for the FPGA. My main accomplishments this week are I wrote some code to interface with the HDMI driver. I did some code modifications to the HDMI driver. Some of the issues I faced with the previous implementation was the display was a little finnicky. I was able to fix this by implementing something called Reduced Blanking in the HDMI driver. This meant that I was able to decrease the clock speed of the HDMI IP by about 15% which meant that it was more easily able to meet timing. The previous design was actually failing timing.

Is your progress on schedule or behind? If you are behind, what actions will betaken to catch up to the project schedule?

As of right now, I am on schedule so I’m not worried about my progress.

What deliverables do you hope to complete in the next week?

Next week I plan on working on the run length decoder and redoing the SPI peripheral to work with the ESP32 properly. The JPEG decoding is on the backburner as the finalized implementation is being coded.

https://photos.app.goo.gl/LBfp1qN6J4SgLGJp9

Michael’s Status Report 3/9/2024

What did you personally accomplish this week on the project? 

For this week, I got the camera driver working on the ESP32. The code that I have currently works at the 240p resolution that we are targeting.I also tested it at 360p, 480p, and 1080p to make sure that it is able to accommodate future extensions if need be. In addition to writing the camera code, I also have some code written that will write the image data from the camera into a microSD card. While this is not needed for our project, it serves as a useful debugging and development tool. Since the Wi-Fi communication has not yet been written, the microSD card is how we are currently testing the camera driver and pulling images from it. Finally, I also made a couple of small modifications in the JPEG encoder and decoder programs to change the pixel format to match the pixel format of the OV2640. The OV2640 outputs images with a 5-bit red and green channel and a 6-bit blue channel. The three channels are then packed together into 2 bytes before being stored. Such a configuration is commonly referred to as RGB565. However, the proof of concept JPEG encoder and decoder uses 8-bit for all three channels, also known as RGB888. To eliminate the need to convert from RGB565 to RGB888, I decided it was easier to just modify the proof of concept to handle a RGB565 format.
With the camera driver and JPEG pipeline modified, we are now able to take a picture, compress it, then decompress it. The following image shows the end result after going through all those steps. The reflection in the camera are from the screen that was displaying the color test bar images

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Currently ahead of schedule by approximately 2 weeks


What deliverables do you hope to complete in the next week?

For next week, I hope to finish porting the encoder over to the ESP32. After this, we should only have to run the decoder on the laptop and also test out the encoder performance when running the ESP32

Neelansh’s Status Report for 9th March, 2024

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

 Over the past week, I started working with the ESP32, and worked on writing code to be able to receive data from my personal computer. I tried sending random bits and then other values, trying to emulate the real world situation of sending compressed frames and then receiving and serializing them. I was able to successfully receive the transmitted data and ensure that the data frames lost were within the limit specified in our requirements ( <10%). I also started reading on other current architecture and solutions present, and read a few research papers and websites which related to fast data transmission and receiving via wireless networks (especially ESP32s). 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We are on schedule and things are going as per plan. 

What deliverables do you hope to complete in the next week?

In the coming week, I plan on developing the receiver node’s physical architecture with my partners, and also work on completing my code, along with extensive real world testing to ensure adequate transmission and receiving of data as per the requirements set in our design. Apart from this, I would also be working on developing a detailed testing plan with the exact metrics, and start initial testing.