Cypress EZ-BT™ Module Mesh Evaluation Kit - Review

Table of contents

RoadTest: Cypress EZ-BT™ Module Mesh Evaluation Kit

Author: Gough Lui

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: A number of modules from Silicon Labs, Nordic Semiconductor, STMicroelectronics, On Semiconductor and Dialog Semiconductor.

What were the biggest problems encountered?: Driver installation issues for the dual USB to Serial used on the board.

Detailed Review:

Cypress EZ-BT™ Mesh Evaluation Kit (CYBT-213043-MESH) RoadTest

by Gough Lui - September 2019


Internet of Things (IoT) connectivity is an area which is constantly evolving, with pressures towards having lower power, smaller footprint, longer ranges, interoperability/compatibility with standards and good throughput. In many consumer “smart-homes”, there may be a mixture of technologies used, including Wi-Fi, Bluetooth and Zigbee, each with their advantages and disadvantages.


As someone who has seen and worked with a variety of radio technologies, I was interested to see just how effective the new Bluetooth 5.0 standard with mesh would be. The Cypress EZ-BT™ kit (US$119.99) seemed ideal – the fact that four boards are included in the package to properly evaluate mesh behaviour suggests that they really understand what prospective evaluators need!


I’m grateful to have been selected by element14 and Cypress for the RoadTest of the Cypress EZ-BT™ Mesh Evaluation Kit (CYBT-213043-MESH), featuring the CYW-213043-02 module built around the CYW20819 integrated circuit. Read-on to learn more about my experience with the kit.


Table of Contents



Market Survey

While Bluetooth has been with us for many years, the development of Bluetooth 4.0 Low-Energy (LE) marked a turning point in strategy, positioning the standard to meet many of IoTs needs. One problem, however, was that Bluetooth has been traditionally a one-to-one or one-to-many architecture with range limitations of around 10m for Class 2 devices.


However, this problem has been overcome with the Bluetooth mesh specification, finally allowing for many-to-many connections with a self-healing network that utilises managed-flooding techniques to allow for networks with up to 32767 nodes and messages to be relayed up to 127 times. Combined with new Bluetooth 5.0 LE which offers a faster 2Mbit/s mode and coded PHY rates down to 125kbit/s for longer range.


When it comes to Bluetooth modules and ICs, there are a large number of companies in the market including Cypress Semiconductor, Dialog Semiconductor, Microchip/Atmel, Nordic Semiconductor, NXP, On Semiconductor, Panasonic, Silicon Labs, STMicroelectronics, Texas Instruments and Toshiba to name the largest.


