Refill Cup Attachment for Restaurants

Design Review

TA: Vivian Hou

ECE 445

Spring 2016

Team 42

Harington Lee Chirag Patil

Arjun Sharma

1

Table Of Contents 1.0: Introduction …………………………………………………………………………………………..2 2.0: Attachment Block Design ……………………………………………………………………...…….5 2.1: Microcontroller ……………………………………………………………………………….3 2.2: Weight Sensor ………………………………………………………………………………...7 2.3: Accelerometer…………………………………………………………………………………8 2.4: RF Subsystem…………………………………………………………………………….….10 2.4.1: RF Network Simulation……………….……………………………………….….14 2.5: Power Supply…………………………………………………….……………………….….15

2.6: Wireless Charging…………………….………………………….……………………….….16 3.0: Hub Block Design …………………………………………………………………………………..18

3.1: Bluetooth Module …………………………………………………………………………...18 3.2: Microcontroller …………………………………………..………………………………….18 3.3: RF System …………………………….……………………………………………………..19 3.4: Power Supply …………………………………………………………………………….….20 4.0: Mobile App Design …………..……………………………………………………………………..20 5.0: Power Analysis …………………………………..……………………………………...…………..22

5.1: Battery and Buck-Boost Converter…………………………...……………………………...22 5.2: Cup Attachment Current Drain…………………………...……………………..…………...23 5.3: Charging and Discharging Time……………………………...……………………………...23

6.0: RF Communication Protocol……………………………………………………………………….24 7.0: Expected Device Operation…………………………………………………………………………28 8.0: Requirements and Verification…………………………………………………………………….30

8.1: Verification Steps for Attachment…………………………………………………………...31 8.2: Verification Steps for Hub…………………………………………………………………...35 8.3: Verification Steps for Mobile App…………………………………………………...……...36

9.0: Tolerance Analysis………………………………………………………………………….……….36 10.0: Safety Statement…………………………………………………………………………………...38 11.0: Parts and Costs…………………………………………………………………………………….38

11.1: Cost Analysis……………………………………………..………………………………...38 11.2: Component Costs…………………………………………………………………………...38 11.3: Total Costs……………………………………………………………………………..…...40

12.0: Schedule and Division of Responsibilities…………………………………………….…………..41 13.0: IEEE Ethics……………………………………………………………………………………… ..42 Citations……………………………………………………………………………………… ………….44 Attachment Schematic……………….……………………………………………………… ………….45 Hub Schematic…………………………………………..…………………………………… ………….46

2

1.0: Introduction

Restaurants are heavily reliant 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.

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.

Figure 1: Project component overview

The main focus of our design is on the attachment system that fits on the glass and

measures the weight of the drink in the cup. It consists of input devices, power supply, microcontroller, wireless charging circuit, and transmitter. The input devices consist of a weight

3

sensor and accelerometer, both of which produce analog values. Both of these input devices transmit their data to the microcontroller. The microcontroller is an IC that performs data analysis on the voltage values from the input devices and manages the logic control of the transmitter circuit for proper operation. The wireless charging circuit includes the rechargeable lithium-ion battery which is connected to a charging coil along with some AC circuitry in the form of a Cockcroft-Walton generator. The final component, RF 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.

Figure 2: Attachment component block diagram

The second focus of our design is a central communications hub interfacing the

attachment devices and the mobile app. The hub performs two important and major operations in our system. First, it handles the RF to Bluetooth conversion so that the RF-encoded data from the attachments can easily communicate with a Bluetooth receiver, commonly found in most embedded devices today. Second, the hub also interfaces multiple attachments to one single system because Bluetooth cannot connect all devices to the mobile app in a round-robin fashion. The hub contains a microcontroller, Bluetooth transceiver, RF transceiver, and battery system for operation.

4

Figure 3: Hub component block diagram

The third and final component of this system is the cell phone or database system. Envisioned as an iOS or Android app, the only requirement for this part of the system is compatible Bluetooth hardware and a supported operating system. 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.

5

Figure 4: Application component block diagram

2.0: Attachment Block Design

2.1: Microcontroller

The central aspect of our design is the microcontroller regulating all active devices. We are using an Atmel ATMega328p for the microcontroller IC on the attachment device because it is one of the few microcontrollers that work with a 3.3V supply needed for operation of all other ICs on the PCB. Code for functional verification before the final design is written in Arduino and the ATMega328p is flashed with the Arduino bootloader to process the compiled AVR libraries. Most of the programming uses premade functions and simple control statements to interpret data from the accelerometer and weight sensor. Critical aspects of the programming include serial functions that control data transmission over a 3-wire interface to the RF transceiver and processing of the digital data from the accelerometer and weight sensor after A-D conversion.

The standalone microcontroller requires very little additional components to operate on for which the datasheet provides values and product names. The microcontroller requires a stabilized power supply of 3.3V which we regulate with the power circuitry on the PCB. The reset pin is active low and designed with a pull-up voltage resistor of 10 kΩ and button so that

6

the activation of the button causes the pin to go low and the microcontroller to reset. The only additional components required are the oscillator system. The datasheet recommends the use of a 16 MHz oscillator across XTAL1 and XTAL2 pins with grounded 22 pF capacitors to set up an oscillatory system. Unfortunately this reference setup is only recommended for use with a 5V supply. With a 3.3V supply an 8 MHz clock should be used rather than the default 16 MHz clock so we are using an 8 MHz crystal in our circuit. For the capacitors, since the resonant crystal has a very high Q factor any changes in load capacitance will not make a significant change in frequency or power, especially for our circuit where clock speed variability isn’t a problem. For this reason the capacitor values still stay at 22 pF, within the tolerable operating range of 18-33 pF as recommended by Atmel. The remaining pins to the microcontroller are digital or analog inputs connected to our sensor circuitry or transceiver.

Figure 5: Microcontroller and peripherals schematic

7

2.2: Weight Sensor

In order to actually determine the volume of liquid in the glass we rely on a strain gauge converted into a weight sensor. The weight sensor consists of a piezoresistive section of wire stretched between a flexible metal beam and the metal body. Our weight sensor has a 4-pin interface of Vdd, Gnd, Sense+, and Sense-. The difference between the two sense signals is an analog voltage that varies linearly depending on the force applied to the sensor (weight of the liquid in the cup). Our sensor is designed to measure between 0 and 5 kg with a voltage range of 20±0.10 mv/V with an excitation voltage. Our 3.3V default excitation voltage results in a signal from 0 to 0.066V, too small for the ADC pins on the microcontroller to accurately resolve. The signal is amplified after coming from the sensor by use of an INA122 instrumentation amplifier which has a tunable gain for use with the ATMega328p. The datasheet for the INA122 specifies that the output differential voltage gain is given by

