jump to navigation

Still To Do July 17, 2006

Posted by arhutchinson in Testbed.
1 comment so far

Overwrite images with node ID

Integrate with node reservation

Create admin area

read coordinates from xml as basis for file coordinates

Redraw map of 7th floor

convert calendar to xml input

To Do This Week – 23rd June 2006 June 24, 2006

Posted by arhutchinson in Links, Moats, Testbed.
add a comment
  1. Go Through Contrib folder
  2. Analyse Packet Format – Osciiioscope & Oscilloscope Wireless
  3. Zero Config
  4. Motelist – Comment & Understand
  5. Tossime – Understand & use
  6. Python – Tutorial
  7. Setting power ranges
  8. Tiny Viz

A. Code to check node pair

B. Given Node pair – Receive packet & Calculate Whats received

  • Sender / Receiver
  • Check on different power levels
  • Fix distances between 2 motes
  • Fix distances between 2 pairs of motes
  • Choose power level
  • Check loss of power level

To Do – 10/11 June 2006 June 10, 2006

Posted by arhutchinson in Moats, Testbed.
add a comment
  • Integrate logging code into another application.
  • On host system create a log file to receive content from a single Moat.
  • Expand capability to create a new log file per moat connected.
  • Look through other logging systems.. make a list of other data to log to file.

Meeting With HEN Development Team – HEN Administration June 10, 2006

Posted by arhutchinson in HEN, Testbed.
add a comment

Spoke to Adam & Felipe again about HEN administration issues and commands. Following information was given:

Moats will need to be added as a new type. – e.g. type "Sensor"

hen.py – main Class file

Superclass -> Subclass

TD: Create New mote class.

/usr/local/hen/etc/physical/ - hen db in XML.

To add node change base class. The file name parser will need to know new type. – hen parser.py.

Topology.xml – main file with all items

"Hm add" – Will create config – add to topology.xml

Uses computer8 & computer16

lsusb – NFO to populate config file

lshw – Info on individual device details

ToDo: Check Motelist to see what devices are connected to what boxes.

Check lshw on soekris

hen/bin -> Source code

Links:

"Learn Python" – David Acker – O Reiley
https://frostie.cs.ucl.ac.uk/nets/hen

Papers Read – 02 June 2006 June 2, 2006

Posted by arhutchinson in Academic Papers, Experiments, Testbed.
add a comment

Read – Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea. Authors: Lakshman Krishnamurthy…

http://www.cse.iitk.ac.in/users/cs725/lec_notes/industrial-sensor.html

Key points:

  1. Look into “Predictive Maintenance (PDM)” ^
  • Predictive maintenance (PdM) has many goals:
    • Reduction in catastrophic failures
    • Move from calendar-based maintenance to indicator-driven maintenance
    • Quantify a new system within the warranty period
    • Meet factory uptime and reliability requirements
  • Paper focuses on vibration analysis. Other techniques for PdM include oil analysis, infrared thermography, ultrasonic detection.
  • Goals of paper:
    • Validation of requirements for PdM
    • Effect of deployment environment on sensor network
    • Assessment of sensor node platform characteristics
    • Experience from an extended period of deployment
  • The possible approaches to PdM are:
    • Online system: needs to be planned at the time of industry layout; can be expensive
    • Manual system of taking vibration readings: labour is expensive, quality of prediction may not be adequate
    • Use sensor network: cost is inbetween the above two
  • 2. Site Planning
  • Necessity of site planning:
    • Assess RF coverage
    • Check for any RF interference
    • Mechanics: where to place the various nodes
  • Their site survey showed no RF interference, and in general good radio connectivity.
  • Connectivity was better at larger frequencies; 433MHz had connectivity problems: could not penetrate some barriers.
  • Note: the metal in industrial environments probably tends to improve connectivity through reflections, unlike office environments.

How: Simple Data copy application used to test interference

3. Architecture

FabApp architecture

  • Uses Sleep/wakeup protocol for battery lifetime.
  • Each collection period – data transfered to cluster
  • At Stargate – Time Stamped & file created for sensor channel
  • Stargate copies to root stargate periodically
  • Transfers data via serial cable using Kermit protocol to bridge Stargate
  • At Bridge Stargate – connected to Intranet & Server
  • At Server – data collected and analysed

