Hello @joanf,

Bonding is not likely to improve the connection reliability in this case. Reconnecting after an unexpected disconnection is not a bad recovery mechanism, but there must be some other issue at play causing it in the first place. What is the "result" code that is generated in the connection_disconnected event handler? This should help tell you what the potential cause for the disconnection is.

Hi @DaraiusH,

A cycle count of 100 is in the right general area. I believe the specific iteration limit depends on what other values are stored in flash, and how much space is available for the PS system to fill other slots with new values before there's nothing left. Given a fixed configuration on a module, the limit should be essentially static. If you've tested this to be some particular repeatable number like 90 or 100, then I would use that as the hard limit, and preemptively defrag or reset when you reach something a bit lower, like 70 or 80.

Hello @DaraiusH,

This error occurs because of the way iWRAP stores new settings in flash, and eventually runs out of contiguous flash space available in the Persistent Storage area. Part of this is due to a limitation in the underlying CSR firmware in terms of how much flash space is available for this type of storage. When iWRAP runs out of space available to write a new PAGEMODE value to flash, it can no longer store new settings. The only option is to perform a PS defrag operation, something which happens automatically during the stack boot process. This is why it works again after you reset the module.

Since the flash write/defrag limitation is inherent in the chipset, it may also be possible for you to keep a simple counter internally each time you write to flash with a SET command, and if you get near the write limit which may result in a "STORE FAILED" error, preemptively run "RESET" or "DEFRAG" when you detect that the module is not busy with a connection. (Note that "DEFRAG" will trigger a reset itself as well.) You might also detect the error and automatically reset the Bluetooth module when it occurs, although the proactive method that defrags intentionally when there are no active connections to be disrupted is probably better.

There are no commands available which provide RAM-only page mode updates, so the above workaround is the only solution

Hi @safetylabs,

Using the BLE1xx C SDK, you can get the MAC address using the following code:

bd_addr tmp;
config_copy_hwdata(tmp.d, hwdata.bt_addr, sizeof(bd_addr));

The tmp.d structure member now contains the MAC address in little-endian byte order. If you want to get the module's chipset serial number (stored in ROM), this can be directly accessed with the primary_address.d predefined structure and member variable.

Hello @Rui,

The bgbuild.exe binary is found in the /bin subfolder wherever you have installed the SDK that you are using (BLE1xx, BT121, BGM111, or WF121). You will need to download and install the latest SDK for whichever module you want to develop with. The SDK installer can be found on the online resource page for the module in question.

Hello @rydello34,

This behavior of the scan response packet is recently discovered and a known limitation of the beta build 136 of the BGM111 SDK. The problem causes no data to be placed in the scan response packet; the packet itself is sent out, but it has no payload.

The problem will be fixed in the official non-beta SDK release that should be coming soon.

Hello @Mamur,

The audio interfaces (both analog and digital) are only used when there is a real audio stream active, either A2DP or SCO. It is not possible to access any audio signal data inside the module for transmission across an RFCOMM-based data connection like SPP or IAP.

However, it is possible to open a basic audio connection using HSP (headset profile) and the SCO OPEN command, or the BUTTON command, as documented in the latest iWRAP HFP/HSP Application Note.

iWRAP further supports A2DP streaming when operating as an A2DP SOURCE device, but modern smartphones do not implement the A2DP SINK side of that profile, so you cannot connect and send unidirectional audio this way. Only HSP/HFP + SCO audio is supported for sending audio to smartphones, because of the limitations imposed by the smartphone operating systems.

Hello @dflabs,

The application that you describe here sounds like something that would be more appropriate for a broadcaster/observer application model using Bluetooth Low Energy. The WT41 is a "classic" Bluetooth module, and classic Bluetooth does not provide any straightforward way to broadcast or scan with received payload data in this way. Connection establishment between two classic Bluetooth modules also usually takes a few seconds for each device.

I would recommend looking into either the BLE121LR or the newly released BGM111 module:

https://www.bluegiga.com/en-US/products/ble121lr-bluetooth-smart-long/#documentation

www.silabs.com/products/wireless/bluetooth/Pages/BGM111-bluetooth-smart-module.aspx

These modules can broadcast custom data, and scan for this data on the receiving end. The stacks that run on each can perform in all of the defined BLE roles, namely broadcaster, observer, central, and peripheral.

Hi Ted,

This typically means that the previous indication has not been fully acknowledged by the time you attempt to send another one. It is not a critical error; it simply means that you have to retry the transmission again (or just skip it if is isn't important).

A more efficient approach which should avoid this case would be to keep an internal "previous value" variable in your code, and only push a new update to a connected client when the value actually changes (which is ideally how indications should be used anyway). This should occur much less often than the reading itself takes place.

Hello @kaustubh,

You can use the SET BT PAGEMODE setting (page mode 0) to disable incoming calls altogether, but you cannot selectively block only HSP calls.

Separately, the AG should not believe that the call was dropped if the connection is closed cleanly with the CLOSE {link_id} command. The Bluetooth stack provides reason codes for link termination, and a lost link is different from a closed link. If the connection is being reattempted automatically even for a cleanly closed link, then the AG may not be configured correctly.