𝑉𝑜𝑢𝑡 = 𝐺(∆𝑉𝑖𝑛) 𝑤ℎ𝑒𝑟𝑒 𝐺 = 5 +200 𝑘𝛺𝑅𝑔

We would like our circuit to sample voltages across a range of 0 to 3 volts, so the default gain that sets the device sensitivity needs to change. Essentially the gain needs to compensate and convert the input voltage range of 0 to 0.066V to the refined 0 to 3V output to the microcontroller.

𝐺 =3 𝑉

0.066 𝑉= 45.45455

45.45455 = 5 +200 𝑘𝛺𝑅𝑔

𝑅𝑔 = 4943.82 𝛺

The inability to find a 4.9 kΩ resistor means the actual circuit uses 4.7 kΩ and 200 Ω resistors in series to provide the required resistance. The wires from the sensor will be soldered to pads on the PCB. Physically the weight sensor will be attached to a metal beam that sits at the very bottom of our circuit and acts as the base for the device packaging. By being at the base, it directly responds to force applied from above and senses a much greater and accurate force compared to being mounted so the cup directly applies force to the sensor.

8

Figure 6: Weight sensor and amplifier schematic

2.3: Accelerometer

In order to prevent the attachment from constantly transmitting data we have an accelerometer that detects the motion of the cup. Data is sent after the attachment has sensed that the cup has been moved with some force in either of the x, y, and z directions. Because the minimum acceleration to lift a cup against gravity is 1G, if the resultant acceleration of all three axes is greater than +1G, we can safely assume that the cup has been lifted into the air and not pushed around on the table. The accelerometer we have chosen to use is the Analog Devices ADXL335 which is a 3V 3-axis analog accelerometer that provides 0.05G resolution to ±3G. It outputs 3 analog signals representing an acceleration fraction in each of the x, y, and z axes. Despite this simple analog control, the accelerometer has an internal ADC which means that it performs sampling on the internal acceleration signal where the sample rate is set by the accelerometer bandwidth. For slow-moving applications such as our attachment system where the action of someone taking a sip is in the range of seconds, a usable bandwidth can be as low as 50 Hz or 50 samples/ second. The ADXL335 allows for user programmability of the bandwidth by the tuning of external capacitors that resonate in an RC circuit with an internal 32 kilo-ohm resistance. The capacitor value can be related to the bandwidth by the following equation detailing 3 dB bandwidth for an RC system:

9

𝐹3𝑑𝐵 =1

2𝜋 × 32,000𝛺 × 𝐶𝑡𝑢𝑛𝑒

The ADXL335 has capacitive compensation for a range of bandwidths and for this reason a simplified equation is detailed in the datasheet for capacitance calculation

𝐹3𝑑𝐵 = 5 𝑢𝐹𝐶𝑡𝑢𝑛𝑒

Using a value of 50 Hz, the calculated capacitor value from the equation above is 0.1 uF. Because we want to maintain symmetry in our data readings, all three axes will be controlled through 0.1 uF capacitors. Another advantage is that 0.1 uF is a commonly used decoupling capacitance value and a value that occurs elsewhere in our projects. By reusing an existing value we can save on product costs associated with buying a different capacitor.

Because the accelerometer analog voltage range matches the same range as the microcontroller it can be connected directly to the analog pins of our ATMega328p. The ADXL335 has a voltage operation range of 1.8 to 3.6V meaning the power supply can be connected to our main 3.3V regulator and the analog quantities processed by the microcontroller. Many of the pins on the IC are designed as no-connect including the self-test ST pin.

Figure 7: Accelerometer and peripherals schematic

10

2.4: RF System

The main circuit comprising our design work in the attachment is the RF transmitter and receiver module. The RF transmitter is found in the actual attachment devices that are used to record weight. The RF receiver is found in the Bluetooth hub that interfaces between the attachments and the mobile app. In order to reduce the complexity of multiple chips that operate on two different frequency ranges or modulation schemes we settled on a single transceiver IC connected to a microcontroller. The advantage of this design is that the same circuit can be implemented across our multiple devices reducing design overhead and also allowing some standardization of operation across devices. Also in the event that a two-way communication protocol is needed, the transceiver allows for functionality to be programmed rather than creating complications in a hardware redesign.

The IC we are using is the TI CC1000 which is a single-chip low-power RF transceiver IC. It consists of an FSK modulation system and a digital data core with programmable operation through a microcontroller. The CC1000 has data inputs, a data output, oscillator IO, and RF IO. The RF IO is connected to an antenna with impedance matching network and frequency sink. The oscillator IO is connected to a crystal oscillator with capacitors to lock an oscillation frequency, reduce the effect of harmonics, and also act as bypass caps. The data IOs are connected to the microcontroller through a 3-wire interface.

Figure 8: TI CC1000 Internal Schematic from Datasheet

11

The IC handles most of the modulation and data processing but additional circuitry is needed to filter the antenna connected to the RF IO and also to decouple the oscillator at the XOSC IO. An inductor bridges the VCO tank IO L1 and L2, and a resistor couples R_Bias to ground. The value of the inductor is provided in the datasheet as 56 nH.

For the RF IO, the datasheet details a matching network to convert the 50 Ω antenna impedance to the CC1000’s internal impedance. The datasheet describes the 315 MHz operating impedance of the CC1000 as 88-j26 Ω which has to match the 50 Ω antenna impedance. We want the antenna to block any transmitted DC from the rest of the circuit and also match a smaller impedance to a larger one so the preferred L-network topology has a shunt inductor immediately in parallel to the load. Since this network uses a parallel shunt inductor at the load, we need to convert the CC1000’s Thevenin series impedance of 88-j26 to an equivalent parallel representation. The equations to do so are

𝑄 = 𝑋𝑅

𝑅𝑝 = 𝑅𝑠(1 + 𝑄2)

𝑋𝑝 = 𝑋𝑠(1 +1𝑄2)

Inserting the impedance into these equations results in

𝑄 = 2688

= 0.29545

𝑅𝑝 = 88(1 + 0.295452) = 95.682 𝛺

𝑋𝑝 = 26 �1 +1

0.295452� = 323.846 𝛺

After the CC1000 series load impedance has been converted into a parallel representation the values of the elements in the L-network can be calculated with the method of impedance absorption. The following equations detailing an L-network are used to first find lumped reactances that represent a sum of the calculated L and C values and any complex impedance of the source or load:

𝑄 = �𝑅𝐶𝐶1000𝑅𝑎𝑛𝑡𝑒𝑛𝑛𝑎

− 1

𝑋𝑝,𝑟𝑒𝑓 = 𝑅𝐶𝐶1000𝑄

𝑋𝑠,𝑟𝑒𝑓 = −𝑅𝑎𝑛𝑡𝑒𝑛𝑛𝑎 × 𝑄