Many of these are Bluetooth Low-Energy capable, however, if we are interested in having the latest Bluetooth 5.0 Low-Energy with Mesh capabilities, the list of vendors is narrowed down considerably. In this market, the main products supporting Bluetooth 5.0 LE and Mesh networking appear to be:

  • Cypress Semiconductor CYW20819 BT5.0 BR/EDR/LE/Mesh + ARM Cortex M4 up to 96MHz – Sensitivity: -95.5dBm 1Mbit/s LE, -89dBm 2Mbit/s LE, -92dBm 1Mbit/s GFSK, -94dBm 2Mbit/s EDR, -88dBm 3Mbit/s EDR, Power Output: +4dBm
  • Cypress Semiconductor CYW20735 BT5.0 BR/LE/Mesh + ARM Cortex M4 w/FPU up to 96MHz – Sensitivity: -94.5dBm 1Mbit/s LE, -91.5dBm 1Mbit/s GFSK, Power Output: +12dBm
  • Cypress Semiconductor CYW20719 BT5.0 BR/EDR/LE/Mesh + ARM Cortex M4 w/FPU up to 96MHz – Sensitivity: -95dBm 1Mbit/s LE, -92dBm 1Mbit/s GFSK, -94dBm 2Mbit/s, -88dBm 3Mbit/s, Power Output: +4dBm
  • Silicon Labs EFR32 Blue Gecko (Series 2) BT5/5.1/LE/Mesh + ARM Cortex M33 up to 80MHz - Sensitivity: -105.1 dBm 125kbps GFSK, -97.5 dBm 1Mbps GFSK, -94.4 dBm 2Mbps GFSK, Power Output: Up to +20dBm
  • Silicon Labs BGM13S Blue Gecko SiP BT5.0 LE/5.1 AoA/Mesh + ARM Cortex M4 @ 38.4MHz – Sensitivity: -102.1dBm 125kbit/s, -97.9dBm 500kbit/s, -94.1dBm 1Mbit/s, -90.2dBm 2Mbit/s LE, Power Output: Up to +18dBm
  • Silicon Labs BGM13P Blue Gecko Module BT5.0 LE/5.1 AoA+AoD/Mesh + ARM Cortex M4 @ 38.4MHz – Sensitivity: -103.2dBm 125kbit/s, -98.8dBm 500kbit/s, -94.8dBm 1Mbit/s, -91.2dBm 2Mbit/s LE, Power Output: Up to +19dBm
  • Nordic Semiconductor nRF52832 BT5.0/Mesh/ANT/Prop. + ARM Cortex M4 @ 64MHz – Sensitivity: -96dBm BLE 1Mbit/s, -89dBm BLE 2Mbit/s, Power Output: Up to +4dBm
  • Nordic Semiconductor nRF52840 BT5.0/Mesh/Thread/Zigbee/802.15.4/ANT/Prop + ARM Cortex M4 @ 64MHz – Sensitivity: -103dBm 125kbit/s, -99dBm 500kbit/s, -95dBm 1Mbit/s, -92dBm 2Mbit/s, Power Output: Up to +8dBm
  • STMicroelectronics BlueNRG-2 BT5.0/LE/Mesh + ARM Cortex M0 16/32MHz – Sensitivity: -88dBm, Power Output: Up to +8dBm
  • On Semiconductor RSL10 BT5.0 LE/Mesh/802.15.4/Zigbee/Thread/Prop. + ARM Cortex M3 48MHz – Sensitivity: -97dBm 250kbit/s, -96dBm 500kbit/s, -94dBm 1Mbit/s, -92dBm 2Mbit/s LE Power Output: Up to +6dBm
  • Dialog Semiconductor DA14682/DA14683 BT5.0 LE/Mesh + ARM Cortex M0 up to 96MHz – Sensitivity: -94dBm, Power Output: 0dBm
  • Dialog Semiconductor DA14585/DA14586 BT5.0 LE/Mesh + ARM Cortex M0 16MHz – Sensitivity: -93dBm, Power Output 0dBm


It is important to note that many of the specifications come with “fine print” and some of the figures above are actually not directly comparable. This is especially true for sensitivity, where Dialog Semiconductor seems to specify a packet error rate (PER) of 30.8%, while others are specified at 0.1% PER, which appears to be the standard. STMicroelectronics seems to use a 0.1% bit-error rate (BER) rather than PER, which complicates comparison as 0.1% BER may correspond to >0.1% PER in a real-life scenario.


When looking at the specifications, the Cypress CYW20819 seems to be neck-and-neck, perhaps middle-of-the-pack. While the Silicon Labs EFR32 Blue Gecko (Series 2) seems to be the “stand-out” product in the round-up with the highest sensitivity and power output figures, the power consumption seems slightly higher and starter kit for this product is almost four-times the price for a single board.


Considering that Cypress acquired Broadcom’s wireless IoT business in 2016, integrating it into their portfolio, the new Bluetooth 5.0-capable products build upon this heritage. On its own merits, the CYW20819 has quite good sensitivity and processing power compared with the remainder of the competition, with the biggest benefit seeming that the module is both Bluetooth Classic and Low-Power capable, allowing for almost any sort of Bluetooth device (e.g. even a headset) to be realised. Another benefit it seems to have is that the Bluetooth stack is part of the ROM of the chip, with a mechanism for patching, thus freeing the Flash memory to hold more user code than in other solutions where parts of the stack (e.g. mesh) may be loaded as part of the user code in the Flash. The Cypress devices are available as chips or modules with various configurations, simplifying integration and certification. Did I mention, the four-board evaluation kit is just US$119.99 from their site, making this a very affordable module to get started with.




