Bradley’s Status Report for 4/27

This week I worked on the microphone and receiving an output on it. Since the regulators on the PCB were not working properly, a workaround was needed in order to test if the microphone would work properly. Eventually I settled on using an esp to read the data as well as another ESP acting as the power source. Here is the setup

For some reason, the esp would not power on if the pins were on the pcb and was receiving power from my laptop. As a result, I just connected the GPIO pins that correspond to the microphone onto a breadboard. After some testing in Arduino IDE, I was able to get an output when the microphone was spoken into. Some concerns are that since it is omnidirectional, it may have a hard time differentiating voices. However, given the proximity the person has with the pendant I don’t think this will be a huge issue. We will see shortly though once the text to speech side of things is implemented properly.

Since the microphone is surface mount, and with the aforementioned uncertainties,, we have ordered a new microphone that we will be using for the demo.  This next week, we hope to have the text to speech trigger created as well as customization preferences to be working properly.

 

Bradley’s Weekly Report for 4/20

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficienteffort into the project over the course of the week (12+ hours). Is your progress on schedule or behind? If you are behind, what actions will betaken to catch up to the project schedule? What deliverables do you hope to complete in the next week?

This week, I worked on getting voice detection working within the app. However, the problem with this is that the library I used does not support continuous listening. Other solutions are platform specific, (such as android only), but I may have found a solution that may be able to support both. The issue is that it uses another interface to calibrate it aside from flutter itself. However, I should be able to get it done this week. The main challenge after that is having the microphone with the esp32 be used as the audio input, as for now only the detection works through the phones microphone. If it the microphone cannot be connected or is not an effective tool, we will have to use the phones microphone as a backup.

I hope to complete a continuous voice detector, as well as have the microphone connect as the audio input for the app. If possible, I will also try to have the RFID tag be able to detect unique RFIDs (main thing getting in the way of that is that we only have 1 RFID tag of each protocol at the moment, and I dont think the reader can be calibrated to support both protocols at the same time).

Bradley’s Status Report for 4/6

This week I got was able to calibrate the RFID Reader. After research and a meeting with Tamal, I came to the conclusion that the best way to go forward is to tap the ring to the pendant to activate the protocol, rather than having a button. Since there is no active RFIDs available for the frequency we are operating, switching the power off to trigger is not an option. There is also a way we can short the coils inside of the tag, but the tag is extremely small and may make the ring build awkward. Furthermore, we only have one tag we can even experiment with for now. I have worked on the voice detection trigger as well. We have ordered a new microphone that is better for our desired usage. I believe we will have the product done on time, but there is not much slack time for us. As a result, we will try to have a first final product soon. Next week I hope to finish RFID working as a trigger, having a ring, and speech detection functioning.

Bradley’s Status Report for 3/30

This week, I worked on the breadboarding, specifically getting the RFID module to turn on. A problem we are running into when trying to breadboard it is that since data in, reset, and power ports are all right next to each other, so it is hard for them all to stay in place while testing. There is also an issue with calibrating the RFID reader, since the datasheet is not very comprehensible and not much documentation is available elsewhere. However, the parts we have are compatible so it will just take some more time in order to get it finally working. Furthermore, while trying to design how we would make the ring, Tamal informed us that using metal to cover up the RFID ring may not be reliable in terms of distance and actually shorting the signal. He suggested we revert back to the button, where we short the RFID tag. We are behind, but I believe we can have something prsentable for the interim demo.

Bradley’s Status Report for 03/23/2024

This week, I helped with grabbing information regarding all of the parts to help create my teammates create the schematic for the PCB. I also helped with testing the RFID Readers we recieved this week, and whether or not they would be sufficient to detect the rings tag being covered up. So far, it has not worked well with the current RFID Reader module, but I am continuing on improving it. Furthermore, I am also working on the app’s code, namely the connection between the ESP32 and the Flutter app, in order for the user to have preferences as well as their emergency contacts saved (for the cellular module when there is no service/phone nearby). So far, it has not been completed, and am in the process of Bluetooth connection from the app to low energy bluetooth. I think we are a bit behind on schedule for this part of the app, but I think I can finish it within this week. The ordering of parts and making sure they will/and work properly was a lot of the focus within the past few weeks for the team, and soon that will be behind us.