4. Issues

  • Power Management
  • Fault Tolerance
  • Data Transfer
  • Power Consumption

2pm Meeting With Brad – 1st June 2006 June 1, 2006

Posted by arhutchinson in Moats, Testbed.
add a comment

Had weekly meeting with Brad and the Gang… Key things to mention:

Logging capabilities:

  • Take String or value from moat
  • Over USB
  • Create file unique to moat
  • Send to file system

Vern Packson Lecture

2pm Meeting with HEN Lead Developers May 23, 2006

Posted by arhutchinson in HEN, Moats, Testbed.
add a comment

Had an extremly productive meeting in Brad's office with the Heterogenous Experimental Network HEN lead developers Adam Greenhalgh & Felipe Huici.

Our objectives:

  • Integrating our Moat testbed into the HEN infrastructure
  • Find out what has or hasn't been done in HEN development and so decide on what tools to develop.

Currently Hardware status

2 Soekris boxes & 2 USB hubs with approximatly 30 Moats available.

Adam:  

Both Soekris boxes have been configured to run on HEN with USB and Power connections.  Prgrogramming Moats and Soekris boxes done via serial ports.  Adam has sent an email detailing how to connect to Soekris boxes via Arkell (Gatebox that allows ssh access to HEN infrastructure).

No Management or reservation software available for HEN in general or WSN,  Although research conducted on existing tools developed by Ramesh Govindan at USC, HEN team thought it wouldn't be feasible.  Brad will research into current USC testbed offering and find out what is on offer.

HEN uses XML for node reservations

Interface – multiple users – Suggest a login/reservation system:

Darren: Issues may be apparent if experiements are run by multiple personel.  Issues will be present in terms of:

  1. Reservation system for Multiple users
  2. Addressing individual nodes
  3. Overlapping of Ranges 

1. Reservation system for Multiple Users

A Look into pre built management and reservation systems is required.  Was highlighted that, even though in a small scale use, with only a few users, reservations wouldn't be a problem, with a larger deployment and as the testbed develops reservations and manipulation of system would be an issue.

Theres a need to know, whats running, have images available and track experiements.

ToDo:

  • Make a list of fine grained requirements for a reservation system
  • Look at current tools available or develop own tools.

2. Addressing individual nodes

Nodes will be deployed in static deployment.  We need to uniquly address each moat.  Various techniques discussed:

Soekris Boxes have their own unique addresses – Adam has a script that queries a box – (Soekris or other) – and finds out what it is connected to.  Addressing moats could initially start with Soekris Address, then moat local ID - E.g. Soekris box 1, Moat 4. – Problems if box rebooted as id's would be reset.

Moats may have some form of MAC address that may be addressable need to look into this.  Deployment may also require development of a default moat image that can go on all moats.

3. Overlapping of Ranges 

On a testbed with many potential tests, overlapping radio ranges may be an issue.  Will need to look into frequencies and possibly setting tests on various frequency bands.

All the above points lead to the development of a Management "Middleware" level designed for easy querying of Moat information, detailing whats connected, whats available.

Theres a need for a static "store" (Database, XML storage),  that:

  • Records Moat information
  • Can allow for querying of Moat
  • Displays information on Moat and its position / usage
  • allows commands to be invoked

Phases:

Development of the Wireless Sensor Network Testbed components can be seperated into the following areas:

Phase 1: Push to Moat

  • Push images to Moat
  • Find Moat by Unique ID
  • Programatically figure which Moat is connected to which node a form of "Moat DNS" – Use MAC address for addressing.

Phase 2: Detect and Write Moat Configuration

  • Run Commands on Soekris boxes
  • Develop auto detection functionality

Phase 3: Reservations

  • Record length of time, experiment types, moats in use, frequency settings

Look and feel: better for look/feel to be different between HEN & WSN.

Brad: Orders been placed for the following:

  • 6 x Soekris boxes
  • 10 x USB Hubs
  • Various lengths of USB cable
  • 4 Pin cable for motherboard

