This shows you the differences between the selected revision and the current version of the page.
| mobilemesh:clickrequirements 2009/11/06 09:53 | mobilemesh:clickrequirements 2009/11/09 11:42 current | ||
|---|---|---|---|
| Line 8: | Line 8: | ||
| * Uses unique file names, based on timestamps, for the logs. | * Uses unique file names, based on timestamps, for the logs. | ||
| * Starts new logs on a regular interval to prevent data loss after accidental power down (and to simplify data offload). | * Starts new logs on a regular interval to prevent data loss after accidental power down (and to simplify data offload). | ||
| - | * Reads GPS position and time directly from ''gpsd''. Logs every entry with gps time and location. | + | * Reads GPS position and time directly from ''gpsd''. Logs every entry with gps time and location. |
| + | * It does not have to cycle through the frequencies for the initial experiment. | ||
| + | * It can continously send, but we need to empirically determine the maximum //packet-rate// that will not lose packets at any bitrate. | ||
| + | * We should also see if there is anyway to get statistics from the driver about packets lost from the send side. | ||
| - | === Open Questions === | ||
| - | |||
| - | * Do we want ''click'' to cycle through the frequencies using a regular round robin schedule? | ||
| - | * What rate of send probes is appropriate? What are the right metrics to measure? What send behavior matches these? | ||
| - | * Do we want to log every send probe, or just the beginning of every burst? | ||