This next week I should be able to complete bluetooth connection for the app, as well as some starter code for the false alarm detection.

Bradley’s Status Report for 3/16

This week we finalized creating our schematic and ordered some new parts. When coming back from break, not all of the parts had arrived. A crucial part, the UHF RFID reader, had not been ordered. Through ordering it again, I eventually found a new one that was cheaper to use. For working on the schematic, we had to look into the pinouts of each of the parts and how decide how everything will be connected on the PCB ultimately. We also had to keep two PCB designs in mind, one for UHF and HF RFID, in case UHF does not work out. As somebody who has not taken a class pertaining to PCBs or used them, I learned a lot about them this week. We also figured out a new way to use the ring. We realized RFID is blocked by metals, so we pivoted to using a plastic ring and using metal to block the frequency being transmitted to the pendant, signaling that the user wants to initiate emergency protocol. Unfortunately, we are behind schedule, and most of our parts have not arrived yet. So, the best use of my time will be researching how everything will be connected so assembly will be quick once the parts do arrive.

Bradley’s Status Report for 3/9

This week, we worked on the design report. Before this, we needed to finalize our design and select the parts. I picked most of the parts, put them on a spreadsheet, and made the orders. I had to consider the size of a feasible battery we could use, and then pick the correct voltages of the remaining parts so they could all be powered by said battery. We ran into a problem involving ordering UHF RFID receivers, as they are very expensive on domestic websites such as digikey. We ordered a relatively cheap one on AliExpress, but our TA has told us to not rely on that website. Tamal said we could use a smaller frequency RFID as proof of concept. As a result, we ended up ordering both types of RFID recievers, antennas, and tags.  After that, I also helped write the design report due this week. Since we were able to finalize our design, as well as get our orders in, I think we are on schedule. This week I also researched how all of our parts will be integrated together, to be ready for assembling when the parts do arrive.

 

Bradley’s Status Report 2/24

This week I worked on my presentation for the design review. I reviewed and changes slides and practiced presenting. For working on the project itself, I picked out which database we should use as well as changed our protocol with how false alarm signals are being sent through our system. I think our progress is on schedule so far, and I hope it will continue to be that way. I hope by the end of next week the parts will be ordered, and we can start constructing our product and see how viable our initial plan really is.

Bradley’s Status Report for 2/17

This week I worked on getting on preparing for the design review presentation, as I will be the one presenting. This included taking the feedback from our proposal while also making our testing plans, implementation, and use cases, more specific and quantitative. We met with James Bain in regards for how we should connect the pendant with the ring, since we heard from Tamal he taught the antenna class at one point. He super helpful and gave us suggestions, such as active or passive RFID or using hearing aid batteries. After discussing, we arrived at using RFID to communicate.

Our initial gantt chart was a bit ambitious, so we adjusted it (finishing the app layout or getting the hardware to connect the ring and the pendant wouldn’t have happened this week). However, I don’t think we are behind schedule since I feel like we are prepared for the design review. But we are looking into finalizing what parts we will order by the end of next week. I specifically will be looking into microphones to order, buttons, batteries, etc. Our research for the design review will help inform me what to order, as well as feedback from the design review.

 

Bradley’s Status Report 2/10

This week we worked on the proposal presentation. I helped with brainstorming the requirements needed for the proposal as well as creating the slides. While brainstorming, we reiterated our original plan from the abstract along with the advice given from Neha and Professor Mukherjee. I was able to identify the protocol we would use to communicate with the ring to pendant (bluetooth). This is because we want the most reliable way to have the button work on the first try, regardless of direction and clothing. After our meeting, I started to ponder which other triggers we would want to use for SOS. The ones I felt confident in for MVP were voice and GPS location. Furthermore, I helped with planning out our GANTT chart, and picked the tasks I felt confident I could complete.  We also discussed the things we would have to remove from the project’s MVP, such as cellular chip on pendant and digital security.  I think currently, our progress is on schedule. By next week, I want to completely outline how we initially plan to communicate between the devices (pendant, phone, ring). With this information, we can order the parts to help put us on good pace.