Inserting the values of the parallel representation of the CC1000 load results in:

12

𝑄 = �95.682

50− 1 = 0.9558

𝑋𝑝,𝑟𝑒𝑓 = 88

0.9558= 92.065

𝑋𝑠,𝑟𝑒𝑓 = −50 × 0.9558 = −47.792

The lumped reactances can be rewritten in terms of the unknown reactances of the L-network and the known reactances of the source and load. This enables us to solve for the reactances of the L-network. Since the input impedance of the antenna is purely resistive the series reactance is equal to the series L-network reactance.

𝑋𝑠,𝑟𝑒𝑓 = −47.792 = 𝑋𝑠 + 0 𝛺

𝑋𝑠 = −47.792

𝑋𝑝,𝑟𝑒𝑓 = 92.065 = 𝑋𝑝 × 323.846𝑋𝑝 + 323.846

𝑋𝑝 = 128.633

These final series and parallel reactances can then be used to calculate the final values of the capacitor and inductor by use of the device equations.

−47.792𝑗 = 1𝑗𝜔𝐶

128.633𝑗 = 𝑗𝜔𝐿

47.792 = 1

�2𝜋(315 × 106)�𝐶 → 𝑪 = 𝟏𝟎.𝟓𝟕 𝒑𝑭

128.633 = �2𝜋(315 × 106)�𝐿 → 𝑳 = 𝟔𝟓 𝒏𝑯

For the RF output the datasheet suggests using an LC tank coupled to the voltage supply to set the circuit sensitivity around the 315 MHz central frequency. The calculation of the LC values can be done by using the formula for a resonant LC circuit and solve for values that result in a 315 MHz resonance. We assume in the following calculation that L=20 nH because it’s a recommended inductance in the CC1000 datasheet and a value we can purchase easily, leaving the capacitor value to be calculated from the following equations.

𝐹𝑟 = 1

2𝜋√𝐿𝐶

315 × 106 = 1

2𝜋�(20 𝑛𝐻)𝐶

13

𝑪 = 𝟏𝟐.𝟕𝟔𝟔 𝒑𝑭 with an inductor of 𝑳 = 𝟐𝟎 𝒏𝑯

For the oscillator, the datasheet provides the circuit arrangement and some suggested values for the capacitor. The internal VCO requires a Colpitts arrangement of two shunt capacitors in series with an oscillating crystal for operation. The datasheet provides the capacitor values for us to use at 315 MHz as 18 pF for both capacitors and recommends the use of a 14.7456 MHz crystal resonator with a 16 pF load capacitance and 0.05 pF parasitic capacitance. This oscillator frequency is then multiplied by 20 using the internal PLL to end with the 315 MHz final transmission frequency used to modulate and demodulate signals from the RF IO.

In order to help with testing and verification the CC1000 comes with a received signal strength indicator (RSSI) pin that allows for an ADC to sample the voltage at the input of the antenna. When performing attenuation testing in verification this function provides a numerical value to assist in making a signal strength curve for calculating the attenuation and operating noise levels of our circuit. The pin generates a current inversely proportional to the RSSI, so for analysis at the mnicrocontroller ADC it is converted to a voltage by use of a shunt resistor in series with a decoupling capacitor to sink any parasitic AC noise to ground. The datasheet provides suggested values for the RC network as 27 kΩ and 1 nF.

Figure 9: RF network schematic with matching network and peripherals

14

In terms of the antenna to be attached to the transceiver the datasheet recommends the use of a simple monopole antenna. To achieve as best a match to resonance as possible and increase the input power, the monopole is designed to be a quarter-wavelength long. For a 315 MHz operating frequency the antenna length is 23.8 cm. The antenna can be coiled up to fit into the package with minimal disturbance to the RF system from any increased inductance.

2.4.1: RF Network Simulation

Because the RF communications link is a critical part of our system we simulated the RF system to test operation around the 315 MHz central frequency. The datasheet recommends the use of simulation to ensure that measured s-parameters match specified values in the datasheet. The figure below details the circuit schematic drawn in ADS for the RF input system. The s-parameter simulation is chosen to cover a range of 100 MHz.

Figure 10: ADS Schematic of RF Antenna Network

The resulting simulation shows that the return loss of the system reaches a minimum of -50 dB at a frequency of 314 MHz and that the return loss is -44.64 dB at our 315 MHz central frequency. The datasheet recommends an insertion loss of less than -25 dB at the RF input so our simulated value passes the requirement. In general the lower the return loss the better performance our matching system is giving to the antenna, so a return loss value of -44.64 dB

15

means that our RF circuit will most likely be performing with minimal issues. However the simulation neglects physical issues of lumped-element modeling and doesn’t consider issues in our antenna’s design so the actual return loss value will be different if measured with a calibrated network analyzer.

Figure 11: ADS S-parameter simulation

2.5: Power Supply

We chose to use is a 3.7V 400mAh polymer lithium battery to power the cup attachments. This battery has dimensions that make it easy to fit inside the cup attachment while providing enough power to last through high usage periods. Many of our components have different allowable voltage ranges so we also chose to use a voltage regulator (TPS63031) to ensure that the voltage stays constant at 3.3V. The voltage regulator also provides an 800mA output current which is more than enough for all of our components. Current draw calculations are done in the power analysis section of this paper. In the table below are the voltage requirements for all of the components we use in the cup attachment.

Component Voltage Requirement

Load Cell Max Voltage: 10V

Microcontroller (ATMega328P-PU)

Max Voltage: 3.3V or 5V

MAX1555 battery 3.7V to 7V

16

regulator

Accelerometer (ADXL335)

1.8V to 3.6V

Amplifier (INA122UA) 2.2V to 36V

Transceiver (CC1000) 2.1V to 3.6V

Polymer Lithium Ion Battery

4.2V±0.03V

The MAX1555 adapter is used to bring the voltage supplied by the wireless charging

circuit to the required battery input voltage. The MAX1555 receives around a 5V input from the wireless charging circuit which is within the 3.7V to 7V range allowed. The battery adapter provides a 4.2V output which is the correct amount for charging the battery. The datasheet for each component has suggested resistor values that we incorporated into the design. While the adapter also allows for USB charging, we will only be using the DC input portion.

Figure 12: Voltage regulation and battery schematic

2.6: Wireless Charging

The battery will be situated inside the waterproof container which limits the charging options available. We will be utilizing a wireless charging circuit that utilizes resonant inductive coupling to match frequencies with an AC function generator connected to a coil of copper wire. Using resonance coupling increases energy efficiency substantially. We chose 80KHz as the frequency to use to determine the inductance required in the pair of coils as it is a reasonable

17

starting point for calculations. 100nF capacitors were also chosen as they are commonly available and easy to work with. To calculate the require inductance, we start with the formula to calculate the resonant frequency in an LC circuit.

