User:Ramesh/VTB Logistics
From Enl
Contents |
[edit] The date
Thursday June 29th for the deployment, Friday June 30th for the retrieval.
[edit] Topology
4 motes per cluster and 5 (~6) clusters. ('x' stands for cluster ID)
[edit] Stargate Topology
123 -- 122 -- 121 -- 124 -- 125
- IP address: 10.0.0.12x
- 120 feet between stargates
[edit] Mote Topology (per stargate)
x2 -- x3 - (BS:12x) - x4 -- x5
- TOS_LOCAL_ADDRESS
- static 1-hop routing
- 30 feet between motes
[edit] Communication Frequency
- 802.15.4 Channels
- cluster1 - 25 (2.475GHz)
- cluster2 - 19 (2.445GHz)
- cluster3 - 23 (2.465GHz)
- cluster4 - 15 (2.425GHz)
- cluster5 - 21 (2.455GHz)
- 802.11b Channel
- channel 1 (2.412GHz)
[edit] Things to take
- 20 or more mote+accel+vibecard assemblies
- 7-8 Stargates together with enclosures and batteries. 6 Stargates to deploy, 1-2 backup Stargates.
- 2-3 IPAQs
- 10 rolls of duct tape
- 4-5 rolls of heavy-duty double-sided tape (check with John if this will work)
- solvent to clean the mounting surface (check with John what kind of solvent we need)
- laptops, extra motes
- programming board and cables (does not hurt to have it)
- one or two large boxes with wheels to carry this stuff (We have 3 of these boxes total.)
- 802.11 spectrum analyzer
- Some snacks and water!
[edit] Software to develop on stargates
Let us be extremely conservative in adding to this list!
- logging software on Stargate (feel free to change the design) -- Ki-Young?
- at the routing layer, dump all data packets destined to words a particular destination prefix to a log file
- when the log file exceeds a certain configurable size (say 10M), close it, rename the file with the current timestamp, and start writing to a new logfile
- should we use this same software on the "base station" Stargate as well?
- should we use jffs2 (Ki-Young/Om spent an afternoon and could not get it to work. Now we have more time, it might be worth investigation further)
- tenet program to task the motes once every hour (Jeong) - DONE
- watchdog script: (Marcos is done.)
- runs on each Stargate, and if the tenet stack is dead, it reboots the machine.
- startup scripts: (Ki-Young)
- start up the tenet stack during bootup - DONE
- startup the application a minute or two after bootup
- monitoring scripts: (Jeong, already done?)
- every 10 minutes, compute the topology. I am not sure if this is useful by itself if the motes are separated by frequency. What might be useful is to monitor the link quality to each of the mote from the stargate. Maybe these two can be combined.
- monitor/log stargate battery voltage and current draw.
[edit] Testing
[edit] Progress
May 2-3, 2006
Problems from previous tests addressed:
- Nodes were disappearing after a while. Potentially caused by parent expiring. Addressed by removing the routing component.
- log packets, create a new file every hour, restart tasks every hour.
- Any other changes from previous tests?
Results from 4 cluster, 16 nodes, 9 hour test
- one stargate ran out of battery.
- Address by charging the battery.
- other clusters worked ok. reasonable number of packets/samples collected
- one vibecard sampled junk
- vibecard defect
- How to address? toss it?
- three nodes gave high noise (~200 as opposed to ~20)
- What is the problem?
- How to address?
Conclusion is without routing, the motes won't disappear from the network.
May 3-4, 2006
Problems from previous tests addressed/changes from previous tests:
- 1 more cluster, 4 more motes
- The stargates are now in their own network (disconnected from the testbed network)
- any other hardware/software changes?
Results from 5 cluster, 20 node 16 hour test
- can we know the number of samples from each node in 16 hours?
- node 22 malfunctioned (bad data) after 13 hours.
- What is the probable cause?
- How to address?
- nodes 23 and 24 seem to have disappeared, not responding at times.
- What is the probable cause?
- How to address?
- node 53 seems noisy most of the time.
- What is the probable cause?
- How to address?
- Details: Results
[edit] TODO
Long-duration tests: (some of these tests can start now, but ideally, we should start testing the whole setup, with all the additional scripts and logging, by the end of the week)
- full scale experiments
- it would be nice to run these tests 2-3 times
- we should discuss how to do this, but I imagine we can put one cluster in each of Gaurav, Bhaskar and Maja's labs, and one in their conference room. Should we try for a third floor lab (say Cyrus')
- if we have time, we should do one completely outdoors test. This test will force us to use iPaQ and laptops to do the test. When we do indoors test, we end up using other facilities in the lab...
Short-term 802.11 range testing:
- put nodes in RTH roof
Robustness tests: these are short duration tests (about 1-2 hours each) where we make sure:
- startup scripts work
- turning stargates on and off doesn't cause us to lose data
- the watchdog timers work (e.g we kill the tenet stack)
- tasking and re-tasking the motes every hour works
Accelerometer calibration
- it would be good to check if the accels are all connected/soldered properly and seem to be reasonable.
--> May 3 : under progress.
Power system (I am suggesting these tests because we seem to have gotten some surprises last night)
- Find out how long it takes to charge the batteries
- Find out how long the motes and the Stargates run on the batteries.
Stargate routing test on a physically long topology (multiple hops) similar to the bridge. Will require 2-3 people to watch the Stargates. We would just send messages back and forth between the two end points.
Learn how to use 802.11 spectrum analyzer. Done.
For Ramesh: Size and load capacity of the painter trolley. Will Caltrans people be there in the trolley? We need this information so that we can plan the boxes/equipment and number of people to bring to the site.
[edit] Software to develop on the handheld
Om will talk to Daniel today. Did, he has an exam on Friday so a bit busy, but he will figure out exactly commands/scripts to: set next hop, send a command via ssh, dump output to a file, fetch that file to ipaq, and display the file, and find out how to plot a simple graph on the display. He will work on the GUI this weekend.
Network measurement:
- Ping and traceroute to any stargate. We probably don't need the bandwidth measurement tool, since this needs an extra component running on the stargate, and that is probably not a good idea.
- An alternative to bandwidth measurement is signal strength indicator. It will be nice to know the signal strength between an iPaQ and a given Stargate. This will help immensely in making minor tweaks to the orientation of the antenna and box during deployment.
Stargate access:
- Reboot a Stargate remotely.
- List of processes running on a Stargate.
- Display free space on the flash on a Stargate.
- Display CPU load on a Stargate.
- SETTING NEXT HOP ON STARGATE
Log access:
- List log files in flash
- Download a specified log file
- Graph downloaded file (don't know how easy this is). We can use a very simple visualization: paint a series of y-values (extract them from the packet) on the canvas component of the GUI on iPaQ.
Other things that'd be nice to have:
- Set wireless channel to any Stargate remotely.
- Set transmit power on the Stargate remotely.
- Provide a shell to a Stargate.
[edit] Getting ready to go out
- Two days before the experiment
- Batteries need to be fully charged.
- All data in CF-cards must be removed.
- Should not forget to fully charge the laptop :-)
- One day before the experiment
- Batteries need to be firmly taped to the box. (box should be shakable)
- Wires and alligator clips need to be firmly taped to the battery.
- Mote enclosures need to be closed (lid on), with the accels outside the enclosure.
- When packing mote enclosures for carrying, must make sure that the external switch is not pressured.
- Everything must be packed to bags & boxes.
