Four tips for assessing BLE module data sheets
May 05, 2017
Bring some salt. Bring a lot of salt, actually. You're going to need it if you're working on a product design and need to select a Bluetooth module fr...
Bring some salt. Bring a lot of salt, actually. You’re going to need it if you’re working on a product design and need to select a Bluetooth module from the stack of data sheets trying their darnedest to get you to pick their solution. There’s a reason these aren’t called “fact sheets.” These are sales materials first and foremost, and you need to take their claims with a grain of salt – or sometimes a pound of salt – if you want to select a Bluetooth low energy (BLE) module that truly meets your needs and will make your product’s performance a success.
Yes, much of the information on a given data sheet is factual. But those facts are often run through a prism of “marketing,” to put it very diplomatically. More importantly, many of the most important pieces of information in data sheets need to be properly interpreted or verified before you make a final choice. The purpose of this article is to provide you with some simple tips that will help you separate fact from fiction and make a more informed decision that you can feel confident in. This is more important than ever, given the sheer volume of design projects in engineers’ pipelines involving BLE for things like IoT deployments and “smart” wirelessly-enabled products. The pace is fast and the stakes are high, which means you can’t afford to pick the wrong module, which can lead to unwanted delays, unexpected costs, and compromised performance in the process.
1. Don’t trust the range
When it comes to datasheets, the answers to the most important questions are often the least reliable information offered. So what are some key areas of a data sheet where an engineer’s skepticism should be on full alert?
One of the most important rules of thumb about any BLE module’s data sheet is that you should completely ignore any statement made about range. Completely. That number might as well have a silly emoji in place of the number they provide because that data point is shaped more by the testing environment and test process than by the module itself. Manufacturers are not dummies. They know that engineers often start their review of wireless product data sheets by looking at a key feature such as range, so the manufacturer is incentivized to make the module’s range look as good as possible on paper. That often means utilizing testing environments that put the module in the best possible light, but bear no resemblance to how the module will perform in your actual finished product architecture, environments, and enclosures – similar to how a new vehicle’s MPG rating on paper never seems to match actual fuel efficiency once you drive the car off the lot and start driving it yourself.
2. Look closely at power consumption
What else in a data sheet should be met with some healthy skepticism and a pound of salt? Power consumption. This is also one of the first things a product engineer will look at in a BLE module data sheet, and it is one of the most deceptive because of how much that metric can differ from an idealized testing environment versus a real-world implementation. Power consumption is too important of a number to simply trust straight off the data sheet, so I always recommend that engineers test it thoroughly to come up with their own numbers using their desired interfaces, configurations, and application needs.
Nothing will make an end user more dissatisfied more quickly than poor power consumption performance in a product they bought specifically because of BLE’s advertised power miser-like qualities, so testing these data sheet numbers will be critical to the success of the product. It’s not called Low Energy for nothing!
I’ve talked a lot so far about what to be skeptical about, but what are some signs that the information in one data sheet might be more reliable than another? Forthrightness and completeness say a lot. Those seem like abstract things, but when it comes to data sheets, the honest, forthright ones stand out very clearly:
- Does it list whether any external components are going to be necessary? That’s a good sign.
- Does it spend time talking about limitations that engineers should know in order to make an educated decision? Very good sign.
- Are the regulatory test reports actually completed and available to review rather than just TBC? Another very good sign.
These are positive harbingers that the BLE module in question will likely test well once you get a unit in the lab, which makes it worth considering for your shortlist of finalists.
3. Test, test, test
The next rule of thumb includes the three most important in your module selection process: test, test, test. Testing the module in an environment that you control is the only way to get range numbers that you can trust enough to factor into your design plan. The testing process is important not only for verifying critical measurements such as range, but also because getting a test module in your hand and putting it through its paces will reveal other things that you never would have learned from the data sheet alone. For example, will any external components be needed as a complement to the module? Data sheets often make the module sound turnkey, but the reality is that many end up needing additional components that take up more real estate in a product design and that require additional engineering and cost. That has significant reverberations as you move forward with the design process, so it’s best to have clarity on that up front rather than get an unpleasant surprise halfway through the process.
Testing will also allow you to identify any compatibility issues with smartphones and other devices early on so those don’t emerge at the last minute and threaten the success of your project. With so many smart wireless products and IoT projects having a smartphone or tablet interface to them as a visual display with accompanying mobile application, the importance of this cannot be overstated. Yes, testing will require an investment of time up front to get sample units in hand, but it will prevent unforeseen problems later on that could create major delays, setbacks, costs or even a full back-to-the-drawing-board restart of the project.
4. Ignore the price and look at TCI
Of all the numbers for a module, you’d think the cost per unit is the most straightforward, but this is often the most misleading number because the key number to assess is actually the total cost of implementation (TCI) for the module. For example, a module with a low per-unit cost may seem to be a bargain, but that dollar figure does not reflect how much time and money will be required for integration, external components, development environment, an embedded stack or an external stack, radio certifications across numerous governing bodies across the globe, and more—which vary greatly from one module to another.
Key questions to ask:
- Is there a future proof capability/upgrade path available?
- Is it Bluetooth “compliant” or actually Bluetooth SIG certified and listed? And if so, can the manufacturer cite its Declaration ID (DID)?
- What about regulatory approvals? Are those done by the manufacturer or will they be your responsibility? Are the certificates and test reports available for review?
- Does the vendor provide mobile apps with source to help you on the “other end” of the connection?
- Whose silicon does it use and is it just a hardware only platform where potentially the vendor simply pushes out hardware with no understanding of the required software stacks or development environment, totally relying on major silicon vendors or forums to support customers’ development?
- Is their local support in the region they are in?
- Is this that manufacturer’s first Bluetooth/BLE solution – is the experience and knowledge base there, or just jumping on the bandwagon?
Comparing the full TCI of various modules (as opposed to merely the stated cost per unit) is one of the most important steps during the selection process, and the best way to estimate that TCI is by having a module in hand and doing the testing I discussed above.
What about Bluetooth 5?
This is one of the most frequent questions I get from engineers, with good reason. They are being bombarded with marketing for Bluetooth 5 right now, and that includes data sheets that increasingly look like ads for Bluetooth 5 features rather than spec sheets for the module. The pressure also comes from inside companies with product marketing teams insisting that everything in the pipeline needs to have Bluetooth 5 since that’s the latest and greatest.
Too often, the process then becomes about achieving a checklist of feature adoption that allows you to say your product uses the new standard. But are all of those features truly relevant to you and your customer—especially when full adoption of all new headline features is not necessary to claim Bluetooth 5 compliance? If not, supporting all those features may be a needless distraction that creates extra cost, extra work and extra everything.
My advice to engineers is to block out the marketing barrage for a moment and have an honest conversation with your team about what parts of the new standard are relevant and worth adopting in the near-term. For example, the additional range of Bluetooth 5 might be a key feature, but is the enhanced beaconing feature relevant to your design? If security is important, Bluetooth 4.2 will give you everything you need because the new standard doesn’t have substantive advances on that front. The reality is that many of the features in Bluetooth 5 may not be relevant to a given design project, so you should build your own checklist of what you need and what you don’t. That approach is a much better route to meeting the needs of customers, meeting the objectives of your company and streamlining the design process.
One important thing I should emphasize here is that you will still be able to market your completed product as Bluetooth 5 certified despite the fact that the process above may lead you to adopt only some—but not all—of the “headline” features in the new standard. From a Bluetooth SIG qualification perspective, a product only needs to support the mandatory and errata requirements of the Bluetooth 5 Core specification. None of the trumpeted “big 3 headline features of Bluetooth 5” are mandatory. Therefore, a product does not have to support everything in Bluetooth 5 in order to be marketed with the new standard front and center on your product’s packaging. That gives product designers the leeway to be selective in which BLE module they choose, by picking and validating a BLE module that meets or exceeds the needs of your actual product and its intended application—not simply the latest greatest solution that the vendor wants you to buy.
