Bluesuite is a very old program supplied by CSR for testing and configuration of its legacy Bluetooth modules. Bluesuite Bluetest3 is often used for RF testing where the DUT is put into BCSP mode before running Blutest3.

If Bluetest3 crashes with an "array" error you may have a conflict or issue with your .net installation. You may be able to fix the issue by removing all versions of .net but please speak to your IT department first as this may cause issues with other software.

In general, cleaning the populated modules is strongly discouraged. Residuals under the module cannot be easily removed with any cleaning process. 

• Cleaning with water can lead to capillary effects where water is absorbed into the gap between the host board and the module. The combination of soldering flux residuals and encapsulated water could lead to short circuits between neighboring pads. Water could also damage any stickers or labels.
• Cleaning with alcohol or a similar organic solvent will likely flood soldering flux residuals into the RF shield, which is not accessible for post-washing inspection. The solvent could also damage any stickers or labels.
• Ultrasonic cleaning could damage the module permanently.

However, if water washing is required you will need to use deionized water. We do not recommend chemical cleaning and cannot guarantee it will not damage the modules. If you MUST clean PCB with chemicals it is recommended that you test on one board and then confirm the module still works after the process, prior to adding it to production, while understanding the above affects washing the populated PCBs can have on the module.

Our fully-embedded modules have a throughput of around 300-360 kbps.  They have an on-board Bluetooth stack and do all of the Bluetooth processing themselves. Bluetooth 2.1 + EDR has a practical transfer rate of 2.1 Mbit/s, but this is not possible on a small embedded module that does not have a powerful PC-type processor.

Based on a scenario between two BTM41x modules (referenced in the BTM41x Low Power Modes Application Note), the role of a device (master/slave) does not have an impact on sniff mode. In the scenario, sniff mode requests were accepted with requested parameters and were applied on the link, regardless of which end they were initiated from. Thus, at least one end must actively request sniff mode at some point after a connection has been created and the other end must at least not reject sniff mode. If the other end requests sniff mode as well, then the parameters of the most recent request will apply to the link.

Again, this has been done between two BTM41x modules. The relevant source code from this scenario was later ported across to the BTM51x. Confirming tests and measurements have not been carried out on the BTM51x. However, there is no obvious reason why it should behave differently on the BTM51x.

Please note that sniff configuration refers to Rfcomm based links :SPP, HSP, HFP. For AVRCP/A2DP there are some a default setting.

It should be possible to evaluate if a remote device requests sniff mode: Disable local sniff mode by setting Sniff parameters to zero (S561- S564, by default these are zero) and while in a connection check ATi13 repeatedly. If the response is ‘1: b,c,d,e’ then sniff mode has been entered, caused by the remote end. The resulting sniff parameters (b,c,d,e) are likely to be the ones requested by the remote end.

This article is designed to illustrate the process of Simple Secure Pairing (SSP) when initiated from a BTM module. Introduced in Bluetooth v2.1, SSP creates a bond in a very different way than the legacy PIN pairing many users are familiar with. This is demonstrated both for security level 2 (default) and security level 3.

Security Level = 2

Assumptions:

peer device is BT2.1 (supporting secure simple pairing)

security level of BTM device is

security level of peer device is

the pairing initiating device is aware of the peer device's Bluetooth Device Address

Note:  Connections in Bluetooth v2.1 are always encrypted.

Figure 1:  BTM vs BTM

Figure 2:  BTM vs PC

Security Level = 3

Assumptions:

peer device is BT2.1 (supporting secure simple pairing)

at least one device with security level = 3 (MITM protection / authentication enabled)

the pairing initiating device is aware of the peer device's Bluetooth Device Address

Remarks:

Connections with BT2.1 are always encrypted

"MITM" = Man-In-The-Middle. "MITM protection" means "protection against a MITM attack".

MITM protection is equivalent with authentication

Figure 3:  BTM vs BTM, security level 3

Figure 4: BTM vs PC, security level 3