RoadTest: ARDUINO NANO 33 BLE SENSE
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?: Software-wise, most of the Arduino environment. I've played around with UBlox products in the past.
What were the biggest problems encountered?: The documentation, references and getting started on the Arduino.cc website for the product is not up to snuff. There's some information to get started, and once you realize most libraries for seperate components are there if you know where to look for they're find-able (but barely informational in several cases), but especially the bluetooth functionality for the device is not described well enough on the site itself. Luckily I found enough information about that in some other source.
'The Arduino Nano 33 BLE Sense' was released on August 2019. A variation on this board the 'Arduino Nano 33 BLE' has also been published. This is essentially the BLE Sense, but with only the inertial sensor. One can tell from the PCB layout that the 33 BLE and the 33 BLE Sense use the same underlying hardware, but for the non-Sense (heh) version, the sensor parts simply haven't been applied, save for the microphone. Over the course of the review I will refer to the product as the Arduino Nano, but not to be confused with the traditional Arduino Nano.
The hardware arrived in a simple box, as I've come to expect from Element 14. The contents simply the all to familiar Arduino carton, the size of a matchbox.
The box contains one Arduino Nano, separate headers, a sticker page and a black isolation mat. I mentioned before in other reviews I'm not a fan of this stuff. In the past I've thrown away IC's and modules after the material in the mat basically tainted the pins of the part attached to it. It puzzled me though why it was added here: The headers are separate from the module and weren't placed in the mat either. I suppose the material is added to apply some physical shock protection.
The separate headers make me wonder if someone at Arduino reads these reviews. The PCB (see hardware review) is designed in such a way that basic headers fit, but the board is also surface mountable on 0.1" spaced islands. Or for example one can wire to the Arduino directly.
At the time of writing, I have not yet decided (leave alone added) the headers included in the package. The fact the Arduino itself has an exceedingly low clearing gives it options as a wearable platform that I do not yet wish to sacrifice.
Addendum: Once I decided what to do for my TinyML attempt, I soldered in the headers. Heads-up though, the holes for the headers in the Arduino are NOT the breadboard spacing! Thankfully I typically insert headers into a breadboard and then put the module on top of that to solder headers on nice and straight. The headers go 'against' the board. If you design your own PCB, you might well space the interface for the Arduino so that the holes can in fact be used....
The Arduino Nano 33 BLE is a drop in replacement for a typical Arduino Nano, provided the original one is the 3.3V signal level version. Since both the original Nano and this version both use the Arduino libraries, porting software shouldn't be a problem.
The silkscreen on the top of the PCB shows the 'ARDUINO.CC' text, some markings next to the USB leds and very little else. Two pins are marked with white squares and some more research points out these are the two GND pads. The bottom of the PCB contains more information about most of the pins. 3 pins are missing a silkscreen marking because it overlaps with soldering pads. D7 and D8 seem disabled by default (but aren't). As is V-USB (5 V output). This pin is connected directly to the USB voltage input. Also, it's possible to power the Nano over something else than the USB input.
Before we can do anything with the Nano, we have to install IDE support for the board. Over the course of the Roadtest I will use Arduino IDE 1.8.13. While not a clean install (I use it regularly, with different boards) I assume that other material will not interfere.
Support for the Nano 33 is found in the board manager under 'Arduino mbed-enabled boards'. At the time of writing this is on version 1.3.2. The support for BLE and BLE sense comes from the same board package.
After installing this board, restarting the IDE and loading a blink sketch, I tweaked the blink intervals (since the board already contains a blinker and I want to recognice mine) and upload the script. Compiling and uploading is no problem and the builtin led then blinks about twice as fast.
My first observation on trying to load the sensors, I noticed that while the board was installed, this apparently didn't automatically also install the libraries for the sensors. Fair enough, the Arduino library manager appears to have readily availble resources for these and I'll mention the downloads for each sensor in the next step.
The sense has a short range of sensors. In this section I aim to go through each of them in short order and write a short test-script for them. I'll probably mostly get these sketches from the Arduino pages, but will deviate / play with them as I see fit. A table with sensor name, type, a reference to my gitlab repository and if applicable a source will also be added.
Temperature and humidity
|Gesture / proximity
Much like any Arduino, this module has a pretty generous amount of I/O pins for a variety of functions. There's 6 Analog pins, 3 digital pins and 2 ground pins. Output for 3.3V and 5V. The arduino can be powered both over USB and the 5V (Vbus) pin, which is connected to the USB input power.
The bottom side of this version of the Arduino Nano 33 BLE has several pads that can be interrupted / soldered over to connect. I have a pretty decent idea what they're for, but am not impressed by the lack of information about them. Half the descriptions I find both on and off the Arduino community barely mention the pads, earlier versions don't appear to have them and the most I figured out is that they're pretty handy if one aims to work in low-power environments.
The good news is that, if you don't really care about the power-draw of the unit, you can ignore them. (I.e. the default configuration is workable.)
Analog input is pretty much exactly that: An input voltage between 0 and 3.3V will result in a read value of between 0 and 4096. One thing of note: The Aref pin on the Arduino is not connected in case of the Nano BLE. Physically it's apparently 'there' for physical compatibility in a circuit, but has no function in analog configuration. By default Vdd (input voltage) is used as a reference and I found no problems with that during my time messing around with it.
Contrary to the Nano 33 BLE, the Nano 33 BLE Sense has a couple of sensors on the board, each of which (safe for the microphone) are connected one of the on-board circuit busses.
The ADPS960 (Gesture / proximity), LSM9DS1 (Inertial) and LPS22HB (barometric) sensors are on the i2c interface. The Temperature and humidity sensor (HTS221) is on SPI and the microphone is on an i2s icrcuit.
Going for a moment systematically through a testrun on each of them, I looked around for some example code and once again was amazed (if not annoyed) that the Arduino community doesn't really have a solid reference to libraries for these components.
Mind you, this does not mean there are none. In fact, I found a different web-blog ( https://gilberttanner.com/blog/arduino-nano-33-ble-sense-overview ) that already did a review of the Nano 33 BLE Sense and had a short example code snippet for each of the sensors. The libraries the snippets used are readily available on the library manager of Arduino IDE.
I ended up taking inspiration from these examples, but build my own code-style around it. The result is visible in my gitlab workspace for this Roadtest:
(See appendix A for more specific test-code implementations for each of the sensors)
One of the key-features of the Nano 33 BLE being bluetooth commuincation, I'd be remiss not to test the feature ofcourse. In its most simple form, BLE is little more than a serial interface over which information is sent and I've put together a simple client / server network to 'prove' it.
Taking inspiration from this blog:
I've coded a simple BLE application:
- Initializaing temperature sensor.
- Initializing BLE connection
- measuring temperature.
- Sending temperature over BLE.
Then on a laptop (using Linux and python3)
- Opening a connection to the temperature service.
- Reading the temperature as it comes in
- Displying it in terminal.
In the process I've learned a lot about the Bluetooth stack, protocol and communication and it took some doing before I had everything stable enough to call it 'working'. (I still wouldn't call the result 'production ready' but it works.)
Code for the Arduino: https://gitlab.com/element14-roadtests/arduino-nano-33-ble-sense/-/tree/master/BLEComm
What initiall drew me to this roadtest, was the indication that the Arduino Nano 33 BLE is the first Arduino that is known to be able to run a TinyML application. TinyML stands for Tiny Machine Learning.
As you might know, the principle of Machine Learning (which I'll shorten to ML for the remainder of the review) is traditionally reserved to environments with a lot of computing power. Powerful PCs or servers, preferrably with hardware accelerators like GPUs are able to do something called 'deep learning' where an algorithm (or series of) builds a neural network capable of making 'decisions' based on uncertain / analog input. Normally when one writes a simple program / script to read input and based on this drive output to switch anything on or off, one does so with a given description of what possible inputs are. These are often either binary or digital (there's a subtle difference, where binary is 2 states, digital is a finite amount of states and analog in comparison is (theoretically) an infinite amount of states between 2 limits. ) and the output is always defined for a given input. Neural networks are useful in environments where sensors give analog signals and a wide variety of other inputs (analog or digital) make things even more complex. Conventional programs might become too complex to maintain. Neural networks however can be trained (with simulated input) and substitute for any conventional program.
While a well-trained neural network can easily replace a conventional program, there are some drawbacks:
The TinyML toolkit aims to fix this:
TinyML is still under active development, but the resources are open-source and developers are actively encouraged to try it.
In the recent past I've seen several projects using this and it got me back into the world of ML. I picked up O'Reilly's TinyML book and started reading. One of the things I love about this book is that, besides the technology and methods to use the toolkit, it also gives some practical applications on how to use it. It has several usecases, even directly referencing the Arduino Nano 33 as a platform and how to build for it.
But this put me in an annoying position: What was I going to do for a TinyML challenge? Material I saw online implemented handwriting recognition, the book ranged several subjects ranging from simple one value inputs to audio and video processing.
I could copy one of those, but that's boring. Instead I opted to do something different.
I've sketched out the following situation: I have 4 capacitors, each of which in paralell a variable resistor. The capacitor can be charged using a FET that, when triggered allows the capacitor to load. The resistor over the capacitor allows me to regulate how fast the capacitor discharges.
The load of the capacitor is read over analog input by the Arduino. The FETS are triggered by Arduino. I would train a neural network that each cycle, it would read all capacitor inputs, decides which capacitor would need charging the most and charge this capacitor for a given interval.
As an extra input layer, I would add 4 switches and these would allow me to exclude the given channel from possible recharging. Mind you: These switches are not going to break the charge circuit, they're going to be input to the neural network as an indication NOT to charge the capacitor for the given circuit....
Since the entire basic testing of the Arduino and this idea for the TinyML implementation is both a hardawre and software undertaking, I decided to make a multistep planning and go at it one step at the time.
2. Add a led output to indicate the state of the capacitor. (low, ok, high)
3. Add a switch bank.
4. Setup machine learning on a laptop
5. Generate training set
6. Generate Neural Network.
7. Run test.
In reality, I must admit I didn't finish up completely as planned. I've tested all seperate features of the Arduino and am confident I can look back at it for a conclusive roadtest review. The TinyML idea failed for several reasons, mostly being my fault. Although 'failed' only in the sense that I didn't actually get it to run a neural network (in the time given / used).
What I mostly got completed is the hardware side and drivers / support libraries for the different components. For this, see https://gitlab.com/element14-roadtests/arduino-nano-33-ble-sense/-/tree/master/unit-testing-hardware
But I painfully messed up in several ways on the hardware side, not in the least trying to use shiftregisters to drive the leds. These were never going to work powering the chips- and with the I/O voltage levels I was providing from the Arduino.
Also, I never really got the FETs to drive any current to the capacitors, although the analog feedback did work (if I charged the capacitor manually, bridging the FET. )
The breadboard setup shows a couple of led-bars in the left-most section, a set of shift-registers in the middle and the capacitor circuits on the right. Below the capacitor circuits there's the Arduino.
To the right of the breadboard, there's the make-shift switchboard for input to control the channels.
Meanwhile I didn't do any work yet for the TinyML setup. I figured that at least for the review, the experience with the hardware and support for the Arduino was more important.
Although at the time of writing the project isn't quite 'complete' as such, I still mean to finish it or at least try again. (both the output and the input must be essentially redesigned / rethought). The idea for my TinyML implementation is reminiscient of, for example stabilization of a drone, or some industrial balancing process and compared to existing implementations of neural nets a novel idea. (Again, I could have just duplicated existing code and projects, but that felt like a cop-out.)
In conclusion to this roadtest: I'd like to again say a Huge 'Thank you!' to Element 14 for sponsoring this initiative! These roadtests not only drive enthousiasts and engineers like me to discover and experiment with new things, but also gives the oppertunity to people that normally don't have access to hardware often sponsored by the RoadTest project.
I'd like to review first specific facets I deem important to this product and then a final conclusion:
I've always like Arduino for what they're doing and mostly how they're doing it. Even if a typical Arduino hardware platform is suboptimal in terms of output, size and shape for more professional setups, this is not what the Arduino community aims for. Hobbyists, students, enthousiasts and other people can play with new controller and processor architectures for (often) an affordable price and proof of concepts with this modules could lead to more professional hardware down the line.
The fact that for the first time an Arduino is finally on a level powerful enough to do neural network execution is exiting. As mentioned, students are among the avid users of Arduino hardware and this allows them to take first steps into a world still in its infancy, but where the industry is actively looking for engineers and developers!
The Nano 33 BLE itself is in almost all regards elegant, stable and worthy of the name Arduino. It's pin-compatible with other Arduino's of the same size. There's things I would have done differently (don't place your silkscreen in a position where you can't see it if you install it!) but that's besides the point.
The Nano 33 BLE is directly supported by the Arduino IDE in the boards manager. As an ARM platform, it takes a moment to download the entire support, but still, it's all there (for the core functionality of the Nano 33 BLE itself). Over the course of my work I have encountered no discernable problems with stability or other issues with hardware drivers. The sensors, that are there on the Sense version, are supported in the library manager under separate downloads. They're easy to find using the component ID's and each description mentions direct compatibility with the Nano 33. Each library I experienced pretty much as plug and play.
The only exception library-wise is the microphone, which is compatible with the PDM support on the Arduino.
This is.... Always a weak-spot for Arduino in my opinion. And once again where they lose points. I experienced little challenge finding the information I was looking for because as an experienced developer I knew what to look for. Especially when I found the other blog reviewing the same Arduino, finding information on how to use the sensors became trivial, it was all there. Thing is: The Arduino.cc website has mentions of the libraries for the components. But there is No link between any product page for the Nano 33 BLE and these sensors. Once I noticed that these libraries were described (briefly, without much detail) on Arduino.cc I leaned on it a bit to get an idea of the function signatures. But that's all. In the end it turned out that what documentation about the BLE functionality there actually was on the Arduino website, was actually incomplete / wrong.
Arduino still has a ways to go here.
I think that the Arduino initiative and community, with all its work, enthousiasm and innovation adds an incalculable value to the maker community. There's scarecly a half-complex project involving sensors and output out there that doesn't contain some sort of controller and Arduino outshines other brands and projects by miles!
I loved working with the Nano 33 BLE Sense very much and will keep working with it until I get that TinyML platform working as well. As mentioned before there's very little about the product that I would change / do not like.
I highly recommend this product, if you seek to learn more, not only about hardware and software and bluetooth communication, but also look for a capable and well supported Machine Learning study platform. (As mentioned the O'Reilly book 'TinyML' mentions and supports this device directly!)
Simple BLE communication code:
PC python script:
Temperature and humidity:
Skeleton statemachine I used in all my projects for this Roadtest:
Unit testing for my more comprehensive hardware setup:
Slightly more simple test specifically for the led-bar:
Arduino getting started:
Page to example code for all sensors and general info on the Nano 33 BLE sense:
Important info on using the BLE feature
If you do not trust me (It is good idea to do not trust random people on internet), you can ensure yourself by checking schematics which are avalaible at https://store.arduino.cc/arduino-nano-33-ble-sense at Documentation tab in PDF.
HTS221 is connected using SCL1 and SDA1 wires (not a MOSI, MISO, SCK and CS):
Microphone is connected using PDMCLK and PDMDIN wires (not a SCK, WS and SD):
"A failure to plan is planning to fail."
Not sure who said it, but somewhere in the past 1 or 2 years it came back to me. And I realized that I did Very bad this period, until I decided to actually put this into practice.
The photographed whiteboard is a result after I decided that it's just better to put my thoughts out of my head instead of keeping them in there (along with all the other scary stuff).
Michal mentioned some flaws in my review. I don't doubt there's others. Also, There's supposed to be way more stuff that allows for way more flaws, that I didn't actually post.
Good road test report.
I like your planning comments, too many people fail to plan out testing to their regret.
HTS221 is not on SPI bus. It is on I2C bus. All sensors (excluding microphone) are on the same I2C bus. There are no sensor connected to SPI.
Microphone is not connected to I2S. It is microphone with PDM output. I2S peripheral is free to use with other microphone/codec/etc....