The Cypress EZ-BT™ Mesh Evaluation Kit comes in a purpose-made plastic bubble pack which safely houses the items inside. The clear top of the case shows the double-sided colour insert which gives a quick introduction to the key items on the board and getting started with the kit. The underside of the case has four separate bubble compartments, each surrounded by foam, showing off the four boards.


In the top layer of foam, four USB-A to microB cables are provided. These are relatively short in length and stiff, allowing for powering and programming the boards. Definitely a nice touch to see these included, so that prospective users don’t have to scramble to find some in a drawer.


Removing the outer bubble pack, we can now gain access to the boards themselves which must be carefully extricated from the foam surrounds.


Looking at the board, it’s a little smaller in height but longer in width than a standard credit card, but overall is pretty compact for what it offers. Power input and programming can be achieved via the microUSB-B socket (J6) which interfaces to a Cypress CY7C65215 USB-Serial Dual-Channel IC (U2) with LED indicators D4 (RX), D5 (TX) and D6 (Power). The module (U1) is the Cypress CYW-213043-02 which has an integrated printed trace antenna, supported by a 32.768kHz crystal (Y1). The board wisely excludes any metallisation near the bottom to allow the antenna to operate with maximum effectiveness. The module is supported by an additional 8Mbit serial flash (U5) from GigaDevice (GD25WD80C). For convenience, three push buttons labelled recover, reset and user are provided, along with a point for current monitoring into the module (J2), the ability to isolate the HCI UART from the USB bridge (SW4), the ability to change USB-provided Vdd (J8) as regulated by a Texas Instruments TPS735 (U3)and select between USB and CR2032 power sources (J5). Supporting this are peripherals such as a Maxim MAX44009EDT+T ambient light sensor (U4), Murata NCP15XV103E03RC thermistor (R17), RGB LED (LED1), Elmos E931.96 + Zilog ZRE200GE PIR sensor (U12/U10). The design seems to be rather well thought out for evaluation purposes and the amount of peripherals supplied is rather impressive.


By comparison, the underside of the board is almost completely bare, except for a very stiff and secure CR2032 battery holder and rubber feet which elevate the board safely above the desk and any (potential) wire scraps. A very nice touch.


From the side, we can see the profile of the board is rather thin PCB-wise, but the Fresnel lens on the pyroelectric sensor and the rubber feet make the board somewhat substantial.


Removing the Fresnel lens, we can see the pyroelectric detector up close. I haven’t seen PIRs featured on many evaluation boards, but perhaps its inclusion makes sense as many of the detectors can idle at a very low quiescent current.


Setup & Demonstration

Cypress helpfully supplies a lot of high-quality documentation, the ModusToolbox IDE and Bluetooth SDK software and demonstration projects and apps for working with the mesh evaluation kit. Unfortunately, to set up the demonstrations took me longer than I had expected owing to a number of hiccups along the way.



A wealth of documentation and software can be downloaded from the Cypress website, some of which requires registration and support can be found in their Developers Forum (which is a Jive powered forum, like this one). The documentation includes PDF-formatted datasheets, quick-start guides, application notes and introductions, all of which I found very comprehensive and easy to read. I found myself reading close to 300 pages of documentation related to the product even before I received the unit. I found it especially impressive that the introduction to mesh covered everything down to the finer details of the included demo programs, while the low-power document was able to provide some simple and concrete best practices to make use of the low power capabilities of the range. The documentation for the evaluation kit also includes a ZIP file which includes the design files and schematics which can help kickstart your own design.


However, the above resources really are just the tip-of-the-iceberg when it comes to documentation, as the ModusToolbox IDE comes with its own documentation bundles. Specifically relevant is the WICED API documentation which can be accessed through the menu which detail all the functions within the library that supports these chipsets. Unfortunately, while this documentation is comprehensive, I found it more difficult to navigate and read especially when trying to do something different to the demo programs, having never developed with Cypress in the past.


Software Installation

The ModusToolbox Eclipse-based IDE software can be downloaded from Cypress for Windows, MacOS and Linux, requiring the creation of a free login. In addition to this, the latest version of the BT SDK is also required – this was V1.1 at the commencement of the review and is now up to V1.4.


Installation was relatively straightforward, but one issue is that the path must not contain spaces. The default path was within my user home folder, as my username contained spaces, I had to change this to somewhere else.


