The aLife Home System

1. The aLife Home System

2. The aLife Home System • Home automation with a different approach • Market flooded • They all take the same approach: GUI’s that wait for user input • aLife is event driven based on • Temperatures • Security • Energy

3. aLife Example Event

4. Project Goals And Objectives • #1 goal: Embedded Android • Create a smart and customizable system • Little to no learning curve • Focus on active user interface • Easy integration with any home • Integrate with 3rd party devices • Low cost

5. Project Block Diagram ZigBee Base Base Station

6. Remote Module

7. Remote Modules - Communications • Module Communication Network– Wireless ZigBee • More reliable, robust than wired • Flexibility in module installation location • Acceptable data rate (up to 250kbps) • Acceptable transmission range (up to 75m) • Open source, abundance of cheap hardware and software available

8. Remote Modules – Block Diagram

9. Remote Modules – Schematic pg1

10. Remote Modules – Schematic pg2

11. Remote Modules – Schematic pg3

12. Remote Modules – Power Supply • Power Supply Requirement Specifications • 3.3VDC output, <= 20mV peak to peak ripple • Source >= 250mA • Efficiency >= 80% • Work off of both 120VAC and battery • Implementation – National Semi LM2841XMK-ADJL switching buck DC-DC converter • 3.3VDC output, 2mV peak to peak ripple (simulated) • 300mA max • 83% efficiency (simulated)

13. Remote Modules – Power Supply

14. Remote Modules – MCU • MCU Requirement Specifications: • Built in ZigBee transceiver • Available ZigBee Consumer protocol stack • Operate at >= 15MHz • >= 32kB built in FLASH, >= 2kB built in RAM • Features: digital I/O, PWM, ADCs, UART, 12C

15. Remote Modules – MCU • MCU Design Implementation • Freescale MC13213R2 • Built in ZigBee transceiver • 20 MHz • 60kB FLASH, 4kB RAM • 8x ADC, 2x UART, 1x I2C, 5x PWM, 22x GPIO • BeeStack Zigbee 2007 compliant protocol stack • Program firmware in C using CodeWarrior IDE

16. Remote Modules – MCU

17. Remote Modules – Base Comms • Communication with Android Base Requirement Specs • Must use a standard that is compatible with both Android base and remote module hardware • Implementation • RS232 using TI SN65C3221EPWR transceiver • Up to 1M baud rate • 15kV ESD protection • No hardware handshaking

18. Remote Modules – Base Comms

19. Remote Modules – Type 1 Functions • 120VAC Power Sensor Requirement Specifications • Measure up to 1800W (max power rating for a standard wall outlet) • Resolution down to 5W at 3% accuracy • < 10m Ohms AC impedance • >2kV electrical isolation between AC and digital side • Ability to disconnect AC output to save appliance power

20. Remote Modules – Type 1 Functions • Power Sensor Design: • Allegro Micro ACS709LLFTR-20BB-T Hall effect based AC current sensor – exceeds specs • AC peak detector circuit for current sensor output • On Semi MC33072ADR2G instrumentation amplifier • Gain controlled via ADI AD5241BRZ1M 1M Ohm, 256 step digital Pot for power ranging from 3W up to 1700W • Theoretical resolution down to 3W at 2% accuracy (still needs to be tested) • In series software controlled relay

21. Remote Modules – Type 1 Functions

22. Remote Modules – Type 1 Functions • Temperature Sensor Requirement Specs: • Accurate to within +/- 2 degrees Celsius • Range of -30 to +100 degrees Celsius • I2C interface • Remote temperature sensor loop (type 2 function) • Implementation • NXP SA56004ED,118 temperature sensor • Meets the above requirements

23. Remote Modules – Type 1 Functions

24. Remote Modules – Type 2 Functions • Type 2 Requirement specifications: • 2 DAC and digital outputs – Lighting, motor control • 2 ADC inputs – Remote current sensor input • 1 Temperature sensor loop – measure outdoor temp • 1 Software controlled relay – garage door control • Surge and short circuit protection for all I/O

25. Remote Modules – Type 2 Functions • Type 2 Function Implementation • Digital and DACs outputs- PWM fed into low pass op amp circuits using Micron MCP665-E/UN dual op amp chip • Can change from gnd to 3.3V in 3ms • Output can drive +/- 90mA • 2 ADC inputs • Surge protection - 400W TVS, clamp at 7.3V • Short protection - 70mA hold, 130mA trip PTCs • 10A relay

26. Remote Modules – Type 2 Functions

27. Remote Modules – Type 2 Functions

28. Remote Modules – ZigBee Transceiver • ZigBee Transceiver Requirement Specifications • Transmission range of >= 30m • ZigBee 2007 compliant protocol • ZigBee Transceiver Design • Single port antenna design to minimize components • Transmission range still unknown pending antenna development • Will use Freescale’s BeeStack Zigbee 2007 protocol, specifically designed for this MCU

29. Remote Modules – ZigBee Transceiver

30. Remote Modules – PCB • PCB implementation: • We will generate a layout from our schematic in Altium and manufacture our own custom PCBs with the following target specs: • 2-4 layer boards • 3”x3” or smaller outside dimensions • Double sided component placement to minimize board area

31. Base Station Hardware

32. Design decision - Functionality • Need a board to be able to run the android operating system. • Has to be able to handle multiple clients accessing it at the same time (up to 5). • Supports serial communication to interact with the ZigBee devices on the network