𝑓0 =1

2π√𝐿𝐶

𝐿 = 1

𝐶4π2𝑓02 = 39.6𝑢𝐻

To create the inductor coils, we will be using multilayer 22 AWG wire. Wheeler’s formula can be used to get a rough estimate of the dimensions of the coils:

𝐿 (𝑢𝐻) =31.6 × 𝑁2 × 𝑟12

6𝑟1 + 9𝐿 + 10(𝑟2 − 𝑟1)

where N is the number of turns, r1 is the radius of the inside of the coil, r2 is the radius of the outside of the coil, and L is the length of the wire used in the coil. The number of turns can be determined by playing around with different values for radius inside and outside of the coil as well as the length of the coil. One limitation for the coil size is that it must fit inside the cup attachment. A limit of around 2 inches on the total diameter works if the coil has 40 turns and is half an inch thick. Other factors such as the shape of the turns can change this result so the most efficient way would be through manual calibration.

Another function of the circuit is to convert the AC input into a DC output. This is done using a Cockcroft-Walton generator. This generator is made up of a ladder network of diodes and capacitors. It also multiplies the peak voltage depending on the number of stages. The alternating input voltage charges different capacitors because of the diode placement. The voltage increases and in the case of a two stage multiplier it reaches 4 times the peak voltage. Assuming a two stage multiplier (N = 2), a 5V AC input, and a voltage drop of around a half through the resonant inductor coils, the peak voltage should be around 1.25V.

𝑉0 = 2𝑁𝑉𝑃 = 2 𝑥 2 𝑥 1.25 = 5𝑉 This voltage is high enough to be used in the MAX1555 adapter while leaving some leeway in case of any fluctuations.

18

Figure 11: Resonant Inductive Coupling Circuit and Cockcroft-Walton Generator

3.0: Hub Block Design

3.1: Bluetooth Module

Because of the difficulties involved in the design of PCBs and circuits associated with Bluetooth technology, we found that it would be fairly time consuming to design and test a circuit associated with complete Bluetooth operation. We were also interfacing with an iPhone for the mobile app and felt it would be safer to use a prepackaged Bluetooth module to eliminate the possibility that our circuit wasn’t designed exactly to IEEE specifications. As a result, the Bluetooth module contains many of the RF, analog, and regulation circuitry that is needed for operation. The module we have used is a KEDSUM generic Bluetooth interface device with four-pin interface. The module uses the serial protocol to talk with the microcontroller and operates with a 3.6-6 V supply meaning that our 4.5V input supply will be adequate.

3.2: Microcontroller

Much like the attachment, we are using an Atmel ATMega328p for the microcontroller IC on the hub device to reduce the number of different components we would need to purchase. The standalone microcontroller requires a similar circuit as in the attachment. It needs a stabilized power supply of 3.3V which we regulate with the power circuitry on the PCB. The reset pin is active low and designed with a pull-up voltage resistor of 10 kΩ and button so that the activation of the button causes the pin to go low and the microcontroller to reset. The oscillator system uses an 8 MHz crystal with the two 22 pF shorted capacitors. The only pins

19

needed on the microcontroller are for the Bluetooth hub itself as BT_TX and BT_RX for serial communication.

Figure 14: Hub microcontroller circuit

3.3: RF System

The RF system on the hub is the exact same as the one in the attachment to ensure all RF devices are operating together. Refer to Figure 9 for the schematic of the system.

20

3.4: Power Supply

The power supply and voltage system is similar to the attachment. Because we have no lithium battery to charge there is no need for the MAX1555 IC to regulate charging from an external voltage source. Also because this is a simple hub that needs to be powered for a long time the power input is 3 AA batteries operating at 4.5V total. The 4.5V can be input directly to the Bluetooth module for device power but needs to be stepped down from 4.5V to the 3.3V for the rest of the circuit components. As a result the only component in the power supply is the TPS63031 IC with a similar as the attachment’s power supply.

Figure 15: Hub microcontroller circuit

4.0: Mobile App Design

The last portion of our project is our mobile app, which will be used to visually track how full the cups are full of liquid. The phone will be the central device, and will constantly be looking for packets to be sent from the peripheral (hub). Most of the design will go into understanding how the central device is set up. Figure 1 below is a simple representation of how our hub (peripheral device) sends advertising packets to the phone (central device) in order to be discovered.

21

Figure 16: Central Bluetooth device discovering peripheral

The phone will be represented by a CBCentralManager object, and the hub will be

represented by a CBPeripheral object. As we are using a remote peripheral, when sending

packets of data the peripheral will send CBService objects that includes multiple

CBCharacteristcs. Once the CBCentralManager object is set up, it will be able to scan for peripherals, and will be able to connect with the hub. A detailed workflow of how the phone will read the packets from the hub is discussed below step-by-step:

1. Start up Central Manager Object 2. Discover the hub

a. Call the scanForPeripheralsWithServices:options: method from CBCentralManager class

b. Once the peripheral device is found, stop scanning for other devices to save power

3. Connect to the hub after discovery a. request connection to the peripheral by calling the connectPeripheral:options:

method of the CBCentralManager class 4. Discover the Data being sent by the hub

a. When the specific data (services) are discovered, implement each service as a CBService object

5. Discover the Specifics of the Data packet a. Each service being sent by the hub will include several characteristics that

define the data enclosed by a data packet 6. Retrieving the data

a. After the phone has found the weight characteristic of the service, use readValueForCharacteristic method of the CBPeripheral class

7. Display Data

The hub will be sending data packets with the weight as well as device ID, so all the phone has to do is reach each characteristic and associate the proper weight with the proper device ID. At this stage, we are ready to do simple data analysis to let the app user view each cup

22

with an accurate representation of how full the cup is, and also show the user a graph that shows the level of fullness of that cup over time. Figure 17 is a simple flowchart showing the UI layout.

Figure 17: UI design flowchart

5.0: Power Analysis

5.1: Battery and Buck-Boost Converter

Battery Nominal Voltage

Nominal Capacity

Power Capacity (Wh)

Polymer Lithium Ion Battery

3.7V 400mAh 3.7V x 400mAh = 1.48Wh

This battery will be connected to the TPS63031 buck-boost converter. Since the desired

voltage of our components is 3.3V, the converter will be acting in Step-Down Mode. According to the datasheet, this leads to an output current at around 800mA with a 3.7V input voltage

23

Figure 18: Maximum Output Current vs. Input Voltage TPS63031

5.2: Cup Attachment Current Drain

Component Current (Receiving) Current (Transmitting)

Microcontroller (ATmega328P-PU) 5.2mA 5.2mA

Load Cell (Generic Uxcell 5kg) 3.3mA 3.3mA

