anchor.diff:  === 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.
  +module. Timeslots are primarily allocated by extending, short timeslots into
  +timeslots of upto 1 second, 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.
  
positive.code: Works with softdevices S110 v7.x and S130 with Timeslot API.
  Offers an API for implementing your own mesh enabled application, operating
  concurrently with regular BLE applications.
  
  == Basic concepts
  
  The Rebroadcasting Mesh framework (hereby referred to as "the framework" or
  rbc_mesh) 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. 
  
  The framework resides on top of the nRF51 Softdevice, utilizing the Timeslot
  API to allocate radio time. The framework will attempt to allocate as much time
  as possible, in order to listen for other nodes' messages.
  
  All nodes in the mesh share a set of dataslots, addressed by handles. 
  These handle-value pairs are propagated through the mesh
  with version numbers, with the objective of synchronizing the same version of
  the values across all nodes in the mesh. Each time a node overwrites a value, it
  increments the version number, and all nodes that receive a broadcast message
  with a version number that is higher than the one in its database, will adapt
  this new version of the value. 
  
  The value propagation is controlled by an implementation of the IETF RFC6206
  "Trickle", a flood control algorithm for lossy, low power networks. The Trickle
  algorithm dynamically decides intervals at which a value will be broadcasted by
  a node, based on how many consistent messages the node picks up, and when the last
  update to the state it manages was. The Trickle algorithm dynamically adapts to
  node density and value update frequency.
  
  The framework provides each handle-value pair with one Trickle-instance (an
  isolated version of the algorithm), and utilizes the Softdevice GATT server
  structure to store the values. All values are stored as characteristics within
  one "Mesh"-GATT Service, which is accessible to external nodes through a
  classic BLE Softdevice connection, implemented in application space. The "BLE
  Gateway example" displays a way to achieve such behavior.
  
  == Usage
  In addition to two provided examples, there is a template project under
  
negative.code: *Get value*
  [source,c]
  ----
  uint32_t rbc_mesh_value_get(uint8_t handle, 
      uint8_t* data, 
      uint16_t* len,
      ble_gap_addr_t* origin_addr);
  ----
  Returns the most recent value paired with this handle. The `data` buffer must
  be at least 28 bytes long in order to ensure memory safe behavior. The actual
  length of the data is returned in the `length` parameter. The `origin_addr`
  parameter returns the address of the node that first started broadcasting the
  current version of the message.
  
  '''
  
  