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).

Team Status Report for 4/20

This week, we made the change from having a button on the ring to communicate with the pendant to tapping the ring on the pendant. This is because the lack of availability of active RFIDs that support HF RFID protocol (most websites do not have any in stock). With the passive tag, we could have found a way to short the coils within the tag, but with only a few tags we can use and how tiny they are, we thought this would be too risky. Other methods such as covering the tag with metal would be too unreliable.

As a result, we decided to go forward with this design decision. We also have completed the geofence as well as the cellular module (removing the requirement for a phone).

We received our PCB this week and started assembling it. There was an issue with the power source and voltage regular but the PCB itself was designed correctly. We will try to fix these issues as soon as possible so we can have it ready for the demo.

Our group has learned a lot about our respective parts. We learned a lot about making PCBs with autodesk fusion, and effective ways to putting the components onto fusion even without a given file from the manufacturer. We also learned a lot about RFIDs, with the different frequencies, protocols, programming and calibrating tags. For newer knowledge such as this, youtube was a good starting point, but to get more specific knowledge (especially with our usage of more obscure parts), we learned to be better at reading datasheets. They may be long, but they should be read through slowly as they are pretty dense with information.

For the development of the app, some of us have never used flutter, so youtube and the flutter documentation were very helpful. For the members of our group who use windows, they had to figure out the android side of the app with android studio, while the others used ios with xcode. Additionally, we learned about different types of microphones, such as unidirecrtional, digital, compression, etc. We also learned about ESP32s and managing different variants of them, baud rates, etc.

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.

Team Status Report for 3/23

the most significant risks right now for the project are delivery time on the PCB and whether our current iteration of the PCB and system will function properly. We have spent an extensive amount of time this week on making sure that our parts are compatible and will function as intended. We are making sure 100% because it’s more important for the PCB to be correct than for it to be earlier but not quite correct.

We made some adjustments to the parts such as a new cellular chip with GPS and antenna included (Old one was less integrated, and more difficult to work with the PCB we are ordering), voltage dividers (to have the 11v battery supply all the various modules), and a new microphone (old one was analog, so transcription would not possible). We are also picking a smaller RFID Tag, since covering it up will be difficult with the current one we have (it’s too big).

No major updates to the project schedule. PCB is not quite on time, but will be ordered very soon.

 

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.