BTM411 Series Bluetooth Module

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.

Laird Connectivity is committed to the long-term supply of all its standard embedded wireless modules and packaged products. Laird Connectivity’s products are specifically designed to meet the needs of the industrial and medical markets, which typically require 7 – 10 years product lifecycle. Although Laird Connectivity can’t guarantee that a component used in our products will not be obsoleted and cannot be reasonably substituted, Laird Connectivity can assure customers we will continue to sell our product when we have customer demand and can obtain the necessary components to build our products.

View our full policy here. 

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