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.
    • Only one stack with a time-synchronous protocol is allowed at a time. (The DMM is not able to coordinate two time-synchronous stacks.)
    • The DMM has only been tested/characterized using TI BLE5-Stack operating in peripheral mode and Wireless Sensor Network example using EasyLink

  • 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.

The following limitations are imposed by the BLE5-Stack operating in peripheral mode:

  • The BLE stack cannot handle preemption while in the connected state.
  • The BLE stack must have high priority while connected, and Propriety-RF operations must fit in between BLE connection events

Assuming that BLE cannot be preempted in the connected state, TI has characterized the BLE5-Stack (peripheral mode) + WSN EasyLink stack combination to determine the minimum BLE connection interval allowed 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

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

  • Only one BLE connection will be considered (additional connections cause BLE connection events to take longer and complicate scheduling)

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

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 17. BLE Connection Interval Restrictions for Proprietary-RF mode
Proprietary RF Mode Recommended BLE Connection Interval (1M BLE PHY)
50 kbps 2 GFSK 100 ms

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.