Designing with Bluetooth Mesh: Device requirements - Embedded.com

Designing with Bluetooth Mesh: Device requirements

In earlier articles in this series, we discussed what Bluetooth Mesh is (Part 1), how it works (Part 2), and what makes it private and secure (Part 3). All of the powerful features offered by Bluetooth Mesh make it a secure low-power network that also provides great interoperability.

With that said, these features also make Bluetooth Mesh implementation a bit complex. If a system designer is left to handle all these complexities, it would take hundreds of man-years efforts to roll out a product. Beyond that, the IoT applications are very broad-based. This means each application requires a slightly different set of peripherals and CPU processing power. For example, if you are designing smart home products, some are battery-powered while others are wall powered, some are analog intensive while some need extensive processing power with a lot of digital peripherals.

Firmware development is often the biggest investment for any systems development project. Even though systems are different, some of the firmware efforts can be reused across designs if the silicon family used remains unchanged. Thus, it is important to choose a device/platform for your first product after due diligence such that you can maximize IP reuse and leverage existing firmware. In this article, we will discuss some of the points that must be considered while selecting a device for your next Bluetooth Mesh application.

At a high level, three key pieces are needed for any Bluetooth Mesh application development and deployment. These pieces are:

  • Hardware
  • Software/Firmware
  • Mobile application

Hardware

While selecting a platform for your Bluetooth Mesh products, the first and most important step is to investigate device capabilities. It is important to consider the long term while selecting the device. Let’s take an example to understand why. Figure 1 shows an example of a smart home system.

click for larger image

Figure 1: An example of a smart home system using Bluetooth Mesh. (Source: Cypress)

As you see here, there are various devices in this network, including lightbulbs, a fan, a thermostat, and a blind controller. An actual smart home may use a greater variety of Bluetooth Mesh products such as switches, dimmers, occupancy sensors, sprinkler controllers, etc. If you are designing smart home products, you may be required to design products catering to all these applications. Thus, even if you are working on a smart switch application, it is important to scope other products as well.

Each of these applications has different design requirements. The same is true for other segments such as building automation as well. Ideal, your designs can be based on a platform that addresses the majority of those application requirements. In addition, you should have the ability to upgrade or downgrade options based on the application without requiring a complete redesign of firmware.

Let’s look into some of the silicon features/specifications that should be considered before choosing a device for your Bluetooth Mesh application development.

Transmit Power and Receive sensitivity – One of the important specifications for any wireless device is its Transmit power and Receive sensitivity. Transmit power and Receive sensitivity define the device’s link budget and the distance at which a device can talk to other nodes in the network. Though Bluetooth Mesh is intended to extend the range of the network, Transmit power and Receive sensitivity limit the distance between individual nodes in the network.

As we mentioned earlier, not every product is same and requirements vary based on the application. Having a higher Transmit power also consumes more current. You may need to limit the Transmit power for battery-powered applications to reduce power consumption and increase battery life. Applications like temperature and humidity sensors, smart switches, etc. are generally battery-powered. It may be favorable to use a lower transmit power in these cases. On the other hand, wall-powered applications can support higher transmit power to extend network range. So, for wall-powered applications, it is important to pick a device that can support up to 10 dBm transmit power.

A Mesh-capable device should be able to support lower Transmit power for battery-powered applications and higher Transmit power for wall-powered applications. It is a good idea to choose a device family that offers different Transmit power options in a similar footprint and with similar resources. This allows you to change only the BOM without having to make any changes in layout, thus simplifying design of new products and speeding time-to-market.

Higher Transmit power is generally supported using an integrated power amplifier (IPA). An IPA, however, comes at an additional cost. To reduce the BOM cost, developer can switch to a low cost device with lower Transmit power in same foot print for battery powered applications, if such an option is available. For example, to address this requirement, Cypress provides the CYW20819 that support up to +4 dBm transmit power and another device CYW20820 that support up to 10 dBm transmit power in a pin-compatible package with same feature-set.

Power consumption – Power consumption must be investigated most carefully for every application, whether wall-powered or battery-powered. To make products environment-friendly, there is constant pressure from regulatory agencies to reduce power consumption even with wall-powered devices. If your product does not meet the specified power consumption requirements, you may not be able to sell the product.

There are various factors that must be examined while looking at a device’s power consumption. First is radio power consumption during transmitting and receiving. Most Bluetooth Mesh nodes continuously scan for packets. Thus, these devices are in receive mode close to 100% of the time, making receiver power consumption one of the most important parameters to consider when choosing a device for Mesh applications.