Once starting the IDE and specifying a workspace directory, the SDK can be manually installed.


While the “Update ModusToolbox SDKs …” option tries to check for software on the internet, it never seems to work and instead the “Install Custom SDK” feature has to be used. Installation of the SDK is otherwise uncomplicated.


Hardware Setup

Prior to being able to upload a project to the mesh device, the hardware must be installed. I expected this to be as simple as plugging the mesh board into a USB port using the supplied cable, but unfortunately under two separate Windows 10 machines, I encountered some errors.


Initially, I had problems installing the Cypress USB-Serial (Dual Channel) device, with no drivers found. Without the drivers, the HCI and Peripheral port both could not be detected and did not come up under Ports (COM & LPT) in Device Manager. I tried on a second machine and with internet connectivity but kept coming back to the same result as it seems the drivers included within the ModusToolbox installation do not cover the particular VID/PID/REV on this particular device.


I force-installed the driver anyway, and instead came up with a new problem. Instead of having the two expected ports, I ended up with four ports, all of which could not communicate and resulted in programming errors.


But by doing this first and then forcibly removing the driver, I found that the WICED Peripheral and HCI UARTs both came up correctly even though the device itself is still not attached to a driver of any sort.


Under this configuration, it was possible to see the temperature and light levels being printed to the serial port periodically. Apparently, this program is pre-loaded to the board as part of manufacturing testing. In one case, I also managed to provoke a blue screen of death while attempting to upload a project to the evaluation board – this may be due to a driver issue or conflict with the Azure Sphere board which I also have attached (for the Sensing the World challenge).


If Cypress could make sure that the drivers would pick up the device correctly on the first try, this would make things a lot more convenient.


Programming Demo Code

The process of loading the code onto the boards was surprisingly straightforward. By creating a new ModusToolbox IDE Application and selecting the correct model of evaluation board, you can create a copy of the sample project. Using the side Quick Panel menu, selecting the “Build + Program” option will take care of the whole process for you. Assuming you have one board connected, it will program to the first detected COM port with a valid response.


In case of an error, the message “Serial port not detected …” will be shown in red along with some suggestions to place the board into recovery mode to ensure it can be programmed.


While this suggestion is a perfectly valid one, it does miss one case which left me scratching my head for a bit. If the user changes the switches on the board to disconnect the HCI UART from the USB to Serial bridge, programming will fail. Perhaps the error message can be amended to remind users to check the state of these switches – as I found myself swapping boards and computers to no avail before remembering what I had done to the board.


Testing the Demo Code

The dimmable light and dimmer switch demo was tested on all four boards with provisioning done via the Android MeshController app. The .apk file is provided within the installation and needs to be manually side-loaded onto the target device. A demonstration of its capability is shown in my video below:

On the first start-up of the application, it requests a total of four permissions:


At this point, I’m not entirely sure why the application requires access to take pictures and record video or access my contacts, but declining any permissions results in the app freezing at the splash screen. As for access to files, this is understandable as the mesh network parameters can be imported/exported, while location is now necessary for those who interface with Bluetooth devices to do scanning. I reluctantly provided all permissions for the purposes of the RoadTest, trusting that Cypress isn’t going to do anything unusual to my contacts.


It seems this application may be used to demonstrate more than just the mesh network capabilities, including features for OTA upgrade amongst others. From the home screen, a new network must be created in order to test the mesh functionality.imageimage

Once a new “room” has been created, a device can be added into the network. A prompt appears to enter the nickname for the device (can be left blank) with unprovisioned devices appearing at the bottom after a short delay. It would not make sense to proceed without an unprovisioned device appearing in the list.

[Screenshot_2019-08-03-13-25-11] [Screenshot_2019-08-03-13-25-53]


Pressing on the toggles allows for controlling the connected device, once you are connected to the network (indicated by the green bar near the bottom). While the application also has features for colour, this is not currently implemented, with the boards only shining red at various intensities. Detailed configuration of each device (rather than the whole group) is also available, allowing the device to be deleted, moved or upgraded. The buttons didn’t render too well on my device, and I found bugs with removing multiple devices from a room in a single session, requiring a force-close and re-open to perform correctly.


