Evaluation Type: Independent Products
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?: Options include, but are not limited to : Raspberry Pi 3, Intel Edison, MediaTek Linkit One, Texas Instruments CC 2650 Launchpad
What were the biggest problems encountered?: null
First of all, a shout out to the good folks at element14 and Genuino who decided to have this Roadtest and select me as one of the reviewers.
My application for the Genuino 101 is called the BLE-Based Smart IoT Node with Future Sight. I admit, the name is a rather amusing mixture of cheesy and chic, but hey, what's in a name?
Everything, as it turns out. The application involves using the Genuino as an IoT sensor node with BLE connectivity in a smart wireless control system. The Genuino senses environmental parameters via its ADC and forwards these values to a mobile device over BLE. The device will input these values to a regression algorithm which predicts future values of the environmental parameter under consideration, say, light intensity. It writes this predicted value to the Genuino's BLE characteristic, which is then read by it. According to the predicted value, the Genuino will turn an actuator on or off.
For ease of understanding, here's a flowchart which outlines the project.
1. Unboxing, First Impressions and Setting Up
The Genuino 101 is a development board with the footprint of a typical Arduino Uno. Rookies might mistake it for the same, but it's hard to do so. Even if you miss the golden BLE antenna snaking along the top edge of the board or the colourful reset switches, the nice, bold Intel logo tells you that this isn't your standard Arduino. You do notice a fair bit of the PCB populated with components you wouldn't normall find on an UNO as well. These are the Intel Curie based processor, the IMU (Inertial Measurment Unit) which houses the Gyroscope and Accelerometer as well as the aforementioned BLE antenna.
The board comes shipped with a small pamphlet, which turned out to be and instruction manual, and not much else. It would've been nice for them to have included a USB type B cable with it, because it really is rare in this day and age. I had to scavenge my old printer to find one.
Setting up the Genuino was a smooth process, aided by their helpful guide on the Arduino page. It is very similar to your first run of any other Arduino,the only extra step being to install the Board Package from Tools > Boards > Boards Manager.
2. Functionality Tests
2.1 Blink : The Hello World of Embedded Systems
Much like the development board itself, the Blink demo serves quite a few purposes from my point of view. Firstly, it checks the basic functionality of the board, where the Genuino blinked away to glory after uploading the code. Secondly, it provides a ready reference for the most preliminary actions that the board may perform, in this case, configuring pins and toggling their states. And thirdly, it is a vital part of the first run. If it is the first code you run (which it usually is), it automatically runs you through the setting up process, which is exactly what it did for me.
The first run for the Genuino involved booting up the Arduino IDE, I'm using the 1.6.4 version, and selecting the Blink example from File > Examples > Basics > Blink. Once you connect the Genuino 101 to your PC, you should see a COM port dedicated to the Genuino 101 appear in Tools > Port. Select it and while you're there, also select the Arduino/Genuino 101 board. Once done, it's a good practice to compile the code before uploading, even if you know that it's flawless. Makes for a well set habit. Once done, upload the code to the Genuino 101, and you should see the Genuino 101 blinking away merrily.
2.2 BLE 101
Over here, I'd like to provide a brief, intuitive understanding of how BLE works. Within a BLE ecosystem as it is a 1-to-1 connection, there are only two devices, a peripheral and a central (also referred to as slave and master respectively.) The peripheral usually generates data and the central demands it, however in some cases it may be the other way around. I won't go into how exactly BLE varies from Classic Bluetooth, but suffice it to say that BLE, as the name suggests, uses a lot less power and is usually used in data packet transmission such as data acquisition from sensors as opposed to traditional Bluetooth, which is more optimized for data streaming.
So how do a peripheral and a central communicate?
Think about the peripheral as a notice board. It has a lot of notices on it, which correspond to services on the peripheral. Services are a set of variables (for the sake of abstraction) which can be read from or written to, according to the properties specified by it. These variables are called characteristics. Thus, each service is essentially a set of characteristics. A peripheral may have a number of services. Now, coming back to our notice board analogy, suppose a central is interested in only one particular notice. It will look at that notice and nothing else. This is done by hooking on to the required service/ notice using a unique identifier called a UUID. Every service and characteristic has a UUID. Once the central has connected to the peripheral via the desired service, it can read or write to the characteristics within that service according to their properties.
2.3 BLE Peripheral Initialization
This was the part I was most excited about. The Genuino 101's party piece, BLE connectivity. What was more attractive was that the entire procedure can be done exclusively from within the Arduino IDE. Now, I've worked with the Intel Edison and the Raspberry Pi 3. Both of them are robust development boards with lots and lots of bells and whistles. They also run operating systems, which is the beginning of a lot of hassles if you simply want to work with BLE. With the Edison, for example, you are required to disable the native bluetooth controller, which for some reason creates its own GATT server, to use the Edison's BLE module with Python or Node.js libraries.
On the 101, however, being a one trick pony in terms of communications actually works out well for it, because although it can only communicate wirelessly via bluetooth, it can do it marvelously. The lack of an RTOS implies a very simple, sequential flow of code, which is very easy to understand for a hobbyist with very little experience with programming. Add to it the high level C++ libraries for the BLE module on the 101, and you have a wonderful prototyping and training tool. You don't have to mess with GATT profiles or configure devices. According to the given BLE example, the procedure for getting your Genuino 101's BLE up and running is as follows.
2.4 BLE Pairing Tests
Now that the Genuino 101 is up and running as a peripheral, it was time to connect to it using a BLE central server. For initial functionality tests, I used my phone, a Nexus 6P running Android 7.0. An app called nRF Connect, available on the Play Store for free, allowed me to connect to the BLE peripheral and explore its offered services and associated characteristics. The sketch uploaded onto the Genuino was the LED sketch provided in the examples menu. This allowed me to toggle an LED on the Genuino 101 via BLE. Sending a 0 would switch it OFF, sending anything else would switch it ON. Below are the screenshots of the app.
Initially, I had planned on developing a standalone Android application as the central for BLE communication with the Genuino 101. While this is indeed a more convenient and ubiquitous solution, it does take a lot of time, Java not being my cup of tea. Hence, I planned on utilizing the MIT App Inventor platform which allows for Scratch programming style drag-and-drop blocks of code to create an Android app. Fortunately, they do carry a BLE block, which unfortunately ran into problems on my Nexus. Secondly, developing a machine learning algorithm using Scratch would be like trying to travel from Earth to the Moon on a bullock cart. I haven't completely ditched the idea of an app, but I won't be using it here.
My next option for a central module was either an Intel Edison or a Raspberry Pi 3. I used the Edison because it seemed like a more elegant system (Intel-Intel, geddit?). After a few virtual gymnastics, I managed to open the BLE module on the Edison for development. I used Node.js to initialize a central server using a module called noble, and let it sit listening for advertisements from the Genuino 101. In particular, the LED advertisement. However, I interfaced a light sensor to the Genuino's analog inputs (the simplest one I could find, a regular voltage divider circuit), tweaked the code a bit, and now the Genuino 101 regularly wrote the light intensity to it's characteristic, which the Edison would read.
2.6 LCD Interfacing and IMU Testing
Serial monitors are usually used for debugging purposes. The board sends messages to the PC over a serial connection, which can then be viewed using your preferred software. Arduino has a serial mobitor built in. However, it does get pretty boring and tedious to upload the code, open the Serial Monitor and watch for messages. Sometimes, if you open the serial monitor before the program has been downloaded, it throws an error. It might seem like a very first-world-problem, but trust me, after countless test runs, you realize that a better alternative could have saved you a lot of time. In the interest of solving this problem, as well as adding another trinket to the Genuino, I decided to opt for an LCD to display messages real time in place of the serial monitor.
The Genuino 101 comes with an IMU (Inertial Measurment Unit) on board. The IMU consists of an Accelerometer and a Gyroscope. The provided examples were pretty helpful, along with the library documentation on the Arduino site. With a few modifications in the same code, I managed to display the accelerometer values real time on the LCD display, which always looks way cooler than a serial monitor.
3. Project Preparations
For my intended used case, using the Genuino 101 as a BLE Node, I had to make a few preparations in that regard, mostly on the Central module, ie Intel Edison side. I'll just go over the utilities I used in the Edison.
Usually in a BLE system, the Central Module does most of the computational grunt work, and this is no exception. The Intel Edison is supposed to receive data from the Genuino 101, store the data in a database, periodically retrieve the data, apply linear regression to the data, get a predicted value and send it back to the Genuino.
4. BLE Central Code Flow
The job of the Central BLE module was to acquire and aggregate the data from the BLE Peripheral module, implement a linear regression algorithm on it, predict the future reading, and send it back to the BLE peripheral. To this effect, there are two scripts and one dynamic database running in parallel on the Intel Edison.
5.1 Sensor Value Database
5.2 BLE Central Script
5.3 Regression Script
5. BLE Peripheral Code Flow
Regression algorithms are part of a category of machine learning algorithms called supervised learning algorithms. It means that they need a priori set of labelled data before they can begin making inferences. So I kept the system overnight to collect data before initializing the regression scripts. As seen above, it collected 55 samples, which is an extremely small set to make any accurate assumptions, but reasonable enough to give some insight into the trend of the data. That is exactly what the algorithm did.
Albeit with a significant error, (2.5 is a huge error when the range of the values a smudge under 30), the algorithm successfully identified a falling trend, which was to be expected, as the moisture sensor received its data from a potted plant. The trend was stored as a sequence of numerical data, which, when represented graphically looks like the graph given below. A few outliers cause the graph to deviate significantly, however it can be taken care of either at the data acquisition phase on the peripheral, or cleaning the data when before being implemented in the regression. Bottom left is without outlier correction, bottow right is with it.
All things considered, the Genuino 101 is a great product, considerately designed, with a lot of documentation and user base, which makes it very easy to have any doubts or queries you may have to be resolved. Compatible with almost all the Arduino shields, it also has tremendous scope for expansion. It's USP, the on board BLE module, is a salient feature in more than one way.
I've always looked at the Arduino Uno as a very capable prototyping and development platform, Almost perfect for a proof-of-concept. Almost. There was always this voice at the back of my head which complained about the lack of wireless communication options. Admittedly,you could pop on an RF Transceiver or even a Bluetooth or WiFi shield, but that would consume I/O. The Arduino Yun, which I reviewed a year ago, did have native WiFi support. You could go for TCP/IP and UDP if you were feeling adventurous or try out MQTT, courtesy the on board Open-WRT OS. The problem here was that it was almost overkill. It had a separate processor and controller, which could only communicate serially. This required two separate scripts running on each. This meant that if you were looking to hack together a prototype, the procedure was rather convoluted .
Conversely,the Genuino 101 manages to fulfill the need of a wireless communication option with aplomb, without the need for an OS. The on board BLE module doesn't use up any I/Os, and the set up is clean and intuitive. It stacks up well with other Bluetooth devices, and somehow, in my mind, it fits the role of a BLE peripheral perfectly. The low power Curie processor doesn't claim to serve up any major computational victories, but is content in its role as an end actuator or a sensor node to acquire data and forward it, and maybe signal actuator or two. And as I've said before, it does this job perfectly. Arduino has always been very hardware oriented, and the Genuino 101 continues this tradition gracefully.
My only complaints about the Genuino are that the USB type B connector takes up a lot of real estate on the board, and is neither very common nor aesthetically appealing. Switching to the ubiquitous microUSB or even ditching the power jack in favor of future-proofing the Genuino 101 with a USB type C connector is something I'd like to see. Also, perhaps it is a fault in the unit I received, but it does not seem to power up when supplied over the 5V and GND pins.I'd really have loved to make this into a standalone unit.
Here, I'll end my review, the Genuino 101 has not disappointed me one bit during the review process, and I have a feeling that it's going to continue in the future as well.