anchor.diff:  
   
   === Trickle Algorithm
  +The Trickle Algorithm was first presented by P. Levis of Stanford University
  +and T. Clausen of LIX, Ecole Polytechnique in March 2010, and has since seen
  +several revisions until it was published as RFC6202 in March 2011. The Trickle
  +Algorithm provides a method of controlled packet flooding across a mesh of
  +low-power lossy network nodes, by letting the nodes dynamically decide when to
  +broadcast their values based on network activity and when the last update to
  +state values arrived. 
  +
  +==== A brief overview
  +The algorithm operate in exponentially growing time intervals of size I, starting at
  +interval size Imin, growing up to Imax. During an interval, it registers all
  +incoming messages, where each message may be either consistent or inconsistent
  +with the nodes current state (the definition of consistency is left for the 
  +user to decide). For each consistent message, a counter value, C is increased
  +by one, and for each inconsistent message, if the interval size I is larger
  +than Imin, the interval timer is reset, and I is set to Imin. At the start of
  +each interval, a timer T is set for a random time in the range `[I/2, I)`. When
  +this timer expires, the node shall broadcast its state if the consistent
  +message counter C is less than some redundancy constant K. At the end of each
  +interval, the interval length (I) is doubled if `I * 2 < Imax`, and C is reset.
  +
  +The exponential growth and insconsistency reset functionality allows the nodes
  +in the network to grow exponentially more silent as the state remains
  +unchanged, but still stays responsive, as new information arrives. The
  +consistency counter C and redundancy constant K allows the system to
  +dynamically adjust to network density, as nodes will choose not to transmit if
  +they've heard the same message from other nodes several times.
  +
  +==== Usage in the framework
  +The framework provides one instance of the Trickle Algorithm for each handle
  +value pair (dubbed a Trickle instance). This means that when one value is frequently updated, while another
  +one remains unchanged, the node only rebroadcasts the active value frequently,
  +keeping the interval times for the static value high. Each handle-value pair
  +also comes with a version number, which increases by one for each fresh write
  +to a value. This version number, along with a checksum allows the framework to
  +distinguish value consistency. If the node recevies a value update with a
  +higher version number than its own, it will automatically overwrite the
  +contents of the value data and notify the user. Any inconsistencies to both
  +version number and checksum results in a reset of interval timing for the value
  +in question. 
  +
  +==== Weaknesses in algorithm and implementation
  +While the algorithm in its intended form provides a rather robust and
  +effective packet propagation scheme, some necessary adjustments introduces a
  +few weaknesses. First off, using several instances of the algorithm on the same
  +set of nodes yields a growth in on-air collisions and poorer frequency
  +utilization control, as the individual instances take no consideration to
  +the others' activity. This means that the scheme doesn't scale that well with
  +several handle value pairs, and the user is asked to consider this during
  +implementation. The choice of doing separate trickle instances is, however a
  +result of a tradeoff: If the entire node state shared one trickle instance, the
  +entire state would be rebroadcasted each time a part of it is updated, 
  +and the amount of shareable data would be severely limited by packet size and
  +packet chaining possibilities.
  +
  +Another weakness in the adaption is caused by the fact that the Softdevice Timeslot API
  +won't let the framework get free access to the radio at all times, resulting in
  +a significantly reduced on-air time for mesh related operations. When the
  +Softdevice operates in an advertising state, this problem only has an impact of
  +5-25% reduction in potential on-air time for mesh operations, but in a
  +connected state with a short connection interval, the Softdevice may reduce
  +timeslots by as much as 80%. This results in a lot of missed packets to the
  +affected node, and may dramatically increase propagation time to this
  +node. 
  +
   === Timeslots
  +The framework does all mesh-related transmissions in timeslots granted by the
  +Softdevice Multiprotocol Timeslot API, operating directly on the radio hardware
  +module. Timeslots are ordered and extended in chunks of 25ms, and the framework
  +will attempt to seize the radio for as much as the Softdevice will allow.
  +At the beginning of each timeslot, the framework samples the RTC0 Low Frequency
  +Timer, and checks whether any timers related to the Trickle Algorithm have
  +expired since the end of the previous timeslot. If this is the case, the
  +framework does all pending operations immediately. After this initial "catch
  +up" operation, the framework handles all operations as they appear for the
  +remainder of the timeslot.
  +
  +For details about the Softdevice Multiprotocol Timeslot API, plese refer to the
  +Softdevice Specification, available on the Nordic Semiconductor homepage.
  +
  +=== Air interface packets
   === Resource allocation
  +Yip Yip
   
   == Forum
   http://devzone.nordicsemi.com/[Nordic Developer Zone]
  
positive.code: 
  == Basic concepts
  
  This framework provides a connection-less, rebroadcasting infrastructure for
  synchronizing states across a set of BLE enabled nodes. All nodes receive all
  messages that are transmitted within their range, and any node may update the
  mesh-global states. There is no hierarchy, and no directed data links. 
  
negative.code: node, depending on configuration parameters provided to the `rbc_mesh_init()`
  function at runtime. Each mesh value will operate with their own instance of
  the Trickle algorithm, meaning that they will be rebroadcasted independently.
  The handles addressing the values are stored as standard https://developer.bluetooth.org/gatt/Pages/GattNamespaceDescriptors.aspx[Bluetooth SIG
  namespace descriptors], where the enumeration of each value is used as
  a mesh-global handle.
  
  _NOTE:_ Because the Bluetooth SIG has defined namespace descriptor 0 as
  "unknown", the handles start at 1, and trying to access handle 0 returns an
  NRF_ERROR_INVALID_ADDR error.
  
  ==== Mesh metadata
  For ease of use, the service also provides a Metadata characteristic, providing
  