The maximum data throughput the module can achieve is half of the PHY data rate. This is due to protocol overhead and packet spacing. For example, if the module is running at 54 Mbps, it will be able to achieve data throughput of 25-27 Mbps.

The WL_UART_DBG pin is a debug pin. It is a 1.8V logic UART TX line. This pin should never need to be used in normal operation. It may be useful to terminate this pin to a test point or header in case it is needed.

This pins are used for a WLAN test mode interface. Both pins are 1.8V logic level UART pins. These pins should be brought out to a header on the host PCB. The WLAN test interface can be used to place the module into constant packet transmit and constant packet receive modes. These modes can be useful for antenna and sensitivity testing.

When BT is awake and active, BT_WU (BT_FUNC2) is high (from host to module). This is an active high signal. The host puts the BT section to sleep by de-asserting (logic low level) the BT_WU signal (input to the module). The module then drives HOST_WU (BT_FUNC5) low to acknowledge to the host that it is has been put into sleep mode.

The BT_FUNC4 (BT_UARTD) pin is a debug pin. It is a 1.8V logic UART TX line. This pin should never need to be used in normal operation. It may be useful to terminate this pin to a test point or header in case it is needed.

See the answer on TI's E2E forum.

The ini file in your OS/Driver likely does not have the correct parameters. It is important that you update this in your OS/Driver by following the instructions in the TiWi Family INI Radio Parameter User Guide available on the TiWi-BLE module downloads page.

The Linux driver supports A2DP, HFP, HSP, OPP and FTP profiles.
The Win CE driver supports SDP, SSP, OPP, FTP, DUN, PAN et AD2P.

Yes, the TiWi-BLE Module is certified as mobile device >20cm from the human body. Note that Ezurio has completed a class 1 permissive change allowing the TiWi-BLE to fall under these certifications.

The TI core Linux IP for WL1271L is Cisco CCX certified, however the Cisco CCX software includes 3rd Party IP which requires a separate License with TI.

The FM radio is tested by TI at the WL1271L level, but not tested at the Module level by Ezurio at the present time. Therefore Ezurio assumes no liability for its operation. If this is a requirement for an application, please feel free to contact Ezurio to discuss. Information on using the FM radio (again at a customers own risk) can be obtained from TI. For example seeTI OMAP Wiki.

The answer to this question depends on if you plan on using the modular certification of the module. If you want to use the modular certification you need to use one of the antennas that the module was certified with. Consult the datasheet, or product webpage to determine which antennas the module was certified with. If none of the certified antennas meet your requirements, another antenna may be used, however the modular certification will NOT be valid. The new antenna will need to be tested for EMC compliance. Contact Ezurio’s EMC Test Services to learn more about this process and how we can help.

Yes, this is possible if:

1. The peak gain of the alternate antenna is less than or equal to the original antenna, and
2. The antennas are the same type.

There are some cases that are not black and white. It is the customer's responsibility to collect and retain the appropriate and accurate test data traceable to NIST standards for the alternate antenna. Please contact Ezurio to discuss any questions.

The datasheet for the WL1271L is not public, and can only be obtained under NDA to customers through TI. Enough information is presented in the TiWi-BLE datasheet for most applications. Contact your local TI Sales Representative if you feel it is necessary to obtain the datasheet.

There is no published command set for either radio. The only interface is through the drivers built into the OS. The commands would have to be extracted, or reverse engineered from there.

We recommend using de-ionized water. Additionally, we recommend avoiding any sonic vibration, heat, and pressure washing as well as any other soaps/chemicals.

Every module has to be calibrated individually or you will run the risk of seeing issues with performance or the module not working at all. However, one way to solve that issue easily is to build a script on the Linux system that calibrates the module every time the Linux system boots.   

No equipment is needed as the calibration is performed inside the module. The only hardware requirement is that the antenna needs to be connected.

Unfortunately, every customer must complete their own listing and because the TiWi-BLE is an untested component, you are responsible for the proper testing and listing. We recommend you work with a Bluetooth Qualified Expert(BQE) to assist you in listing your product with the BT SIG properly.

The Manufacturer's Specific Data Type is used for manufacturer specific data which can be proprietary data structures defined by the manufacturer and only identifiable by manufacturer's equipment/applications. To use the Manufacturer's Specific Data Type you need to have a Company Identifier as assigned by the BT SIG. You must be a registered member of the BT SIG and must apply for the company identifier using the process below (found at this link: https://www.bluetooth.com/specifications/assigned-numbers/company-ident…)   Application & Assignment Process Submit the following below to  Bluetooth Support : Company information (legal name of company) Name of company's primary contact (name and email) A statement that your company is currently a Bluetooth SIG member in good standing* Please allow five business days for your request to be fulfilled, and two business days from the time your request is fulfilled to view your Company Identifier on this page. *  ? BLUETOOTH Member in Good Standing ? shall mean any firm, corporation or other legal entity that has been admitted to membership in the BLUETOOTH SIG, whether a Promoter Member, Associate Member or Adopter Member, as defined in the organizational documents, that has fulfilled all of the requirements for membership, has paid and is current with payment of any and all membership fees, dues and assessments, and whose membership neither has been voluntarily or involuntarily suspended, terminated, or withdrawn from membership consistent with the lawful provisions of the organizational documents of the BLUETOOTH SIG.?

When doing the calibration of the modules a 50-ohm load needs to be connected to the modules antenna port.  

The calibartion procedure described under http://processors.wiki.ti.com/index.php/WL12xx_NLCP_Calibration_Process… needs to be performed on every module during the production process as there is no non-volatile storage on the module to store the generated .nvs file. That has to be stored in the Linux filesystem .  

