Day 4 at Techtop Workshop
Today was the day we officially came up with a product and began designing the product. In the morning, my group brainstormed and finalized a product design. We also presented it in front of the whole track. We are planning to create an alert system for hospitals storing temperature sensitive medicines like vaccines. Details below:
“Smart Sensor”
Problem:
The storage of vaccines requires that they are kept at a certain temperature and humidity level range; otherwise, they cannot be used. There is monitoring in place, but there is not an immediate alert sent so that action can be taken quickly to ensure the quality of the vaccines is kept.
Solution
There is a need of immediate alerts because when vaccines are not properly kept, they can’t be used and must be disposed of. This is costly and not helpful to the patients. We would like to be able to alert the responsible party for those vaccines through SMS if the temperature and humidity levels are not within the range that are required to store the vaccines so that action can be taken to ensure that the vaccines are kept properly. This can be done through the use of a temperature and humidity sensor that we kept inside the container for monitoring.
Market
Electrical Components
Design
Need Statement:
The problem we are trying to solve is that the storage of vaccines in the hospitals is not always done correctly because they are not kept at the correct temperature and humidity level, which can ruin the vaccines and medicines that are necessary to help people’s health. There is monitoring, but there is not an immediate alert sent when the temperature isn’t correct. It’s more just data logs.
We would like to be able to alert the responsible party for those vaccines if the temperature and humidity levels are not those that they need to be to properly store the medicine. Once the alert is sent, action can be taken to ensure that the vaccines are kept properly.
Used by:
Hospitals
send alert to who is monitoring a certain group of patients that need the vaccine, in charge of that particular department
What does it do:
has ability to input a desired temperature and humidity level that is needed of that container
when the sensor senses a temperature/humidity level that’s not the desired one, it will send an alert to the stakeholders through SMS
Technology it uses:
temperature sensor and humidity sensor inside
records the readings and checks if the values are out of range
sends SMS to stakeholder using technology attached outside
GSM module (like sim card) that sends the SMS
a container by hospital that will have this embedded
powered by 5 volt battery
interface to change the desired temperature and humidity levels and input in the phone number
Things to Consider:
sensors and modules must be able to withstand very cold or hot temperatures
must last for few days/weeks—the storage time of the vaccines
Design:
LM35 temperature sensor - 3 pins (gnd, vcc, output: voltage)
Some things that were brought up during our presentation was that we could possibly make a user interface to change the temperature instead of hard coding, use this sensor in something like storage of food or temperature-sensitive equipment, and having the container adjust to the temperature/humidity level that is desired by itself. As of now, we are trying to create the simple alert system but would consider doing the suggestions had we had more time, skills, and resources.
To achieve our product idea design, we developed a plan. Using the microcontroller we had already created, we are utilizing its ADC (analog digital controller) pins to attach the temperature sensor (LM35) and the GSM modem that will send the SMSs. Currently we are trying to learn AVR code to program the microcontroller and how to program the GSM to send SMSs to numbers. AVR code seems to be similar to/is machine/assembly language.
Here is some information I collected on the GSM modem:
2.1.7 Send Message(AT+CMGS) This command enables the user to send SMS messages. Section 2.2.3 describes how to build such messages. How to include user defined text and recipient telephone number. After the user defined fields are set, the message can be compressed and sent using the “AT+CMGS” command. An example usage of “AT+CMGS” is given in section 2.2.3.
[table here]
2.2.3 Building and sending a message in PDU mode The SMS message, as specified by the ETSI organization, can be up to 160 septets long. The maximal user payload is then restricted to 140 octets, together with additional fields in the PDU protocol. These additional fields are crucial since they contain information about receivers-address, address length, validity-period, type of address, data coding scheme, protocol identifier etc. A message sent from modem to a service center is called an SMS-SUBMIT message. Table 2-12 shows how to build such messages. To avoid any problems with manufacturer specific meta-data, the modem is set to do this using the “00” option. Rest of the protocol stack is defined according to GSM 03.40.
[table here]
In advance of sending our string, we need to calculate its length. Counting the number of octets, excluding the leading meta-information, gives a total length of 17 octets for the SMS string in Table 2-13. Using a terminal application, the following could be sent to the modem.
AT+CMGS = 18 //Send a message containing 18 octets, excluding //the two initial zeros
The modem will now delay for a while and get ready to receive the 18 octets long SMS string. A “\r\n> ” will be displayed on the screen when the modem is ready to append your payload. See code below.
> //Promt given from phone when ready to send 0011000A9174214365870000AA05E8329BFD06 //SMS string to send
The modem should now return “OK”, meaning that the message is sent. Using a Cellular Phone this could be verified as a new entry in the Sent Items folder. Most error messages for “AT+CMGS” originate from using the wrong message length, so this should be checked twice. Remember to omit counting any leading zeros in the header!
It seems pretty hard right now, but we are making good progress and hope we can pick it up and understand it all soon. As all three of us are computer scientists with little to no electrical engineering background, we hope that we can build a functioning product.
No comments:
Post a Comment