Refill cup attachment for restaurants  Project proposal    Ta: 

Transcript

Refill Cup Attachment for Restaurants  Project Proposal    TA: ​ Vivian Hou    ECE 445    Spring 2016                                                              Harington Lee  Chirag Patil  Arjun Sharma    1.0: Introduction    1.1: Statement of Purpose    Restaurants are heavily reliant on on customer reviews and a good way of improving  customer satisfaction is through better service. A common job of a waiter is to provide and refill  drinks. The refill cup attachment would make this task easier and more streamlined by keeping  track of the liquid levels of every patron’s drink. The waiters would be notified by an application  when a customer’s drink is empty which would reduce the amount of time a customer’s drink is  empty. The improved service would lead to more satisfied customers which would increase tips  and garner more business.    1.2 Objectives    Our project consists of a multiple cup attachment system that interfaces  with a central hub  using RF communication. The attachment will have wireless charging capabilities with a battery  life of at least six hours to last through peak restaurant times. The hub would then communicate  through Bluetooth to an IOS application. Our prototype will consist of two identical attachments  connected to a single hub for a proof of concept. Other similar projects that have been made  use different liquid level measuring techniques. One in particular uses RFID signal strength as it  varies depending on the amount of liquid nearby. A problem this project ran into was that when  ice was in the cup detection was nearly impossible. Another project used capacitive sensing by  installing the electrode design on the sides of the cup. However, this requires the design to be  integrated within the cup which requires designing a completely new cup. The goal of this  project is to make a product that can be used on existing glassware and can be used in any  drinking conditions.    Benefits:  ­ Can be used on existing glassware to save costs  ­ Potentially higher tips and better reviews for restaurants  ­ Better drink service for patrons  ­ Easier way to keep track of refills for waiters  ­ Data is organized and easy to view in a mobile application which is accessible for  anyone with a smartphone    Product Features:  ­ Wireless charging on cup attachments  ­ Long battery life for use in rush dining times  ­ Waterproof attachment to keep electronics dry  ­ Multiple cup attachment support through the use of a central hub  ­ Liquid level tracking using weight sensor and accelerometer  ­ User set threshold notifications on mobile application      2.0: Product Design    In general, our project is a modified transmitter­receiver system consisting of three parts:  the attachment, device hub, and cell­phone. The attachments are always transmitting some  form of data to the device hub, which acts as a permanent receiver. Data from the hub is then  sent via Bluetooth to a device such as a cell­phone or tablet running an Android or iOS app to  manage beverage levels and any empty cups.    2.1: Block Descriptions    2.1.1: Attachment Device    The attachment is the physical device that attaches to the beverage glass to track  consumption. It consists of an input device, the controller, wireless charging circuit, and  transmitter. The input device consists of a weight sensor, which generally produces an analog  value, and an accelerometer, which produces a digitally­encoded signal. Both of these input  devices send signals to the controller. The controller is a microcontroller IC that performs data  analysis on the value from the input devices, transmission control, and generates appropriate  error signals and diagnostic information for the entire system and user to process. The wireless  charging circuit includes the rechargeable battery which is connected to a charging coil along  with a Qi Charging controller. The final component, transmitter, is an antenna combined with an  APSK modulation system to encode input data from the microcontroller and output a radio wave  that contains information for the whole system to use. Below is a block diagram of the sensor  attachment.      2.1.2: Device Hub    The next major component of the system is the device hub, which maintains a central  connection center for all attachments. It’s primary function is to handle radio­to­Bluetooth  communications between the cell phone and the attachment. A secondary function is that it  helps with arbitration between multiple devices, which by the nature of Bluetooth  communications across multiple devices is difficult. The inability to pair multiple devices at once  to a cell phone is what prompted the design of a central hub. Also in real life applications where  a restaurant may have tens of customers, the hub allows for scalability so that if a restaurant  increases its customer count the increase in required sensors won’t stress the existing hardware  system. It consists of a Bluetooth module integrated into an SoC or microcontroller, a battery,  and a radio receiver module.    2.1.3: Mobile Application    The third and final component of this system is the cell phone or database system.  Envisioned as an iOS or Android app, the only requirements for this part of the system is  compatible Bluetooth hardware. The app will maintain a database of current customers’ liquid  consumption and notify a waiter if a person’s level drops below the threshold amount for  “empty.” This threshold can be set manually by the user since the weight may be different  because of liquid type or cup weight. Through software it can keep track of all active devices  and also handle diagnostic information for all devices such as battery level and operability.                                        3.0: Verification Design    Our system is designed so that each individual component can be independently tested.  Below is a verification plan to test the various components of the system    Component  Verification Plan  Antenna network  1. Antenna network  transmits at a peak  of 315 MHz.  2. Antenna network  peak power is  above ­35 dBm.  3. Peak value of noise  is 14.5 dBm below  peak power value.  Connect a 3.3V power supply to the Arduino with RF module  attached. Connect the RF receiver on the device hub to a  spectrum analyzer and the  Arduino running SoftwareSerial  library. Program UART test via the SoftwareSerial to send 8  packets of x3F24 to antenna.   1. Using the spectrum analyzer, check for a peak around  315 MHz when the UART is transmitting..  2. Using the spectrum analyzer, check the peak power.  3. Use the spectrum analyzer at 315 MHZ to check for the  peak value of the noise.  Wireless Charging  System  1. Qi controller  functions from 3.3V  to 5V.  2. Power draw is  within the limits of  5­7W.  3. Coil inductance is  from 12­35 uH.  Connect Qi controller to Arduino running SoftwareSerial and  power supply.  1. Connect a variable voltage supply to Vin. Connect a  voltmeter to the controller’s GPIO pins. Perform a power  sweep from 3.3V initially to 5V checking that the Qi  controller’s GPIO pins don’t register 0V.  2. Check with the power supply that the power draw is  5­7W with 1A.  3. Connect coil to a calibrated network analyzer and see  that the measured load impedance is with the tolerance  ranges of 12­35 uH.  Attachment Component  1. Weight sensor is  within 10 %  accuracy.  2. Weight sensor  functions from 0­5  kg.  3. Weight sensor  functions from 3V ≤  Vin ≤ 4V.    4. Accelerometer  detects less than  5% value fluctuation  when stationary.  5. Accelerometer  angle is accurate  1. Measure an empty cup in a digital scale. Connect the  weight sensor + amplifier to a 3.3V power supply and  measure voltage difference between the green and  white wire when weighing the same cup. Convert to the  digital scale’s units using the datasheet calibration  formula. (Measured Force = 5 * Measured mV/V + B  (offset).  2. Test various weights starting with no force to the 5 kg  limit by adding water into a cup on top of the sensor at  .5 kg intervals. Convert the voltage difference across the  green and white wire to a measured force using the  above formula and check for 10% accuracy.  3. Attach variable voltage supply to Vin. Measure voltage  difference across green and white wires and convert to  weight using given calibration formula. Use objects with  known weights and test for accuracy within 10% while  sweeping the voltage.  within 5 degrees.  6. Accelerometer  functions from 3V ≤  Vin ≤ 4V.  7. Battery life lasts at  least 6 hours.    4. Connect a 3.3V power supply to Vin. Attach a voltmeter  to the Xout output pin. Leave the accelerometer on a flat  surface and ensures the value does not change more  than 5%. Repeat for Yout and Zout.  5. Connect a 3.3V power supply to Vin. Connect the  voltmeter to each output pin. Individually test each axis  sensor (x,y,z) in 30 degrees intervals from 0 to 180  degrees by attaching the accelerometer to a flat board  and measuring the angle with a protractor. Record the  measured sensor values and convert to degrees using  the inverse tangent triangle formula. Compare the  measured and known angles.  6. Attach variable voltage supply to Vin. Connect the  voltmeter to each output pin. While sweeping the  voltage from 3V to 4V, measure sensor values from  Xout, Yout, and Zout at known angles (0 to 180 degrees  in 30 degree intervals) and convert them to degrees.  Ensure that these values are within 5% accuracy.        7. Fully charge the battery. Attach all sensors and  communication modules and time how long accurate  information is being sent to the device hub. Use known  weights and accelerometer values to make sure the  information is correct.  Bluetooth Hub  1. Compare encoded  radio bytes to  decoded data with  CRC error codes to  confirm the data is  correct.  2. Make sure that all  connections to the  SoC have been  properly made.  3. Check that  attenuation is less  than 2.5dB/m  Connect Bluetooth radio SoC to Arduino running the HC05  Bluetooth library. It facilitates data transfers at low clock speeds  and as simple function calls.  1. Perform a serial Tx transfer on the Arduino by first  sending xAAC2502E to initialize the SoC through  Register5.  Transmit data bytes xFE, xBC, xA9, x87, x65, x43, and  x21 by using the IOSent() function. After completion Pin  15 should go low, measurable in the Arduino as  IOSent() returning a 1.  Next put the SoC into Rx stage by sending xAAC2502F  and changing pin 15 to high. If the previous data was  properly transmitted and received running dataCheck()  returns with a 0; if errors do happen, it returns ­2.  Additional functions allow for the data to be transferred  to console via USB.   Using the Arduino place the SoC into diagnostic  validation mode by sending three byte transfers of  x48AE02CC with a x0F between each one.  The calculated CRC for xFEBCA987654321 is  x10BD3BC2. Perform step 1, and then send  xAE188000. Check that the CRC received at Rx is  x10BD3BC2 .  After placing the SoC into diagnostic mode, send  xFFFFC000 to test a JTAG scan of all pins. The JTAG  checks that there are no faults across the entire scan  chain of attached devices to the Bluetooth SoC.    2. Perform a JTAG scan test by sending in a scan chain of  xAE00000000FFFF0000FFFFFFFFB2AFF to Tx and  checking that the diagnostic output value at Rx is x0.  Alternative scan chains can be generated for our PCB  design by Cadence tools if this pattern doesn’t fully  work.    3. Connect the SoC to a network analyzer running an  antenna attenuation control system and check that the  attenuation is less than 2.5dB/m as the device is moved  away from the network analyzer’s antenna.  Phone App  1. Write a BIST in software as per iOS architecture  1. Phone UI changes  specifications. Simulate in XCode all APIs and UI/UX  corresponds to the  tweaks. Simulate in XCode the Bluetooth connection to  correct weight  the hub. Check XCode systems menu to see that phone  information.  app compiled correctly.  2. Multiple attachment              Perform basic tests.  weight information  a. New device added: should show a new device.  is handled correctly.  b. Drink filled: Weight level indicator turns from  grey to green.  c. Drink nearing threshold: Weight level indicator  turns yellow.  d. Glass is empty: weight level indicator turns red  and notification is displayed.  e. Device moves out of range: should notify that  certain device is now missing.  2. Put two different known weights on top of the two cup  attachments. Send weight info simultaneously from both  attachments, make sure that FTP protocol is working by  phone identifying two separate IDs with different  weights.                        4.0: Tolerance Analysis    Considering that this device uses wave propagation to accomplish data transmission,  any object that generates some type of interference is obviously a hard to clean data being sent  from attachment to phone. For this reason, tolerances are strict when it comes to the various  aspects of a microwave system.  Because our devices are designed to work in any restaurant environment, whether it is a  small pub or a giant food court, signal integrity is of huge importance. Even though our device is  designed to operate in an open frequency band of 315 MHz, the interference from other sources  in the vicinity created by harmonics or mixing is significant to impact the clarity of our signal. Any  other sources of power around that frequency can overpower the signal from each individual  device. We plan to design our device so that the transmitter modules operate with a large Q  factor so that noise from other sources won’t “bleed” into our available bandwidth. If our Q factor  is too low, our original wave energy is spread out over a larger range of frequencies and it  becomes difficult to read any data from our transmitter from background noise. If the Q­factor is  very high, it produces a narrow and powerful peak but then any deviation that causes the  frequency of the peak to shift slightly such as frequency drift in the transmitter system will bring  the peak out of the limited input window of our receiver.   Using an estimate of 55 devices in an average restaurant, and that each device would  produce roughly 4 dBm of noise per FCC rules, this means that there will be a threshold of 220  dBm of noise above background levels if all devices noise didn’t interfere. Worst case all  devices are communicating at the same time resulting in an overload of 220 dBm on the  receiver. In an average crowd rush for something like a weekday night, only 4 or 5 devices are  operating at any time, so we should expect to see 16­20 dBm of background noise on average.  During our tolerance testing, we plan to see if the receiver and our communication algorithm is  well designed to handle an extra 216 dBm of noise across the 15 MHz bandwidth of our device.  We plan to test this by applying the 216 dBm of noise as a series of power sweeps from  an antenna located in the microwave communications lab of ECEB. The antenna is connected  to an RF generator outputting random frequency noise within the bandwidth of our radio system.  Our transmitter is placed into diagnostic mode to continuously output a signal to be received.  The receiver is connected via Bluetooth to the mobile app, which should display that the device  is in diagnostic mode. A parallel antenna placed as close as possible to the receiver is  connected to a TRL­calibrated network analyzer, calibrated with the antenna’s length as an  electrical offset. Initially the power is set low to test that the devices can communicate with no  interference. We then slowly raise the noise power of the antenna, visually seen as random  peaks within our allocated bandwidth. The main peak magnitude will vary slightly due to the  resolution of the calculations done in the NA. At some point along the magnitude increase,the  receiver will be unable to output proper data and the Bluetooth device will output an error code  corresponding to packet loss and a general warning for retransmission. This value of the power  that the RF generator supplies is the threshold of device operation.        5.0:Cost and Schedule    5.1: Cost Analysis    5.1.1: Labor    Name  Hourly Rate  Hours Working  Salary (Hourly Rate x 2.5 x  hours to complete)    Harington Lee  $30  230  $17,250    Arjun Sharma  $30  230  $17,250    Chirag Patil  $30  230  $17,250  Tota l      690  $51,750                5.1.2: Parts    Part Name  Quantity  Cost  Weight Sensor (RB­Phi­118)  2  $14  Accelerometer Chip  (ADXL335)  2  $30  Microcontroller (ATmega)  2  $10  Charging Coil  2  $10  RF Transmitter (WRL­10535)  2  $8  RF Receiver (WRL­10533)  1  $4  Waterproof Attachment Case  2  $10  Rechargeable Battery  2  $10  Bluetooth Module  1  $10  Misc. Parts (Amplifier(hx711),  Resistors, etc.)    $5  Total    $111        5.1.3: Grand Total      Labor Cost  Parts Cost  Total Cost  $51,750  $111  $51,861      5.2: Schedule      Week  15­Feb  22­Feb  29­Feb  7­Mar  Task  Responsibility  Work on Mock Design review  Harington Lee  Work on Mock Design review  Arjun Sharma  Work on Mock Design review  Chirag Patil  Choose weight sensor, accelerometer, and bluetooth module  Harington Lee  Select wireless charging coils and mobile application platform  Arjun Sharma  Select microprocessor, RF modules, and rechargeable battery  Chirag Patil  Purchase parts  Harington Lee  Research power requirements for each component  Arjun Sharma  Test parts for accuracy and communication ranges  Chirag Patil  Integrate sensors with microcontroller and transmitter  Harington Lee  14­Mar  21­Mar  28­Mar  4­Apr  11­Apr  18­Apr  25­Apr  Develop UI for mobile application  Arjun Sharma  Program the attachment microcontroller to interface with hub  Chirag Patil  Assemble central hub  Harington Lee  Interface central hub with mobile application using Bluetooth  Arjun Sharma  Test to see if the microcontroller is sending data from weight  sensor at correct times  Chirag Patil  Attach components to PCB  Harington Lee  Create infrastructure for data display such as graphs in mobile app  Arjun Sharma  Program the hub microprocessor to transfer data to the Bluetooth  module  Chirag Patil  Integrate wireless charging coil and battery  Harington Lee  Check for data errors from the attachment to the hub to the app  Arjun Sharma  Debug charging components and test for battery life in different  usage conditions  Chirag Patil  Test attachment with different usage conditions and liquid levels  Harington Lee  Put together components in waterproof case  Arjun Sharma  Ensure that basic verification and requirements are fulfilled  Chirag Patil  Assemble second cup attachment  Harington Lee  Debug hub to mobile application communication  Arjun Sharma  Debug attachment to hub data transfer  Chirag Patil  Fix any remaining issues  Harington Lee  Ensure the mobile application can separate data from different  cups  Arjun Sharma  Test multiple attachment system with central hub  Chirag Patil  Finalize demonstration  Harington Lee  Work on final report  Arjun Sharma  Work on mock presentation  Chirag Patil  2­May          Finalize presentation  Harington Lee  Complete lab checkout and lab notebook  Arjun Sharma  Work on final report  Chirag Patil