33. Design decision - Practicality • It’s a wall mounted unit, so the overall weight should be less than 5 pounds • Should be able to be wall mounted • Needs to be powered off a wall outlet • LCD should be bigger than 2 inches to be considered easy to interact with

34. Processor • i.MX51processor board

35. i.MX51 Specifications • Processor – ARM Cortex A8 • Runs anywhere from 600 MHz – over 1GHz • Meets the minimum android system requirements of 200 MHz • Supports Ethernet Connectivity • Contains multiple interfaces that we needed to interact with our system

36. Picture of Complete System Included in this picture: Processor board LCD Screen Expansion board

37. Communication Scheme • Serial Communication is the main way this board talks to the network • Problem – Android OS doesn’t support communication over serial ports! • After some difficulty implementing serial comm., we decided on using some lower level C code as an intermediary

38. Format for the C code

39. Base Station Software

40. Specifications and Requirements Functional: • Base station must be able to accept up to 5 simultaneous service request on a first come first serve basis • Multiple request to service the same notification must only be serviced once • Must be able to add/remove/update a row in database with 98% reliability Security: • All user must have unique login; Allowed 5 unsuccessful attempts before lockout • Only registered remote client devices may have service request fulfilled by the base station Notifications: • All notifications must have a unique notification ID • Users shall only receive notifications that they are registered to receive

41. Design Approach and Implementation • V-Model • Proven and well structured • Allows for redesign • Android Operation System • Supports notifications • Supports secure socket communication • Database support • Eclipse IDE w/ Android Development Tools (ADT) Plug-in • Free • Best support for Android Development V – Model

42. Design Decision Database Management System (DBMS) SQLite • Needed the use of a database for our software • Had several choices, but implemented SQLite: • Extensive native support provided by Android platform. • Will run on Base Station, no need for additional hardware • No need for purchase server space. • Relatively fast compared to other DBMS

43. Software Block Diagram

44. Software Block Diagram – Background Services Fields: • PowerNotif (Boolean):  Field tells whether a powered device notification is set up • SecurityNotif (Boolean):  Field tells whether a security device notification is set up • ControlNotif (Boolean):  Field tells whether a control device notification is set up • ActiveDevices(Device [ ]):  Array of active devices in the network • RequestedService (String):  String representation of a request Methods: • BaseStation ():Constructor to create the GUI interface for our system. • getActiveDevices():  Takes in no parameters.  Returns all active devices in database. • addDevice(Device X):  Adds specified device to network and database.  No return. • removeDevice(Device X):   Removed specified device from network and database.  No return. • setNotifications():  Takes no parameters.  Sets all initial notifications booleans.  These will dictate which notifications will be checked for continuously throughout the program. • pollDevices(ActiveDevices):   Takes in all active devices and updates their information in the database tables.  Returns nothing. • socketParser (ByteStream):  Takes in a socket byte stream and returns the requested service in string format. • requestService (Device X, RequestService):  This method will take in a device and service request and will fulfill the said service.  Returns nothing.

45. Software Block Diagram – Devices Class Fields: • ID (Int) :  Device's ID • Name (String): Name provided by user for device • Status (Boolean):  Provides status of device, on or off Methods: • getID(): Takes in no parameters.  Returns an Int, the value of the devices ID. • setID(Int ID):  Takes in an Int and updates ID field.  Does not return anything. • getName():  Takes in no parameters.  Returns a String, the value of the devices Name. • setName(String name):  Take in a String and update Name field.  Does not return anything. • getStatus():  Takes in no parameters.  Returns Status of device • setStatus(Boolean Status):  Takes in a boolean and updates Status of device.  Does not return anything.

46. Software Block Diagram – PowerDevice Fields: • TotalWatts (Int):  Provides total watts used by device • SetWatts (Int):  Provides user defined limit for watt usage • CurrentTemp (Int):  Provides current temperature information • SetTemp (Int):  Provides user defined limit for temperature • PollTime (Int):  Time the information was polled • SetTime (Int):  Set time for notification purposes • Timeframe (Int):  Timeframe for power information i.e. 7 days or 30 days Methods: • PowerDevice():  Constructor to create object.  Will have generic and specific constructors. • turnOn():  Takes in no parameters.  Sends message to ZigBee device to turn on • turnOff():  Takes in no parameters.  Sends message to ZigBee device to turn on • getTemp():  Takes no parameters.  Polls ZigBee device for temperature. • setTemp(Int Temp):  Sets ZigBee device with provided temperature.  Does not return anything. • getWatt():  Takes no parameters.  Polls ZigBee device for wattage. • getTimeframe():  Takes in no parameters.  Returns the timeframe field. • setTimeframe(Int Timeframe):  Sets the timeframe field.  Does not return anything.

47. Software Block Diagram – SecurityDevice Fields: • SetTime(Int):  Provides set time for any notifications Methods: • SecurityDevice():  Constructor to create object.  Will have generic and specific constructors. • isOpen():  Takes in no parameters.  Returns true if ZigBeedevice is open. • IsLocked():  Takes in no parameters.  Returns true if ZigBeedevice is locked.

48. Software Block Diagram – ControlDevice Fields: • SetTime(Int):   Set time for notification purposesMethods: • ControlDevice():  Constructor to create object.  Will have generic and specific constructors. • turnOn():  Takes in no parameters.  Sends message to ZigBee device to turn on • turnOff():  Takes in no parameters.  Sends message to ZigBee device to turn on

49. Database Structure The SQLite database will be utilized to store information about current users, devices, power history, notification history, and notification set ups.  Each of these elements will be have their own table in our database with their own specified fields.  

50. Remote Client Device (RCD)