Transmit power consumption is another important specification given that Mesh devices which act as a relay have to forward received messages. Transmit power consumption must be examined at the maximum supported Transmit power of the device. Some devices tend to perform better at lower transmit power compared to when they are used at higher transmit power.

Vendors support different low-power modes in their devices. It is important to understand what is needed for your application so you can accurately estimate average power consumption based on the time device is likely to spend in active and other low power modes.

Processing power – It is generally a good idea to select a device with good processing power. Some applications like LED bulbs may require quick processing and modification in LED status (On/Off or color) based on user requests. As devices consume the lowest power in their low-power modes, using a faster CPU allows tasks to be completed quickly. Thus, the device can go to sleep for a longer duration that reduces the average overall power consumption.

Memory – Flash and RAM size requirements vary, based on the chosen application. It is important to find a product family that offers a flexible memory footprint. The Mesh implementation should allow the application code to be ported between devices with a different memory footprint without any additional effort. This allows you to select a lower cost device for your applications which need less memory. Also, some devices have ROM to store Bluetooth stack and peripheral drivers. This frees up Flash for application use. This means that devices with internal ROM and Flash are typically better suited for Bluetooth Mesh products.

Peripherals – As we mentioned earlier, different peripherals may be needed for different applications. For example, a smart bulb may need three or four pulse-width modulators (PWMs) for RGB/RGBW LED control, an analog-to-digital converter (ADC) for temperature measurement using a thermistor, and an I2C interface to serve as a passive infrared (PIR) sensor controller interface. On the other hand, a themostat requires an ADC and a power management block to support low power modes. While selecting a platform for your products, it helps to list the potential peripheral needs for all applications and identify a device that fits them best.

Extended temperature and industrial temperature support – Some applications such as lighting need support for extended temperature (up to +105° C) given the high power dissipation across LEDs and AC-DC subsystem. For this reason, it is important to pick a device family that offers the product both in industrial and extended temperature grades.

Software

Software is a really important piece that must be investigated. By software, we not only mean an IDE and toolchains but also the underlying Software Development Kit (SDK). The IDE must be easy to use, such as commonly used Eclipse-based IDEs.

The SDK needs special attention. Bluetooth Mesh has several models and node types. The use of a particular model and node type depend upon the application. For a product to qualify as Bluetooth Mesh, the underlying model and node type must also qualify. Some vendors do not have all Bluetooth Mesh models and node types qualified. If the application requires a model that is not qualified, the burden is on the developer to go through the entire qualification process. That requires the developer to thoroughly understand the Bluetooth Mesh specification and invest additional money and time in the qualification process. It is the responsibility of the Mesh silicon vendor to abstract that complexity and provide a solution that is fully Bluetooth Mesh qualified. Thus, before selecting a device for your Bluetooth Mesh application, refer to the Bluetooth SIG website to find out which mesh models and nodes are qualified for a particular device.

Once you have identified a device that supports all mesh models and node types, it is a good idea to find out what reference code examples are available. Code examples kick start development with a new technology that you have not used before.

Mobile applications

The idea of IoT is to connect things such that they can be accessed by users easily. Almost all IoT applications require a mobile application, and so do Bluetooth Mesh-based IoT applications. Whether it is light bulb control or reading the temperature from a weather monitoring station, users want to access and control devices using their phone. To facilitate this, silicon vendors must provide iOS and Android mobile applications for their Bluetooth Mesh product.

Ideally, source code is provided for these applications so that you can to make customizations to accommodate your brand and product specific modifications. If the silicon vendor does not provide these applications, you will need to develop these applications from scratch. App development costs can run $200K+ for each application, not including the impact on time to market for your product.

You can also watch Learning More about Bluetooth Mesh video to learn to create a Bluetooth Mesh network and communicate with it.

In the next and final article in this series, we will discuss whether a silicon device or a module should be used for your Bluetooth Mesh application, and we will describe the factors that impact the decision in choosing between these two alternatives.


Sachin Gupta is Product Marketing Manager at Cypress Semiconductor. He has more than 11-years of experience in product marketing and applications engineering roles. He has managed USB Type-C, Wi-Fi, Bluetooth, SoC and FPGA products in his product marketer roles. He can be reached at sachin.gupta@cypress.com.
Santhosh Vojjala is currently working as Principal Applications Engineer at Cypress Semiconductor. He has 11+ years’ experience in managing and developing world class connectivity (IoT), touch screen and embedded systems solutions for world wide customers. He can be reached at santhosh.kumarv@cypress.com

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.