System Performance and Limitations

The typical use-case for the DMM is a smart phone being used to interface with a dual-band TI device such as CC1352 and an application on the smart phone to control or configure a sub-g device or a network of sub-g devices. Typically the BLE connection is not used for streaming content but only intermittent information exchange.

DMM Current Limitations

The current DMM implementation has the following limitations:

  • The DMM only supports 2 simultaneous stacks.

  • The DMM can only store 5 RF command callbacks. (used to intercept RF callbacks and perform corrective scheduling action before sending )

  • The DMM policy’s time constraint is currently binary. It only considers whether or not the given stack is time-critical or not in a given state.

    • In the future, the timing constraint field may be expanded to handle advanced timing restrictions.
    • The DMM scheduler does not take action when the policy is transitioned to one that has a stack paused. When a policy enters a pause state an application callback is invoked to pause the stack. The pause policy should only be used if the application callback has been implemented and registered with DMM.
    • The DMM has only been tested/characterized using TI BLE5-Stack operating in peripheral mode alongside either the Wireless Sensor Network Easylink example or the TI 15.4 sensor example.

  • The DMM does not perform arbitration of peripherals or hardware. The high level applications must be written in such a way that conflicting access to peripherals or UI is avoided.

Protocol Stack Limitations

The DMM will attempt to maximize the time domain utilization of the radio while still respecting the constraints of the protocol stacks that are using it. However, unlike CPU scheduling, RF commands cannot resume once they have been canceled or preempted. Combining two protocol stacks means that there must be application defined limits of the parameters that can be used by each stack based on what the application needs to accomplish. Time-synchronous protocols such as BLE further increase these limitations.

Assuming a low-priority BLE connection in connected state, the application must make sure that the BLE Stack is able to operate within the supervision timeout of the connection to avoid disconnecting from the device.

TI has characterized the BLE5-Stack (peripheral mode) + WSN EasyLink stack combination to determine the minimum BLE connection interval that can be used in a dual mode system. The following parameters were used for characterization.

  • Consider the worst case for Sub-1GHz Proprietary-RF TX (max packet size 128 bytes) and RX (for ACK) using the following PHYs.

    • 50 kbps 2-GFSK
    • 5 kbps Simplelink Long Range (SLLR)

  • Include turn-around time and PHY switching required by the radio in stated limitations

  • Only one BLE connection will be considered

  • BLE Long Range PHYs will not be considered (reduced symbol rate increases radio time required for each command)

  • BLE is high-priority when in connected state

Using the above parameters the following limitations are stated:

  • BLE connection intervals must be set according to the table below
  • Only one BLE connection is supported. Only peripheral mode is supported.
  • BLE Long Range PHY is not supported
Table 26. BLE Connection Interval Recommendations for Proprietary-RF mode
Proprietary RF Mode Recommended BLE Connection Interval (1M BLE PHY)
50 kbps 2 GFSK 100 ms
5 kbps SLLR 1000 ms

The recommended BLE connection interval is also valid when combining the TI 15.4 stack and the BLE5-Stack. The TI 15.4 + BLE5-Stack (peripheral mode) example have been characterized based on the same BLE parameters and limitations. For the TI 15.4, the defualt sensor example settings is used. For more information on the specific settings, see the Application/154senosor/subg/config.h found inside the dmm_ti154sensor_remote_display example.

The following limitations are set for the TI 15.4 stack:

  • Currently only support IEEE 802.15.4 Frequency Hopping mode
  • TI 15.4 is only used as a sensor
  • BLE connection may be dropped when the TI 15.4 sensor scans for a network

Adjusting the BLE connection interval

The BLE peripheral is not able to directly control the connection interval, it may however request a connection parameter update to the central device.

For more information about the connection parameter update process, refer to the GAP section in the BLE5-Stack User’s Guide ( Developing A Bluetooth Low Energy Application - > The Stack -> Generic Access Profile (GAP)). In the GAP chapter there is a section that covers the connection parameter update process and the APIs needed to perform one.