TEAM 3: Rememberall
Spring 2008

MEMBERS

Jason Knichel
Boris Lipchin
Kartik Subramanian
Mike Phillips

PROJECT CONCEPT

We propose a mobile device that will remind you of appointments and other events. As an event approaches, a tricolor LED will change gradient and will eventually blink at different frequencies to attract user attention. The event list will be synchronized with a computer via bluetooth. The device can be adapted to other functionality such as displaying weather, stock prices and bus schedules.

MOTIVATION

Many of the calendar and appointment reminder apparatus in use today are either immobile (desktop systems) or are expensive mobile systems (cell phones, PDAs, laptops etc.). We see a need for a cheap, yet trendy and effective systems to remind people of appointments/imminent events in a clear, discrete and unobtrusive manner. Our product should be cheap, robust and mass producible.

COMPETITIVE ANALYSIS

IPhone, Blackberry, other smart phones - these products are not cheap and are targeted to a different different market segment than the one we are targeting. We are looking for the low end market, kids and teens market, etc.
Laptop - A person could turn on their laptop and check their schedule but laptops are not portable to the level we are trying to achieve.
PDA, PocketPC - these are, again, expensive and a totally different price point.
Ambient Stock Orb - This is an orb that by default will glow different colors based off how the stock market is doing. You can go online and change what plugin you want the stock orb to show (e.g. make it display different colors based off the weather outside). It is too large to fit into your pocket easily and requires an external power supply and an external antenna.
Weather Beacon - This glows a different color based off the weather outside. It isn't portable.

TECHNICAL SPECIFICATIONS

The product will include a primary controller, a bluetooth controller, LED and UI subsystem and the power subsystem. Persistent storage will be accessible by all the subsystems and will help isolate the stateful segments of all the subsystems. We will strive to make the other subsystems as stateless as possible.

Primary controller The LED subsystem Bluetooth controller AVRISP Programmer


A picture of our current hardware:


See more pictures

PRIMARY REQUIREMENTS

  • Define a schedule as a sequence of events tuned to a particular time granularity. Each event must represent a time at which it occurs and a color associated with that time.
  • The device must allow the user to turn it on, and turn it off on demand
  • When on, the device must alert the user to any upcoming events in its schedule. It should do this by 'appropriately' displaying colors that correspond to and are relevant to the color associated to that particular event.
  • When on, the device must maintain the current time (modulo clock drift), and the last synchronized schedule.
  • When off, the device must not consume any power, and may not maintain any previous state. Schedule information may not persist.
  • When on, the schedule on the device must be configurable. Individual events, time granularity and event colors must be configurable by the user.
  • The method of update must be carried on a major wireless protocol that requires minimal hardware and software support on the user side.
  • The method of update must be accepted as long as the update conforms to the RCF (Rememberall Communications Format) API.
  • The device must warn the user when it is running out of power and is about the lose its schedule.
  • The device must represent no imminent harm to the user (Lithium ion batteries explosion - KABABOOM).
  • The amortized synchronization time must be on the order of 5 seconds.
  • The device must work, using a standard battery, under nominal loads, for at least 2 days.
  • The task of deciphering the LEDs must not present cognitive overload.
  • The device must be mobile and light

    • SECONDARY REQUIREMENTS

  • The device can present an alternate method to alert the user of impending events.
  • The device can go into a sleep mode to conserve battery power.

    • ARCHITECTURE

    Conceptual Architecture:

    USE CASES (INTERACTION DIAGRAMS)

    Interaction between user and device

    Interaction between device and database (computer) Interaction with third-party products Environmental conditions Faults in the device Recovery of device Conditions that might result in missed deadlines

    SYSTEM STATES & TRANSITIONS

    RISKS & MITIGATION STRATEGIES

    ERROR HANDLING

    IMPLEMENTATION DETAILS

    TEST CASES

    EXPERIMENTAL EVALUATION/METRICS


    The data for these graphs was taken using a laptop with a 1.8 Ghz processor and 768 MB of RAM. It was on a wired connection in Morewood Gardens. An automated process started our application and told it to download a provided schedule from an AFS web location. There are a total of 21 different size schedules. 20 trials were done for each schedule file. The amount of time to perform the schedule update was timed using Java's System.currentTimeMillis(). Each event in the calendars were created in Google calendar using the string "meeting with priya at CIC Building". They were created at random times on random days in June and July and for random durations. From the first graph you can see that the amount of time taken to download the schedule and update the display grows linearly with the number of components in the schedule. From the second graph you can see that the amount of time taken to download the schedule and update the display grows linearly with the size of the schedule. View csv file here

    LESSONS LEARNED

    FUN STUFF

    To be completed.

    REFERENCES

    You can view the most up to date information about our project at our wiki

    Back to the top of this page
    18-549 course home page