Debugging Directions

1
Debugging Directions
2
Deployment Lessons

• Power-Saving
• Turn LEDs off during long-term deployment How
  do we get feedback from motes? One LED consumes
  an extra 2.5mA
• Maximize beacon periods - TS routing?
• Optimal settings for bmac lpl levels
• D batteries
• Minimize Channel Congestion to make debugging
  easier
• Physical Deployment
• Deploy one batch at a time
• Tier each batch out (over multiple hops)
• Not too many in each batch
• Filter bad nodes in lab (start query in lab and
  then take it out there)
• Equipment
• Stargate with battery, wireless capability
  (passive snooper)
• Laptop with full programming capability
• 3 extra sensor boards that we know work
• Extra stargates, extra motes
• Screw-drivers/zip ties/tape/labeling/bailing
  wire/duct tape
• AP
• Ethernet cables/Serial cables/Power cables

• Functionality
• NO MANUAL STEPS!!
• Know what has/has not been tested
• Lab testing should include
• Dynamic on/off of nodes and sink
• Disk-Saving
• Stripped Binaries
• Shared Libraries
• Misc
• Run emrun as daemon or it exits on log out or
  start up on boot as daemon.
• Install using ipkg to make it a standard routine.
• Common issues
• Not getting data at the sink
• Not getting much data at the sink
• Node wouldnt add logical neighbors to its
  neighbor list so didnt route data

3
Do we need internal actuation?

• Paraphrased from Tom
• During poor performance, we want to specify
  that a node change its routing table. i.e. have a
  way to specify certain rules or changes.
• What is the best way internally (i.e. BluSH) or
  through external probing?
• Useful to test configuration changes
• What are the risks?

4
Extracting Information

• External probing (i.e. Sympathy)
• Regular broadcast of metrics
• Active probes to request more information
• Internal probing (i.e. BluSH) by local
  visitor
• Internal/External Ping
• Maybe enables LEDs
• Returns some status information
• Which scenarios are each useful in?

5
Dynamic Jittering

• Contention caused by concurrent/synchronized
  transmissions
• Dynamic
• DSE jitter sample return based on percentage
• Reliability Layer dynamic backoff period to
  handle forwarding of stored data
• Routing beacons/adverts/etc should dynmically
  adjust their rates based on underlying stability
• AVOID Hardcoded defined values! (In conjunction
  with ow duty cycle congested the network)
• Where should it go? MAC layer (but then it needs
  to know density), routing layer, application
  layer? Still have hidden terminal.
• Make it a function of period and density

6
What Metrics are Helpful?

• Number requests received
• Number of query-responses a node has tried
  transmitted How is this different from seqNum?
• Number packets a node has routed
• Node's next-hop/neighbor lists
• What else?

7
Recommendations

• Deployment/Debug Mode
• Enable LEDs
• Enable regular/frequent transmission of metrics
• Enable internal actuation
• Not on all the time, nodes start in this mode,
  and toggle upon receiving cfg command
• BluSH-type tools
• Sympathy-type tools
• Emissary