"Engineers have many choices in low-power wireless technologies, including RF based technologies such as low-power Bluetooth, ant, ZigBee, RF4CE, NFC and Nike +, as well as infrared technology advocated by the infrared data association (IrDA).
This paper will especially introduce the hardware, firmware and software development of various low-power wireless technologies. Then, the power efficiency and peak current consumption of each protocol and their impact on battery life will be discussed in detail. In addition, bill of materials (BOM) cost and target market analysis will be provided.
The design adopts low-power Bluetooth
Today's low-power Bluetooth SOC is almost entirely based on 2.4 GHz radio and equipped with arm ® Cortex ®- M0, m3, M4 and m4f embedded processors use flash memory and ram to store and run stack firmware and application software. While introducing single-chip hardware, chip suppliers are trying to provide reference design, application instructions and design tools for engineers who lack RF expertise to simplify the design of their wireless products.
Although SOC like Texas Instruments (TI) cc2640r2f Bluetooth 5 SOC contains all the hardware (and firmware) to realize a complete low-power Bluetooth solution, it is unlikely to form an effective solution only by welding the chip to the printed circuit board and energizing it.
Like all RF designs, a fully functional system requires additional circuits composed of passive components to form matching circuits, power supplies and antennas (Fig. 1).
Alternatively, many third-party companies provide tested and certified modules built around the latest SOC without designing external circuits, but need to make a trade-off between increasing cost and increasing size.
The tested and verified low-power Bluetooth stack provided by this factory meets the requirements of wireless protocol. At the same time, there are many official and open source libraries that provide verified application code for the most common low-power Bluetooth applications. In addition, the popularity of suppliers and third-party development kits (DK) and software DK (SDK), combined with the widely used user-friendly integrated development environment (IDE), makes it easier for qualified engineers to design new applications.
For details on using low-power Bluetooth design, see digi key library article "low-power Bluetooth SOC and tools compatible with Bluetooth 4.1, 4.2 and 5 can meet the challenges of the Internet of things (Part 2)".
How about ZigBee?
In many aspects, ZigBee has a similar design orientation to low-power Bluetooth, in part because many companies that provide low-power Bluetooth chips, reference designs and Dk / SDK also deal with their ZigBee products in the same way. SOC with integrated transceivers, microprocessors and high-capacity flash memory and ram is sufficient without using a separate processor and transceiver development environment. However, designers familiar with a specific processor family can choose to use the only ZigBee chip of the transceiver with its commonly used MCU. An example of this matching is microchip's at86rf232, which can be paired with an MCU in microchip / ATMEL AVR MCU series.
NXP's jn516x series is the best example of the latest SOC for ZigBee Based projects. The device is programmed with ZigBee Pro stack, and has embedded 32-bit RISC processor, flash memory and EEPROM memory. The SOC also includes a 2.4 GHz transceiver and a comprehensive combination of analog and digital peripherals.
Since RF4CE is a custom application of ZigBee stack, the hardware design is the same as other ZigBee applications. For example, NXP jn516 can fully support RF4CE applications. What developers need to do is build their own applications on RF4CE firmware instead of using the standard ZigBee stack.
Similar to low-power Bluetooth, ZigBee products need standard compliance and regulatory certification to carry the logo of the standard.
Is ant a good design option?
Ant is similar to the development challenges faced by low-power Bluetooth or ZigBee projects. Dual chip (Ti cc2570 and msp430f2 MCU), SOC (Nordic semiconductor nrf52832) or modular (dynastream innovations D52 ant module) hardware solutions can be adopted. The first two options require additional peripheral components to form the working device, and the module is a fully tested hardware solution.
Ant protocol is provided as a self-contained firmware stack. Developers only need to develop application code in software. The application code development of cc2570 is completed by using the development tool of the selected MCU, while nrf52832 SOC and D52 ant module (based on nrf52832) completely separate the protocol stack from the application code using software architecture, thus simplifying the development process. Nrf52832 adopts embedded arm m4f microprocessor. Both Ti and Nordic semiconductor provide ant DK and SDK to support application code development.
One disadvantage of ant protocol is that if the existing ant + device profile is not suitable for the application, developing a new device profile requires collaboration between the protocol developer dynastream innovations and the OEM to ensure interoperability. This may prolong development time.
How is IrDA implemented?
IrDA provides multiple versions of communication protocols according to the application. These simple protocols require appropriate IR transceivers (such as Vishay's tfbs4711) to provide services. The data rate of the device can reach 115 KB / s in the range of 1 meter. When a higher data rate is required, the complexity will increase because of the cumbersome IrDA protocol stack and 16 bit microprocessor.
Since IR is a line of sight technology, optical considerations are very important. For example, plastic IR transmission windows, which ensure that IR strength meets specifications, are key requirements for end products using IR. Standard compliance certification is mandatory and needs to be conducted in a test laboratory authorized by IrDA.
What are the key challenges in NFC design?
Perhaps the most difficult part of designing an NFC system is getting the right antenna. The antennas of the transmitter and receiver need not only coupling to transmit data, but also power supply. This makes the design more difficult than transmitting and receiving data alone. The good news is that there are many application instructions and reference designs from major suppliers that provide guidance on antenna design.
The firmware of NFC is based on a series of functional layers, ranging from the physical layer to the implementation of application software. The physical layer usually includes microcontroller and related infrastructure, communication interface and radio. Above it is the intermediate layer, including data packaging, NFC command generation, logical link control protocol (llcp) and simple NDEP exchange protocol.
The higher layer includes nDef messages and nDef records, and the top layer is a user interface (Figure 2). The design follows a process similar to that adopted by technologies such as low-power Bluetooth and ant +. Developers build products on the factory firmware stack and use appropriate development tools to customize their own software for specific applications.
Due to the low power output, NFC regulatory certification is not mandatory, but standard radio transmission tests must be performed to ensure that transmission is limited to the 13.56 MHz band. However, if interoperability is required in the final product, a standard compliance certification program is required.
Is Wi Fi hard to achieve?
Among all low-power wireless alternatives, Wi Fi is the most complex technology for developers. In particular, the design of hardware must have tight tolerances to ensure the realization of radio performance specifications.
Designing Wi Fi solutions from scratch requires a high level of GHz RF expertise, making pre assembled module routing popular among developers who want to accelerate the speed of product launch. Modules are tested, validated and certified wireless products that can be quickly integrated into Wi Fi solutions.
IEEE 802.11n modules and related development tools can be easily obtained from multiple chip suppliers. They typically integrate WLAN baseband processors and RF transceivers that support IEEE 802.11n A / B / N / g, power amplifiers (PAS), clocks, RF switches, filters, passive components, and power management. The module can run with a separate microprocessor or from an embedded device. Like most other RF hardware solutions, developers may have to specify 2.4 or 5 GHz antennas connected through controlled impedance printed lines to achieve fully functional RF circuits (although some modular solutions even extend to these components).
Microprocessors will need to run an advanced operating system (OS) such as Linux or Android. Drivers are available from Wi Fi chip providers, while other drivers such as wince and a range of real-time operating systems are provided through third parties.
The certification of Wi Fi device operation is not mandatory, but if the device is not certified, the Wi Fi mark cannot be used. Due to the use of extended test methods, the certification cost is higher than other technologies discussed（ For more information on Wi Fi design, see the digi key library article "comparing 2.4 GHz and 5 GHz Wireless LANs in industrial applications".)
Trade off protocol reliability and efficiency
The first part of this paper introduces the composition of overhead (such as packet ID and length, channel and checksum) and transmitted information (called "payload") in each wireless communication protocol. The ratio of payload / total packet size determines the protocol efficiency.
Figure 3 shows a low-power Bluetooth packet. The protocol is allowed for various payloads, and this example shows the maximum payload. Please note that this is a packet structure that follows Bluetooth version 4.0. There are some minor changes in the packets of versions 4.1, 4.2 and 5, but these changes do not significantly change the protocol efficiency.
The low-power Bluetooth packet in Figure 3 includes:
Preamble = 1 octet (8 bits)
Access address = 4 octets (32 bits)
Header = 1 octet (8 bits)
Payload length = 1 octet (8 bits)
Payload = 31 octets (248 bits)
Cyclic redundancy check (CRC) = 3 octets (24 bits)
Low power Bluetooth protocol efficiency = payload / total packet size
31/41 = 76%
It is important for designers to determine the protocol efficiency of shortlisted technologies because they directly affect the user experience. Low power wireless solution providers are keen to tout the "raw data" transmission speed, but may not be happy to disclose how much data is a useful payload.
From a user's point of view, a technology with excellent raw data speed may appear to have poor performance if it is not efficient. Worse, inefficient protocols consume a lot of energy to send useless data, thus reducing battery life (which is a key design parameter of low-power wireless technology).
However, it should be noted that there is a trade-off between reliability and efficiency. For example, the protocol can increase some efficiency by eliminating checksum or error correction, but if packets must be retransmitted continuously (because they are often damaged when they arrive at the receiver), this efficiency increase will be quickly offset.
When comparing the shortlisted technologies, it is recommended that designers communicate with suppliers to determine the theoretical protocol efficiency (remember that even a single technology may have different versions, and each version has a unique packet structure), and then test the actual efficiency of multiple use cases to find out the rate of successful packet transmission by analyzing transmission. This rate is usually lower than the rate indicated by the theoretical efficiency, even in the optimal radio environment.
What is the cost of manufacturing low-power wireless devices?
The main costs associated with low-power wireless sensors are transceiver and microprocessor (or SOC if these components are combined), antenna, voltage regulator and printed circuit board space (Table 1). Here, it is assumed that the costs of batteries, battery connectors and sensors are independent of wireless technology, so they are omitted from the comparison table. In addition, please note that these figures are estimates and may vary from vendor to vendor.
External crystals may account for a large proportion of the cost of low-power wireless sensors, because high-quality devices are usually required to meet strict regulatory requirements. The higher the accuracy of the device (i.e. the lower the PPM deviation relative to the nominal frequency), the higher the price.
Typical crystal tolerances in PPM are as follows:
NFC = 500 (the crystal only needs to keep the radio operating in the allocated frequency band, not for the data clock)
Low power Bluetooth = 250
Nike+ = 60
ANT = 50
ZigBee/RF4CE= 40
energy efficiency
Low power wireless technology is mainly designed to prolong battery life, but the performance of each technology is quite different.
A major example of each technique is in sensors. In the simplest example, such sensors can be used for measurement and transmission (e.g., temperature, humidity, and pressure). A typical sensor has a lightweight and compact design with only room for a small battery (for example, a 3 V CR2032 button battery with a nominal capacity of approximately 225 MAH).
Computing battery life in applications is a complex task, which depends on the hardware of the sensor. For example, if the sensor contains a status LED, the power consumption will be higher than that of a device without a status LED. Similarly, peak transmit and receive current, propagation time, sleep mode current and other factors can affect battery life.
Some vendors (such as ant developer dynastream innovations) provide convenient power consumption calculators on their websites, enabling developers to estimate the battery life of a given use scenario.
A good benchmark for the power efficiency of each protocol is to consider the energy required to transmit one bit. Such calculations illustrate the fact that protocols with greater throughput require shorter propagation times than protocols with more moderate throughput
Our other product:
