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.
- The default application task size has been increased to enable full logging.
- 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'.