The LM930/ LM931 Bluetooth Low Energy (BLE) module makes it incredibly easy and cost effective to design your wireless product. The LM930/ LM931 communicates with a phone, tablet or embedded system with the LM961 over a BLE connection. Bluetooth Low Energy (BLE) is a light-weight version of the Bluetooth Classic ideal for the developer to create small applications.
The lower level protocol firmware of the Bluetooth v4.1 stack is stored in the ROM. Your unique application firmware communicates with the stack with APIs. This application firmware is programmed and debugged within the CSR μEnergy SDK provided with the LM53X development kit. Your application is then flashed over SPI to the EEPROM. GAP is used to establish Bluetooth Low Energy connections, while GATT defines how the data is organised and sent bidirectional between the LM930/ LM931 and another BLE device.
Generic Access Profile (GAP)
The Generic Access Profile is part of the CSR Bluetooth v4.1 stack used for controlling the connection between your product with the LM930/ LM931 and another BLE device.
LM930/ LM931 GAP Roles
In a Bluetooth Low Energy point to point connection there are two roles:
- GAP Peripheral – The LM930/ LM931 is defined as a peripheral device as it has all the resources for a small application e.g. a monitor, meter and iBeacon.
- GAP Central – Typically phones, tablets and computers with a more powerfully processor and larger memory capacity.
Advertising and Scanning
LM930/ LM931 advertises (broadcasts) its presence to all the GAP Central devices within range. It advertises with 31 byte advertising payloads which can state a predefined device name. The GAP Central device sends scan response payloads the same as the advertising payload sent by the peripheral. The advertising payloads are sent in intervals within a window of time defined by the developer in the CSR μEnergy SDK. The shorter the interval and window set in milliseconds the more responsive the advertising will be. However, there is a trade-off between the responsiveness and the battery life when using a small battery to power your application. Once the LM930/ LM931 has made a connection with a GAP Central device it will stop advertising it’s presence to other central devices. It will only transmit advertising payloads again when the connection has dropped. The BLE connection between the LM930/ LM931 and the central device allows GATT services to transfer data in both directions.
Wireless Personal Area Network (WPAN)
In a Bluetooth Low Energy network the GAP Central device can connect to up to 7 GAP Peripheral devices. Data can be sent over these 7 connection simultaneously, only restricted by the processing power and memory size of the GAP central device.
The LM930/ LM931 forms a connections with one GAP Central device at a time and can communicate with another peripheral device through the connected central device.
The LM930/ LM931 GAP Peripheral module is able to send data to more than one device as a broadcast. The data is sent one way to any GAP Central device in range as a 31 byte advertising packet. Our iBeacon firmware is available on the LM930/ LM931 for sending the broadcast messages.
Generic Attribute Profile (GATT)
The CSR μEnergy SDK is used to develop GATT Services. GATT Service firmware operates on the LM930/ LM931 once GAP has established the connection. Within the firmware you can define the way the LM930/ LM931 transfer data to the connected GAP Central device and vice versa. The data is transferred in a client/ server architecture, where the LM930/ LM931 is the server and the connected GAP central device is the client. The LM930/ LM931 is responsible for responding to all the requests of the client.
In development one or more services are implemented within your application to execute the required behaviour. For example the key fob demo application consists of a Battery Service, Device Information service and a customised Automation IO service for the switches and RGB LED functionality. With the LM930/ LM931 you can use and modify existing services and create new ones. All services are stored in the Attribute (ATT) protocol lookup table using a UUID. The service contain characteristics used to define the procedures and formats of the services.