Accelerometer (AXL335) 362.5uA 362.5uA

Battery Charging Adapter (MAX1555) 1.75mA 1.75mA

Amplifier (INA122UA) 60uA 60uA

Transceiver (CC1000) 9.6mA 25mA

Total 20.27mA 35.67mA

Since the cup attachment is the only part of the project reliant on the battery and buck-boost converter, the hub is not included. The current draw from the load cell was calculated based on its resistance and input voltage.

3.3𝑉1000Ω

= 3.3𝑚𝐴

The current draws of the other components were obtained from their respective datasheets. The average current draw is based on the usage of the cup. The transceiver will be transmitting roughly 30% of the time.

𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝐿𝑜𝑎𝑑 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 = .7(20.27𝑚𝐴) + .3(35.67𝑚𝐴) = 24.89𝑚𝐴

5.3: Charging and Discharging Time

The battery has a standard discharge of 0.2C meaning that it is rated for a 5 hour life. Since we will be using a load current that is lower than 80mA (400mA x 0.2 = 80mA), the life of the battery should be more than five hours.

𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝐿𝑖𝑓𝑒 = 𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦𝐿𝑜𝑎𝑑 𝐶𝑢𝑟𝑟𝑒𝑛𝑡

𝑥 .7 = 400𝑚𝐴ℎ24.89𝑚𝐴

𝑥 .7 = 11.25 𝐻𝑜𝑢𝑟𝑠

24

The 0.7 factor accounts for external factors that will negatively impact battery life. Realistically the actual battery life is somewhere in between these two values and requires physical testing. Our choice of a 400mAh capacity battery satisfies the battery life requirement of six hours that we set to simulate a rush hour period. The estimated battery life exceeds the requirement to account for situations where the attachment is only partially charged before being put back into use. Also, the small profile of the battery fits the slim dimensions of the cup attachment.

The battery will be charged by the MAX1555 charge regulator IC which is connected to the generator and resonant transformer circuit. The MAX1555 has a charging current set at 280mA. The datasheet of the battery lists a 4.5 hour charge time with a 200mA charge current and a 3 hour charge time with a 400mA charge current. This means that a 280mA charging current roughly corresponds to a 3.6 hour charge time

6.0: RF Communication Protocol

The attachment and hub communicate through a NRZ-encoded data stream but since this is a complete custom system there is no ideal communication protocol implemented for the actual RF communication. We considered some sort of wireless SPI or 1-wire protocol but settled on a custom implementation of the serial transmission protocol. Our data is concatenated into a 3-byte packet that is transmitted serially through RF to the hub. The hub performs some error detection/correction and repackaging into the Bluetooth serial encoding for transmission over Bluetooth to the mobile phone. Byte 1

1 ID DS[2] DS[1] DS[0] BAT[2] BAT[1] BAT[0] Start bit Device

ID Device Status Battery Status

7 Bit Position in Byte 0

Byte 1 is the first byte of the data transmission and contains identification and diagnostic information of the attachment device.

Position 7 holds the start bit of the data packet, always a 1. Without any data sent on the RF signal, the CC1000 treats any signal as a 0. Anytime the digital stream between devices switches to a 1 the hub begins recording the next 23 bits of data as a packet of information.

25

Position 6 holds the device ID. For our simple system of two devices, there are two possible encodings of 1 or 0. In a realistic system the device ID field size can be expanded to any size to fill the NC bits in Byte 2, corresponding to 2DS devices. Positions 5 to 3 correspond to the device status bits which alert the app to any problems in device functionality. 3 bits translate to 3 possible error codes (the default encoding of 000 means no errors at all). The error codes are summarized in the following list:

Error Code Status Problem Explanation 000 Normal No errors, good operation 001 UC Diag. Error Microcontroller diagnostic error,

alert the user to run a diagnostic test for this device and check for issues in the microcontroller software.

010 No Sense Sensor data isn’t being processed by microcontroller, a possible software problem or a hardware fault of sensor devices.

100 Batt issue Battery approaching critical level of 3.3V despite charging indication being on or charging above the recommended 3.9V safety rating.

Positions 2 to 0 indicate the battery level as a 3-bit value that maps a voltage range of

3.7V to 3.3V to 8 bits. This allows the user and app to monitor the battery life of the device and eliminate the need for an always-on battery sensor in the attachment. Byte 2

W[3] W[2] W[1] W[0] 1 1 1 1 Weight NC NC NC NC

7 Bit Position in Byte 0 Byte 2 contains the transmitted data from our attachment consisting of data from the sensors interpreted into weight. Positions 7 to 4 store the recorded weight of the attachment as a mapped 64-to-16 bit value depicting an input range of 0.1 to 3 kg of weight. The data from the accelerometer is processed by the onboard microcontroller and not needed by the hub or mobile app.

26

Positions 4 to 0 are unused bits padding the weight value. In the future with more devices and development these bits can be used by existing fields which need to grow in size or used by any additional diagnostic information from the attachment. Byte 3 ECV[2] ECV[1] ECV[0] ECH[3] ECH[2] ECH[1] ECH[0] XZB ECC Vertical XOR ECC Horizontal XOR XZBit 7 Bit Position in Byte 0 Byte 3 is additional information related to error detection and correction of the transmitted signal. Ideally the data transmission should be error-free, but noise and distance impact the performance and reliability of data received from the microcontroller. This byte contains check bits against which computed data is compared to see if an error has been generated. The algorithm detailed below is a two-dimensional redundancy checksum implementing single-error detection and correction. The generation algorithm for the codeword that makes up Byte 3 is implemented as a 3-bit wide by 4-bit tall matrix 𝐺[𝑥][𝑦] where 𝑥 represents a horizontal position and 𝑦 a vertical position. The matrix is designed so that 𝐺[0][0] is in the bottom right corner and 𝐺[2][3] in the upper left corner. Each position refers to a specific position of the subfields within Byte 1 and Byte 2 detailed below:

B1[7] B1[6] B1[5] ECH[3]

B1[4] B1[3] B1[2] ECH[2]

B1[1] B1[0] B2[7] ECH[1]

B2[6] B2[5] B2[4] ECH[0]

ECV[2] ECV[1] ECV[0] XZB

Rows in the matrix maintain even parity while columns maintain odd parity. The vertical

check bits are added such that the vertical columns maintain odd parity with the data, while the

27

even check bits are added such that rows maintain even parity. Generate an ECV, ECH, or XZB bit value such that the following equations are satisfied.

B1[7] ⨁ B1[4] ⨁ B1[1] ⨁ B2[6] ⨁ ECV[2] = 0 B1[6] ⨁ B1[3] ⨁ B1[0] ⨁ B2[5] ⨁ ECV[1] = 0 B1[5] ⨁ B1[2] ⨁ B2[7] ⨁ B2[4] ⨁ ECV[0] = 0

