anchor.diff:  - 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
   
  
positive.code: either ANT or website sniffing. Why one would do this is beyond me,
  just saying, is all.
  
  == Website Sync Communication
  
  == Device Communication
  
negative.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.
  
  The USB information in the logs truncates most of the ANT protocol
  specific information. USB communication looks something like
  
  ------
  02/02 22:25:36 Setting channel id [number: 65535, type: 1, transmission: 1]...
  02/02 22:25:36 [40] 0x00, 0x51, 0x00
  02/02 22:25:36 Channel id set.
  02/02 22:25:36 Opening channel...
  02/02 22:25:36 [40] 0x00, 0x4b, 0x00
  02/02 22:25:36 Channel opened.
  02/02 22:25:42 [9A] 0x00, 0x58, 0xf7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Acquired beacon.  Sending RESET packet...
  02/02 22:25:42 Queuing packet to send...
  02/02 22:25:42 >>>>> SEND 0x78, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Sending 8 bytes of ACK data...
  02/02 22:25:42 [9A] 0x00, 0x58, 0xf7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 [05] 0x00, 0x01, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Pending acks: 0
  02/02 22:25:42 Tracker reset.  Sending LINK REQUEST...
  02/02 22:25:42 Queuing packet to send...
  02/02 22:25:42 >>>>> SEND 0x78, 0x02, 0x8b, 0x7a, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Sending 8 bytes of ACK data...
  02/02 22:25:42 [9A] 0x00, 0x58, 0xf7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 [05] 0x00, 0x01, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Pending acks: 0
  02/02 22:25:42 Closing channel...
  02/02 22:25:42 [40] 0x00, 0x4c, 0x00
  02/02 22:25:42 Close request acknowledged...
  02/02 22:25:42 [02] 0x00, 0x01, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  02/02 22:25:42 Waiting for close message -- ignoring incoming data
  02/02 22:25:42 [07] 0x00, 0x01, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  ------
  
  This is not a complete log of USB messages, however, the explanations
  of some of the messages are quite useful for translating the actions
  into code.
  
  While working on the web communication, it was also found that error
  messages about communications flow were quite helpful. Errors are
  