Are you considering using Cypress’s PSoC 4 BLE to run as a central?

Cypress offers a wide range of BLE 4.x System on Chip (PSoC) and Radio on Chip (PRoC) as well as plenty of certified modules for a faster time to market.

They also offer various basic embedded software example codes, which are very important for a successful development.

Many BLE systems are used as Peripherals, running a GATT Server. A client can connect to the peripheral and typically performs read / writes on its characteristics.

One type of popular Client are smartphones, they are usually used for user setup, gathering data and general interaction with the Bluetooth peripheral.

It is also possible for Cypress’s PSoC 4 BLE to act as a client. The IoT chip can scan for advertisement data, get the scan response, connect to the peripheral, discover its characteristics, and perform read/write/notify on them.

Multiple peripherals

Cypress’s PSoC 4 BLE does not support simultaneous connection to multiple peripherals.

They however advertise what they are calling “time multiplexing”.

What is Cypress’s PSoC connection time multiplexing? 

Behind this marketing term “time multiplexing” is a very basic concept : because PSOC 4 BLE used as a central cannot connect to multiple peripheral at once, the central will connect to one peripheral after another, one at a time… as easy as it sounds.

A typical application for a PSoC 4 BLE Time Multipled Central (TMC) could follow a sequence like this :

1. Scan for all peripherals.
2. Connect to the first peripheral and discover its characteristics.
3. Disconnect.
4. Connect to every other peripheral and discover their characteristics in a similar manner.
5. Bond to all peripherals the system is interested with.
6. Connect to one of the peripheral.
7. Do the necessary Read/Write operations.
8. Disconnect.
9. Repeat operations #6 to #8 in a loop with every peripheral.

Why is Cypress’s Time Multiplexing a bad approach? 

While a BLE Time Multiplexed GAP Central seems easy and works fine, there’s a couple of reasons why this approach is very bad.

Power (in)efficiency

First, BLE stands for Bluetooth Low Energy, and as the name implies, it has been designed to be energy efficient. The time multiplexing does not allow to take profit of the design and thus is very inefficient.

In BLE, the connection is maintained open by periodical short messages (Connection Interval), this is handled at the low level (Link Layer), allowing the application to sleep. Cypress’s solution for a multi peripheral central implies CPU and BLE overhead due to the connection /disconnection. This affects both central and the peripheral.

Notification/Indication 

BLE has a Notification/Indication system that can notify the client of a change in the peripheral’s value. Doing so there’s no need of constantly polling the data. Both central and peripheral can sleep as long as there’s no data update.

These flags are disabled by default and it is required to activate them by performing a write operation to the CCCD (Client Characteristic Configuration Descriptor) of the corresponding characteristic.

Most peripherals reset all flags on disconnection, thus making it useless with Cypress’s time multiplexing.

Stolen peripheral 

BLE is now widely used and everyone has a smartphone capable of connecting to any peripheral that is advertising. Once connected, the peripheral will stop advertising because it is already connected and cannot accept a new connection.

This means that if you have 4 devices you connect to in a time multiplexed manner, each device will be available and connectable 3/4 of the time.

During this time, should anyone connect to the device, it’ll be invisible to the central and impossible to connect to. Connecting to a peripheral could be intentional or unintentional. What I’ve learned from experience and very concerning in an industrial environment is that bugs in some Android devices lead Android not willing to disconnect from the peripheral even though the Bluetooth is switched off in the UI! The only reliable solution found is to reboot the Android phone.

Placeholder for research : would BLE authentication improve this issue by avoiding a hacker to connect to the peripheral?

Could the BLE component be improved 

Cypress’s BLE component could certainly be improved in various manners, but the limiting RAM space and lack of low layer documentation seems to make this solution very difficult. I think this development time should be spent doing a better user application rather spending time on developing a proprietary BLE driver

The advantages of BLE Time Multiplexed Connection

The main advantage by far of such a system is to be able to connect to an unlimited number of peripherals. Whether there are 4 or 40 sensors in the system, there is not much difference from the central’s point of view. The connection time will of course be shared between all sensors with all the downside listed above.

Most sensors are battery powered, it is possible for the user application to sleep while no client is connected and wake-up only once a connection request is received. Advertisement is handled by the link layer, no need for the user application to run.

Other solutions 

I have successfully developed a BLE central client, able to connect with multiple simultaneous peripherals at once. The central is maintaining connections for 4 peripherals while advertising and allowing connection of a client to its own GATT server. The low power client also supports all the benefits of BLE including Notifications and CPU sleep. However, the BLE central is based on a TI CC2640R2F instead of Cypress’s solution.

Are you looking to create your own BLE central device, taking advantage of the low power design of the wireless connection? I am looking forward to discuss your needs, contact me now: jerome at yupana-engineering.com!