This article is going to give you an example of sending the battery level indication from a Bluetooth handsfee device to iOS devices so that the iOS devices can display a battery level indication icon for the connected Bluetooth handsfee device.
Handsfee battery indication is implemented by two Apple-specific Bluetooth HFP AT commands. For the details, please refer to section 4. Bluetooth Accessory Identification and 5. Bluetooth Headset Battery Level Indication in Apple’s <<Bluetooth Accessory Design Guidelines for Apple Products>> (click here to download)
1. Module: WT32i (iWRAP6)
2. iWRAP settings:
SET BT BDADDR 00:07:80:47:bc:7a
SET BT NAME DKWT32i
SET BT CLASS 240428
SET BT AUTH * 0000
SET BT IDENT BT:47 f000 6.0.0 Bluegiga iWRAP
SET BT LAP 9e8b33
SET BT PAGEMODE 4 2000 1
SET BT PAIR 18:46:17:22:47:85 4d6834208f9db36932ca6548f32de306
SET BT PAIR 5c:95:ae:ea:97:70 b89ea2b48e7959f496272df92b2ef90e
SET BT POWER 6 6 6
SET BT ROLE 0 f 2580
SET BT SNIFF 0 20 1 8
SET BT SSP 3 0
SET BT MTU 667
SET CONTROL AUDIO INTERNAL INTERNAL EVENT KEEPALIVE
SET CONTROL BAUD 115200,8n1
SET CONTROL BIND 0 400 R VOLUME UP
SET CONTROL BIND 1 200 R VOLUME DOWN
SET CONTROL BIND 2 10 R AVRCP FORWARD
SET CONTROL BIND 3 8 R AVRCP PLAY
SET CONTROL BIND 4 1 R AVRCP PAUSE
SET CONTROL CD 00 0
SET CONTROL CODEC SBC JOINT_STEREO 44100 1
SET CONTROL CODEC AAC JOINT_STEREO 44100 0
SET CONTROL ECHO 7
SET CONTROL ESCAPE 43 00 1
SET CONTROL GAIN 8 8
SET CONTROL MICBIAS b 0
SET CONTROL MSC DTE 00 00 00 00 00 00
SET CONTROL PIO 00 00 00
SET CONTROL PREAMP 1 1
SET CONTROL READY 00
SET CONTROL RINGTONE gfgfgf__gfgfgf______gfgfgf__gfgfgf
SET CONTROL VREGEN 2 02
SET PROFILE A2DP SINK
SET PROFILE HFP hands-Free
SET PROFILE SPP Bluetooth Serial Port
SET PROFILE AVRCP CONTROLLER 00
1. Let an iOS device to pair with the WT32i module and make connections to that module
RING 0 5c:95:ae:ea:97:70 19 A2DP
RING 1 5c:95:ae:ea:97:70 17 AVRCP
RING 3 5c:95:ae:ea:97:70 1b AVRCP
RING 2 5c:95:ae:ea:97:70 3 HFP
HFP 2 CODEC NEGOTIATION
HFP 2 BRSF 1007
RING 4 5c:95:ae:ea:97:70 19 A2DP
HFP 2 STATUS "service" 0
HFP 2 STATUS "call" 0
HFP 2 STATUS "callsetup" 0
HFP 2 STATUS "battchg" 5
HFP 2 STATUS "signal" 1
HFP 2 STATUS "roam" 0
HFP 2 STATUS "callheld" 0
HFP 2 CHLD (0,1,1x,2,2x,3)
HFP 2 READY
2. Use LIST command to know the link_id for HFP connection. For this example, the link_ID for FP connection is 2.
LIST 0 CONNECTED AVRCP 672 0 0 5574 0 0 5c:95:ae:ea:97:70 17 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED A2DP 672 0 0 5574 0 0 5c:95:ae:ea:97:70 19 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 2 CONNECTED HFP 667 0 0 5573 8d 8d 5c:95:ae:ea:97:70 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 3 CONNECTED AVRCP 672 0 0 5573 8d 8d 5c:95:ae:ea:97:70 1b INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 4 CONNECTED A2DP 672 0 0 5573 8d 8d 5c:95:ae:ea:97:70 19 INCOMING SNIFF SLAVE ENCRYPTED 0
3. Enable custom AT commands from the handsfee by AT+XAPL
HFP 2 UNKNOWN (0): \r\n+XAPL=iPhone,7\r\n
HFP 2 OK
1. "@" is used to specify the link_id for the AT command to be sent.
2. where "UNKNOWN" means iWRAP does now understand the response of "n+XAPL=iPhone,7" from the iOS device. However, it does not mean this is an error message.
4. Report a state change (e.g. battery level) by AT+IPHONRACCEV
I just thought to share with you (and possible the community)
that I tried this morning to again compile the
Bluegiga_Android_App_20140416.zip in android studio on a mac.
I am not sure how relevant it was but I updated studio (0.8.6.
beta) and targeted APK 18 / 4.3.
I followed the advice of Jeff Rowberg on your forum at
on post date April 23, 2014 20:55.
On the screen "Welcome to android Studio" in the "Quick Start"
column, press on "Import Project..."
I select the container directory as described by Jeff above.
Next window gives the default option as "Create Project from
existing sources", I left it as this.
When you complete the import it bitches about.
1) Migrate to gradle.
2) update property files
3) update (was it template files?) cannot remember.
I updated 2 and 3 above by just clicking on the links.
Compiled and built APK without issues.
I hope this encourages others to try.
Demonstrates both master and slave components of a simple remote control, where the input logic state of 8 pins on the BLE master side are sent over a BLE connection and mirrored (output) on the slave side. Think of it as a wireless 8-channel GPIO extension cable.
The master begins scanning on boot and connects to a slave advertising the correct 128-bit service UUID, then performs a GATT discovery to locate the correct service and characteristic handle according to their UUIDs. Once the connection is established, detected GPIO interrupts on P1_x pins (in input mode) trigger a 1-byte GATT write operation to the connected slave, which then writes the same matching logic values to its P1_x pins (in output mode).
NOTE: this demo uses the dual-port rising+falling interrupt technique to effectively achieve "pin change" interrupt behavior. This is accomplished by connecting matching pins on both ports together, e.g. P0_5+P1_5, and P0_6+P1_6, etc. and then configuring the rising edge on one port and falling edge on the other. In this way, GPIO polling can be avoided entirely, and the application uses as little power as possible since the module can sleep between interrupts.
|Safe to Flash:||BLE112, DKBLE112, BLE113, DKBLE113|
|Unsafe to Flash:||BLED112 (no ability to return to DFU mode, no GPIO access)|
BASIC ARCHITECTURAL OVERVIEW:
Raised on boot/reset. This event handler enables relevant interrupt edge detection on desired, pins, then sets scan parameters and initiates a scan with the "gap_discover" command.
Raised when the connection status is updated. This happens when the connection is first established, and the "flags" byte will contain 0x05 in this instance. However, it will also happen if the connected devices bond (i.e. pair), or if encryption is enabled (e.g. with "sm_encrypt_start"), or if either side of the link updates the connection parameters used. Once a connection is established, the script begins a service discovery with the "attclient_read_by_group_type" command.
Raised for each group found during the search started in #3. If the right service is found (matched by UUID), then its start/end handle values are stored for usage later. We cannot use them immediately because the ongoing read-by-group-type procedure must finish first.
Raised for each attribute found during the search started after the service search completes. We look for one specific attribute during this process: the 128-bit UUID designating the GPIO remote control characteristic's data attribute. If/when this is found, it is stored in another variable for use later.
Raised when an attribute client procedure finishes, which in this script means when the "attclient_read_by_group_type" (service search) or the "attclient_find_information" (descriptor search) completes. Since both processes terminate with this same event, we must keep track of the state so we know which one has actually just finished. The completion of the service search will (assuming the service is found) trigger the start of the descriptor search, and the completion of the descriptor search will (assuming the attribute is found) set the correct application state so that GPIO data is sent over the air to the slave when needed.
Raised when a connection is terminated. This is used only to put the BLE device back into a scanning state, essentially starting the process over again.
Raised when a scheduled soft timer interval elapses. This is used only during the connection process to detect if too much time has elapsed since the connection attempt began (4 seconds in this demo). If the timer fires, then the connection attempt is cancelled and the module is returned to the scanning state. The timer is cancelled preemptively if the connection is fully established within 4 seconds.
Raised when a GPIO interrupt occurs. Once the connection is established and all necessary GATT discovery has occurred successfully, GPIO data is written to the GATT server (slave) when necessary. Since the CC254x chipset inside the module does not support CHANGE interrupts, the script enables rising-edge interrupts on P1_x pins and falling-edge interrupts on P0_x pins, and pulls pins on both ports low. Electrically, you can then connect a button (or any signal) to BOTH matching pins on each port (e.g. P0_5 and P1_5), and effectively get "pin change" interrupt data. This configures all 8 available pins to work this way, assuming the following electrical connections:
BASIC ARCHITECTURAL OVERVIEW:
Raised on boot/reset. This event handler sets the desired Port1 pins to OUTPUT mode and initialized them to a logic low state, then puts the module into an advertising/connectable state.
2. connection_status (PLACEHOLDER ONLY, NOT ACTUALLY USED)
Raised when the connection status is updated. This happens when the connection is first established, and the "flags" byte will contain 0x05 in this instance. However, it will also happen if the connected devices bond (i.e. pair), or if encryption is enabled (e.g. with "sm_encrypt_start"), or if either side of the link updates the connection parameters used. This demo does not require any unique behavior based on a new connection.
Raised when a connection is terminated. This is used only to put the BLE device back into an advertising/connectable state.
Raised when a remote GATT client writes a new value to a local GATT characteristic. In this demo, that means that the remote device has sent a new GPIO logic value which we need to apply to our Port1 output pins.
BLE SW Update Tool provides both Graphical User Interface (GUI) and Command-Line Interface.
The command-line interface is meant to be integrated into production systems for updating the software for the BLExxx modules in production line. It doesn't provide all the features of the GUI version, namely it doesn't compile Profile Toolkit projects or BGScript sources, nor does it maintain recovery data of the devices in case of upgrade failures. For the details of the recovery feature which is provided the GUI interface, please refer to
Please refer to section <<1.3 Command-Line Interface>> in the attached user guide for the detailed descriptions of the command-line interface.
Development kits Covered: WT32i, WT41, WT12, WT11i, WT32
WT32i and WT32:
Connect the micro USB end of the provided cable into the UART port on the development kit.
WT41, WT12, WT11i
Connect the USB end of a usb-to-rs232 adapter ,such a the one shown, into the computers USB port and the 9-pin serial connector into the the 9-pin serial connector on the Development Kit.
The Default iWRAP port settings are:
The image below shows the result of pressing the hardware reset button with the Development Kit connected to the terminal application. The iWRAP version is 5.5.0 with a build number of 891
NOTE: If the build number you wrote down in step 1 matches the build number shown for your device below, you have the latest firmware and do not need to update the Development Kit.
The Find Me profile (FMP) defines the behavior when a button is pressed on one device to cause an alerting signal on another device.
The FMP can be used to allow users to find devices that have been misplaced.
The profile defines two roles: Find Me Locator and Find Me Target:
The Find Me Target - shall be a GATT server.
The Find Me Locator - shall be a GATT client.
The profile makes use of Immediate Alert service. The Find Me Locator writes a value to the Alert Level characteristic to cause an alert in the Find Me Target device.
The Alert Level characteristic can be written using the GATT Write Without Response (shown in the above figure) sub-procedure with an alert level of either “No Alert," “Mild Alert," “High Alert," to set the written alert level.
When the Alert Level characteristic is written, the Find Me Target device shall start alerting:.
If the written alert level is “No Alert," no alerting shall be done on this device.
If the written alert level is “Mild Alert," the device shall alert.
If the written alert level is “High Alert," the device shall alert in the strongest possible way.
The specific action that occurs in the device for the mild and high alerts is implementation specific. For example, this could include flashing lights, making noises, moving, or other methods to alert the user.
This alert continues until one of following conditions occurs:
An implementation specific timeout.
User interaction on this device.
A new alert level is written.
The physical link is disconnected.
The Find Me Demo BGScript example can be downloaded at Bluegiga Bluetooth Smart download page
Note: Click [Example Applications] and download << Bluetooth Smart Software: Example Applications, Configurations and Demos>>
Find Me Target -- implemented by BLE112 or BLE113 Evaluation board
1. Switch on the LCD display on BLE112 Evaluation board
2. Download Find Me example to BLE112 Evaluation board
3. Press Reset button
"Find Me Demo" will be display on the LCD display
Find Me Locator – implemented by BLED112 dongle + BLEGUI2 on PC
1. Plug a BLED112 dongle to a PC
2. Run BLEGUI2
For step 12, assuming the user presses a key on the Find Me Locator to cause an alerting signal on the Find Me Target device. In this demo, the Find Me Locator (BLED112) writes Mild Alert, which is 1 (also see below notes), to the Alert Level characteristic in Find Me Target device (BLE11x Evaluation board) by Write Without Response procedure. Upon receiving the value of Alert Level, the Find Me Target device alerts the user by displaying "Mild Alert". Note: Buzzer, vibrator, LED, ...etc can be used to alert the user in real application.
Alert level = 0; “No Alert," no alerting shall be done on this device.
Alert level = 1; “Mild Alert," the device shall alert.
Alert level =2 ; is “High Alert," the device shall alert in the strongest possible
BLE SW Update Tool will read the module information, such as module type (device type), license key, MAC address, etc, and save that information on the PC before firmware update. The information can be used to recover the module later in case the communication between BLE SW Update Tool and the module fails in the midway of firmware update.
If you see an error message on BLE SW Update Tool, you can click [Recover] to try to recover the module with the stored data. Note you may need to reset the module and/or cc-debugger and make sure the connection between the module and the cc-debugger is good. Furthermore, you also need to make sure the power stable is stable before you try.
Error message examples:
If "recover" does not work, you can try to manually recover the module. The following is the procedure:
1. Run TI's Flash Program and read the primary address (= serial number) and secondary address (= MAC address). Reference:
Note: If Flash Programmer can't make a connection to the module, this could be hardware problem, e.g. the connection between the module and cc-debugger.
2. Request the license key of the module by providing the primary address (= serial number) at https://siliconlabs.force.com/home/home.jsp You can also ask for a new secondary address (MAC address) or you can also copy the primary address to the secondary address if the module is your internal testing only.
3. Rewrite the secondary address (MAC address) to the module. For the details, please refer to
4. Close Flash Programmer and Run BLE SW Update Tool. Click [Delete recovery information] and confirm it.
5. Copy and paste the license key to [License key] input box (do not copy the carriage return character).
6. Select the desired BGScript project file (*.bgproj) and click [Update] button
7. Click [Info] button to check
Note: Unfortunately, the Device Type can't be recovered by this mothed. However, the module can still run without any problem with UNKNOWN device type.
It is possible to solder a RF cable to WT32i-A with appropriate modifications for RF testing. This article is going to let you know how to modify WT32i-A (internal chip antenna) and solder a RF cable on it.
The following diagrams show the schematic and PCB layout of the antenna section of the module.
1. Remove ANT1 and C1
2. Replace L2 by a 0ohm resistor
3. Solder a RF cable to the pad #1 of ANT and the GND
Bluetest3, which is an application software for Windows, can be used to control the module for RF testing.For detailed test setup and procedure, please refer to <<Bluetest3: Certification test setup and procedures>>
|Project Name:||Dual mode beacon implementing iBeacon + Google Physical Web Beacon|
Demonstrates how to create a dual mode beacon implementing Apple iBeacon and Google Physical Web Beacons (URI beacons) with the Bluegiga BLED112 Bluetooth Smart USB dongle
The examples shows how to build the advertisement data according to the Apple iBeacon and Google's URI Beacon specifications and how to enable advertisements and switch the operating mode, so the device advertises itself 50% of the time as iBeacon and 50% of the time as Google Physical Web beacon.
The example also shows how to implement DFU over USB interface.
|Safe to Flash:||The example is made for BLED112 USB dongle.|
|Unsafe to Flash:||N/A|
Our latest full-stack Bluetooth Low Energy module, the BLE121LR, uses the same SDK, source files, hardware definition files, and build tools as our previous two module (BLE112 and BLE113), but there are some differences between the BLE121LR and the other modules which must be considered during the design phase. The main cause of these differences is that the BLE121LR incorporates a power amplifier (PA) and low-noise amplifier (LNA) to allow improved range compared to the other modules. If you are moving a design from the BLE112 to the BLE121LR, there are a few additional considerations which are similar to those necessary when moving from a BLE112 to a BLE113.
One VERY CRITICAL point is to ensure that you follow the PCB layout recommendations shown in the BLE121LR datasheet. The RF design of this module requires more attention to the keepout area and specifically a larger solid ground plane for optimal RF performance. See the BLE121LR datasheet for more detail.
The main differences between the modules that impact the firmware development process are these:
Most everything else is the same as far as the SDK is concerned at a high level, but the internals of the stack are modified to make take advantage of these differences. The hardware footprint of the modules are also different, but this much is shown in each module's datasheet.
From a hardware perspective, the BLE112's two USB data pins (USB+ and USB-) have been swapped out for I2C pins (SDA and SCL). This means that the P1_6 and P1_7 pins required for the BLE112's software I2C should not be used for that purpose, but instead you should use the dedicated hardware I2C pins. No changes to the BGScript or BGAPI commands are necessary to take advantage of this difference; it will be handled automatically.
Finally, the module's P1_0 and P1_1 pins must not be used by your application (and they are not externally available on the module), or else the radio will not operate correctly. If you have moved a previously working project to the BLE121LR and find that the RF range is essentially zero, this is usually the reason. Make sure that P1_7 is also assigned to regulator control in the PMUX setting as described above.
The main thing you have to change in your BLE project's main definition file (usually project.xml or project.bgproj) is to add or modify the device type line. For projects meant for the BLE121LR, this file should include the following line:
<device type="ble121lr-m256k" />
Without this, it will not flash properly onto a BLE121LR. In many of our example projects, you will see multiple project definition files, one of which includes "121lr" somewhere in the name. This makes it easy to reuse the same set of XML files and BGScript files so that the same project can be easily flashed onto either kind of module.
The TX power range for a BLE121LR is 0-9, instead of 0-15 on the BLE112 or 0-14 on a BLE113. This has to do with the actual division of power settings that are available given the unique RF design of the 121LR. If you use a value greater than 9 on a BLE121LR, the stack will behave exactly the same as if you had used 9, so there is no risk of damage or reduce power or anything of that nature.
The other change is to make sure that your hardware.xml definition and (if applicable) your BGScript source file do not enable or reference the USB port or endpoint, as this will not work.
Finally, since P1_7 is reserved for DC/DC converter control (this pin is now in fact labeled "DCDC" in the datasheet), ensure that you do not need or attempt to use the USART1/Alt2 peripheral arrangement. These "alternate" configurations require the use of P1_7, which is not allowed.