Milestones

Insert pictures of our progress at every milestone

Jan 25, 2008 - 1st design review with Priya

  • Had our basic idea to tell her
  • We decided to scrap the RFID and add plugins that could control the second LED for reasons of cost and of complexity

Feb 1, 2008 - Project Proposal & Requirements

Feedback

Strengths

  • it seems very convenient and personable for the user
  • the portability of the device will be the most appealing aspect
  • "Key chain size" - smaller and lighter than laptop or PDA would be nice
  • Low cost - less expensive to lose than a PDA
  • Eye-candy - glowing colors are cool ;)
  • Innovative user interface.
  • Quickly view information.
  • Extensible, would be nice to add widgets based on user preference
    • we already have this planned
  • Cheap based on description, this will be a big incentive for people to buy
  • innovative, interesting idea
  • simple yet very useful
  • wireless
  • cheap for user (cell phone)
  • idea hasn't really been done before
  • Very simple interface
  • Stylish, so people might like it exactly for the novelty

Weaknesses

  • color based will lose a lot of information
  • no text on the device might make it confusing after a couple of modifications
  • Still requires to sync with computer and does not provide any additional functionality
    • The schedule aspect of it only requires sync-ing every so often which you might do if you were using a PDA for its calendar aspect also. The additional functionality comes from the widgets and the simplicity of its interface.
  • No direct interface to device — difficult to see what is going on inside if there is a problem.
  • Size of the object is questionable; you may not want to have an orb in the end, not easy to carry around
  • Seems awkward to carry around a spherical object in your pocket.
    • We don't have to make it a perfect sphere. Maybe we could make it a flattened sphere or something?
  • Relies on connection to laptop (?).
    • Only some additional widgets would require a semi-constant connection to laptop. The calendar aspect would require sync-ing every so often but wouldn't need a constant connection.
  • Not very useful when you have an iPhone or Blackberry.
    • This is intended for people who don't have or don't want to spend the money on an iPhone or Blackberry.
  • The ability to display only one widget could be a problem. If the user wants to monitor two different type of events, would they need two orbs?
    • The device would have two tri-color LEDs on it. We originally intended for one to always be dedicated to a calendar app and the other to be able to be configured to a widget based off our computer interface but it would be possible for us to make both configurable.
  • Only color is displayed, unable to have any indication which widget is running
    • You would set which widget is running in the program on the computer and it would be up to you to remember which widget you had set it to
  • shape might be a problem, no one wants to carry a round ball
  • features can be integrated with an existing product
    • There is a limited set of items for which something similar to this could be integrated into and then you would have to own that item whose cost may or may not be prohibitive.
  • market was not well defined
  • need to have a person to maintain the system in the building
    • Ours does not require a system in the building. Was this comment intended for group 2?
  • Seems like just a high-tech clock with vague output
  • Seems more like a novelty technology versus something people would want for practical purposes
  • How does it keep working when laptop is off/out of range?
    • The main calendar app would only require communication with a laptop a couple of times a day… possibly even once if your schedule doesn't change much. Thus as long as it can sync that often, it wouldn't need to be in range of the laptop for the rest of the day.
  • Is clock accurate or capable of being reset periodically?
    • There will most likely be oscillator drift but we are assuming the drift will be small enough that if we update the time when we sync with the computer, it shouldn't be too bad. We also plan on having long term interaction between the device and the computer keep track of how much drift the oscillator seems to have and to take that into account in the future to minimize the effects of drift.