While it would be logical to add lights and dimmers to a room, the temperature monitoring demonstration using the thermistor can also be added to the room.


Within the menus, it is possible to set the publish settings to cause the unit to send temperature readings at an interval or when a certain level of change is detected. I found the interval setting seemingly didn’t work but the change setting seemed to work just fine. All in all, that is a lot of features to demonstrate within this kit without getting into developing anything.


In the case of access via Windows computer with a Bluetooth radio, the Mesh Client application can be used to provision and configure the network. The tool is somewhat bewildering to those who may not be familiar with Bluetooth Mesh, but has a lot of capabilities.


For those who may not have access to a compatible iOS, Android or Windows-based device with the necessary Bluetooth capabilities, there are tools provided that allow for working with the mesh, using one of the kits as an interface via the HCI UART. The ClientControlMesh application can be used, which is even messier but has a lot of options which can be useful for debugging the various different BLE mesh profiles.


I was also able to use a third-party program to scan for BLE devices, where the dimmable light nodes appeared as MESHKIT, with a number of attributes.




Two major parameters I felt were worth testing in this RoadTest was the range that can be achieved from module to module and in mesh, as well as the power consumption of the module and system which could be important in battery-powered applications.


Range Testing

I evaluated the range that the unit could achieve first by modifying the existing dimmer control code to instead send periodic on-off commands in an endless loop. I would then use a second board programmed as a dimmable light and do a “walk test” around my house to check for coverage. Once this was completed, I joined other dimmable light boards to the mesh and then walked outside with the board into the street to see how far it would go. The results are shown in this video:

In all, it was quite impressive as even without the use of mesh, just having the one board seemed to give adequate whole-of-house coverage for a double-storey four-bedroom house even through obstructions and when powered solely using a single CR2032 cell. With mesh used, I could easily get into the street, crossing my neighbour’s house and into the neighbouring house to that before the connection began to be slightly intermittent, which suggests that the range could even be further than the 35m demonstrated.


I think this is an excellent result nonetheless, especially when considering the compact dimensions of the module, its Class 2 power output rating and the use of a printed circuit trace antenna which often translates to mediocre range. I suspect the Bluetooth 5.0 LE coded-PHY capabilities may have helped extend the range further than otherwise possible with regular 4.0 LE 1Mbit/s mode.


Power Consumption

Power consumption can be a critical part of ensuring IoT device lifetimes when running on battery. As a result, I decided to test power consumption using the included dimmable light and dimmer switch demo programs in the “low-power” and “non-low-power” modes.


CR2032 Power Consumption



While Cypress have conveniently provided a current test point (J2) which looks at the current flowing into the Bluetooth module, I was first interested in knowing what the load on the CR2032 cell would be for the whole evaluation board inclusive of the peripherals that were not in use at the time. To test this, I decided to modify two of the boards to allow for powering via lab power supply (Keysight E36103A) to the battery input contacts, while measuring current by observing the voltage drop over a 24Ω shunt resistor sharing a common ground using the Rohde & Schwarz RTM3004 oscilloscope with the RT-ZP10 passive 10x probes. I compensated for the shunt voltage drop by testing the Vdd at the board on the supplied test points so as to maintain an average-level at the intended voltage.


Testing the board in this configuration revealed some unusually high current consumption and oscillation behaviour, especially when the input was at 3.3V or 3.6V. This was tested with the HCI UART switches set to disconnect from the USB to Serial chip. I initially suspected some oscillation from an internal regulator as being potentially the culprit, but by forcing the voltage up to about 3.8V, the oscillation disappeared and the current loading looked more normal. This resulted in the LED near the USB port glowing slightly, so I suspect this oscillation behaviour is due to the USB to Serial bridge chip potentially being under-voltage or back-fed in a way as to cause it to be unhappy.


While testing using the CR2032 input, it was discovered the board’s quiescent consumption is anywhere from about 0.5mA to 2mA depending on the Vdd. This was measured by removing the J2 shunt, thus disconnecting the Bluetooth Module from the Vdd bus.