ECH[3] ⨁ ECH[2] ⨁ ECH[1] ⨁ ECH[0] ⨁ XZB = 0

B1[7] ⨁ B1[6] ⨁ B1[5] ⨁ ECH[3] = 1 B1[4] ⨁ B1[3] ⨁ B1[2] ⨁ ECH[2] = 1 B1[1] ⨁ B1[0] ⨁ B2[7] ⨁ ECH[1] = 1 B2[6] ⨁ B2[5] ⨁ B2[4] ⨁ ECH[0] = 1 ECV[2] ⨁ ECV[1] ⨁ ECV[0] ⨁ XZB = 1

After the ECV and ECH bits have been calculated they are encoded as Byte 3 and sent with the other two bytes as a packet from the attachment to the hub. After the data has been demodulated and decoded in the hub’s microcontroller the same redundancy check algorithm is applied to generate another set of ECV, ECH, and XZB values encoded internally as a Generated Byte 3 (GB3). With no errors, GB3 should match B3 and the data can be sent for Bluetooth encoding. If GB3 doesn’t match B3 due to an error XZB will be always wrong and at least 1 ECV and 1 ECH value will be wrong. The matrix entry corresponding to the row and column of the wrong ECV and ECH value will give the bit causing the error. Inversion of the bit will fix the data. In the transmission example below GB3 and B3 do not match due to an error in ECV[1] and ECH[2] meaning that the bit in 𝐺[1][2] needs to be inverted to fix the error.

B3 GB3 Error?

1 0 1 0 0 No

1 1 0 1 0 Yes

0 1 0 1 1 No

1 1 1 1 1 No

0 1 1 1 B3

0 0 1 0 GB3

No Yes No Error?

28

Since this algorithm only detects and corrects single bit errors, if multiple bits errors are detected then the packet is deemed faulty and discarded. Because our system will make a measurement upon regular intervals of 10 seconds discarding a packet is not a problem.

7.0: Expected Device Operation

The attachment device performs most of the physical operation of the system, the hub acts as a translator between our custom data protocol and the Bluetooth standard, and the mobile app performs the data computation and “human interface.” For this reason, the focus of hardware design for operation is the attachment. The entire attachment device operation is described by the walkthrough list below.

1. After device power-on the TPS63031 and MAX1555 Ics maintain a 3.3V supply from the 3.7 V of the lithium battery or the 5 V of the charging circuit. This boots the microcontroller, starts the RF transceiver, and provides power to all other devices on the board.

2. The microcontroller then configures the transceiver to specific operating modes. Through the 3-wire interface of PCLK, PDATA, and PALE the microcontroller programs in baud rate and frequency spectrum with a series of memory-mapped register accesses. It runs two diagnostic tests (described in the datasheet) to verify IC operation. It finishes by sending an interrupt request to put the system into a receive state.

3. Once finished with the transceiver setup process the microcontroller continually samples values from the accelerometer and the weight sensor. For the first sample, it checks if the accelerometer reading is below the threshold of 1G, at which point it encodes the weight and other device information into the three-byte RF packet.

4. The microcontroller sends an interrupt signal to the transceiver to switch to transmit mode. It sends configuration information to set frequency specifics and data encoding information. The data is then sent to the transceiver and the microcontroller waits for RSSI to go stable again indicating that all data has been transferred.

5. Process steps 3 and 4 will repeat once every 10 seconds following an internal microcontroller loop ensuring that 1 packet of data has been transmitted once every 10 seconds. In the case of an accelerometer movement greater than 1G, we make the assumption that the cup and attachment has been lifted for the user to take a sip. If at any

29

point the accelerometer reading goes above 1G all data from the weight sensor is discarded and the microcontroller waits for a 0 ± 0.01G reading from the accelerometer. When the reading is detected, indicating that the cup has been put back down, the weight sensor is sampled and data sent to the transceiver as per steps 3 and 4. The accelerometer is an asynchronous interrupt within the default 10 second transmit regime so the acceleration always gets highest priority as a deciding condition whether or nor data will be sent across the system.

The transmit and receive operation of the transceiver with the accelerometer is

represented as the state diagram below. The microcontroller operates after boot in the three shaded states. Any change in the values from the accelerometer or the internal counter causes a transition to another state, with the counter being a regulated loop and the accelerometer an asynchronous interrupt. In each state data is encoded into a packet ready for transfer to the transceiver with the exception of the “Accelerometer Input Detected” state where the data is erroneous and the packet deleted.

Figure 19: Attachment dataflow diagram

The operation of the hub is extremely simple. Because the hub only has to perform the process of encoding an RF input to a Bluetooth output, the microcontroller performs the

30

conversion and insertion of the data packet into a steady Bluetooth signal. A walkthrough procedure is detailed for the hub below:

1. Upon power-on of the hub the microcontroller, transceiver, and Bluetooth module boot. The Bluetooth module takes longer to finish compared to the microcontroller so the microcontroller idles until the Bluetooth module has finished.

2. The microcontroller then configures the transceiver to specific operating modes. Through the 3-wire interface of PCLK, PDATA, and PALE the microcontroller programs in baud rate and frequency spectrum with a series of memory-mapped register accesses. It runs two diagnostic tests (described in the datasheet) to verify IC operation. It finishes by sending an interrupt request to put the system into a receive state. The hub’s transceiver never transmits data to the attachment so transmit mode is never enabled.

3. The Bluetooth module operates on a serial bus so when a packet is received by the microcontroller from the transceiver it can be directly sent to the Bluetooth module through a serial() command.

8.0: Requirements and Verification

The table below lists major requirements that our devices should pass. After all chips and components have been soldered to the PCBs each requirement is completed with testing and debugging. Most of the requirements are adjustable in software sent to the microcontroller because the functionality of external components in the attachment is done by complete ICs, but some components like the transceiver need to be tested physically to verify correct operation to FCC standards and check for matching network errors. System Component Major Requirements Points Attachment Microcontroller 1. Microcontroller can boot and run a simple

Arduino test program (4) 2. Microcontroller can receive data from sensors.

(2) 3. Microcontroller can encode the incoming data

from sensors and generate the parity Byte 3. (4)

10

Attachment Transceiver 1. Transceiver successfully boots. (7) 15

31

2. Transceiver’s RSSI output indicates it can transmit and receive data. (5)

3. Data can be transmitted to the transceiver. (3) Hub Transceiver 1. Transceiver successfully boots. (3)

2. Transceiver’s RSSI output indicates it can transmit and receive data. (1)

3. Data can be received from the transceiver. (1)

5

Hub Microcontroller 1. Microcontroller can boot and run a simple Arduino test program (2)

2. It can perform error correction on the received data according to the checksum algorithm. (1)