Anticipated Risks

  • might cost more than anticipated with Bluetooth and wireless charge
  • durability issues with being in a person’s pocket all day long
  • Might be difficult to debug Bluetooth connection between small device and PDA, if the two do not pair
    • I'm not sure what this comment is referring to. We did not mention anything about trying to have our device communicate with a PDA.
  • Limited market -> some users may perfer the simplicity of a calendar or the famliarity of PDA (no syncing or pairing required)
    • Then you would have to carry a calendar around with you (or some electronic device that can display a calendar or buy a PDA (which you may not have the money or desire to buy)
  • May cost more than you anticipate.
  • Wireless charging might be unrealistic/insufficient depending on radius of the object.
  • possible problems with battery life
  • competing products
  • need to minimize cost to the owner of the building or else it will difficult to market
    • This doesn't apply to our product. Was this comment intended for group 2?
  • difficulty determining distance to routers
    • This doesn't apply to our product. Was this comment intended for group 2?

Advice, Pointers, Links

  • Have the color change in magnitude as the event nears closer
    • What is meant by magnitude? As part of the device, we already plan to have it move along a gradient from white to some color as the event approaches in time.
  • Look into a similar orb that medical patients use to remind them to take pills
  • Try to make the cost as low as possible and as pretty as possible. These are your two biggest selling points.
  • interesting idea but seems like easier to implement most of the features on an existing product. I guess the ball shape makes it interesting
    • What products do you know of that can glow in a way like this orb can?
  • wireless signal changes through walls of different types
    • This doesn't apply to our product. Was this comment intended for group 2?
  • If you're planning on it being carried, need to be quite small, as ball is not the most convenient thing for carrying in pocket.

Feb 8, 2008 - Second design review with Priya

  • Go over hardware procurement requirements, risks, etc

Feb 15, 2008 - Design & Architecture

Feedback

Strengths

  • Nice, simple, easy-to-use (depending on software) device
  • Should be cheap to implement, so easy to sell
  • Extendability with "widgets"
  • Simple, easy to use, provided that code is written well
  • seems doable with low price and low power
  • portability
  • Descriptive usecases (normal and abnormal)
  • Complete requirements
  • Simple, not too complicated architecture - mainly dealing with one protocol
  • Could be used for other functions like stock updates, weather, etc.
  • Ordered hardware parts already.
  • Might be a cool toy for high school students and college students (but not so much for people in the work force)
  • Simple, strong concept. Marketing the Rememberall will be a breeze (if J. K. Rowling doesn't sue)
  • Blinking LED patterns could convey a lot of data.. morse code widgets will definitely be made
  • Using the integrated Bluetooth, as you described, should make your life easy.
  • Perhaps use foam to create a shell with LED holes to use for padding your project, should someone accidentally drop it.
  • well-defined concept/idea
  • seems to have realistic goals
  • Positive presentation and good question answering
  • Interesting and fun to use device; people would be excited to use it
  • Architecture looks good; it would be cool if you guys can follow up; this is not just another agenda; if it's reliable, it could be the "cool thing to have"

Weaknesses

  • If it doesn't replace a PDA, people may not want to bother with it (more LEDS->more info, maybe?)
    • PDA's cost a couple of hundred dollars. We are hoping this will cost $10 or so to manufacture so the consumer pays around double or triple that. This is for people who can't or don't want to spend money on something like a PDA.
  • 24 hour running time (in standby) is pretty low - if person forgets to plug it in at night, it's worthless
    • We are hoping for at least 24 hours running in the worst case. Ideally, under normal usage, it would last longer than that.
  • people might put it in pocket and just forget to look at it ever - pager vibrator would help
    • I didn't have this on my slides but I mentioned it while speaking: We are considering putting a motor on the device so it can have a vibrate function for when its in your pocket.
  • Potential lack of information from Orb.
    • I'm not sure what is meant here. We have clearly defined what kind of information we expect people to be able to get from the orb.
  • Bluetooth might take a lot of power
  • Syncing every 15 min might not be frequent enough
    • It depends on the widget. For our main idea of a schedule thing, your schedule typically doesn't change very often. We haven't discussed this too much but I believe we will have a way for you to force a sync if you need to.
  • User might not look at it the whole time, in that case, the orb needs other way to notify user
    • See a few bullet points above about the vibrating
  • might be easy to lose
    • People carry a lot of small objects around in their pockets and any of them might be easy to lose. That doesn't mean people stop carrying them around in their pockets.
  • Need to finalize how to tell user of certain problems (low battery)
  • Not certain if the orb requires a motor for vibration (notification)
    • See above about motor for vibration
  • Accuracy of the tactile sensor—how sensitive is it?
    • We haven't done too much research into the tactile sensor since we are more concerned with getting the basic functionality working first.
  • Have to charge the device everyday
    • See above comment about a 24 hour battery life
  • Extra thing to carry around in pockets. products today are converging to have one machine do everything. I don't understand why someone would want to carry around another object.
    • The products that have one machine do everything tend to be expensive. This is for people who cannot or do not want to spend the money on a product that does everything.
  • The shape is a problem. a ball feels especially uncomfortable in pockets.
    • We are considering alternative shapes like a flattened orb.
  • Maintaining a persistent event cache (across reboots) will be power draining
    • Not sure what is meant here. We plan to keep the information in the microcontrollers SRAM which requires little power to keep in memory.
  • There's no internal clock? It loses track of all time when it reboots? I think a clock circuit wouldn't be too much to add
    • I'm not sure what is meant by a reboot but in order to keep track of time you need an oscillator and oscillators need power. jknichel said during the presentation that we want 2 "off" modes. One that turns everything off but still uses some power to keep track of time and one that turns EVERYTHING off, including any timing stuff so the next time you turn it on, it will need to resync in order to get the correct time.
  • Fortunately, there are a ton of uses for an information-displaying orb. For your demo, pick a variety of slow and fast-changing variables to show the variety of information displayed on how well implemented it is. Perhaps an event approaching slowly in time, and a stock ticker or something?
  • slides somewhat bland for such a colorful product
  • presenter should have projected better
  • Does your device require the laptop to be on and connected to the internet at all time? That might be hard to achieve.
  • What if you forget to look at it? User could miss an important meeting just because he didn't have it out and wasn't paying attention to the device
  • You talked about making it vibrate, I think you should definitely do that

Anticipated Risks

  • Make sure that touch sensor would work in some sort of enclosed device - and would not be turned on in pocket
  • Might be having trouble making a good interface using bluetooth
  • Durability of the orb, shock resistance, etc… similar to a cell phone, I imagine people will drop this frequently.
  • How will you run multiple widgets at one time? If there are multiple ones, it could get confusing.
    • There will be 2 physical LEDs. Each one will only display information for a single widget. It will be up to the user to remember what widgets they have told the device to use.
  • UI will be important
  • Startup delay
  • Bluetooth implementation (may need to drop down to WiFi)
  • Multiple events - how do you know which event corresponds to which led
    • A scheduling widget would only be controlling a single LED. As for knowing what events correspond to what colors on that LED… the user would be able to set that in the software and it would be up to the user to remember what colors go with what types of events.
  • Might be difficult to debug with just led's - might want an external lcd screen
    • jknichel believes (but is not sure) that the board we are using for development has a JTAG interface that we can use to help debug. Of course, before this was put into production, we would CAD a custom board that was much smaller and didn't have extra features, but the software can be debugged on this development board before being run on a board that has no easy way to debug.
  • Should be able to withstand water.
    • Cell phones aren't required to withstand water (Yea, they can withstand being used in the rain a little, but aren't expected to survive being dropped in a pool or something). jknichel doesn't think our device should be able to withstand water any better than a cell phone.
  • No electric circuit breaks and accidental shocks from accidentally breaking the ball.
  • It seems that all applications are closely time bound.. you mentioned appointments, checking the bus schedule, etc. Be very careful about clock drift.
    • We have already mentioned clock drift as a risk and come up with some ideas as to how to mitigate it.
  • It's going to be hard making a sturdy ball. Maybe you should cover it in insulation like Pig Trail
  • Your greatest risk is going to be technical - trying to construct a compact, useful, but rugged portable orb to be used for displaying information. A company recently started by a CMU graduate student in embedded systems, MobileFusion, is making portable military sensor balls for use in combat. They have insane requirements for the ruggedness, so shoot one of their technical folks an e-mail and see if they'd be willing to at least give you some pointers.
  • The second risk you face is effectively differentiating yourselves in the market from AmbientOrb, the current market provider of colored orbs for displaying information. The advantage of yours is the wireless interface (when portable), but consider the cost-benefit analysis of this and ensure that your product is sufficiently effective to justify the purchase of a portable, likely-more-expensive orb as opposed to the competitors.
    • We are expecting our device to cost the consumer $20 - $30. AmbientOrb costs anywhere from $99 - $150. It may be possible that AmbientOrb is out of production (3 or 4 different sites had it listed as out of stock, including the manufacturer's website). Also, AmbientOrb is very large (I believe it was something like 4.75 inches x 4.75 inches by 5 inches or something like that), requires an external power supply, and requires an external antenna to connect up to a nationwide wireless network for this company. Our device just needs to sync with your personal computer.
  • if the person needs reminding of some of this stuff, how are they going to remember the specific colors anyway? (like neville in harry potter, he couldn't remember what he had forgotten)
  • what about rain/temperature conditions, making it durable would make it drop-friendly, but how much environmental change can this withstand?
  • LED .6 or .7 cutoff maybe you can't control brightness too well
  • Be careful on the footprint of the device (has to be about the size of a phone or smaller), otherwise people wouldn't want to use it

Advice/Pointers/Links

  • Good quartz crystal - from normal watch - should have low drift
    • It is a consideration, but would probably raise the price of our product.
  • Is time drift really predictable? Can it be fast one day and slow the next?
    • jknichel does not know much about oscillators or drift. jknichel believes it is relatively consistent given a consistent voltage. Our plan for mitigation would not care about if its varying speed, since it will figure out how much the clock drifted each time it syncs and use that to update the device's correction mechanism. Variable drift would make it harder to keep the clock accurate, but our software solution should still be able to reduce the effects of drift, even if it can't fix them completely.
  • I like the squeezing idea for turning the LEDs off. Something that can be done w/ gloves on.
  • vibration or beeping?
  • Can to try to sync with other other people's orbs to view friend's schedule
  • Should try to make the object as small as possible and possibly also try to make a cell phone application which could do the same thing but on your phone instead (have it come out of sleep mode right into your application)
  • If you added a small speaker, i could become an amazing alarm clock (one that you don't have to set because it already knows your schedule)
  • Maybe have the device make some sound as well
  • If the device has to be within WiFi range, should consider supporting wire connection as well.

March 5, 2008 - Mid semester demo

  • Demo'ed some of the software and that we could power the hardware up.

Feedback

Strengths

  • cool microprocessor, hardware should be done soon.
  • Functional program for creating the calender.
  • Practical, real time system.
  • Good communication established between system and mobile widget platform
  • Written java code for client side API
  • Usual function of reading google calendar
  • lots of potential functionality
  • The ICal feature seems good since it allows you to sync with a lot of other calender apps
  • The client app. was straight forward and easy to follow
  • Nice to see you have all hardware working (even if it looks a bit dangerous)
  • Good job on server application, it's nice to have started that platform.
  • desktop-side software looks like it will be useful for selecting specific tasks/meetings to monitor
  • ability to sync w/ popular calendar formats is definitely "a good thing"
  • Java GUI working is good.
  • Humor is always good :)
  • A lot of work was done in different areas and levels of hardware and software
  • The team has a good understanding of their equipment and tools
  • Had a lot of demo material
  • Have made a lot of progress

Weaknesses

  • The hard part, chip to computer interface, hasn't been done.
  • LEDs heat up and may need to be replaced regularly which may be inconvenient to user.
  • Still unstable and not user-friendly (intricate, manual connections have to be made) but this will probably improve over the semester
    • We had gotten the hardware less than a week before and didn't end up having all the right parts to power it on and program it. The actual device won't be so manual
  • Bluetooth functionality not complete yet
  • Would have liked to see an actual orb or a picture of what the orb might look like
  • The hardware demo was very hacked together and kind of distracting since it kept turning on and off
  • Wiring? I don't know how you guys got this far w/o the right connectors, wires, and ways to power your device.
  • LED demonstration is very confusing, for all we know, you could just have turned 3 lights on. See advice section.
    • The "LED demonstration" wasn't an actual LED demonstration. Those LED's you saw on the dev board are not the LEDs we talk about for our project. We were just showing that we could power our board on and it did something.
  • Considering you want something very usuable and ambient, you need to work on the display of your product as well as the functionalities.
  • risky to not have proper connectors…
  • what's the backup plan for frying hardware?
  • estimated down time?
  • implement reverse polarity protection?
  • how will you use 3 leds to represent more than 8 tasks? different blink/vibrate patterns?
    • The 3 LEDs you saw on the board are not the LEDs we will be using. The LEDs we will be using are much larger and can go through a whole spectrum of colors
  • You should be more careful with your products. Go down to tech electronics and get a few project boxes & protoboards. Idk if they can order orbs though…
  • Since hardware is being assembled at a low level, problems seem to occur
  • Difficult to understand and interpret the LED interface
    • The 3 LEDs you saw on the board are not the LEDs we will be using. The LEDs we will be using are much larger and can go through a whole spectrum of colors
  • Hardware demo was a bit confusing, it wasn't clear what they were trying to show
  • Was hard to see the rememberall widget platform, font was too small
  • How well can you display the schedule/item that you would like to display?

Anticipated Risks

  • A JTAG for boundary scanning may be helpful.
  • Create real connectors will make your life easier.
    • We plan on it. We had to put something together in a short period of time and ran out of parts.
  • Security of system (non-owners might have access to owners' schedules)
  • connectivity of Bluetooth
  • memory space needed to include function such as calendar
    • not sure what this means
  • I feel like the entire color scheme idea might be hard for a person to decipher unless they only use a few easy to tell apart colors
    • The available colors will be divided into several distinct gradients.
  • What about people who may be color blind, it might be hard for them to use the colored orb
    • People who are fully color blind may have trouble using this except to tell if the orb is lit or not. People who are only somewhat color blind can choose colors they don't have trouble distinguishing.
  • Good chance of burning something out with your current setup
    • What was shown in the demo for the hardware is definitely not what we are going to actually use as our product. It was just hacked together in a short period of time so we had something to show since we had gotten our hardware less than a week earlier.
  • With your goal in mind, think about how this device will recharge and how you will present it in final demo.
  • What do those chips consume in terms of power? How heavy will the orb be? This has to be very lightweight and last a good period of time.
  • physical robustness of system?
  • how will it hold up to physical shock?
  • how will it hold up to static shock?
  • I haven't seen anything on battery power… even if you aren't going to run off battery you should calculate the size and weight of the batteries you will need to plug into this thing.
  • Hardware assembly could be a problem and unsafe without extensive hardare testing
  • User-friendliness could be an issue
  • How many different colored leds is the final product going to support?
  • Will there be enough colors for everything they want to do?

Advice

  • Maybe look into more practical and user friendly implementation of the product
    • The actual product would look nothing like what we have now. In fact, if this went into production we would CAD our own board and not use a dev board like we are using to develop it.
  • Have you thought about making the client app. more GUI based like an actual calendar app. where you can click or drag and drop new events
    • The main focus of our device is not entirely the calendar aspect. We felt that instead of making a full fledged calendar program (which has been done many times before. e.g. Google calendar, outlook, iCal, etc) we would just interface with an existing calendar using the iCalendar standard which most mainstream calendar programs support. This way, the user can continue to use their existing calendar program, with all of its bell and whistles.
  • Have you thought about using vibration or sound as other types of prompts to the user
    • We are considering a motor so it can vibrate if its in your pocket, etc
  • Customize your server application so you can "control" the time, this way we can see that as time "changes", your LED's actually change. We don't want to wait during a presentation to see your event LED's change.
  • Laptops dying is a testament to why you need version control. Hope you didn't lose anything / too much.
    • We do use version control (subversion). Nothing for this class was lost.
  • A speaker on the device could prove to be useful as a secondary interface

March 28, 2008 - Third design review with Priya

  • Showed her updates to GUI, hardware, bluetooth
  • Can get two bluetooth dongles to communicate with java code
  • had some problems programming avr but that has been resolved

April 4, 2008 - Mid semester demo

Feedback

Strengths

  • The incorrect data has been tested.
  • The power consumption is well thought. I'd like to see the test result on this in the future.
  • The long distance that the device can receive a signal
  • The length of time the device can go without synchronization
  • Testing with sending corrupt or incorrect data is a good idea, as being able to recover from this will be critical in such a closed (user interface-wise) system.
  • Impressive bluetooth results, if you really can transfer data from so far away you could probably have it automatically update whenever the user is anywhere near the computer (like anytime they're in their house), this would make the system much more convenient if it doesn't require the user to go to their computer ever time to update the schedule.
  • Good experimental data that mitigates the dropped connection probleem
  • nice eye candy
  • already beta testing application
  • have bluetooth communication between laptops
  • test cases seem to be complete and exhaustive
  • already started a lot of testing
  • Signal strength appears to be good
  • Test cases and metrics presented were relevant to project, especially power consumption
  • Test cases and experiments were clear
  • You implied that you're using only volatile memory to store the schedule. Good plan!! My group has already destroyed a few blocks on our uSD card. Reformatting around bad sectors every now and then is not a good longterm plan.
  • Good that you can update your schedule from accross a football field. Some people do sit pretty far back from their desks. I like to lean in real close, but it's good to know I can start a sync and go get coffee without taking the thing off of my belt.

Weaknesses

  • Is there a security issue
  • The connectivity and the signal strength is not linear. Ideally, it'll probably decrease as the distance is farther.
  • Needs to determine the accurate amount of battery life for the number of uses
  • Mitigate the increase in the power consumption when signal strength decreases
  • I don't really understand how testing bluetooth signal between two computers is going to help you. Why don't do the test with your real hardware as that will be a use case that you'll actually encounter?
  • Is Doherty hall a good test location for this? I would imagine Doherty hall would act rather like a huge antenna in one of those hallways and give you exceptional signal strength. A person's house or apartment won't have a room like this, and it will be much more relevant to be able to communicate through a standard wall than down a Doherty hallway.
  • Bluetooth dongle is not working yet.
  • Bad Graph - Bad labels no title. 0-255 is very informative even if linux outputs signal strength in 1 byte. Why not use dB?
  • too much text on slide, can't ready all of it
  • plot scale misleading
  • I didn't see any tests for when the device goes out of range
  • I think a stress/overload test would be important
  • Graph of signal strength doesn't have min/max, variances, etc
  • I didn't see any test cases that involved user interaction (touching it, etc)
  • I'd be interested in seeing some power consumption metrics at the various bluetooth power levels.
  • Your LCD screen looks really cool (I like the splash screen with the rss icon), but it doesn't seem like it's going to fit into the orb. :P jk, sorry I couldn't help it, and I can't think of anything else you didn't discuss.

Anticipated Risks

  • Is there a security issue? If the user does not want others to see his/her information, since the data is transmitted through bluetooth, there will be some security issue.
  • If there are many bluetooth devices under the environment, it may affect the system as you mentioned.
  • Transmission in a busy area with many people in the surrounding area
  • Use a different type of battery that may last longer
  • Does using a class 1 BT device use a lot of power? I would think that using a class 3 would give you better battery life, but I don't really know.
  • Have you considered at all physical robustness of your system. Perhaps it's beyond the scope of the demo situation, but if I were to actually have a Rememberall I would want to know it would not break if I dropped it or sat on it or something if it was going to be just in my pocket.
  • Bluetooh strength and interference
  • Don't think anyone wants to carry an orb around.
  • Have you considered fluctuating between bluetooth classes will drain more power than actually using a different class
  • Device may be too heavy —> why not just use AAA batteries?
  • power consumption might be an issue
  • durability of hardware might be a problem
  • I'd anticipate seeing difficulties with large file sizes as your biggest hurdle
  • Packaging the hardware into final form factor
  • Bluetooth versus power consumption
  • You may have trouble reaching your intended 24hr battery life (see suggestion below)

Advice

  • The device seems to be affected with other bluetooth devices. Also, when it's not a straight line between the server and the device, it might be different as well. If there's an obsticles on the way, that may be affected. More user testing under different environment should be tested.
  • You might want to have some non-connectivity related tests, such as reliability or response to touch or visibility of leds (which colors work well, which don't)
  • Try forcing bluetooth to go to low power mode
  • I thought you had a vibrate function as well…
  • How will the user select which Bluetooth device to connect to? I'm not sure how you are going to represent that if your device is based on LEDs…
  • Since your device is a carry-with, data throughput vs distance might not be a problem for users.
  • People remember things differently, maybe do a simple survey to find the best way that your device can do to be more effective
  • You might want to find a way to switch the bluetooth module off completely and provide an interface to switch it on when you're ready to sync (sort of half way between awake and sleep mode). This will probably significantly increase battery live compared to leaving the bluetooth device on.

INSERT MORE MILESTONES HERE (I was too lazy to finish going through the schedule from the first lecture)

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