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
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.
We have been trying to implement a demonstration of Wake-On-RF (RfSense) by following this knowledge base article:
KBA_BT_1009: Waking from Deep Sleep Using RF Sense
We have observed:
We would like to ask if you have any suggestions for us, as to what might be going wrong.
(We find it hard to believe that this chip is being manufactured and sold and advertised as having this RfSense feature being an important part of what makes it an ultra low-power device, if the feature is completely unusable.)
I have an intermittent issue that I've been debugging over the past few
days and welcome your input. The problem is that our application doesn't
receive an evt_le_connection_closed event if the connection drops
due to insufficient signal.
Server is a custom board with a BGM13S22 part on it. It's based off the
4305C radio board and has very few parts.
Client is a Google Pixel 2 running Android 10. Since the Blue Gecko app
doesn't work on Android 10, we're using the nRFconnect app to talk with it.
Server firmware is based off the soc-empty project in Simplicity.
SDK is 2.6.2 and compiled using the GNU ARM 7.2.1 compiler
The environment is harsh and the RSSI for the client-server connection is
weak (-90 to -100 dBm).
Details aside, our firmware has two basic states:
1. When we receive an evt_le_connection_opened event, we start sending
notifications to the client
2. When we receive an evt_le_connection_closed event, we stop sending
notifications and restart advertising so that the client can connect again
We often lose our connection because the RSSI is so weak. The problem we
see is that about every 50 times or so, we lose the connection but never
receive the evt_le_connection_closed event. Since we never receive the
"closed" event, we don't start advertising and the client can't connect
to our device again.
I captured the system counters for the passing case and the case where
we disconnect without the "closed" event. It looks like the packet counters
are incrementing in the passing case (probably advertising packets) when the
connection closes. In the case where the app doesn't receive the "closed"
event, we simply keep on sending notifications but they never get sent out
so the packet counters don't increment.
Our boards are encased in potting, so getting locked in this state where
we don't advertise locks up the system and kills the possibility to access
it. Our work-around is to observe the number of packets transferred during
our "connected" state. If the number of packets isn't incrementing, we issue
a hard-reset to the whole system to restart advertising.
Since the server app doesn't receive the evt_le_connection_close event, this
seems to be a bug in the BLE stack.
Questions for tech support:
1. What additional information can I capture from this issue to help you
determine the root cause of the problem in the BLE stack? Are there
any state variables or memory dumps that would help?
2. Is there a better way to "kick" the BLE stack into starting up again
instead of a full chip reset? Can we simply call the cmd_le_connection_close
function to force a disconnect? What about calling le_gap_start_advertising?
It takes us about two hours and seven boards to reproduce this issue. Any
suggestions for what information to gather to get to root cause would be most welcome.
Sorry for asking such a trivial question,
but in our custom board, we seem to be unable to change the output state of the PB11 and PB13 pins.
PB11 is always at VCC level and PB13 is always at GND level.
All other (non debug pins) can be used as GPIO as expected.
Updated Studio to latest version today.
Built SOC-empty for 4305c Dev Kit (and ran the script for gbl)
Built soc-smartphone for 4305c dev kit (and ran the script for gbl)
Built gecko bootloader 512K single image for 4305c
used Commander to erase the whole module and programmed using the COMBINED S37 file
Used Studio to program the module with soc-empty
downloaded the application.gbl file for soc-phone to my Galaxy S9+ and launched the BG Explorer App
Ran the scan and selected the Empty device
Tried to connect...failed...tried again...failed...rinse repeat a number of times...eventually it will connect and show the GATT table (sometimes it will bail at this point back to the scan screen)
Selected OTA update, selected partial OTA pointed to the application.gbl file, started the OTA
Rebooting...Waiting...Attempting...Rebooting...now stuck forever on the SCAN Screen showing 'OTA' - no error codes, no other indications...
Resetting dev kit at least shows the empty program. Rinse repeat to select and try OTA again.
Every now and then it will actually start the OTA and then fail without checking the END box on the screen. Then I have to start over with commander and erase, flash, etc.
Sometimes it will actually finish and successfully run the downloaded soc-smartphone application.
Any suggestions as to how to get more reliability and not brick the module and have to redo everything?
I have a custom board with a EFR32BG13P532F512GM48, that I have the DTM software running (based on KBA_BT_0917). I can successfully test most packet types, but the unmodulated types: 3 and 254; and type 253, fail to transmit. I am using the 184.108.40.206 SDK for this project.
I currently work on a Project,
where up to now we have used a 868Mhz signal in order to sync several slave units.
The master sends the sync signal once every 100ms,
and all slaves which have received the signal synchronize to it.
We get synchronicity/accuracy of around 1us doing it like this.
The new product series will be using a bluetooth module.
We would like to use the BGM13P32 module.
Since using a 868Mhz module AND a BLE module in the same product would be redundant,
especially since the 868Mhz module would do time synchronization only, I was wondering whether it is possible
to use the bluetooth module for time synchronization.
As far as I understand, it should technically be possible, since a broadcast from the master would be received at pretty much the same time by all slaves.
Is there a timer reset, or a pin interrupt, that happens at the exact time a ble broadcast packet is received?
Or is there an interrupt that is triggered with a constant delay after receiving the broadcast packet.
In my eagerness to try out the new Android 10 OS, I found out that it doesn't seem to support the Blue Gecko Android app any more.
When will a new app for Android 10 be available?
I´m working with BGM113A256V2 modules and last bluetooth SDK 220.127.116.11 version. In my project, I need to set different tx power levels.
Always I use "gecko_cmd_system_set_tx_power" function when the radio is in idle (not connected and not advertising) and always in the range from -6dBm (-60 function parameter value) to +3dBm (30 function parameter value).
It works fine except in this case. When I try change the power level from a previous value less or equal than 0 dBm to a value above 0 dBm, "gecko_cmd_system_set_tx_power" function always returns "-140". For example, I´m trying to set increase the power level from -6dBm to +3dBm.
I´ve noticed that if I call "gecko_cmd_system_set_tx_power" function 2 consecutive times, the second call works fine (I pass 30 parameter and returns 29, not 140)
EDIT: I just realized that it only happens when at least the radio has been advertising once
I am using BRD4161A board on top of WSTK development board. I am using this as NCP through default example_ncp_host present at "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\blemesh\v1.5\app\bluetooth\examples_ncp_host". My goal is to use Vendor model in NCP.
Following is the procedure that I followed
1. Created "Silicon Labs App Builder project"->"Bluetooth Mesh SDK"->"NCP - Mesh Empty Target" for BRD4161A board.
2. After creating project, ISC file opens up. Added a vendor model in the ISC file as shown below and generated the project
3. Compiled and loaded the project in the board.
4. Opened first terminal. Browsed to location "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\blemesh\v1.5\app\bluetooth\examples_ncp_host\ncp_daemon" and ran command "./exe/ncp_daemon.exe /dev/ttyS5 115200 encrypted unencrypted"
5. Opened second terminal. Browsed to location "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\blemesh\v1.5\app\bluetooth\examples_ncp_host\mesh-secure-ncp" and ran command "./exe/empty.exe ../ncp_daemon/unencrypted 0". This command gives following output
Resetting NCP target...
System booted. Calling node_init...
6. Code hangs up at Node Initialization. It does not go beyond.
If we don't add Vendor Model in the NCP Host project. Node initialization succeeds. Only adding Vendor model causes the application to fail. What step I am missing here which is causing this issue?
Note: Vendor Model with NCP was working previously, With latest updates NCP has started failing.
I am developing a product that, instead of using USB communication, will use Bluetooth communication.
For this, besides being paired, it is needed to create the virtual ports, configure with 1200bps baud rate, odd parity, flow control and be able to change the module name when detected.
However, there is no development kit, only the module BT121 and a FTDI interface.
Could anyone help me?
Thanks a lot.