TEAM 7: The Caffeinaters
Spring 2009

MEMBERS

Evan Gates Juan Lasheras Max Salley
(egates) (jlashera) (msalley)

PROJECT CONCEPT

Placing WiFi access points ("arrays") requires a site survey. Most of the time the guess work involved in the survey, along with the repetition, makes the process long and tedious. This project aims to simplify the process by introducing embedded systems ("tags") which will dynamically monitor and report the status of an array's signal as it is adjusted, for faster site surveys.

Check out our video:
Download large video
Download small video

MOTIVATION

This project is motivated by Xirrus' concept for a faster site surveying method.

COMPETITIVE ANALYSIS

There are no competitors; there are no products designed for this functionality.

TECHNICAL SPECIFICATIONS

Hardware: (please follow the links to the vendor's sites)

TS-7200 Board (8mb) + Dev Kit
 Sparklan USB 802.11a/b/g/n Adapter

Part Number Description Price
TS-7200-32-8F TS-7200 Single Board Computer (SBC) with 32 MB RAM and 8 MB Flash $149
KIT-7200 Development Kit with 1GB Debian Compact Flash, regulated DC power supply, all needed cables, USB-CF adapter, utility CD with SBC resources, and printed documentation (TS-7200 SBC not included) $120
WUBR505N-S0 SparkLAN WUBR-505 Wireless-N 802.11abgn draft 2.0 dual band 2T/3R USB Adapter (Ralink RT2870) $54.95

REQUIREMENTS

Mobile: Robust: Cheap:

ARCHITECTURE

USE CASES (INTERACTION DIAGRAMS)

[Unit has no use cases besides trivial on/off interaction]

SYSTEM STATES & TRANSITIONS

RISKS & MITIGATION STRATEGIES

  • Possibility of collisions.
    • Will use random backoff times or possibly coordinate between tags in a token ring like way.

  • Possibility of lost "I can't hear you" messages.
    • Broadcast for a period of time insuring someone is awake to hear it.

  • Possibility of excessive power consumption.
    • Unit sleeps while not interacting with unit, reason for not using tcp connections.

    ERROR HANDLING

    In general lost packets will be due to collisions and are not a big deal. They should resolve themselves the next time they are sent due to the random backoff intervals. If a tag dies during the test we will use the last valid data received from it, and it will be replaced for the next round of testing. Each round of testing should only last a few seconds and it will not be hard to repeat after replacing the dead tag.

    IMPLEMENTATION DETAILS

  • GNU iwlist used to detect wireless networks and collect statistics
  • Perl script used to parse AP Mac address and signal/noise information for pre-determined SSID
  • UDP connection used to create a low-overhead communication portal. Allows units to be stateless and to freely create/destroy connections

    • TEST CASES

    Gathered wireless statistics using a tag as well as a consumer wifi enabled product (Apple Macbook). Testing was intended to reveal whether the tag acts as a good sensor by providing readings representative of real-world usage

    EXPERIMENTAL EVALUATION

    High correlation between the tag and a normal consumer product shows that the tag can function as a useful sensor:

    LESSONS LEARNED

  • Off the shelf components are unlikely to fit a real-world product's requirements without introducing significant overhead
  • Support can be very platform specific
  • Wifi chipset drivers supported ARM Linux platforms, but only specific kernels and only specific ARM versions. The drivers we used officially supported our processor's preceding and succeeding versions, but not our version
  • Most boards that provide a USB 2.0 host also provide unnecessary, power hungry features, such as LCD drivers, multitudes of Digital I/O lines, A/D convertors, FPGA's, etc.

    • REFERENCES

    PRESENTATIONS

    mid_semester_demo.{odp,pdf,ppt}
    testing.{odp,pdf, ppt}

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