3. It can send data with Serial() command with no errors (1)

4. Bluetooth module sends and receives data to/from microcontroller (1)

5

Mobile App 1. App compiles with no errors and runs on any stable iOS version (5)

2. App can access Bluetooth API (5) 3. App can read data from the attachment (5)

15

Total: 50

8.1: Verification Steps for Attachment

Component Requirement Verification Plan

Antenna network 1. Antenna network transmits

at a peak of 315 ± 10 MHz.

2. Antenna network input

return loss is less than -15 ± 5 dB.

3. Peak value of external

noise is 14.5 ± 5 dB below peak power value.

1. Connect a 3.3V power supply to the RF subsystem, particularly the CC1000 chip.

a. Connect a 3.5mm coaxial antenna to a spectrum analyzer.

b. Probe RF_IN and RF_OUT traces of CC1000 IC on board.

c. Calibrate the spectrum analyzer using the Agilent SOLT calibration kit.

d. Program the ATMega32 to run a UART test via the SoftwareSerial library. It should send 8 packets of x3F24 to the CC1000 chip.

32

e. Look for a peak at 315 MHz on the spectrum analyzer. If a peak is detected at this frequency within the tolerance specified in Component Requirement 1 the antenna is transmitting properly.

2. Use the marker tools to center the peak and measure the power.

a. Check on the spectrum analyzer that the received antenna power is higher than -35 dBm.

3. Connect an Agilent noise source to the noise port of the spectrum analyzer

a. Calibrate the noise source with the following values: 5 Hz spurious noise, 300 MHz start frequency, 330 MHz stop frequency, -25 dBm power threshold, -15 dBm peak power threshold, no hold.

b. Capture the noise spectrum on the spectrum analyzer and plot with the antenna spectrum.

c. Using the marker compare value tool check that the resulting delta value is less than -14.5 dBm.

RF network 1. Transceiver successfully

boots and runs diagnostic tests.

2. Transceiver’s RSSI output pin voltage is less than 0.5 ± 0.1 V indicating it can transmit data.

3. Transceiver can transmit an empty byte sequence xFF00FF from the microcontroller.

1. Run an Arduino terminal on a computer to which the microcontroller is connected through an FTDI USB bridge. Configure the terminal so that it samples any data at pin 12 of the microcontroller (DIO).

a. Upon power on confirm that the terminal prints out the diagnostic codes found in the datasheet. The first code should start with x22 and end with xA092.

b. Transmit the configuration information generated by the SmartRF software from TI for the CC1000.

c. Confirm that the terminal now prints out a random value that doesn’t fluctuate. This is a default polling state that waits for any interrupt.

d. Through the terminal send three packets of xA001 to the microcontroller and check that the returned value from the pin is x3E. This indicates the CC1000 has been properly booted and configured.

33

2. Probe the RSSI pin of the CC1000 with a multimeter.

a. Send the interrupt vector xAE00 to the CC1000 to put the chip into the RSSI transmit mode.

b. Confirm with the multimeter that the voltage on the pad is less than 0.5 ± 0.1 V

c. If the voltage is greater than 1.3 ± 0.1 V the CC1000’s baud rate has been incorrectly set. Reset the chip and retry all of Verification step 1 to reconfigure the chip.

3. Send these bytes from the microcontroller to the CC1000: xEE 00 15 4A C7 19 0B BA FF

a. Probe the RSSI pin of the CC1000 with a multimeter.

b. If the input data is being properly encoded into NRZ, modulated, and sent to the antenna, the RSSI pin voltage will increase to 2.5 ± 0.1 V for 1 packet of data sent before returning to the threshold of 0.1 ± 0.01 V.

c. Retry steps a to b with this new sequence of bytes from the microcontroller to the CC1000: xEE FF 29 EC EA 01 00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF AE 19 EC EA.

Attachment Sensors 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 within 5 degrees.

6. Accelerometer functions from 3V ≤ Vin ≤ 4V.

7. Battery life lasts at least 6 hours.

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.

34

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.

Wireless Charging Circuit 1. Output voltage after the

Cockcroft-Walton Generator should be between 4V to 6V.

2. Both coils are resonating

at the same frequency which will be 80kHz ± 10 kHz.

1. Use a multimeter to probe the Vout of the wireless charging circuit using the DC settings.

2. Attach the function generator probes in parallel

with the LC circuit. a. Attach oscilloscope probes also in parallel. b. Sweep the frequency near 80kHz and

examine the voltage waveform. c. Stop the frequency sweep when the voltage

waveform amplitude is at its maximum. d. Compare the frequency being used with the

requirement of 80kHz ± 10 kHz. e. Confirm that this resonant frequency is the

same in the other coil by repeating the process.

35

8.2: Verification Steps for Hub Bluetooth module

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.

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

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

c. Using the Arduino place the SoC into diagnostic validation mode by sending three byte transfers of x48AE02CC with a x0F between each one.

d. The calculated CRC for xFEBCA987654321 is x10BD3BC2. Perform step 1, and then send xAE188000. Check that the CRC received at Rx is x10BD3BC2 .

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

36

moved away from the network analyzer’s antenna.

8.3: Verification Steps for Mobile App Phone App

1. Phone UI changes corresponds to the correct weight information.

2. Multiple attachment weight information is handled correctly.

1. Write a BIST in software as per iOS architecture specifications. Simulate in XCode all APIs and UI/UX tweaks. Simulate in XCode the Bluetooth connection to the hub. Check XCode systems menu to see that phone app compiled correctly.

Perform basic tests. a. New device added: should show a new

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

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.

9.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 ± 5 MHz, the interference from other

37

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 have designed our device so that the transmitter modules operate with a Q factor of 0.95 so that noise from other sources won’t “bleed” into our available bandwidth. If our Q factor was less than the CC1000’s threshold of 0.5 our original wave energy would be 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 was above 1.5 our circuit would produce 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. The Q-factor controls how much noise we could tolerate in our system before the signal-to-noise ratio becomes large enough for packet loss. Determining this SNR requires physical testing.

Using an estimate of 55 devices in an average restaurant, and that each device would produce a maximum of 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 as much of the 216 dBm of noise across the 10 MHz bandwidth of our device as possible.

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 incident RF power of the antenna is set to -40 dBm to test that the devices can communicate with no interference. We then slowly raise the noise power of the antenna in steps of 2.5 dBm, visually seen as random peaks within our allocated bandwidth. The main peak magnitude will vary by ±0.1 dBm 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 hub will transmit an error code to the mobile device corresponding to packet loss. This

38

value of the power that the RF generator supplies is the maximal threshold of device operation without any interference.

10.0: Safety Statement

Our cup attachment system will be handled directly by its users so it is extremely important that it is safely designed. This is crucial in both the prototype/experimentation phase and actual restaurant usage. Before doing any work in the lab, members will have to complete the safety trainings posted online. Here are the safety rules we will follow in our design process.

