anchor.diff:  either ANT or website sniffing. Why one would do this is beyond me,
   just saying, is all.
   
  -== Website Sync Communication
  -
  -== Device Communication
  +== Website Communication
  +
  +=== Account Establishment and Tracker Bonding
  +
  +Nothing yet known about this.
  +
  +=== Data Synchronization
  +
  +Communication with the website happens via HTTP requests to a REST
  +API, with replies of XML blocks. These blocks contain opcodes to send
  +to the device, as well as information the website will need to
  +identify the device in later commands.
  +
  +Opcodes and their results are encoded via base64. 
  +
  +The data flow between the website and the client happens in the follow
  +order (all commands go to http://client.fitbit.com, REST locations are
  +listed below):
  +
  +- Client receives beacon from tracker, establishes link (see Fitbit
  +  Communication section)
  +- Client contacts website at /device/tracker/uploadData, sends basic
  +  client and platform information
  +- Website replies with opcode for tracker data request
  +- Client gets tracker data (serial number, firmware version, etc...),
  +  sends base response. Sends to /device/tracker/dumpData/lookupTracker
  +- Website replies with website tracker and user ids based on tracker
  +  serial number, and opcodes for data dumping
  +- Client dumps data from device, sends to
  +  /device/tracker/dumpData/dumpData
  +- Website replies with commands to erase data from device, and
  +  synchronize time (and possibly data?) with website.
  +- Client sends successful responses on all opcodes (but no specific
  +  data) to website at /device/tracker/dumpData/clearDataConfigTracker
  +- Website replies with command to close tracker, and have the beacon
  +  sleep for 15 minutes (probably conserves power).
  +
  +== Fitbit Communication
  +
  +=== Base Initialization
  +
  +=== Establishing Tracker Communication
  +
  +=== Querying Tracker Information
  +
  +=== Data Dumping
  +
  +=== Device Erasing
  +
  +== Data Formats
  +
  +=== Second Data
  +
  +=== 5 Minute Interval Data
  +
  +=== Daily/Per Sync Data
  +
  
positive.code: complete record of both USB and website communications, with copious
  amounts of annotation. Each call to and response from the device and
  website is logged and even sometimes documented.
  
  While working on the web communication, it was also found that error
  messages about communications flow were quite helpful. Errors are
  
negative.code: - ANT Message and Protocol Documentation: http://www.thisisant.com/images/Resources/PDF/1204662412_ant%20message%20protocol%20and%20usage.pdf
  - FitBit FAQ: http://www.fitbit.com/faq
  - FitBit Manual: http://www.fitbit.com/manual
  
  == What We Don't Know
  
  As this section will probably be updated frequently, I'm putting it
  near the top for now. This lists things I haven't figured out about
  the fitbit's protocol and client yet.
  
  - How the erase opcodes work
  - Exactly what data we're getting from the website to send to the
    device in the erase step
  - How the seconds data is stored/parsed
  - What the encrypted attribute on opcodes in the website response xml
    means
  - How authentication setup with the website works
  - How device bonding with the website account works
  
  == Terminology
  
  