iOS devices will not pair with BLE devices unless one of the device's characteristics specifies that encryption is required. Apps need to provide their own UI for the user to discover and select the BLE peripheral they want to work with, this is because the app knows what service(s) are required for the app while iOS Bluetooth settings does not. Even when pairing of BLE devices is performed it is still initiated through the app. Bluetooth settings is used to "forget" the device (remove the stored encryption keys). However, it seems that iOS does list BLE devices when they advertise some of the BT SIG adopted services such as the Heart Rate service. By advertising this service you can get your device visible in the Bluetooth Settings page..

If WiFi/Bluetooth co-existence issues occur in the TiWi-BLE, ensure that the latest firmware is being used as there were patches applied to it by Ti that correct co-existence issues. Below are the links to the firmware and firmware build process.

Firmware Link: http://git.ti.com/wl12xx/ti-utils/trees/ol_R5.SP8.01/hw/firmware

Firmware Build Process Link: http://processors.wiki.ti.com/index.php/WL12xx_NLCP_Build_Instructions#Build_Scripts

The TiWi-BLE can be tested a couple of ways. Either with the TiWi WLAN Eval Tool or in Linux with the following weblink to guide on how to do that. The customer needs to read through our product documentation before going to the following Ti page: http://processors.wiki.ti.com/index.php/WL127x_TX_Testing

Before we suggest using the Ti link above, the module must be calibrated, those steps and instructions are in the Documentation section on the product page.

The factors to confirm when checking the soldering job on Bluetooth modules are solder stencil aperture size, solder stencil thickness, solder ball size, solder type, and the MSL guidelines. If the parts have been left out for too long then the modules should be baked to remove any moisture prior to soldering. If there are any failures, we highly recommend providing an x-ray of the module.

We highly do not recommend conformal coating the radio module. If you plan on encapsulating the radio module in a potting compound or conformal coating, you must assure that the compound in liquid or solid form does not enter under the shield where there are sensitive RF components. Some of the capacitive and inductance values are as low (pF and nH) and could be sensitive to contacting materials such as potting compounds. There are potting compounds and conformal coatings which have very good dielectric constants and are suitable for 2.4 GHz potting applications, however, when you apply any of these, they were not accounted for in the circuit design and might reduce performance of the device (or all together cause it not to function).  You should run tests on their particular potting compound and evaluate radio's performance and range.  Also, it's worth mentioning that applying any compound, conformal coating or potting directly to the module WILL void the warranty. If your application requires 100% sealing of the radio module, there is a way to do this very successfully without impacting the module performance. Simply place the module on your PCB. Place a plastic cover over the module (like a hat), make the cover large enough to cover the whole module. Apply glue around the bottom perimeter of the cover where it sits on the PCB. This allows the module to function in free air-space while there is a complete seal around it. This information is only for reference and we recommend you should conduct your own testing with your prototype of your end application to find the best suitable fit for your design.  

We only recommend reflowing our modules once as it can damage the module and void the warranty.

Instructions on building the TiWi-BLE's driver can be located at the link below, it is in the "Linux Driver" section on the TiWi-BLE product page. Firmware is handled by TI, as the TiWi-BLE uses TI's WL1271 firmware. It can be located at the following git.ti.com website: http://git.ti.com/wl12xx/ti-utils/trees/ol_R5.SP8.01/hw/firmware

Ezurio provides layout files PADS and PADS ASCII formats. The ASCII files will import to Altium (and Protel varients) as well as Cadence (Orcad and Allegro) CAD packages. As far as we know, there is no way to import to Eagle CAD. Please be sure to use the .asc file for PCB and the .txt file for the schematic when importing to Altium. Ezurio uses ORCAD for schematics (Gerbers). 

The TiWi-BLE is NOT AEC Certified.  

The Serial Number is not stored on these modules, it's only displayed on the product label. Recently a database was added to provide MAC address to Serial Number correlation. MAC to SN correlation can be requested via our support.

The recommended cleanser is "hydrocarbon cleaning oil", which can be used to clean the RF shield and PCB. We do not recommend the use of alcohol as it doesn't work as well and could leave residue on the boards.  

You can get the version of the driver by issuing the following command in Linux:  strings /lib/modules/$(uname -r)/updates/drivers/net/wireless/wl12xx/wl12xx.ko | grep 'ol_R5' -m1

The weight of TiWi-BLE's single piece is 0.0011kg.

Bonding is pairing AND saving of the Long Term Key(LTK) for a later connection where as pairing will not save a LTK for future connections.

Indications and Notifications are a way for a GATT Client to subscribe to data provided by a GATT Server. A Notification is an unacknowledged message or update while an Indication is an acknowledged message or update. These Notifications and Indications are sent any time the relevant data in the GATT table on the GATT Server is updated. (You must "subscribe" to the data that you would like to be Notified or Indicated of) In a way Indications and Notifications are much like TCP and UDP packets. TCP requires that when data is sent, the receiver acknowledges that the data has been received by sending back an ACKnowledgement packet. UDP just sends off data without any concern whether it is actually confirmed to be received or not. In this sense Indications are akin to TCP and Notifications are akin to UDP.

A GATT Server is a device which stores attribute data locally and provides data access methods to a remote GATT Client paired via BLE. A GATT Client is a device which accesses data on a remote GATT Server, paired via BLE, using read, write, notify, or indicate operations. Once two devices are paired each device can act as both a GATT Server and a GATT Client.