ToDO:

  • Brad – looks at current USC code and contacts Ramesh to find out what is available or could be reused.
  • Read Vera's report – decide on power levels for network to be connected and communication between moats
  • Darren: Aquires guide on how to set different channels & find out whether channels overlap.
  • Check operation of Moat List and other Moat tools to see what is available for unique node addressing.

2pm Meeting with UCL’s Resident Moat Experts May 18, 2006

Posted by arhutchinson in HEN, Moats, Testbed.
add a comment

Had an productive meeting with UCL’s Moat experts, Vera Cady & Vladimir Dyo today in our regular 2pm meeting with Brad.

Key points from our chat were:

Root privilages are better for installation purposes, though not ideal.

Vera: Tmote’s have 15 power levels… 1 gives a range of 30cm’s, 15 give a range of the whole 7th floor.

Clock drift is apparent when multiple power over ethernet.

Brad: We have on hand in the department:

  • Approximatly 30 Moats
  • 2 USB Hubs
  • 2 Soekris Boxes

Orders for more hardware have been placed and will be confirmed next week. USB Hub will arrive in days, Soekris boxes will take 1-2 weeks.

We’ll be using the D-Link 7 port DUB H7 hub…

Problem highlighted in experiments that when 4 – 7 motes in operation after a week they die

Soekris boxes that boot on HEN have no disk. Boxes need to be set up to netboot over PXE so there’s no need to install anything on the boxes.

As an overview the topology will be as follows:

  • Soekris boxes will be placed in a region
  • Moats will hang off Soekris boxes.
  • Multiple hubs will have long run length – provide potential to daisy chain devices.

ToDo:

  • Look at Chip Con for power level settings.
  • Make Contact with HEN team – Adam / Felipe
  • Develop remote login capabilities on Moats
  • Find out the run length limit of USB cables
  • Update & Include Topological diagram from presentation on blog

ToDo Aside:

  • Tiny OS – Version 2.0 – Check features
  • Contiki as opposed to Tiny OS
  • Stargate
  • Power Over Ethernet (POE)

Requirements May 10, 2006

Posted by arhutchinson in Testbed.
add a comment

Ok, For the deployment of the Wireless Sensor Network testbed, I'll need to complete the following things in no particular order:

  • Research, Annotate & Analyse CLDP & GDSTR papers 
  • Research Testbed Deployments throughout the world.
  • Install Tinyos environment on Windows & Linux PC's
  • Make a list of requirements for Testbed Deployment
  • Develop set of tests and Metrics to cover in test
  • Develop a deployment architecture.
  • Get plan of 7th floor.
  • Linux net booted on Soekris boxes as part of HEN
  • Get Moat Software built and accessible on Soekris – Mount built software via NFS.
  • Verify code downloadable to motes using Soekris.
  • Get logging (Debug) working over usb from Motes to Soekris stored in NFS mount on HEN filesystem.

Will be adding to this as I go along but these will be some of the key things that need completing .

Motivation… May 9, 2006

Posted by arhutchinson in Testbed.
add a comment

I'm an MSc Student currently undertaking a group project at UCL

Working with a "motley crew" of fellow students, We are charged with working on a comparison of two Geographic routing algorithms: Cross Link Detection Protocol or CLDP  and Greedy Distributed Spanning Tree Routing or GRSTR.

With the use of Emperical studies we'll be comparing the routing characteristics of these two algorithms.

Having seen one of my estemed collegues Alan Medlar develop a Blog detailling the extensive software efforts apparent in writing CLDP & GDSTR code, I thought it would be a good idea to chart my progress on my various sections of the project.

This is NOT the central site for our group project.  A project Wiki has been developed that encompasses the steps taken by the group to complete our project.  Our Wiki site is here.

My main area of specialisation will be the deployment of a Wireless Sensor Network or WSN Testbed within UCL.  UCL has a Heterogenious Experimental Network called HEN, designed to enable the conducting of tests of internet operations.  More information on HEN can be found here.  We'll be connecting our WSN to the already deployed HEN infracture.

 This site has 2 main purposes:

  1. Tracking my progress as I move towards deploying the WSN within UCL
  2. A guide to anyone who may have to develop a Wireless Sensor Network or develop using TinyOS or Nesc.

 Hope you find it interesting.. comments, questions and critcisms are always welcome !!