TEAM 3: Rememberall
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
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.
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
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.
The LED subsystem
- 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
- 2 tricolor LEDs (costs $7.26 each)
- brightness and blinking will be controlled through the PWM channels on the primary 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
A picture of our current hardware:
See more pictures
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
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
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
The device can present an alternate method to alert the user of
The device can go into a sleep mode to conserve battery power.
USE CASES (INTERACTION DIAGRAMS)
Interaction between user and device
Interaction between device and database (computer)
User flips the on switch and the device illuminates
tricolor LEDs to display widget information
Secondary objective :
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
Secondary objective :
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
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 with third-party products
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
Any kind of communication errors that Bluetooth may entail
Our device does not interact with any third-party products except the database (computer)
Faults in the device
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
Recovery of 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)
Conditions that might result in missed deadlines
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)
If the device is not synced for an extended period of time, the internal clock may drift causing deadlines to be missed
SYSTEM STATES & TRANSITIONS
RISKS & 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
urable/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
Computer software Error States
- GUI sends data to the device and the data gets corrupted
- In the middle of the transmission, the connection is lost
Each time we synchronize, we send the entire schedule from the current point in time
as far into the future as we currently have it set to go, so if this happens, then
the user just has to do another synchronization and it will be fixed.
- The user wants to download a non-existant iCalendar file
The user will be notified with an error message that there was an error downloading
that iCalendar file
- There is no internet connection for the user to use to download an iCalendar file from the web.
- The internet connection dies in the middle of downloading the iCalendar file
- The device wants to initiate a synch and the user has not set what widgets control what LEDs yet
- The user tries to have the same widget control both LEDs
The user will be notified that it cannot have the same widget control both LEDs.
- The user tries to download a file that is a real file, but isn't an iCalendar file
The computer side program was written in Java using the Swing and AWT libraries for the
The program uses the ical4j library for parsing
The bluetooth is written on top of a serial library
called BlueCove. This library only works for Windows and OSX, but works better on windows
The program uses the standard javadoc system for generating documentation. The javadoc for our
system can be found here
The program uses the standard JUnit utility for unit testing.
- 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.
- 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
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
We should have decided on hardware earlier and ordered it earlier.
Setting up Java environments from scratch can be really annoying.
We should make sure to read logic levels of chips before we order them so we realize that we need
another part to switch the 5v output of the processor to the 3v our bluetooth chip wants.
Bluetooth USB dongles and/or the linux operating system will increase the transmission power
if it detects the signal starting to weaken. This makes it difficult to get a signal strength
vs. distance graph.
AVR ISP programmers can break/stop working easily, especially if you are using hacked together connection
The ECE undergrad lounge is a blackhole for wireless signals of any kind.
To be completed.
Project Proposal and Requirements,
Team Project Presentation, February 1, 2008
Design & Architecture,
Team Project Presentation, February 15, 2008
Mid-semester Project Status,
Team Project Presentation, March 5, 2008
Test Plan & Experimental Validation
Team Project Presentation, April 4, 2008
Final Project Presentation
Team Project Presentation, April 30, 2008
May 2, 2008
Javadoc for our system
Video of our product - click here
You can view the most up to date information about our project at
Back to the top of this page
18-549 course home page