Page tree
Skip to end of metadata
Go to start of metadata

Release Date

June 9, 2016

Enhancement/Fixes to existing features

Example BLE application bleprph fixed

The example BLE application bleprph has been fixed for the two issues observed in the 0.8.0-incubating release. See RN-0.8.0-incubating for details.

  1. The default application task size has been increased to enable full logging.
  2. BLE peripheral devices respond correctly to the service discovery requests from the central device.

Boot loader fix

The file system no longer fills up after repeated image upgrades.

Event queue polling and wait timeouts 

Previously eventq_get() blocked until an event was put on the queue and waited forever if no event was placed. The eventq_poll() function has been added to allow for polling multiple event queues, and specifying a timeout in OS ticks for the wait.

New Docker instance available for toolchain (and with Windows support)

The Docker instance has been updated with the latest toolchains for Windows. It bundles the newt tool with other toolchains such as gcc for embedded ARM, openOCD, Segger J-Link Commander (JLink.exe) etc. Your Docker instance can be updated by running:

$ docker pull mynewt/newt:latest


New features

Support for HCI mode in BLE (NimBLE): a new BLE example application

The BLE stack in Mynewt OS now allows a different (non-Mynewt) BLE host to talk to the Mynewt NimBLE controller via the Host Controller Interface (HCI). NimBLE has implemented the HCI Commands for the controller, allowing the host access to the baseband controller and link manager, and access to configuration parameters. An example application 'blehci' is included in the release to allow the user to build a target that will respond to messages sent by the HCI driver on the host. 

Pairing and bonding support in BLE (NimBLE)

Support for pairing and bonding have been added and enabled by default. They are available in the example BLE apps: bleprph and bletiny.

Pairing is the exchange of security features and establishment of an encrypted connection between two devices. Security feature information includes things like i/o capabilities, requirement for man-in-the-middle protection, etc. An encrypted connection is established using a temporary security key. In this encrypted connection, long term keys are exchanged. Mynewt NimBLE supports all the legacy pairing algorithms (Just Works, Passkey Entry, Numeric Comparison, and Out Of Band). LE Secure Connection pairing requests will be supported in the next release.

 

Bonding is when two paired devices store and use those keys the next time they connect. 

The SMP (Security Manager Protocol) implemented in Mynewt NimBLE offers applications running over a Bluetooth Low Energy stack access to the following types of services. Device Privacy is planned for the next release.

  • Device Authentication
  • Device Authorization
  • Data Integrity
  • Data Confidentiality

The SMP currently works with 3 types of keys. Identity Resolving Key (IRK) and Connection Signature Resolving Key (CSRK) are not supported in this release.

  • Temporary Key (TK)
    • Determined by the type of pairing used – as of this release, all Legacy Pairing methods are supported.
  • Short-Term Key (STK)
    • Used to encrypt a connection when 2 devices are pairing for the first time
  • Long-Term Key (LTK)
    • Used in bonding

Eddystone beacon support in BLE (NimBLE)

A device running Mynewt OS with NimBLE can be configured to emit beacons in the Eddystone beacon format. The Eddystone support is included in the example BLE app 'bletiny'. 

 

   

  • No labels