1 / 7

Debugging Directions

Debugging Directions. 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

nat
Download Presentation

Debugging Directions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Debugging Directions

  2. 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 wouldn’t add logical neighbors to its neighbor list so didn’t route data Deployment Lessons

  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

More Related