● When soldering components, stay in a well ventilated area to minimize inhaling vapors ● Familiarize yourself with your environment to locate nearby water sources in case of self

burns when soldering ● Cover exposed skin when soldering in case of spattering ● Keep battery voltage below maximum listed voltage (4.2V) [2] ● Battery current draw should not be greater than 1C ● Do not charge battery at more than the recommended rate (1C) ● Do not bend or puncture the battery ● Visually inspect the battery for any issues prior to each use when testing ● Keep the battery within the listed temperature range (-5 to 35°C) ● Do not use a NiMH/NiCad/lead-acid charger ● Do not let the battery get in contact with any liquids

While the components will be housed in a waterproof and completely sealed container, it

may be possible that it breaks open if severely damaged. Avoid touching the circuitry and dispose of the components properly. If liquid comes in contact with the attachment, the waterproof container should prevent any liquid from reaching the inner circuitry. Always inspect the attachment for any fractures that could lead to device failure before any use.

11.0: Parts and Costs

11.1: Cost Analysis 11.1.1: Labor

39

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

Total 690 $51,750 11.2: Component Costs

Part Name Quantity Cost Purchased?

Weight Sensor (Uxcell 5kg) 2 $15 Yes

Accelerometer Chip (ADXL335) 2 $20 Yes

Microcontroller (ATmega328P-PU) 3 $10 Yes

Charging Coil (22 AWG) 2 $5 No

Transceiver (CC1000) 3 $25 Yes

Waterproof Attachment Case 2 $20 No

Polymer Lithium Ion Battery (400mAh)

2 $14 Yes

KEDSUM Bluetooth Transceiver 1 $10 Yes

Amplifier (INA122UA) 2 $0 (Samples)

Yes

Battery Charging Adapter (MAX1555) 2 $4 Yes

Voltage Regulator (TPS63031) 3 $0 (Samples)

Yes

100 nF Capacitor 2 $0.2 Yes

2.2 uF Capacitor 4 $0.45 Yes

Schottky Diode (BAS40) 4 $0.1 No

40

1 uF Capacitor 5 $0.6 Yes

10 uF Capacitor 2 $0.2 No

1.5 uH Inductor 1 $0.18 Yes

22 pF Capacitor 4 $0.65 Yes

8 MHz Crystal Oscillator 2 $0.55 Yes

10 kΩ Resistor 3 $0.35 Yes

65 nH Inductor 2 $0.75 No

10.6 pF Capacitor 2 $1.5 No

56 nH Inductor 2 $0.75 No

82 kΩ Resistor 2 $0.25 No

1 nF Capacitor 2 $0.50 No

27 kΩ Resistor 2 $0.75 No

18 pF Capacitor 4 $1.00 Yes

14.7456 MHz Crystal Oscillator 2 $1.80 Yes

12.8 pF Capacitor 2 $1.25 Yes

20 nH Inductor 2 $0.75 Yes

Total $136

11.3: Total Costs

Labor Cost Parts Cost Total Cost

$51,750 $136 $51,886

41

12.0: Schedule and Division of Responsibilities

Week Task Responsibility

15-Feb

Work on Mock Design review Harington Lee

Work on Mock Design review Arjun Sharma

Work on Mock Design review Chirag Patil

22-Feb

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

29-Feb

Purchase parts Harington Lee

Research power requirements for each component Arjun Sharma

Test parts for accuracy and communication ranges Chirag Patil

7-Mar

Integrate sensors with microcontroller and transmitter Harington Lee

Develop UI for mobile application Arjun Sharma

Program the attachment microcontroller to interface with hub Chirag Patil

14-Mar

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

21-Mar

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

28-Mar

Integrate wireless charging coil and battery Harington Lee

Check for data errors from the attachment to the hub to the app Arjun Sharma

42

Debug charging components and test for battery life in different usage conditions

Chirag Patil

4-Apr

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

11-Apr

Assemble second cup attachment Harington Lee

Debug hub to mobile application communication Arjun Sharma

Debug attachment to hub data transfer Chirag Patil

18-Apr

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

25-Apr

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

13.0: IEEE Ethics

Our project complies with the IEEE code of ethics in all aspects. One of the key components is “to accept responsibility in making decisions consistent with the safety, health, and welfare of the public, and to disclose promptly factors that might endanger the public or the environment”. As discussed in the safety section, there are inherent risks when there are liquids in close proximity to electrical components. The dangers are listed out and will be made available to any user.

43

The cup attachment system that we are designing uses multiple sensors and communication systems that have a unique application. One of the codes in the IEE code of ethics is “to improve the understanding of technology; its appropriate application, and potential consequences. We believe that this application is a natural use for the type of technologies that we are incorporating. The consequences of developing this project are beneficial to both the user (restaurant patrons) and supplier (restaurant staff).

The design of the project has both electrical and software components. Our team consists of two electrical engineers and a computer engineer. Our knowledge combined with our TA’s experience is sufficient for our project’s development and design. This is addressed by IEEE’s statement that engineers should “maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations”. The design review process and weekly TA meetings ensure that we have the technical competence to complete the selected project.

44

Citations

[1] Texas Instruments, “Single Chip Very Low Power RF Transceiver.” [Online]. Available at: http://www.ti.com/lit/ds/symlink/cc1000.pdf. [Accessed: 18-Feb-2016]. [2] Shenzhen PKCELL Battery Co., “Li-Polymer Battery Technology Specification,” Li-Polymer Battery Technology Specification . [Online]. Available at: https://www.adafruit.com/images/product-files/1578/c1854 pkcell datasheet li-polymer 503035 500mah 3.7v with pcm.pdf. [Accessed: 18-Feb-2016]. [3] Analog Devices, “ADXL335.” [Online]. Available at: http://www.analog.com/media/en/technical-documentation/data-sheets/adxl335.pdf. [Accessed: 18-Feb-2016]. [4] Great Power, “http://cdn.sparkfun.com/datasheets/Prototyping/PRT-10718 GSP652535.pdf,” Product Specification, 30-Sep-2011. [Online]. Available at: http://cdn.sparkfun.com/datasheets/prototyping/prt-10718 gsp652535.pdf. [Accessed: 01-Mar-2016]. [5] Blaze Labs Research, “Cockcroft Walton Multiplier,” Blaze Labs. [Online]. Available at: http://blazelabs.com/e-exp15.asp. [Accessed: 01-Mar-2016]. [6] Alexander Hiam, “Power management with LiPoly batteries,” Gray Cat Labs, 15-Jun-2012. [Online]. Available at: https://graycat.io/tutorials/power-management-with-lipoly-batteries/. [Accessed: 01-Mar-2016].