Category: Team Status Reports

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.

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.

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.

This week we have divided up work in order to present working parts for the interim demo.

Anika: establishing a connection between the companion app and the esp in order to send contact information to the esp.

Olivia:  getting the esp to send information to the cellular module

Bradley: getting the RFID working.

We’ve successfully established the first 2 parts and by the interim demo we hope to show everything connected on the breadboard to show our progress. With the progress we have so far I think we are getting back on track with our timeline.

Demo video for ESP and Companion App connection

 

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.

 

The most significant risks are with a component delivery time that could jeopardize our project and timeline. For risk management, we have developed a few contingency plans with two suppliers to ensure if Ali Express does not come in we also ordered from Digieky. We will be tight-pressed on time for the final product but know we can get it done and are adjusting and accommodating to these potential delays.

 

No significant design changes were made this week, except ordering a different supplier’s motor as it has a better CAD file for the PCB design but was almost the same. Several other specification choices but not overall design changes were made.

 

No updates to the project schedule other than announcing the end of the PCB design section which was delayed from the original first week’s scheduling. By finishing the PCB schematic we are excited to move to the next stage in the schedule.

The most significant risk to our project’s success remains consistent with our previous reports. Additionally, the complexity and depth of our project, with its many moving parts, present a substantial challenge. In order to successfully navigate this it will require a high level of dedication and effort from the team to bring our invention to life. One of the biggest issues holding us back thus far was not having all our parts figured out. While creating the design report we were able to finalize our parts list and get them ordered. We are still in budget with these changes. Now with this done, we can start to work on our PCB design to get that finished and ordered as well while we work on the parts individually in the meantime.

After thoroughly reviewing our materials, we have implemented some changes to the system’s overall design. The block diagram was modified after feedback from the design review in order to make our flow more understandable and have a clear logical flow on how different parts of the product come into play with each other.

Liv was also able to write the bluetooth code for communication between the ESP32 and mobile app which works for communication in both direction. We have also created a github to consolidate all our work into one location.  Our next topic we need to discuss as a team is how data gets serialized between the phone and pendant (in both directions)

The schedule in the design report is still current.

A was written by Anika, Part B by Olivia, and part C by Bradley

Part A: In regards to global factors our product is meant to be worn by any one anywhere. Outside of the Pittsburgh area what we do need to do is make sure that our product/code does not violate any sort of privacy laws anywhere else. the device is also intended to be user friendly. While there may be many moving parts we hope to mitigate this by have a very clear and concise tutorial/page on how to get started with the device. We also as we finalize tour design will hope to get feedback on our instructions as to make it as clear as possible.

Part B: In regard to cultural factors, these have not changed very much. If going into real product stages of this project and we were to develop a mass-produced item, we would need to review different religious, cultural and overall style factors to ensure that our pendant and ring could be worn by everyone. To ensure all races, genders, religions and more not only want to but are able to wear our devices, we must take into concern many factors, with current fashion ideals as well as rules with clothing due to peoples’s personal beliefs all while also maintaining discretion. While not in the process yet, this will have huge considerations during final outer design is underway.

Part C: Our device is inherently environmentally friendly, with the parts being recyclable. Also, our device uses a rechargeable battery instead of a non rechargeable, reducing waste. Ideally In terms of living organisms, our device is not related to them, as it is a personal safety device.  To make our device even more environmentally friendly, we could use recycled metals for the jewelry pieces.

 

The most significant risk to our project’s success remains consistent with our previous reports. Additionally, the complexity and depth of our project, with its many moving parts, present a substantial challenge. In order to successfully navigate this it will require a high level of dedication and effort from the team to bring our invention to life.

After thoroughly reviewing our materials, we have implemented some changes to the system’s overall design. We expanded the role of the ESP32, innovatively leveraging its extensive capabilities to serve not only as a Bluetooth connector for our app integration but also as the main MCU unit. Further research into RFID technology informed several specific design alterations, enhancing our method of communication between modules. We have developed multiple contingency plans to address potential challenges and ensure continued progress.