With the boards programmed with the non-low-power version of the demo, modified to toggle at 1s intervals, the mean power current consumption at various voltages was as follows:

  • Mesh Dimmer
    • 1.8V - 13.232mA
    • 2.5V – 9.7353mA
    • 3.3V – 9.2145mA
    • 3.6V – 8.7551mA
  • Mesh Light
    • 1.8V - 13.467mA
    • 2.5V – 10.62mA
    • 3.3V – 10.825mA
    • 3.6V – 10.792mA

The current is seen to reduce slightly with increased voltage, which is suggestive of a buck converter of sorts, which is present in the module for supplying the core voltages. The resultant current profile shows a number of “steps” and some spiky behaviour, which may correlate with the chip’s internal operation. Compared to the datasheet values of about 5.9mA for the module in continuous power mode at a Vdd of 3V, the additional current consumption is likely to be due to the quiescent draw of the other peripherals on the board and due to noise or measurement errors. While this level of current was tolerated by my CR2032 cells, it would not result in a long lifetime and would exceed the (nominal) 4mA continuous draw which they are specified for.


Testing the low-power version of the dimmer switch demo code, the average current has dropped significantly to just 3.1351mA at a Vdd of 3.3V, which would be more suitable for CR2032 cell usage but is still perhaps a bit high due to the quiescent current contribution of the other peripherals on the board. A close-up look at the current profiles during a button push show a small pulse when the button is pushed, followed by three sets of three spikes which may be related to packet transmissions, trailed by a smaller spike which may be the result of an internal processing of code.


At this point, I felt it would be wise to look at the module’s power consumption in isolation, to try and isolate the consumption of the module from the peripherals (assuming that current isn’t being sourced or sunk by the pins the peripherals are connected to).


Module Power Consumption

Now that I have seen the interference that can happen from the rest of the board’s peripherals, I decided to measure the power to the module using J2 and a shunt resistor of 12Ω to reduce the burden voltage while providing a signal that wouldn’t be swamped by oscilloscope noise.


Using the low-power version of the dimmer code and testing at the three provided Vdd levels of 1.8V, 3.3V and 3.6V, the measured idle average currents were 1.7839mA, 1.1338mA and 1.2595mA respectively. There is a fair amount of noise in the measurements, but they seem to correspond well with the datasheet expectations assuming the deepest sleep states are not being used. Every 10ms or so, there appears to be a short period of wakefulness, with some sporadic awakenings mixed in-between.


Unfortunately, due to a bug with browser image caching, the results for regular (non-low-power) mode current consumption for 1.8V and 3.3V did not save correctly, however, based on the 3.6V result, we do have a good idea what it might be. At 3.6V, the average idle current measured 6.2739mA which may be slightly influenced by noise and error, but is in-line with expectations as the datasheet specifies a 5.9mA maximum consumption at a Vdd of 3.0V. Because of this difference, it really highlights the need for effective utilisation of sleep modes to maximise battery life by minimising power consumption.


With the low-power version of the code, the pushing of the button to send a command results in the train of three large current spikes repeated three times as noted before. These spikes appear to reach 14mA at 1.8V, 8.86mA at 3.3V and 8.36mA at 3.6V but only persist for a short duration. I suspect the addition of the large ceramic capacitor over the battery input helps to reduce the magnitude of the current spikes, thus ensuring longer lifetime from the battery.



One thing that has not been mentioned so far is that I was unable to get the module to stably boot in the 1.8V setting with the current measurement shunt in place. I suspect the high current draw during the boot sequence may have resulted in the Vdd dropping enough to trigger the internal brown-out detection, causing a continuous reboot. Illustrated above is the current profile when the unit is booting with both low-power and regular dimmer demo code at 3.3V and 3.6V.


During initial start-up, there is a period of almost a second of relatively high current consumption around 18-20mA. This settles down for about 1.1 seconds then a short burst of activity occurs before the user code is executing in the case of the low-power mode version. The regular version shows a similar high-current consumption during boot, but then the consumption settles by about 1.1s where it appears to be in the stable operating regime. Whatever product the module is integrated into must be able to handle this initial start-up current consumption – this may cause issues say if a module is reset when the battery is low, as it could probably continue operating in the low-current mode, but would not be able to source the current required on a reset.


