RoadTest: Silicon Labs Bluetooth Design Kit
Author: BigG
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Microchip's RN4870/1 would be very similar (BLE 5.0) with it's AT commands and a data streaming mode. Laird Connectivity have a range of BLE 5.x modules too which use a type of Smart Basic for logic control etc. Then there are maker options, although they use BLE 4.x, such as Seeed Studio's BLE Grove module (UART) and Adafruit's Bluefruit modules (SPI/UART) which use an AT command set and have a data streaming mode.
What were the biggest problems encountered?: The Android Commander app is not great. There is no feedback to tell you the app is scanning for devices. Then, if you decide to disable the BGX13P encryption (i.e. no pairing required) for more open access, the Commander app can connect but will not read the data. Thus the app cannot be used in this case. There were also a few bugs with some of the BGX13P API commands. These are now being dealt with by Silicon Labs technical support, which are very helpful.
Detailed Review:
As a wireless serial bridge, the Silicon Labs Bluetooth Wireless Xpress BGX13P is certainly no dinosaur. The BGX13P22GA is a pre-certified Bluetooth 5 System-in-Package (SiP) module, which incorporates its own internal firmware to provide you with a fast and energy efficient wireless serial link with no programming required. It comes with it's own custom abstracted API or command set, which gives you control over parts of the BLE stack, such as adjusting PHY bit rates for faster/slower data throughput to suit application.
The BGX13P22GA integrates a high performance chip antenna, which (according to the datasheet) requires minimal PCB, plastic, and metal clearance. The total PCB area required by BGX13P is only 51 mm2. This module is a simple serial replacement offering Bluetooth connectivity, so, all you have to do is attach the module to a serial port and you are good to go.
For this road test we were provided with a Wireless Xpress BGX13P Starter Kit together with the EFM8 Universal Bee Starter Kit.
For my roadtest review, I set out to first ascertain the ease and speed of development using the tools and documentation provided. Then once familiar with how things worked, I expanded and tested my knowledge with some simple projects.
As with any new product, we are often biased in our approach based on the familiarity of other related products, and I'm no different. I've certainly used quite a few wireless serial bridges in the past, with varying degrees of success, so I was very intrigued to see how well the GBX13P Starter Kit worked.
With this bundle, I wrote up a “first dates” review shortly after receiving the products. It highlights my first impressions, knowing little about how things worked. Much progress has been made since.
So, let's dive into the detail.
The SLEXP8027A is a development board that includes the BGX13P module. The development board also includes:
The User's Guide provides a handy pinout reference for the expansion header. This pinout reference is also provided on the reverse side of the PCB.
All GPIO's are digital only. There is on ADC/Analogue options available. The buttons and LED's are linked to the BGX13P GPIO's as follows:
According to the BGX13P datasheet, we have the following specs:
| Parameter | Symbol | Test Condition | Min | Typ | Max | Units |
|---|---|---|---|---|---|---|
Operating ambient temperature range | TA | -40 | 25 | 85 | °C | |
| VDD operating supply voltage | VVDD | 2.4 | 3.3 | 3.8 | V | |
Active supply current, Unconnected, Idle | IACTIVE_IDLE | Baud rate ≤ 9600 bps Baud rate > 9600 bps | 3 3.25 | μA mA | ||
| Active supply current, Advertising | IACTIVE_ADV | Interval = 546.25 ms, Baud rate ≤ 9600 bps Interval = 546.25 ms, Baud rate > 9600 bps Interval = 20 ms, Baud rate ≤ 9600 bps Interval = 20 ms, Baud rate > 9600 bps | 90 3.3 2 4.7 | μA mA mA mA | ||
Active supply current, Connected (15 ms Interval) | IACTIVE_CONN | Idle, Baud Rate ≤ 9600 bps Idle, Baud Rate > 9600 bps TX/RX (ack'd) at highest throughput, Baud Rate ≤ 9600 bps TX/RX (ack'd) at highest throughput, Baud Rate > 9600 bps TX/RX (NOack) at highest throughput, Baud Rate ≤ 9600 bps TX/RX (NOack) at highest throughput, Baud Rate > 9600 bps | 660 3.5 3.5 5.25 4.0 7 | μA mA mA mA mA mA | ||
| Maximum TX power | POUTMAX | 8 | dBm | |||
Total current into supply pins Total current into ground pins | IVDDMAX IVSSMAX | source sink | 200 200 | mA mA | ||
| Current per I/O pin | IIOMAX | source sink | 50 50 | |||
| I/O pin pull-up/pull-down resistor | RPUD | 30 | 40 | 65 | kΩ |
According to datasheet, the BGX13P can be reset by three different methods:
The reset state in BGX13P does not provide any power saving functionality and is not recommended as a means to conserve power. BGX13P has an internal system power-up reset function. The RESET pin includes an on-chip pull-up resistor and can be left unconnected if no external reset switch or source is used. This now explains the reason behind "quirky" behaviour of the RESET button on the starter kit, which I noticed during my "first dates" video.
In this section I take a top-down approach, starting with a look at the website and the documentation. I then finish off with a review of the abstracted Command API and the Commander App.
As mentioned in the “first dates” blog, the Wireless Xpress BGX13P Starter Kit comes with a “Get started!” business card style insert with a website URL. Typing this URL into a browser, brings you to the Bluetooth Xpress framework landing page.
I found the design of this landing page to be very good. In fact I found the Silabs.com website to be very well designed.
This page provides you with a clearly presented 6-step process to get you started, from options to purchase the product through to download options and videos. The steps were covered in my "first dates" blog.
However, delving deeper, as I tend to do, I found a few anomalies on the website. These are just general pointers I found relating to navigating around the silabs website. If you are not interested, move on to the next section.
The first is the website hierarchy. On the Bluetooth Xpress page the hierarchy is shown as:
Silicon Labs » Support » Getting Started with Silicon Labs Products » Bluetooth » Bluetooth Xpress
Now, if you clicked on “Bluetooth” (as in, Silicon Labs » Support » Getting Started with Silicon Labs Products » Bluetooth) it takes you to a web page that then does not give you “Bluetooth Xpress” as a click down option. As such, the “Bluetooth Xpress” page appears to an enigma that can only be found via the “get started” link. Maybe this is an oversight, so thought it was worth pointing out as it is these sort of things that create confusion and you could find yourself lost on the website if you then want to get back to the Bluetooth Xpress framework page.
The second website structure anomaly is found on the SLEXP8027A (BGX13P) product page. Here it lists information about the BGX13S Arduino Shield. This is a little confusing, in my opinion, as my rationale sees the BGX13P and BGX13S products as subsets of the Bluetooth Xpress framework. As such, I would've thought that the BGX13S information should be placed on the Bluetooth Xpress framework page as a drill down option.
Then on the Bluetooth Xpress support webpage there is also no link to this page, which provides guidance on the difference between BGX13P and BGX13S:
https://www.silabs.com/wireless/bluetooth/bgx13-wireless-xpress-modules
I think this page is really helpful in describing the subtle differences between the two modules.
As shown on the Bluetooth Xpress webpage, there are four documents available for reference:
Overall, I found the documentation to be excellent but maybe a little repetitive with each document containing something slightly different about the same subject matter (e.g. Xpress Configurator). This was somewhat frustrating as, when learning, you would recall something that answered a question but then you could not remember which document contained that specific detail.
Then there was one issue I had within the Data Sheet.
This has to do with interoperability and the use of standards. The data sheet notes on page 1 that BGX13P modules can be used in a wide variety of applications and then lists a range of possibilities including health, sports, and wellness devices. While this is certainly technically possible, if you are going to use a BGX13P module for this purpose you will essentially be bypassing the standardised Bluetooth Low Energy GATT services and characteristics provided for Health, sports, and wellness devices as the BGX13P only provides its own custom GATT Service and Characteristics. As such, I would not recommend these as viable applications if you want to be fully compliant with the Bluetooth Low Energy standards and allow for interoperability.
The Xpress Command API Reference can be accessed via the Bluetooth Xpress landing page (use silabs.com/start-bgx to get you there - under Bluetooth Xpress Resources).
For all my development work using the BGX13P Starter Kit I relied very heavily on this guide.
There is everything you need here from functional guides through to application examples. So, if you want to do anything with the BGX13P Starter Kit this is where you need to focus your effort. Thankfully, I found the structure and content to be very good and well thought out.
The menu on the left is split into four categories of interest for a developer (there's also a fifth, Revision History):
The BLE services section is particularly helpful if you want to create you own mobile phone app or if you want to use your own BLE central controller. This sections explains the GATT services and characteristics used by the BGX13P module.
The command and variable reference is really nicely structured and I found this to be my goto reference. The only thing I sometimes ponder over is why the use of a verbose response such as "[STREAM_MODE]" and "[COMMAND_MODE]" when all the commands use nicely abbreviated syntax. Surely "[S_M]" and "[C_M]" would have been more efficient.
Another section I found rather important, when creating your own central control device application, is the Xpress Streaming Service Flow Control section. The methodology applied here is unique to the Bluetooth Xpress framework and you will need to understand how it works, especially with the initial exchange of Transmit Byte Available (TBA) and the use of an Initial Buffer Size Control Message and then the Buffer Bytes Freed Control Messages. See my ESP32 write and read demos (shown later) which had to apply this logic to work. Note that the BGX Commander app handles this all for you. Similarly, if you used another BGX13P as your central controller device. This is all taken care of.
I'll be looking more at the Application Examples in the next section.
The marketing pitch for the BGX13P22GA module makes the claim that this is a “zero programming device”. While the Quick Start Guide (QSG161) introduces us to the building blocks to help us get started, it does not offer any examples to demonstrate this feature.
As such, I wanted to see if this was indeed true, and so I created a simple test case of replacing a serial link with the BGX13P Starter Kit and used the Commander App to see if I would get the serial data stream without any coding. The result confirms that it is indeed a zero programming module, which can auto switch to streaming mode (unlike many other modules out there).
But this project merely proves the BGX13P22GA as a serial bridge. It does help me learn how I can apply the other features that are available on the Starter Kit.
Unfortunately, there is very little guidance in the four PDF documents (see Review of Documents section) or on the Silicon Labs to assist you with application development wayfinding.
To explain my rationale, here is what I found in the documentation.
Buried within the Starter Kit User's Guide (UG369) are references to ready made examples, which can be used to test functionality. For example, in section 4.3 it makes mention of an EFM8 example (BGX13P demo) which you can use with a EFM8 Starter kit connected to the BGX13P starter kit. The User's Guide provides no detail though on what this example does.
Here is a video, capturing the output from this example when also using the Energy Profiler Tool (I spotted this tool being mentioned at the end of the User's Guide and in the Application Note AN1157):
Section 5 of the User's Guide covers the peripherals. Now, as the Starter Kit comes with 2 LED's and 2 User Buttons, I would have expected to see some examples provided to allow the user to test the use of these peripherals. Unfortunately, the User's Guide provides no tutorials and throws you in the deep end with random commands that you know little about.
I was rather disappointed with what is provided here as my first goal, as a newbie, was to simply blink an LED as being biased from other development boards. I thought that this would be straightforward and it would be a good starting point to test that these LED's work and then build from there. So, it became a rather frustrating process to find information about how to do this. From the look of things, the primary purpose of the LED's is to show the BLE module's advertising or connection status and to show when data is streaming. These are indeed extremely useful features, especially with the configuration, but it is not highlighted here in the User's Guide. Instead it is partially alluded to in the Application Note (AN1157) and the detail is buried within the Xpress Command API reference.
The Xpress Command API reference, on the other hand, has a dedicated section for Application Examples. Within this section, four use-cases are provided:
The BGX to Phone use case is a temperature sensor demo. The demo functionality described in this section as follows:
It begins by initializing the host MCU and BGX. The user begins the demo by pressing push button 1 (PB1) on the host MCU. The host MCU will send an advertise command to the BGX via UART. This allows the mobile app to find the BGX and connect to it. Once connected, the host MCU will continue to collect and send temperature readings to the mobile app every 2 seconds. The temperature reading will revolve around a 1-point calibration that resides in the MCU flash memory. The user can write a 1-point calibration to the MCU using BGX Commander. If the MCU detects this incoming calibration data, it will recalibrate the temperature based on the user's new 1-point calibration. All low power features integrated within this process are discussed later.
This description is followed by a nice looking flow chart and we are then informed that this demo requires the use of an EFM8SB1 Starter Kit. This is a little baffling to say the least as any of the EFM kits could be used to connect with the BGX13P Starter Kit via the expansion header. In fact any MCU could be used if it has an ADC and you had your own analogue temperature sensor.
But, what's even more baffling is that no reference is given as to where to get the code. Is this something the user does themselves or is this a ready made example. If it is a ready made example then what is the name of the example and where to you find it. All we have is a functional overview highlighting various features. It provides no explanation on the how to. So this was not much use to me.
The BGX-to-BGX use case is a Smart Light Demo. This looks to be a great example as it demonstrates the application of the different PHY settings available and this “multi-set” advertising feature. I was not able to test this as I did not have two BGX13P starter kits (need one as a central device and one as a peripheral device).
In the overview section, we are presented with a video. This is worth watching just to understand how the different PHY settings can be applied and it tells us what the “multi-set” advertising feature is about.
This time, we are given a link to the code, which is found on their GitHub repository: https://github.com/SiliconLabs/wireless-xpress/tree/master/products/BGX13/demos/longrangedemo.
This example also walks through the different BGX commands needed to make this example work. This is what I would have expected with the Temperature Sensor demo example.
The 3rd use case is the Xpress Connect And User Functions (UFU) Demo. Unfortunately to follow this example verbatum requires two BGX13P Starter Kits.
However, it is well worth reading through this example as it tells us how to configure the LEDs to blink or remain on depending on the BLE advertising and connection settings. It also introduces us to the “User Functions” settings. These user functions are unique to the BGX13P command API so it's useful to know how to do it.
Finally, the 4th use case is an I2C bridge example, which is an I2C Hall Effect Sensor Demo. I did not have an I2C Hall Effect sensor but I did try this out with an old BMP085 sensor breakout board.
Unfortunately, I could not get my BGX13P module to communicate with my sensor. I eventually worked out that the reason for this is how the BGX13P configures the GPIO's when you apply the command “gfu 4 i2cm_scl” and “gfu 5 i2cm_sda”. It sets these pins high by default and enables the pull up resistors. When I changed the default setting to low and disabled the pullups (as my sensor breakout board already included pullups), I was at least able to communicate with the sensor.
This latest version (2.30) was a real disappointment. I never tested the IOS app but from the screenshots I've seen it appears to be better developed. That said, I found the BGX13P OTA firmware update facility to be plain sailing, once you got the app connected with your device.
This Android app offers the most basic bare minimum. In fact, it really is just a template as more could readily be done with it. For those wanting to develop this Android app further, all the files are available on Silicon Labs GitHub page. Further information is also provided on the Bluetooth Xpress webpage (see Xpress Command API Reference - BGXpress Host Software).
The Android Commander app, from a user experience perspective, is dreadful. I honestly thought at first that this app was not working. Firstly, you get no indication what the Android app is doing. This is a screen shot of the app scanning for BGX13P compatible devices. If you push the app to the background and then reload after a few minutes you will spot a small “toast” simple telling you “Scan Failed. Error:1”. This happens if it cannot detect a BGX13 module.
If you have Bluetooth disabled on your phone you will get a message telling you this. However, the app does not allow you to switch Bluetooth on to continue. You have to close the app completely first then enable Bluetooth and then reload the app.
When you download the app it will inform you that for Bluetooth to work it requires the “location” setting to be turn on (applies from Android 6.x). However, the app makes no check to see that location is actually turned on or off at run time. As such, if you turn off location, as I do by default, the app does nothing. You will eventually get the same Scan Failed message. In this case, you can turn on your location setting while the app is loaded and it will then detect your device.
The app works great in both portrait and landscape mode, although I found on a tablet device the streamed data received (black rectangle) is not responsive and does not scale accordingly. So it looks a little odd, in my opinion.
So for me, the app user experience really exposes the classic budgetary and user experience issues of trying to develop a common app for both IOS and Android phones, when using Swift for IOS and Android Studio for Android.
It cannot be done simply and it typically requires two development teams. Thus, in my opinion, if you take this approach it overrides the ease of development benefits you get from using a Bluetooth Xpress module for the complete project.
As such, my suggestion would be to consider newer frameworks, such as Flutter, which does offer a common development platform to deliver a similar user experience, or find something similar via the other webview type development frameworks. Another alternative is to consider using the Web Bluetooth API for easy and early stage evaluation and testing.
As we are provided with the BGX13P's GATT service and characteristic details, I wanted to see if I could connect with the BGX13P with another BLE central device. I decided to use an ESP32 for this test case as within Arduino we have a handy "BLE client" example available.
The secret ingredient to implement encryption which does not provide pin authentication is to add this line of code: BLEDevice::setEncryptionLevel(ESP_BLE_SEC_ENCRYPT);
You simply add this to the "connecToServer() function and we can then connect to a BGX13P module, when it's using the (default) "any" security mode setting:
bool connectToServer() {
Serial.print("Forming a connection to ");
Serial.println(myDevice->getAddress().toString().c_str());
/* Here we have implemented simplest security. This kind security does not provide authentication */
BLEDevice::setEncryptionLevel(ESP_BLE_SEC_ENCRYPT);
BLEClient* pClient = BLEDevice::createClient();
Serial.println(" - Created client");
pClient->setClientCallbacks(new MyClientCallback());
// Connect to the remove BLE Server.
pClient->connect(myDevice); // if you pass BLEAdvertisedDevice instead of address, it will be recognized type of peer device address (public or private)
Serial.println(" - Connected to server");
// Obtain a reference to the service we are after in the remote BLE server.
BLERemoteService* pRemoteService = pClient->getService(serviceUUID);
if (pRemoteService == nullptr) {
Serial.print("Failed to find our service UUID: ");
Serial.println(serviceUUID.toString().c_str());
pClient->disconnect();
return false;
}
Serial.println(" - Found our service");
// Obtain a reference to the characteristic in the service of the remote BLE server.
pRemoteCharacteristic = pRemoteService->getCharacteristic(charUUID);
if (pRemoteCharacteristic == nullptr) {
Serial.print("Failed to find our characteristic UUID: ");
Serial.println(charUUID.toString().c_str());
pClient->disconnect();
return false;
}
Serial.println(" - Found our characteristic");
// Read the value of the characteristic.
if(pRemoteCharacteristic->canRead()) {
std::string value = pRemoteCharacteristic->readValue();
Serial.print("Characteristic value: ");
//Serial.println(value.toInt());
Serial.println(value.c_str());
}
if(pRemoteCharacteristic->canNotify())
pRemoteCharacteristic->registerForNotify(notifyCallback);
connected = true;
return true;
}
Here are two videos demonstrating operation. The first is a write test, which is the more straightforward of the two.
The second demo is a read test. This is slightly more complex as you have to apply the logic described in the Xpress Streaming Service Flow Control section.
The Bluetooth Xpress framework is focused on providing fast and reliable data transfer using predefined custom GATT service, and this works really well. It is a great module for acting as a wireless serial bridge and the use of Bluetooth 5.x technology makes it just as capable as the original Bluetooth 2.0 SPP options but way more energy efficient.
While the BGX13P still follows some of the traditional Bluetooth SPP dinosaur methodologies, such as the requirement to switch between a command mode and a data stream mode, it has brought in some automation to make this a much more streamlined process. This certainly makes it easier to slot this module into an application that requires a serial wireless bridge but does not have the ability to manually switch modes if required.
You can tell this is a new module as it still has a few bugs to flush out the system. However there are some missed opportunities, which hopefully could be implemented one day. Namely, I would like to see the option for another GAP option so that a broadcasting feature could be used (i.e, implementation of Eddystone and iBeacon functionality) as not every application warrants connection with a device in order to transfer data.
Then, as it stands, I personally do not see this module as being suitable for health and fitness devices as you are not able to use the standardised GATT services and characteristics used for this purpose. In my experience, I have found that the standardisation of GATT service and characteristics for predefined Bluetooth applications really does help and using custom services/characteristics does not lend itself to a common approach. However, if custom services and characteristics want to be used in a open setting then it would be useful to include options to configure and define the intended data structure for the application (using UUID 2904: Characteristic Presentation Format). At the moment it simply assumes unsigned character transfer only. It would also be nice in some applications to inform the central device or client or user what the intended data represents by way of providing a custom description (UUID 2901). I believe the BGX firmware could be adapted to incorporate these options without adding additional complexity or additional resource constraints on the processor.
So, if you are looking for a fast and easy to use wireless Serial Bridge then I would highly recommend this one to be added to your short list.
Top Comments
Thanks.
Yes settings remain in ram during runtime and you can also save your settings in nvm for reuse if powered down.
https://docs.silabs.com/gecko-os/1/bgx/latest/commands#save
Serial also includes flow…
Exactly.
You could also try the sparkfun option too... it's without the MAX type chip... and without CTS/RTS: https://www.sparkfun.com/products/8780
Had a similar idea (because of 1.2mm pitch). I was…
…