The schedule in the design review slides is still current.

 

This week we made a few changes to our design after feedback, further research, and meeting faculty members for advice. In our proposal, we wanted to use bluetooth for the ring to communicate with the pendant, which received pushback from students and faculty. We initially thought it would be the most reliable way for a button press to communicate with the pendant. However, we started to have our doubts from this feedback, and eventually met with James Bain, who gave us possible alternatives. He suggested that we use UHF RFID to communicate from the ring to the pendant. If we use passive RFID, this will completely eliminate the need for a battery in the ring. Looking for a Bluetooth module and battery small enough was a problem when trying to keep the ring compact.

Outside of RIFD, we also changed a few parts of the pendant, such as adding an Antenna, specifying a uni-directional microphone (to reduce noise), and SIM.

During our presentation, one of the students suggested another trigger for us, which if the ring and pendant separate a certain amount of distance. We thought that was a great idea and have added that into our design.

Some of the things that we are worried about for the success of our project are voice detection in a crowded place and the pendant’s battery lasting past 6 hours. For voice detection, we are trying a uni-directional microphone to reduce noise. We will also try to reduce issues with crowded places on the software side as well. For battery life, the main obstacle is the voice trigger. The contingency plan will be for the user to turn on voice detection when they think it is necessary, rather than being active all the time.

Our updates schedule is in our design review slides.

A was written by Anika, B was written by Olivia, C was written by Bradley

Part A: In regards to considerations of public health, safety, or welfare, our project attempts to tackle these three considerations as follows:

Health/Safety – The jewelry system operates as safety device meant to help a person contact help when in dangerous situations or are facing physical harm. With multiple options on how to alert authorities and emergency contacts the device provides the user with a strong sense of security. In addition, because our jewelry is designed with the intention of being discreet the user does not have to worry about drawing excessive unwanted attention while wearing the devices, which improves their psychological well-being.

Welfare:  It is a basic need for people to be able to go about their day without having to worry about/encounter dangerous situations, and this device aims to mitigate this risks by seeking help efficiently and quietly.

Part B: In regards to social factors and how they play a part in our project: Culture: With discretion and protection of individuals in mind this must ensure that its follows cultural norms when it comes to jewelry and wearable technology, ensuring that if certain cultures have requirements that we are meeting them so that anybody can use/wear them, this also includes our audio recognition, it must have multilingual support and cater to not just English speaking people. For Social factors this includes accessibility and usability, with this in mind, our button must be easily pressed for example or the mobile app must be easily used for people with low-technology proficiency. In regards to political factors, we must ensure we are following all different area’s regulations and privacy restrictions as different counties, states, and countries have massively differing rule sets. For economic factors, we intend to make the jewelry cost-friendly for a younger demographic that has limited spending power.

Part C: with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services.

Our product may share traits with other products on the market, does not share the same principles in terms of cost and user experience. When looking online for similar products, they typically will go higher than $149 dollars for retailing. Furthermore, products like inviswear require a costly subscription on top of that. We plan to make a product that is much more affordable and free of a subscription requirement, while still looking fashionable and discrete.

 

This week we presented our proposals, and got feedback that will help as we move forward with our Design Presentations. We recognize that it will be important to highlight what makes our design unique and that we should go into more detail why we have a ring/pendant system (specifically that the ring trigger can be pressed by the user in situations where they are unable to move their hands and the button on the underside of the ring can be easily pressed with the thumb using one hand.) In addition we also need to consider in more detail how we are going to test our design b/c with a safety device it’s consistency is crucial. We also need to modify our block diagram to be less high-level for the design presentation.

As we order supplies this week, we face significant risks if a necessary material for our final project has a long delivery or wait time, that we are giving us enough time to not only order the part, but ensure it will work with our implementation. We will manage these risks by ensuring we have 2 back up plans for every high risk item. This means that we either order additional materials, an extra variation of a material or have a backup design that can work without the material for extreme cases. This will most likely slightly change our costs of our original system if we eventually go with a different variation, but as of right now, nothing will change specifically.