The datasheet suggests that at a 3V input, the operating current would range from 1.3 to 5.9mA depending on mode, with various sleep modes ranging from 1.75 to 16.5µA which would be quite suitable for long-term operation from a coin-cell battery. It would seem that even with the low-power mode flag enabled in the demo, it was not reaching these even lower-powered states as they may require the module to lose connectivity with the network or lose its internal state entirely. The measured currents seemed relatively consistent with the datasheet values, although the means of measurement may have introduced some level of error due to burden voltage.



The Cypress EZ-BT™ Mesh Evaluation Kit (CYBT-213043-MESH) seems to be a rather interesting and inexpensive evaluation kit that showcases CYW-213043-02 module built around the versatile CYW20819 chip which supports both Bluetooth 5.0 Classic and Low-Energy modes in addition to mesh. Its specifications seem neck-and-neck with its peers, demonstrating impressive range in testing. Its power consumption was moderate with the demonstration code, allowing for operation from CR2032 cells, however enabling lower power operation was fairly straightforward. The provided demo code and apps made evaluation of the mesh operation profiles fairly straightforward and documentation was excellent in its quality, however, driver issues did cause some frustration. The ModusToolbox environment is Eclipse-based, while the demo code is well explained by documentation, I found other API features of the WICED libraries not as easily accessible requiring a more considered effort to browse the API documentation. The demonstration tools cater for all situations, evaluating with on-board Bluetooth interface, iOS/Android mobile devices or using one of the boards via HCI as an interface. While the demo code did not make use of the other peripherals on the board, including the ambient light sensor, PIR sensor and two of the three colours of the RGB LED, their inclusion should facilitate experimentation and implementation of practical devices once the demos have been thoroughly explored. I think the kit is quite likeable, but really only scratches the surface regarding the versatility of the CYW-213043-02 module which is capable of a lot more with its onboard peripherals and supermux I/O.


Thanks to element14 and Cypress for their selecting me for this RoadTest and for their generous support of the community. While I have achieved the bulk of my RoadTest proposal, I mentioned that I would endeavour to build a surveillance system using the onboard PIR sensors if time permitted, but unfortunately, this was not achieved. In part, this is due to my unfamiliarity with ModusToolbox and the WICED APIs, complications in set-up which took more time than I expected and also due to time limitations caused by a number of other commitments (two other product reviews including a launch-day review, two TV media appearances, the Sensing the World challenge, job contract changes and health issues). However, if I should find the time to make it happen, I will post a follow-up blog posting detailing the process.


