Description

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, and similar 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.
smartPhones.jpg
  • Laptop — these are not portable to the level we are trying to achieve.
laptop.gif
  • PDA, PocketPC — these are, again, expensive and a totally different price point.
palmPilot.jpg
  • 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.
stockorb.gif
  • Weather Beacon — This glows a different color based off the weather outside. It isn't portable.
weatherBeacon.jpg

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

  • AVR ATMega 128 with 6 PWM channels.
    • 128K Bytes of In-System Reprogramming Flash
    • 4K Bytes EEPROM
    • 4K Bytes Static Ram
  • This chip contains an internal real time oscillator to maintain time.
  • TiniAVR board
    • Board Size: 1.0"(W) x 1.3"(L) x 0.6"(H)
    • JTAG connection for flash programming/debugging
    • Costs $59.00

The LED subsystem

  • 2 tricolor LEDs (costs $7.26 each)
  • brightness and blinking will be controlled through the PWM channels on the primary controller.

Bluetooth controller

  • Bluetooth DIP Module - Roving Networks
  • Class 1 power output
  • Bluetooth stack is completely encapsulated
  • Fully configurable UART
  • Includes support for BCSP, DUN, LAN, GAP SDP, RFCOMM, and L2CAP protocols
  • Dimensions: 1.0x0.9"
  • Costs $64.95

Power subsystem

  • Lithium Ion button batteries — 3V and >= 50mAh
  • Ammeter and charge controller circuit.
  • Piezoelectric charger (maybe?) or an inductive charger (maybe?)

AVRISP Programmer

Requirements

  • The device must allow the user to turn it on, sleep it, and turn it off on demand
  • When off, the device must not consume any power
  • When asleep or on, the device must maintain the current time (modulo clock drift), and the last synchronized schedule.
  • When on, the device must alert the user of an impending event. The alert start and end times must be configurable.
  • The device must allow the user to update its calendar when it is on.
  • The method of update must be carried on a major 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, which will be published soon.
  • 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 synchronization must take at most $sync_time milliseconds.
  • The device must work, using a standard battery, under nominal loads, work for at least 2 days.
  • The task of deciphering the LEDs must not present cognitive overload.
  • Laptop side-software will automatically configure pleasantly corresponding colors, providing a few examples.

Architecture

Conceptual Architecture:
conceptualArchitecture.GIF

Use Cases

  • Interaction between user and device
    • Normal
      • User touches capacitive outer shell and the device illuminates tricolor LEDs to display widget information
      • User squeezes shell to click a simple switch to respond to the device reminder of an event (either through sound or vibration), which then stops the reminder
      • User squeezes shell and holds it down for several seconds causing the device to go into sleep mode so that the only thing the device will do is keep track of time (will not display any information, or use Bluetooth), until reawakened by the user clicking and holding the shell again
    • Abnormal
      • The device when low on power or has not been synced with the database (computer) recently enough to display correct information, will blink LEDs with corresponding color to signify the problem
  • Interaction between device and database (computer)
    • Normal
      • Communication over Bluetooth in order to resynchronize the devices internal clock, download new widgets to the device (if the user chooses to), and update the schedules for the widgets currently on the device
    • Abnormal
      • Any kind of communication errors that Bluetooth may entail
  • Interaction with third-party products
    • Our device does not interact with any third-party products except the database (computer)
  • Environmental conditions
    • The pass of time
      • If the device is not touched for several seconds without the capacitive outer shell being touched, it will turn off LEDs to conserve power
      • Every once in a while the device will use Bluetooth to scan for the database (user’s computer) in order to sync
      • The device will check for upcoming events to notify the user with every few seconds
  • Faults in the device
    • If the device has dropped to such a low battery level that it may endanger the Lion battery to remain powered, the device will just turn off completely
    • If the device’s internal schedule is corrupted or has run out of information to display (due to not syncing recently)
  • Recovery of device
    • In the case of running out of power, the device can only be recovered by the user recharging it
    • In the case of corrupted schedule, or running out of information to display, the only way to recover is for the device to be resynchronized with the database (computer)
  • Conditions that might result in missed deadlines
    • If the device is not synced for an extended period of time, the internal clock may drift causing deadlines to be missed

System States and Transitions

fsm.jpg

Risks and Mitigation Strategies

  • Device could be damaged from being in a person's pocket all day and/or being dropped
    • We can make sure that all wire connections are securely made and resistant to some bouncing around and also make sure our outer shell is durable enough to withstand being dropped from a reasonable height (a couple feet maybe?) and durable/scratch resistant since keys, cell phones, pencils, pens, etc might be in the pocket with the device.
  • Device could run out of power
    • We can make sure our electronics draw as little power as possible and pick the right battery such that a user can get at least 24 hours of use out of our object before the battery dies. This would require the user to recharge the device once a day.
  • You could be late to something due to the timer being off due to oscillator drift
    • Our sync software will keep track of how much the device's clock has to be corrected each time the device syncs and the device will adjust itself accordingly to eventually get rid of drift. e.g. the device could figure out that its oscillator drifts 1 second every 10 minutes and thus can add 1/4 of a second every 2.5 minutes or even more fine grained correction than that so the device is always within a reasonable margin of the correct time.

Error Handling

Implementation Details

Quality Assurance (testing, empirical evaluation)

Test Cases

  • Incorrect data transmission
    • This is important to ensure that our device does not corrupt the user’s schedule with garbage values
    • To test this case we will send wrong or incorrectly formatted data over Bluetooth and check that the device’s schedule is not corrupted.
  • Dropped connection
    • It is important to make sure the device acts reasonably when the Bluetooth connection is dropped partway through transmission
    • We will test this by removing the computer’s Bluetooth dongle during a transmission
  • Power up/down
    • It is important to make sure the device acts reasonably when the power is lost and then restored
    • This can be tested by disconnecting the power and then reconnecting it while the device is running.

Experimental Evaluation

  • Power consumption
    • This is important to ensure our device lasts long enough on a charge to be useful
    • We will monitor how much power is consumed over periods of time.
    • We may want to compare power consumption to how often we use Bluetooth to synchronize
  • Bluetooth throughput vs distance between computer and device
    • This is important to determine how much time it will take our device to synchronize with a computer
    • To test this we will time the duration of synchronization at different distances

Lessons Learned

Fun Stuff

References (presentations, etc)

Presentation on Feb 1, 2008

Rememberall-00.ppt

Presentation on Feb 15, 2008

Rememberall-01.ppt

Presentation on Mar 5, 2008

Rememberall-02.pdf

+Old text (Scratch)

The device will also have some way to indicate that its power source is almost empty so you know you have to recharge it soon.

This entire device would be encapsulated in a semi-opaque orb so you cannot see the circuitry. You would only be able to see the colors glowing through the orb. The LEDs would be 180 degrees apart from each other so their glowing interferes as little as possible with each other. The device would also have capacitive sensors so it knows when a person is touching it and some sort of pressure sensor/button you can press. These will be used to reduce power consumption (e.g. it only lights up when something is touching it).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License