›

More BTLE-compliant firmware and operation

ericleigh007ericleigh007
in Firmware

The fix for this issue would require both work here and work in the actual MetaWear firmware.

The current firmware for the device is not what one familiar with Bluetooth 4.0 Low Energy would classify as "compliant" with the standard.

The reason is that the current interface does not utilize a characteristic for each unique type of input or output, as required (or at least suggested) by the Bluetooth SIG's LE standard. Instead, the interface uses a single Command characteristic and a single Notify characteristic and codes the buffers in each to access different buffers within the device.

In a future update, making this more standards-compliant will allow a more streamlined interface, and a more modular code pattern, as well as remove a lot of the complexity of the interface code. As well, since the different mobile platforms are optimized for battery life around the use of unique characteristics, the mobile platforms will be able to be more battery-efficient.

 If one is familiar with how the TI SensorTAG firmware is written, that is a much better example of how a more conventional BTLE interface should operate.

-thanks
-e

Comments

  • MattMatt
    edited December 2014
    Hi Eric,

    Thank you for your feedback regarding the MetaWear protocol.

    There are several constraints underpinning our decision to tunnel through GATT instead of building on top of it.  The gist is that it cannot handle an implementation with this scale of complexity.  Some issues:
    • Mandatory use of 128-bit UUIDs for custom characteristics requires significant RAM/ROM limiting characteristic/feature count
    • Service/Characteristic discovery doesn't scale well to 100s of characteristics
    The MetaWear Service and it characteristics are compliant with BT4.0.  The spec does not prohibit implementing protocols with GATT as the transport.

    The protocol results in less radio traffic -- far fewer characteristics for discovery, and only one characteristic to enable notification on -- than an equivalent GATT implementation, reducing the net energy consumption on both ends.

    The sensor tag model works well if you only want periodic sensor data.  However, it cannot be scaled to support all of the modes we have: offline events and actions, NVM logging of literally any event or sensor data, firmware side programmable signal conditioning, and more... We have the equivalent of over 100 characteristics and counting.

    If you are interested in support for SIG standard services, this is something we would like to support in the future.  So that you could, for example, add circuits to MetaWear to measure heart rate or bicycle cadence, compute the result using the signal processing module, and send that data through the BTLE standard HRM or Cadence service for use with a compliant app like MapMyRun, etc.  No firmware development required.

    Matt
This discussion has been closed.