Top Comments

  • Amazing review.

    Well done!




  • Thanks for the comment , and my apologies for missing it yesterday when I posted the review.


    Indeed, I find many of the Bluetooth devices I have won’t make it upstairs without much reliability (or even out of the room) – but this all depends on how big your house is, the intervening materials, the competing noise-floor/interference of other devices in the 2.4GHz band, the amount of actual data being passed (and potential for retransmission), the physical layer coding in use (Bluetooth Classic, Bluetooth Low-Energy) and potentially even out-of-band interference (e.g. the 2300MHz LTE band could cause some desensitisation). I can’t say it would perform equally well in other people’s houses, but for comparison, my ESP8266-based Adafruit Feather (802.11n Wi-Fi) is sitting outside doing my weather station link and only manages to “just” hang in on a distance of about 10m through walls to the outside. The AP reports a received signal strength of about -82dBm and a link rate of just 1-2Mbit/s (similar to Bluetooth). This comparison alone shows just how impressive the range is, given both modules use printed trace antennas but the ESP8266 has a lot more output power (20dBm vs 4dBm). I’m actually considering replacing the outdoor weather station with a Bluetooth solution after seeing what it does – especially as the power consumption is quite a lot lower too (170mA active on the ESP8266 vs 10mA active with the Cypress). Perhaps this just goes to show that the inclination for Wi-Fi as the default choice for home IoT out of convenience may not be the best choice …


    With regards to the Cypress product, it already has an advantage compared to some other Class 2 devices which have just 0dBm (1mW) output – it has 4dBm (2.5mW). The higher output power would reach further – but perhaps not as far as devices with more power (e.g. Class 1 devices). I suspect the printed antenna design is quite well optimised, along with the design of the base board that is free of metallisation near the antenna – a few design mistakes can really affect your radiation pattern and antenna efficiency.


    Another advantage that can be added to this is the Bluetooth 5.0 low-energy coded PHY options which can reduce data rate down to 125kbit/s. This allows for longer ranges through error correction and the lower signal-to-noise requirement/higher sensitivity for the same error rate. The Cypress has about 7.5dB sensitivity advantage over the STMicroelectronics solution, and the coded PHY seems to add another 7.6dB judging from the Silicon Labs figures. Add up the few dB advantage here and there and the range can be substantially increased – it takes about 12dB to double the range in an ideal case.


    That being said, I suspect that perhaps sporadically reported “kilometre+” range Bluetooth low-energy connections could perhaps happen in the ideal case, which is pretty amazing compared to what Bluetooth’s original intention was – to be a “personal” area network. This is actually a good thing for IoT as it means that even for cases where consumers may not go “all-in” on home automation (for example), just a few globes should ensure reliable coverage within the whole house. I suspect if the IC was connected to a proper dipole antenna or one with some gain, significantly longer ranges could be possible, which could make for some amazing low-powered telemetry system links as well.


    Of course, if the end user device is not capable of Bluetooth 5.0 LE, they won’t benefit directly from having the coded PHY rate extensions, but on the other hand, the Cypress’ GATT Proxy feature will allow the phone to “speak” with the nearest module and have it relay the message across the mesh. It’s a very handy feature in case of using older Bluetooth devices with the mesh, especially since the chip also supports Bluetooth Classic. There’s really a lot of capability … I’ve really only scratched the surface.


    - Gough

  • Good road test report.


    Well done.



  • Thanks for the comment @BigG.


    The Bluetooth HCI interface is actually quite useful for a number of reasons - the first is that the HCI is a standard for communication to a host stack, so you could theoretically use the module as a radio for a PDA or PC as long as it understands the HCI protocol. This is what one of the included MeshClientControl app does for the people who may not have a compatible Bluetooth capable device to evaluate with. By breaking them out, you can potentially avoid current leakage and also provide a way to leverage the module with another host using the HCI protocol.


    The second reason that the HCI UART connection is broken out is that I suspect it can be used either as an HCI UART or as almost anything else due to the SuperMux I/O capabilities. The HCI UART is the pins P28-31, and according to the CYW20819 Datasheet (002-22950) in Table 4, it seems that these pins support the SuperMux remapping to virtually anything else listed in Table 5 and 6. This way, you (theoretically) could give up the HCI UART altogether and instead route I2C or SPI to these pins that are presently mapped to HCI should the HCI not be needed.


    The ambient light sensor is using the I2C bus on Pins P27 and P32. While they are not broken out for your convenience (which is a shame), you could also perhaps use the J4 connector and take Pin 3 (P12) and Pin 7 (P13) and route that to a second I2C controller (as the silicon has two hardware I2C buses) and get the I2C broken out without any hard work. Otherwise, you could just solder to the non-Vdd end of R18 and R19 ... not ideal but far from being impossible. Ordinarily the second I2C bus is recommended on P19 and P20 which don't seem to have a footprint on this module at all.


    - Gough

  • A great overview with some nice indepth testing. I particularly liked the fast button test and the explanation about the cause for the lag. Spot on with the evaluation. I was also scratching my head over why the board included an HCI UART pinout (J1) and your write up help me understand its (or one of its) purpose(s). So, will be intrigued if you could review this aspect a little more if you ever get time. Otherwise the J4 pinout seem a little limiting if you wanted to expand application. E.g. there does not appear to be an I2C port option even though I believe the light sensor uses I2C.

  • Awesome Roadtest. That is quite an impressive range. Bluetooth pretty much fails between upstairs and downstairs in my house.


    Kind regards.

  • Thanks for your kind words ... it's been a rather busy time for me, so I do feel a little bad for not developing something with it in the time available, but at least I was able to give the demos a thorough test which was the majority of my proposal. I hope others find the Cypress EZ-BT kit as interesting as I did - the price isn't bad when one considers they get four boards as part of the deal image.


    - Gough

  • Good review . The gold standard of course.