RoadTest: Solar-Powered IoT Device Kit
Author: BigG
Creation date:
Evaluation Type: Evaluation Boards
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?: I'm not aware of any comparable product on the market that provides both a Bluetooth Low Energy module with an integrated Power Management module offering essentially 4 different power supply options on a single compact PCB. An online search for solar powered off-the-shelf beacons revealed a couple of commercial options but these were not development platforms: http://www.ekoor.io/ and http://gcell.com/gcell-launches-worlds-first-indoor-solar-powered-ibeacon.
What were the biggest problems encountered?: The demo software provided would not compile on PSoC Creator.
Detailed Review:
Firstly, I would like to thank Element14 and Cypress for the opportunity to road test this product. This was my first road test and this was also the first time I’ve used any of the Cypress products before. By the looks of things I picked an interesting one.
I have a business and systems engineering background so could see potential novel use cases for this product based on my active involvement in developing applications within the Internet of Things (IoT) market. Hence my initial interest to road test and familiarise myself with the Cypress development platform.
The more I've delved into the engineering behind the product and the more I've built upon the embedded software examples provided for this development kit, the more I can see the potential for this integrated Bluetooth + PMIC “motherboard” (or derivatives of it e.g. PMIC with Broadcom WIFI module), becoming a “go to” off-the-shelf platform for industrial IoT measurement / monitoring applications (e.g. cold chain monitoring where battery performance can be poor).
I found the User Manual provided to be very comprehensive, covering everything I needed to know about the platform. I found it very clear and instructive and have continually used it for ongoing reference.
It’s just rather unfortunate that the Cypress team have still to fix the demo firmware download files to make them install and compile correctly. These download files still show last updated as of 10/28/2015, despite the fact that they've been informed that the download process is flawed. Hopefully these problems, if they remain unresolved, do not put off potential users of what I think is a great product that will serve certain market segments extremely well, as is.
It is also rather unfortunate that you cannot purchase additional motherboards to facilitate more extensive field testing, which is minimum requirement for wireless sensor networks, and to allow for small projects to be created using this platform. As it stands I see limited value in purchasing just the kit, which only has one motherboard and one dongle, other than for testing a basic proof of concept. In my opinion, I would think that the compact nature of the hardware also limits the ease in which one could readily get small quantities of these motherboards made cheaply. Hence the desire to be able to purchase the motherboards directly.
My road test review dives straight in to the technical detail. Please read my blog which documents my first impressions unboxing and getting started with the Development Kit.
There are 2 main components to the Development Kit, namely:
The Energy Harvesting Motherboard includes the following Cypress devices:
My first impression was, wow they’ve packed a lot onto this board, which measures just 45mm x 25mm. As pictures do a better job explaining here are some comparisons.
Picture on left shows RedbearLab’s BLE Mini, which has TI's CC2540 SOC (system-on-chip). With this SOC you require the IAR compiler to develop your own firmware, which is not free (software license required).
The picture on the right shows a CSR Bluecore 04-External single chip Bluetooth system. This is a standard Bluetooth Serial Profile module, which implements the Enhanced Data Rate (EDR) Bluetooth® specification.
If you exclude the antenna on the CSR Bluecore, then both TI’s CC2540 and CSR Bluecore SOCs are of similar size. As you can see the CYBLE-022001-00 EZ-BLE PROC module on the motherboard is significantly smaller in size.
The motherboard has a 2x10 2.54mm pinout for external connections. The board comes with one row soldered with pin headers (J1-1) and the outer row unpopulated (J2-1). I soldered additional pin headers onto my board so that I could connect an external device to the I2C SDA and SCL ports.
The energy harvesting motherboard essentially has four power supply options. There are separate pin connectors for each power source and there is an additional connector for a storage capacitor:
Two of power supply options are common with many development boards, namely USB and battery. The 5V USB power supply is via a mini B connector which bypasses the S6AE101A PMIC and is stepped down to 3.3V by the MB39C022G LDO. Battery power would be through a CR1220 3.3V lithium coin cell battery which is handled via the S6AE101A PMIC. You would need to purchase and solder a BK-885 battery holder on the pads supplied on the bottom of the board, as shown on the silkscreen, if you wish to use a battery. Note battery power was not tested in this review.
The other two power supply options, namely solar cell and AC (piezoelectric), are handled via the Energy Harvesting Power Management IC (S6AE101A). The PMIC has been configured (with the use of resistors) to deliver an output voltage from 1.9V to 3.3V. The User Manual provides a useful block diagram for reference (as shown below).
The solar cell provided with the development kit is the Panasonic AM-1801. Following a quick check, I see that the Panasonic Amorton Solar Cells are available through Digikey and Mouser and that there is an extensive range to choose from with suitable voltages. The AM-1801 has an open circuit voltage of 4.9V with typical short circuit current of 20µA. There is certainly scope here to increase the size / capacity of the solar cell to deliver enhanced performance should your application demand it. For a few dollars more you could use the AM-1815, for example, which has an open circuit voltage of 4.9V with typical short circuit current of 47µA.
By way of a quick comparison, I did the 10Ω Resistor Current Measurement Test as described in 11.2.1 of the User Manual (page 94) with 2 other solar cells I had in my possession. These were low cost 0.5W and 1W cells. Both these were of single-crystal material. Neither cells are considered in spec as have a higher open circuit voltage. Nevertheless these demonstrate just how little power is required by the PMIC when powered by the AM-1801. In comparable lighting conditions the AM-1801 recorded 202µA, the 0.5W solar cell recorded 1298µA and the 1W solar cell recorded 2671µA. Page 97 of User Manual provides a useful formula to calculate the Maximum Power Point (MPP1) energy if you wish to determine best case for solar cell operation under given lighting conditions. The development kit specification claims that the system will operate using light >200 lux energy. This was not verified. Needless to say if having problems with AM-1801 providing sufficient power then upgrade as I believe there is plenty of scope to upgrade here. An overvoltage protection (OVP) function is built into the input pins of the solar cells, and the open voltage of solar cells is used by this IC to prevent an overvoltage state.
According to section 6.1.5 of the User Manual, the motherboard supports receiving AC voltage from piezoelectric or electro-magnetic Energy Harvesting Devices (EHDs). According to the energy harvesting block diagram an external diode bridge is required. Unfortunately, very little else is provided regarding specification of power limits and suitable or effective AC frequencies etc. AC voltage input requires a 2 x diode bridge (1SS383’s).
I did not test this power option, but if AC power can be used then I see no reason why you cannot use a good old fashioned dynamo to generate power for the motherboard or use more sophisticated non contact magnetic induction generators instead of just finding ways to harness vibration energy. If this is the case then this means that you have the potential to generate a regenerative power source to the motherboard from with any rotating or moving machinery.
Similarly with strict minimum lighting standards required on all factory floors, this platform has the potential to be used for all sorts of industrial related telemetry measurement or monitoring applications that would normally exhaust any battery operated device. Furthermore, I would think that this product would work well with certain thermoelectric energy harvesting devices in certain conditions.
It is worth noting for the reader’s benefit that the PMIC does not provide a charging circuit to recharge any battery, as you may often find with some solar cell lithium ion / polymer battery chargers. Instead the S6AE101A supports hybrid operation where the battery provides a backup charge. According to the S6AE101A datasheet, the voltages at the VDD pin and VBAT pin are monitored, and selection control of the input power supply is performed based on this voltage state (Figure 7-1). This is one reason why the board can be powered with such a small solar cell.
The board also provides two connectors (VSTORE) which allows for a capacitor to be connected. The Development Kit comes with a 220 μF capacitor which can be used and the user documentation provides an explanation of how it is used in section 11.2.2. Larger capacitors could also be used is so desired. The impact of using a larger capacitor is that it extends the start up time.
Not knowing anything about the Cypress product range to start with, it took me awhile to work out that PROC (Programmable Radio on Chip) modules are not PSOC (Programmable System on Chip) modules, but I have yet to work out why they also make a distinction on the landing page for BLE between EZ-BLE modules and standard BLE (as in PSoC 4 BLE and PRoC BLE). Even now as I write this and look at their website it is still quite confusing. So, you need to keep your wits about you navigating the Cypress website as you are often presented with PSOC information through term searches which may not be applicable.
Cypress provides product road maps which are worth looking at as they provide a high level overview of which model does what. Here is the overview of their EZ BLE product range.
Then within the EZ-BLE PRoC/PSoc module range (all of which are fully integrated, fully certified, programmable modules) there are 9 product part numbers, where each differs based on amount of flash memory, GPIO’s, UDB’s, OpAmps, etc. See the Cypress website for more detail.
The Bluetooth module on the motherboard is the CYBLE-022001-00 EZ-BLE PROC module. The datasheet for this module is available here: http://www.cypress.com/file/140791/download. According to this datasheet, the CYBLE-022001-00 is a turnkey solution and includes onboard crystal oscillators, chip antenna, passive components, and Cypress PRoC™ BLE. It is part of the CYBL10X6X family of PRoC BLE modules. A datasheet is also provided describing the CYBL10X6X family: http://www.cypress.com/file/139841/download
According to the Cypress website, the PRoC BLE is a 32-bit, 48-MHz ARM® Cortex®-M0 BLE solution with CapSense®, 12-bit ADC, four timer, counter, pulse-width modulators (TCPWM), thirty-six GPIOs, two serial communication blocks (SCBs), LCD, and I2S. PRoC BLE includes a royalty-free BLE stack compatible with Bluetooth® 4.1 and provides a complete, programmable, and flexible solution for HID, remote controls, toys, beacons, and wireless chargers. In addition to these applications, PRoC BLE provides a simple, low-cost way to add BLE connectivity to any system.
The Development Kit’s User Manual, provides a helpful Block Diagram (Figure 1-1) and a schematic of the EZ-BLE module. Note that the 2.54mm 2x10 pinouts on this module do not show SPI by default (this can be assigned through PSoC Creator). It only includes I2C SDA + SCL, UART RX + TX and GPIO’s. On the motherboard there is also a footprint for a pushbutton / DIP switch marked SW1. This is connected to pin P4.1. I learnt through the forum that this pin cannot act as a hardware control pin. There is also an LED (LED1) on the board which is connected to pin 3.4 and there are 4 GPIO pins available (P0.4, P0.5, P3.6 and P3.7).
Finally the User Manual provides a detailed Bill of Materials (BoM) of the motherboard for those who wish to look at producing their own customised version. A complete list of project files, include a BoM file is also provided when you download the Demo Kit software package from the website.
A separate connector is provided for use with the MiniProg3, which is not included with the kit. According to the User Manual, the MiniProg3 is the hardware/firmware block for onboard programming, debugging, and bridge functionality. It is a common reusable hardware/firmware block used across many Cypress kit platforms.
Section 7.2 of the User Manual provides a detailed description of how to connect and use this programmer.
As no MiniProg3 was provided for the road test, I did not evaluate this functionality.
The dongle, as pictured above, uses the following Cypress devices:
According to the Cypress website, the CY8C58LP PSoC® 5LP family is a true programmable embedded system-on-chip, integrating configurable analog and digital peripherals, memory, and a microcontroller on a single chip. This includes a 32-bit ARM Cortex-M3 core plus DMA controller and digital filter processor, at up to 80 MHz. A datasheet is available here: http://www.cypress.com/file/45906/download
The CYBL10162 PRoC BLE module is also part of the CYBL10X6X family, as mentioned in the previous section 2.1.1.
According to the User Manual, the initial firmware programmed into the BLE-USB Bridge does not support the CySmartTM Software Utility (which is referred to on the Cypress website for the CY5670 CySmart USB Dongle). Instead, the firmware provided for this dongle is a custom version used for demonstrating the features of this kit.
As such during this road test the dongle was merely used for evaluating data received from the motherboard and did not form part of the evaluation. As such I did not evaluate how one could update or change the firmware for this dongle.
When it comes to practical applications where you need to collate data onto a PC etc. from various EZ-BLE modules then it is an extremely useful piece of the kit.
It is worth noting that the User Manual still provides schematics and a BoM for this USB dongle, and the design files are also provide in the project folder.
At the bottom of the S6SAE101A00SA1002 Solar-Powered IoT Device Kit webpage (http://www.cypress.com/documentation/development-kitsboards/s6sae101a00sa1002-solar-powered-iot-device-kit) you can download the related project files.
When you’ve installed the package, you may see the PSoC Creator updater show the following (well it did for me anyway):
Seeing “Network Error” underlined and in red did not exactly fill me with confidence, especially as I was only starting out and had never used PSoC Creator before. So getting to know PSoC Creator did not start well at all for me. It required a quick query on the Cypress forum to check that I had not made an error.
Surely there is a simple fix to resolve this as it is damaging the reputation of the other Cypress software.
The problems did not end there. Once you have installed the package you get 4 examples to choose from under “Kits” as shown below.
I found that none of these examples provided would compile. After extensive trial and error, as had still to learn the ropes with PSoC Creator, I discovered that when selecting any of the programs shown, PSoC Creator did not then copy the UART_Bootloader subfolder across into your workspace. To resolve this issue, I simply manually copied the UART_Bootloader subfolder (any one will do) from the Cypress program folder into my workspace directory. I posted a query on the Cypress forum that touches on this issue and raised a ticket with Cypress technical support.
Then when you have this folder copied across you need to manually set up the correct dependencies in the Bootloadable component in TopDesign.cysch. That should then allow the examples to be built.
A further problem, which I ignored, is that if you select “new component updates” and update your components a bunch of new errors will arise. So the tip is, don’t update your components unless you want to spend time debugging and problem solving.
Once these issues are sorted you have 4 examples to work with. Just to note that for this review I did not experiment with the dongle firmware, BLE-USB_Bridge.cywrk. Suffice to say that this example has been configured to work with the iBeacon data structure which is used in two of the motherboard examples, namely Simple_BLE.cywrk and EH_Motherboard.cywrk. The other motherboard example is a simple LED hello world project (LED_ONOFF.cywrk) which does not use BLE functionality.
Chapter 8 of the User Manual (pages 51 – 65) is dedicated to the pre-installed project. It is a very well documented project providing you with everything you need to know about the program structure, function list and explanations of some the key functions. The documentation also provides waveform visualisations of what is happening internally. For example, this shows what happens to Output Voltage following each BLE advertisement:
This chapter of the User Manual also provides a very useful description of the BLE data structure:
The BLE beacon parameters can also be configured through the USB serial connector and with TeraTerm. The User Manual provides a list of commands that can be used to configure the program.
The firmware on USB-BLE dongle has been configured to read this data (you will see a flashing blue light on the dongle when it is doing so). When you insert the USB-BLE dongle into a PC/Laptop you can then use a separate program PMIC.exe to evaluate the data received. This is explained in 6.1 of the User Manual.
The default demo with the PMIC application is the RSSI signal strength / distance estimation. There is also an option to show temperature and humidity data via a Silicon Labs temperature and humidity sensor (Si7020) embedded on the motherboard.
The other BLE project that comes with the kit is a simple BLE beacon demo.
As can be seen from the PSoC Creator TopDesign schematic and the pinout configuration there are no UART or GPIO interfaces. This example simply transmits a data packet at a set interval based on the timings configured in the Watch Dog Timer component.
With the AM-1801 solar cell connected, you can literally stick and leave the motherboard anywhere where there is sufficient light (User Manual suggests minimum 200 lux). I tested this example using an Android beacon scanner I found on Google Play with the beacon placed indoors.
The User Manual provides a handy table to determine timing intervals for your beacons based on lighting levels when using the AM-1801 solar cell:
For those who are aware of the Apple specification for iBeacon, they recommend a timing interval of 100msec. As you can see the worse case timing intervals given here are not really compliant with the iBeacon standard but then so will many other beacons, which will trade off this interval frequency for improved battery longevity.
However, for Shopping Malls, factories and offices where lighting levels will be consistent and at sufficient LUX, you could readily achieve this spec if you upscale this minimal AM-1801 solar cell, and then if needs be add in a suitable storage capacitor and use the back-up battery for added reliability.
If you are considering this platform for beacons / “physical web” applications then Google’s Eddystone format, would probably be a better bet as the timing intervals used here tend to be 1.5 seconds. With Eddystone you get the option to define a UID (unique identifier), a URL (in compressed format) and include telemetry payload (TLM) data such as temperature and battery voltage.
There is an Eddystone BLE example available on Github as part of Cypress’s 100 BLE project series. Unfortunately this is not tailored for this platform but I believe it can be readily customised to suit. I did not have time to verify this assertion.
As I said I had no prior knowledge of any Cypress products before. In a commercial organisation there is always a risk to using unfamiliar products due to unforeseen problems. In my case this was a self-learning exercise which can be quite frustrating at times but once you stumble on the right information it is certainly worth doing. Although not targeted at this platform specifically, I found the PSoC 101 video series to be really helpful in familiarising yourself with the terminology used, PSoc Creator itself and the prescribed processes to get firmware developed.
There are many novel features, such as first creating your TopDesign schematics using the component menu, defining the pinouts for your chip and then creating your firmware template using the “Generate Application” menu option, which seem strange at first but the more you get into it the more sense it makes.
I have to say that I really like the PSoC Create IDE. Even without having the MiniProg3 debugger, the IDE provided very good feedback on code errors. The IDE is the best I have used to date (not that I have extensive experience mind you, and this is just personal preference – for example I don’t find the Eclipse IDE easy to use while I’m sure many other readers will swear by it).
So to familiarise myself with the Cypress development environment while at the same time testing this platform I decided to attach an Adafruit TSL2561 sensor to the motherboard and get it to calculate LUX values from the light and IR values read through I2C.
I then modified the data structure used in the EH_Motherboard.cywrk so that it could include LUX values. I did this by adapting the UID allocated space to allow me to still use the BLE-USB bridge firmware. The temperature and humidity data was included in the major and minor values (I modified code here too). I then created a simple Processing (www.processing.org) application using one of the serial port examples to extract out the data received from the BLE-USB dongle and then posted this to Carriots, a cloud based system (www.carriots.com). Processing has an MQTT library and Carriots accepts MQTT publications to upload data. Here is a schematic of the rudimentary data logging system I created:
My initial TSL2561 I2C code is attached (code is provided as is). Note my workspace folders and the project folder is a little mixed up. This project (I2C_TSL2561_Test.cydsn) was created as a standalone which uses the UART to send LUX updates and provide debug information. Note to see the UART output, you first need to press the motherboard reset button and wait for the 10 second bootloader routine to expire.
