米6体育平台手机版

SWRA475A January 2015 – October 2016 CC2540 , CC2540T , CC2541 , CC2541-Q1

3.2 Creating a Beacon Application With TI Bluetooth low energy-Stack

The BLE-stack available from Texas Instrument for the CC26xx Wireless MCUs provides an easy and reliable implementation of connectable and non-connectable beacons. There are sample applications that can be used as templates when designing a beacon, which are described in Table 5. It is assumed that you are familiar with the IAR Embedded Workbench and the BLE-stack.

Table 5. Beacon Software Examples for CC26xx

Example Project	GAP Role	Type	Device Support
SimpleBLEPeripheral	Peripheral	Connectable	CC2640, CC2650
SimpleBLEBroadcaster	Broadcaster	Non-connectable	CC2640, CC2650

SimpleBLEPeripheral is thoroughly described in the software Development Guide ^[8] and is generally the best starting point if implementing a connectable beacon. The SimpleBLEBroadcaster is a simplified version of SimpleBLEPeripheral, which only supports non-connectable beacons. The API to enable beacon functionality is the same for these projects so the following code examples apply for both, although SimpleBLEBroadcaster (BLEv2.2) is used as the referenced example project.

The application is implemented in SimpleBLEBroadcaster.c where the broadcasting data is defined as advertData.

static uint8 advertData[] = 
{ 
  // Flags; this sets the device to use limited discoverable
  // mode (advertises for 30 seconds at a time) instead of general
  // discoverable mode (advertises indefinitely)
  0x02,   // length of this data
  GAP_ADTYPE_FLAGS,
  GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED,
  
#ifndef BEACON_FEATURE
  
  // three-byte broadcast of the data "1 2 3"
  0x04,   // length of this data including the data type byte
  GAP_ADTYPE_MANUFACTURER_SPECIFIC, // manufacturer specific adv data type
  1,
  2,
  3

#else
    
  // 25 byte beacon advertisement data
  // Preamble: Company ID - 0x000D for TI, refer to https://www.bluetooth.org/en-us/specification/assigned-numbers/company-identifiers
  // Data type: Beacon (0x02)
  // Data length: 0x15
  // UUID: 00000000-0000-0000-0000-000000000000 (null beacon)
  // Major: 1 (0x0001)
  // Minor: 1 (0x0001)
  // Measured Power: -59 (0xc5)
  0x1A, // length of this data including the data type byte
  GAP_ADTYPE_MANUFACTURER_SPECIFIC, // manufacturer specific adv data type
  0x0D, // Company ID - Fixed
  0x00, // Company ID - Fixed
  0x02, // Data Type - Fixed
  0x15, // Data Length - Fixed
  0x00, // UUID - Variable based on different use cases/applications
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // UUID
  0x00, // Major
  0x01, // Major
  0x00, // Minor
  0x01, // Minor
  0xc5  // Power - The 2's complement of the calibrated Tx Power
    
#endif // !BEACON_FEATURE
};

The default advertised data includes the mandatory Flags followed by 3 bytes of Manufacture-Specific Data (numbers 1, 2 and 3). The Manufacture-Specific Data can be modified to be something else, although note to update the length of the data as well, if necessary.

The configured variables are then committed to the GAP layer, which sets up the Bluetooth low energy stack. Note that the advertEnable is not instantaneously triggered, especially not during the initiation of the application (simpleBLEBroadcaster_Init). The advertise will start when the protocol stack runs, at a later instance.

GAPRole_SetParameter( GAPROLE_ADVERT_ENABLED,sizeof(uint8), &advertEnable );
GAPRole_SetParameter( GAPROLE_ADVERT_DATA, sizeof(advertData), advertData );
GAPRole_SetParameter( GAPROLE_ADV_EVENT_TYPE, sizeof(uint8), &advType );

The advertising interval is default set to 100 ms although it can be increased up to 10.24 seconds, which is the maximum allowed by the core specification. If longer intervals are needed, it is possible to manually enable and disable the advertisement with the use of an OSAL timer, as an example.

// Advertising interval (units of 625us, 160=100ms)
#define DEFAULT_ADVERTISING_INTERVAL          160

To ensure discovery of broadcasts, there is a general rule that the advertisement Interval + 10 should be less than scan window of the observer device. This means that the beacon must be designed with the peer device capabilities in mind. Otherwise, it is possible that it will take a very long time to receive broadcasted packets. This implies that a lower broadcast interval will allow broadcasted data to be observed more quickly, although it requires more power due to the more frequent wake ups. The interval is setup with following API:

uint16_t advInt = DEFAULT_ADVERTISING_INTERVAL; 

GAP_SetParamValue( TGAP_LIM_DISC_ADV_INT_MIN, advInt );
GAP_SetParamValue( TGAP_LIM_DISC_ADV_INT_MAX, advInt );
GAP_SetParamValue( TGAP_GEN_DISC_ADV_INT_MIN, advInt );
GAP_SetParamValue( TGAP_GEN_DISC_ADV_INT_MAX, advInt );

For more information regarding application architecture and API description, see the software Development Guide ^[6].

By using the TI Packet Sniffer ^[7], the broadcasted data can be verified (as shown in Figure 10). The illustration shows a packet on channel 37 (0x25) that is connectable (ADV_IND). The AdvA value is the IEEE address and advData includes Flags (0x01) and Manufacturer-Specific Data (0xFF).

Figure 10. Packet Sniffer v2.18.1, SimpleBLEBroadcaster Packet Over the Air