There are ~100 Knowledge Base Articles (KBAs) in the Bluetooth section of the forum on a diverse range of sub-topics. We know they are sometimes challenging to find, especially when you don't know what exists (and therefore you don't search for it).
To simplify this task we have created a Bluetooth Knowledge Base Article List which has all the KBAs divided into sub-topics. This list only contains KBAs which are meaningful today, so you won't find anything related with SDK 1.x, BGScript or anything else which has been deprecated. Most of those KBAs are still here but their title has been marked with a "[Deprecated]" prefix and a Note pointing for a more updated KBA where applicable. This is to avoid confusing our customers into reading material which is no longer applicable.
It would be great to hear if you find this list useful and any thoughts you might have on how to improve it.
This version has some feature improvements, but these improvements required that we make some changes to the GATT attributes. Because of this, some phones may experience connection problems after the BGX13 firmware is updated.
Reason for Problem
Some mobile devices remember the GATT attributes of devices that have been paired or bonded in the past. When the GATT attributes are changed after the 1.2 update, the mobile device cached GATT information is misaligned between the two devices. This causes invalid handles to bluetooth services and characteristics. As a result attempts to connect to the device may no longer work, or some feature may not work such as sending or receiving data between a phone and the specific BGX for which this invalid bonding exists.
Invalid/misaligned bonding data must be cleared and then the bond should be re-established using the correct GATT attributes.
Solution
The problem may manifest in the following ways.
On iOS, you may see a message on the device details screen reading "SOME_OTHER_MODE".
On either Android or iOS, you may also see a password dialog appear at an inappropriate time or when no password has been set. You might also see that data is not being sent from the phone to the BGX or from the BGX to the phone.
To solve this problem, perform the following operations:
If you have access to the BGX command line interface such as through a Terminal emulator connected to the serial interface, enter the command 'clrb' to clear the bonding information from the BGX.
On your phone, open the Bluetooth Settings and locate the BGX device. Click a "i" icon, gear icon, or other details icon for the device in the Bluetooth settings and choose "Forget" or "Unpair".
On your phone, turn Bluetooth off and then back on. This has been particularly noted as a necessary step on iOS 13. Alternatively, you could reboot the phone itself. However, rebooting is not a substitute for "forgetting" the device in the Bluetooth settings.
Kill the BGX Commander app as you would any app on your iOS or Android phone.
Restart BGX Commander and re-connect to the device. It should work correctly now.
After testing, I removed the soc-thermometer example and put my custom project on the first board. It too has a Health Thermometer service and Temperature Measurement characteristic, exactly identical to the original example. The problem is the now the service is not discovered by the second board. The gecko_cmd_gatt_discover_primary_services_by_uuid command is issued but the gecko_evt_gatt_service_id event never happens.
If I use nrfConnect on a tablet to connect o my custom project, I can see Health Thermometer Service. So my custom project is not completely dead etc.
So why can I discover a service from the tablet app and not from my Multi-Slave Multi Master example code?
In Mesh SDK 1.6.1 I saw in mesh_sizes.h that there were added six new mesh size constants (MESH_MEMSIZE_LC_CLIENT, MESH_MEMSIZE_LC_SERVER, MESH_MEMSIZE_LC_SETUPSERVER, MESH_MEMSIZE_SCENE_CLIENT, MESH_MEMSIZE_SCENE_SERVER and MESH_MEMSIZE_SCENE_SETUP_SERVER).
However, later in the definition of BT_MESH_HEAP_SIZE these six constants are added, but MESH_MEMSIZE_LC_SERVER is added twice and MESH_MEMSIZE_LC_SETUPSERVER is missing:
the rpl size affects the RAM and the PS. The replay protection list stores the sequence numbers received from each peer the node communicates with. Does this value affect every node in the mesh network? Is it possible to switch off the effects of this value (like reserving PS and RAM) or turn of the replay protection? Why should a LPN use this value? Is it possible to implement your own replay protection or switch to an other RPL with a different size?
We use the BGM13P as µC and the and the Bluetooth Mesh SDK 1.5.3.
as a LPN our device consumes appro 12mA in EM0 and appro 0.9mA in EM2. Now I want to use this device as a normal Node and put it in EM2 manually. If i use the functions functions SLEEP_Sleep(), EMU_EnterEM2(false) the device "works" like a (no BL Mesh messages, no HF Oscillators, ...) but the device consumes farther appro 12mA.
So here is the question: How did I get into the EM2 Mode and reduce the electricity consumption?
I'm currently working on enhancing the nodes in my Bluetooth mesh with the ability to scan for extended advertisements. Since I'm having trouble combining the mesh communication and the scanning for extended advertising packets I was wondering if anyone has already done that. I've tried to modify the priorities in various ways like the article https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2018/09/28/bluetooth_radio_task-snmO suggests. Nevertheless, I still do not get any mesh messages with extended advertisement scanning enabled. I've even tried to make the scan_interval much bigger than the scan_window using the function gecko_cmd_le_gap_set_discovery_timing but even when no extended advertisements are reported no mesh messages are received.
All hints are very much appreciated.
Best regards
PS: here are the details on the setup:
SDK version: Bluetooth Mesh: Bluetooth 2.12.4.0, Micrium OS Kernel 5.7.0 (v1.5.3)
Part number: BGM13P22F512GE
PPS: I hope it's okay that I've opened a new post for this matter. My previous question was closely related but still a different question.
I'm working on a wearable device equipped with a EFR32MG12 and I'm using OTA DFU to upgrade the firmware. The board
is powered on by the means of a pushbutton and the firmware drives a GPIO output to hold on the power, so the circuit
remains working after the releasing of the pushbutton. Once done that, there is nothing exciting to see, except for two
leds that turn on.
So, to upgrade the application, I first generate the application.gbl then I load it into my smartphone and start the OTA
thru Blue Gecko app.
The upgrade terminates successfully ONLY IF I KEEP THE PUSHBUTTON PRESSED until the end of transfer. Otherwise
the chip resets - I see two leds turning off after starting OTA - so the power hold GPIO pin is cleared too and the
circuit shuts off.
To call the appLoader, I currently use the following code:
/* Check if need to boot to OTA DFU mode */
if(boot_to_dfu)
{
/* Enter to OTA DFU mode */
gecko_cmd_system_reset(2);
}
that is the suggested way to start the appLoader, but to avoid such reset I need an alternative.
How could make my application jump in a polite way directly into appLoader code without performing a reset?
I have had repeated issues with using the coded phy modes in the example projects. I would like to implement the 125kbps or 500kbps phy for maximum connection reliability. It is very unstable when compared to the 1M phy mode which contradicts the spec. I had another post on this that identified the connection interval minimum to be 20ms for the 125kbps mode. However, it still seems unstable when compared to the 1M mode. I have been looking at the network analyzer for more insight as to why this is and there seem to be several things wrong that I do not understand.
Below is an image of the network transactions in 1M phy mode, everything is working as expected:
Below is an image of the network traffic with the only change being the phy configuration in 500kps mode:
I am trying to understand why there are packet retransmission errors and what the packet out of sync error means. I can not find any information on these errors.
Additionally, if the connection is stressed (measured RSSI between -70dbm and -80dbm) there are invalid frame and field length overflow errors, followed by a disconnection from supervision timeout (Shown below). Note, this same test can be done with the 1M phy mode with only retransmission errors and never results in a disconnection.
I would like to understand what is happening here so I can successfully use the coded phy 500kbps or 125kbps mode. Any help with this would be greatly appreciated.
Info on setup:
- 2 xGM210P032 Radio Boards with wireless starter kit
- Gecko Suit v2.7.0
- Running soc-thermometer-rtos and soc-thermometer-client examples with connection interval 20ms, AFH enabled with 200ms scan interval, +20db tx, and 500kbps phy.
- Attached is main.c from my modified client example
Forum
Bluetooth Knowledge Base Article List
There are ~100 Knowledge Base Articles (KBAs) in the Bluetooth section of the forum on a diverse range of sub-topics. We know they are sometimes challenging to find, especially when you don't know what exists (and therefore you don't search for it).
To simplify this task we have created a Bluetooth Knowledge Base Article List which has all the KBAs divided into sub-topics. This list only contains KBAs which are meaningful today, so you won't find anything related with SDK 1.x, BGScript or anything else which has been deprecated. Most of those KBAs are still here but their title has been marked with a "[Deprecated]" prefix and a Note pointing for a more updated KBA where applicable. This is to avoid confusing our customers into reading material which is no longer applicable.
It would be great to hear if you find this list useful and any thoughts you might have on how to improve it.
Additionally please check out our Bluetooth training page -> https://www.silabs.com/support/training/bluetooth
BGX13 v1.2 Upgrade Issues
Problem
Some mobile devices may have connection problems after updating BGX13 to 1.2.2045.0.
SIlicon Labs recently updated the firmware for BGX13 to version 1.2.2045.0.
https://docs.silabs.com/gecko-os/1/bgx/latest/release-notes
This version has some feature improvements, but these improvements required that we make some changes to the GATT attributes. Because of this, some phones may experience connection problems after the BGX13 firmware is updated.
Reason for Problem
Some mobile devices remember the GATT attributes of devices that have been paired or bonded in the past. When the GATT attributes are changed after the 1.2 update, the mobile device cached GATT information is misaligned between the two devices. This causes invalid handles to bluetooth services and characteristics. As a result attempts to connect to the device may no longer work, or some feature may not work such as sending or receiving data between a phone and the specific BGX for which this invalid bonding exists.
Invalid/misaligned bonding data must be cleared and then the bond should be re-established using the correct GATT attributes.
Solution
The problem may manifest in the following ways.
On iOS, you may see a message on the device details screen reading "SOME_OTHER_MODE".
On either Android or iOS, you may also see a password dialog appear at an inappropriate time or when no password has been set. You might also see that data is not being sent from the phone to the BGX or from the BGX to the phone.
To solve this problem, perform the following operations:
Also refer to https://docs.silabs.com/gecko-os/1/bgx/latest/firmware-update#problems-after-upgrade
Tips for troubleshooting and asking questions
1. Clarify to yourself what the specific issue is.
2. Apply basic troubleshooting:
3. Consult the datasheets and reference manuals. Sources include:
4. Search to see if someone has asked the same question already.
5. Include the relevant parts of your development setup in the problem description. Examples include:
6. Include steps to reproduce the problem or specific conditions the problem occurs in.
7. Be patient and avoid making duplicates of your question.
For general community usage please refer to the Silicon Labs Community Guidelines.
Cannot discover services on remote Gatt server
Hello,
I am running the soc-thermometer example on a BGM13P22F512GA WSTK board. On a second BG13P22F512GA + WSTK board I am running the Multi-Slave Multi Master example given here (https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2016/12/01/multi-slave_multi-ma-HjAO)
Every thing works fine and as expected. After the connection is made, the following events occur and commands are given:
EVENT: gecko_evt_le_connection_opened_id
ISSUING COMMAND: gecko_cmd_gatt_discover_primary_services_by_uuid
EVENT: gecko_evt_gatt_service_id
EVENT: gecko_evt_gatt_procedure_completed_id
connState: discoverServices
ISSUING COMMAND: gecko_cmd_gatt_discover_characteristics_by_uuid, service handle:1114132
EVENT: gecko_evt_gatt_characteristic_id
EVENT: gecko_evt_gatt_procedure_completed_id
connState: discoverCharacteristics
ISSUING COMMAND: gecko_cmd_gatt_set_characteristic_notification, thermometerCharacteristicHandle: 19
EVENT: gecko_evt_gatt_procedure_completed_id
connState: enableIndication
connState: scanning
After testing, I removed the soc-thermometer example and put my custom project on the first board. It too has a Health Thermometer service and Temperature Measurement characteristic, exactly identical to the original example. The problem is the now the service is not discovered by the second board. The gecko_cmd_gatt_discover_primary_services_by_uuid command is issued but the gecko_evt_gatt_service_id event never happens.
If I use nrfConnect on a tablet to connect o my custom project, I can see Health Thermometer Service. So my custom project is not completely dead etc.
So why can I discover a service from the tablet app and not from my Multi-Slave Multi Master example code?
Thanks.
RAM expansion
Hey,
is it possible to use external RAM with the BGM13P22? If so what are the requirements for the RAM and in the software?
Kind regards
definition of BT_MESH_HEAP_SIZE
In Mesh SDK 1.6.1 I saw in mesh_sizes.h that there were added six new mesh size constants (MESH_MEMSIZE_LC_CLIENT, MESH_MEMSIZE_LC_SERVER, MESH_MEMSIZE_LC_SETUPSERVER, MESH_MEMSIZE_SCENE_CLIENT, MESH_MEMSIZE_SCENE_SERVER and MESH_MEMSIZE_SCENE_SETUP_SERVER).
However, later in the definition of BT_MESH_HEAP_SIZE these six constants are added, but MESH_MEMSIZE_LC_SERVER is added twice and MESH_MEMSIZE_LC_SETUPSERVER is missing:
MESH_MEMSIZE_LC_CLIENT + MESH_MEMSIZE_LC_SERVER + MESH_MEMSIZE_LC_SERVER +\
MESH_MEMSIZE_SCENE_CLIENT + MESH_MEMSIZE_SCENE_SERVER + MESH_MEMSIZE_SCENE_SETUP_SERVER +\
This should be fixed (if not yet done) to the following, right?
MESH_MEMSIZE_LC_CLIENT + MESH_MEMSIZE_LC_SERVER + MESH_MEMSIZE_LC_SETUPSERVER +\
MESH_MEMSIZE_SCENE_CLIENT + MESH_MEMSIZE_SCENE_SERVER + MESH_MEMSIZE_SCENE_SETUP_SERVER +\
Thanks.
Details about BGM210 Bluetooth 5.1
Hi Silicon Labs,
I'm Kishore D from Yana Mobility India Pvt Ltd located in India, Hyderabad.
Am working on BGM210 Product.
1. Does this product supports Direction finding ? If yes, how can we find Direction using BGM210. Is there any example available for validation ?
2. Does this Device supports minimum of 50 meters Range ?
Thanks & Regards
Kishore D
Rpl Size on mesh devices
Hey,
the rpl size affects the RAM and the PS. The replay protection list stores the sequence numbers received from each peer the node communicates with. Does this value affect every node in the mesh network? Is it possible to switch off the effects of this value (like reserving PS and RAM) or turn of the replay protection? Why should a LPN use this value? Is it possible to implement your own replay protection or switch to an other RPL with a different size?
Kind regards
Going into other Energy Modes
Hey,
We use the BGM13P as µC and the and the Bluetooth Mesh SDK 1.5.3.
as a LPN our device consumes appro 12mA in EM0 and appro 0.9mA in EM2. Now I want to use this device as a normal Node and put it in EM2 manually. If i use the functions functions SLEEP_Sleep(), EMU_EnterEM2(false) the device "works" like a (no BL Mesh messages, no HF Oscillators, ...) but the device consumes farther appro 12mA.
So here is the question: How did I get into the EM2 Mode and reduce the electricity consumption?
JSON string
Hi,
I need to send/receive the JSON string between two BLE endpoints (Blue Gecko device to mobile app).
What is the recommended GATT service to be used to achieve this type of transaction?
Also please let me know the GATT example project to share the file via v5.0.
Thanks,
Ganesh
Flash Lifetime Estimator
Hi!
This document: UG103.7: Non-Volatile Data Storage Fundamentals
claims that there exists an excel sheet (ug103-07s-token-lifetime-estimator-efr32-series1.xls)
that can be used to estimate wear-out for flash memory.
By searching the forum I was unable to find the excel sheet. Could you pls provide that?
Thanks
-Eki
BLE mesh: extended advertising scanner
Hello,
I'm currently working on enhancing the nodes in my Bluetooth mesh with the ability to scan for extended advertisements. Since I'm having trouble combining the mesh communication and the scanning for extended advertising packets I was wondering if anyone has already done that. I've tried to modify the priorities in various ways like the article https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2018/09/28/bluetooth_radio_task-snmO suggests. Nevertheless, I still do not get any mesh messages with extended advertisement scanning enabled. I've even tried to make the scan_interval much bigger than the scan_window using the function gecko_cmd_le_gap_set_discovery_timing but even when no extended advertisements are reported no mesh messages are received.
All hints are very much appreciated.
Best regards
PS: here are the details on the setup:
PPS: I hope it's okay that I've opened a new post for this matter. My previous question was closely related but still a different question.
Alternative way to start OTA DFU?
Hello,
I'm working on a wearable device equipped with a EFR32MG12 and I'm using OTA DFU to upgrade the firmware. The board
is powered on by the means of a pushbutton and the firmware drives a GPIO output to hold on the power, so the circuit
remains working after the releasing of the pushbutton. Once done that, there is nothing exciting to see, except for two
leds that turn on.
So, to upgrade the application, I first generate the application.gbl then I load it into my smartphone and start the OTA
thru Blue Gecko app.
The upgrade terminates successfully ONLY IF I KEEP THE PUSHBUTTON PRESSED until the end of transfer. Otherwise
the chip resets - I see two leds turning off after starting OTA - so the power hold GPIO pin is cleared too and the
circuit shuts off.
To call the appLoader, I currently use the following code:
/* Check if need to boot to OTA DFU mode */
if(boot_to_dfu)
{
/* Enter to OTA DFU mode */
gecko_cmd_system_reset(2);
}
that is the suggested way to start the appLoader, but to avoid such reset I need an alternative.
How could make my application jump in a polite way directly into appLoader code without performing a reset?
ps. i'm using gecko sdk suite 2.5
Giuseppe
Save current replay protection list?
Hey,
chapter cmd_mesh_node_save_replay_protection_list of the mesh sdk states that the replay protection list must be saved before a device is turning off.
What happens if an unwanted power off occours (battery is empty, out of mesh range)?
Is this really necessary or does the mesh network work without this command?
PHY Coded Modes Instability Root Cause?
Hello,
I have had repeated issues with using the coded phy modes in the example projects. I would like to implement the 125kbps or 500kbps phy for maximum connection reliability. It is very unstable when compared to the 1M phy mode which contradicts the spec. I had another post on this that identified the connection interval minimum to be 20ms for the 125kbps mode. However, it still seems unstable when compared to the 1M mode. I have been looking at the network analyzer for more insight as to why this is and there seem to be several things wrong that I do not understand.
Below is an image of the network transactions in 1M phy mode, everything is working as expected:
Below is an image of the network traffic with the only change being the phy configuration in 500kps mode:
I am trying to understand why there are packet retransmission errors and what the packet out of sync error means. I can not find any information on these errors.
Additionally, if the connection is stressed (measured RSSI between -70dbm and -80dbm) there are invalid frame and field length overflow errors, followed by a disconnection from supervision timeout (Shown below). Note, this same test can be done with the 1M phy mode with only retransmission errors and never results in a disconnection.
I would like to understand what is happening here so I can successfully use the coded phy 500kbps or 125kbps mode. Any help with this would be greatly appreciated.
Info on setup:
- 2 xGM210P032 Radio Boards with wireless starter kit
- Gecko Suit v2.7.0
- Running soc-thermometer-rtos and soc-thermometer-client examples with connection interval 20ms, AFH enabled with 200ms scan interval, +20db tx, and 500kbps phy.
- Attached is main.c from my modified client example