Posted on

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.

 

Posted on

Team Status Report 4/27

This week was doing tests on our breadboard version that we presented demo videos of in our presentation. We did a bunch of tests to verify that the communication between the ESP and phone worked as well as sending messages either from the phone or from cellular itself. We expected the results to be no more than 15 seconds and all the tests passed. Regarding other tests like battery life and RFID/mic, we weren’t able to do due to the PCB not working yet and and finishing up RFID and the mic.

Anika debugged the PCB this week to figure out what was wrong and if this was an issue that can be solved or if the PCB won’t be able to work in time.  The voltage regulators were not working when we powered the board and the lithium ion battery would die every time we plugged it into the board. Because all the components worked when put tested on the breadboard, it was deemed be an issue with the board itself. At this time, because we are so close o the demo we can’t redo our PCB and need to focus on finishing implementing everything on the breadboard, which we have begun this week. We seem to be able to fit all the components onto a very small breadboard, and we will use this to represent our pendant. We also found a new battery component we can use instead of the lithium ion battery that was much smaller than the previous one.

Posted on

Anika’s Status Report 4/27

This week I prepped for my final presentation and worked on debugging the PCB. We ran into a few issues with the PCB. The first one being that the 5V and 3V regulator did not work on the PCB. When We soldered a new PCB with just the voltage regulaors and no loads, the 5V regulator ended up working but the 3V3 regulator still didn’t work as it outputted the same voltage it got in. I did some tests including powering it with a different battery source  (another esp) but that didn’t work either. Another issue was that everytime i fully charged the lithium ion battery and plugged it into the PCB the battery drained almost immediately. This meant that either something was wrong with the battery or the board itself.  When I recharged the battery and plugged it directly into a breadboard instead the battery was fine which meant it was a board issue. Furthermore when i soldered wires to the the 3V3 regulator and connected it with the battery, it was able to regulate the voltage down to 3.3. Because of these issues with the PCB and with the demo being next Friday, we moved to put all our components on a small breadboard, instead. While this isn’t ideal, we want to prioritize getting everything to work. Next week we are finishing up the breadboard and trying to get RFID and the mic working by Friday.

 

 

Posted on

Olivia’s Status Report 4/27

With one week left, and a new RFID tag coming in, I worked on ensuring communication between the new tag and RFID is working. This entailed creating code to upload to the RFID that can allow the RFID to sense the ISO type of the tag. Due to issues with our PCB, I worked on a breadboard version of our design, as well as currently working on the microphone on the breadboard, as our digital solderpad version on the PCB was not working as we wanted it to. This is going to require a lot of work as we come to demo day, as with finals and other classes while simultaneously working to ensure our final product is up to our standards. This week, I will finish the grind to ensure everything is working properly. This means the final stretch for RFID and microphone as those are the last components that need tweaking and work, as the rest are meeting our design requirements. Looking back, I have learned so much from this project and have dived deep into concepts with flash storage, RFID communication, BLE communication, CELL communication, and PCB design. It was exciting to work on a product that could genuinely help people as well.

Posted on

Anika’s Status Report 4/20

This week I assembled our PCB and worked on our final presentation while recording demo videos to show the class. I’ve attached a pic of our assembled PCB below. We did run into some issues with the battery the way it needed to be plugged in but we were able to manually fix our battery connection with some header pins. We also ended up connecting our battery adapter and extra powerjack to an extra PCB we had so we can use that as a seperate charging circuit so it didn’t power our PCB while simultaneously charging. Right now we are running into some issues with our voltage regulators as our VIN is not being regulated to 5V like it should be so I need to test if the regulator works or not with some of the extra parts we have. As I’ve designed , implemented and debugged our project, tools that were necessary were definitely an understanding of the data sheets, and a lot of experimentation with libraries for the companion app.  I had to get good at understanding other code from libraries I was using in order to apply functions for my own purposes. Next week I hope to debug this voltage regulation issue.

 

Posted on

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

Posted on

Olivia’s Status Report for 4/20

This week was an exciting but very important week for everyone! With one week left for demos, this week was devoted to finishing the PCB, putting as many finalizing touches into the code, both MCU (PCB programming) and front end of the mobile app. This week I finalized the geofence in the MCU code for the cellular’s GPS module. With trial and error I figured out a way for the GPS and CELL to switch properly allowing for use of both ( before there was an issue with switching). I also worked on refining the flash storage of the stored information from SOS contacts to the home geofence area and radius. I also worked on the presentation as well as testing. I conducted the tests for the PCB communication alongside Anika to test the mobile apps communication to PCB. These tests ranged from stress testing durability, range and more, as well as speed of communication testing, and ensuring they fit within our standards for the use case requirements and design requirements.

Posted on

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.

Posted on

Team Status Report for 4/6

Current risks are that PCB does not come in time or does not work properly. This would be very unfortunate and hard to combat if it went wrong, to aid in preventing this, we spent countless hours ensuring the PCB design was as best as it could be, checking with professors and TA’s to help ensure everything would work properly and testing on a breadboard.

 

No changes have been made to system design.

Updated scheduled was changed last week and discussed in team demo/last week reports.

 

Tests we have run:

Cell:

  • Testing in areas with low/high amounts of cellular devices and interference nearby (testing speed of communication, receiving/transmitting data as well as overall time it takes for text to send)
  • GPS coords testing [this is still being worked on/tested] ie with geoFence and ensuring quick oscillations of the GPS trigger have a back up to stop sending triggers in situations where they may have forgot to turn the geofence off. And overall testing location accuracy (down to almost +- 10 meters)

BTE:

  • Same as cellular but also testing main controlling aspects of the ESP32 with CELL and Mobile app.
    • Flash storage and receive times of BTE update of preferences (SOS #’s, geofence location and radius, triggers)

RFID:

  • RFID testing is still going on and won’t fully be able to be testing most likely until sodlered onto the PCB. Since we only have one RFID, and it is already pretty janky when it comes to testing (as we have to hold the wires into each pin of the RFID and not move a muscle to ensure it works), we will either have to come up with a better testing setup, or try to get the PCB solder done as soon as possible.

Overall all these tests will be used to see if we still fit our original requirements as stated in the beginning team reports. As we are able to test more in this last week, we will have a much better understanding of what is up to out standard and what is not, and possibly what standards we over or under estimated.

Posted on

Olivia’s Status report for 4/6

This week I worked on testing and verification as well as getting Geo fence and location tracking with the onboard cellular unit working. This took figuring out how I would be able to take a latitude, longitude and radius and figure out latitude and longitude that was within that radius to create a whole area that was a “safety zone” and depending on if a person wanted the trigger would alert and SOS when they stepped out of the area, it would send an alert to their specified SOS people. Realizing that the GPS unit had multiple tracking abilities, including a update coords or syncing the GPS location when the actual device has moved was great, as this helped so that it would not take a lot of battery when trying to get the coords even when they are stationary. This unfortunately introduced a few bugs that while the GPS was running, it struggled to send texts, but after rigorous debugging and testing, we were able to fix it.