Introduction to the Nano 33 IoT

The Arduino Nano 33 IoT is a useful little microcontroller board. It can do the things that the Arduino Uno can, and it has a number of additional features for physical computing projects. In 2019, we started using it as the standard for Intro to Physical Computing. This page introduces some of the functions that this board supports.

Form Factor

The Nano 33 IoT is based on the original Arduino Nano pin layout, so if you’ve used the Nano in past projects, the layout is the same. It’s a dual-inline package (DIP) format, meaning it’s got two rows of pins spaced 0.1 inches apart, so it fits nicely on a solderless breadboard. You can get it with or without header pins, and it’s small enough that you can incorporate it in handheld projects as well.

The physical pin numbering for DIP devices goes in a U shape. Holding the micro USB connector at the top, the numbering starts with physical pin 1 on the upper left, counting down the left side to pin 14 on the lower left, then counting from pin 15 on the lower right, to pin 28 on the upper right. For the most part, the left side of the board is power and analog inputs, and the right side is digital I/O pins.

In brief, the Nano pins are as follows, counting from physical pin 1 (upper left) to pin 15 (lower left) across to pin 16 (lower right) to pin 30 (upper right):

  • Pin 1: Digital I/O 13
  • Pin 2: 3.3V output
  • Pin 3: Analog Reference
  • Pin 4-11: Analog in A0-A7; Digital I/O 14-21
    Pin 12: VUSB (not normally connected)
  • Pin 13: Reset
  • Pin 14: Ground
  • Pin 15:Vin
  • Pin 16: Digital I/O pin 1; Serial1 UART TX
  • Pin 17: Digital I/O pin 0; Serial1 UART RX
  • Pin 18: Reset
  • Pin 19: Ground
  • Pin 20-30: Digital I/O pins 2-12
Arduino Nano 33 IoT board with USB connector facing the top
Figure 1. Drawing of the Nano 33 IoT

The microcontroller pin functions page details the functions of each pin for the Nano and other Arduino boards. The full specifications of the Nano 33 IoT and an official pin diagram can be found on its Getting Started page.

Typical Breadboard Layout

Arduino Nano on a breadboard.
Figure 2. Breadboard view of an Arduino Nano connected to a breadboard.

In a typical breadboard layout, The +3.3 volts and ground pins of the Nano are connected by red and black wires, respectively, to the left side rows of the breadboard. +3.3 volts is connected to the left outer side row (the voltage bus) and ground is connected to the left inner side row (the ground bus). The side rows on the left are connected to the side rows on the right using red and black wires, respectively, creating a voltage bus and a ground bus on both sides of the board.Other board layouts can be found on the Breadboard Layouts page.

Handling the Board

You should be careful when handling the Nano 33 IoT as there are two delicate parts on it: the MicroUSB connector at the top, and the WiFi/Bluetooth antenna at the bottom.  Figure 2 shows a picture of the board.

Like many microcontrollers these days, the Nano 33 IoT uses a MicroUSB connector. This is a delicate connector, and you shouldn’t handle the board by the connector. If you are mounting the board in a project box or as a wearable and you are using the USB connection, make sure the cable and the board are mounted so that they won’t move relative to each other.

The WiFi/Bluetooth Antenna is the small rectangular part at the bottom center. If it is broken off, your WiFi and Bluetooth range will be significantly reduced. For more on caring for it, see the Care of your Nano 33 IoT video and Breadboard Basics.

Photo of an Arduino Nano 33 IoT module. The USB connector is at the top of the image, and the physical pins are numbered in a U-shape from top left to bottom left, then from bottom right to top right.
Figure 2. Arduino Nano 33 IoT

Power

The Nano 33’s first difference from the Uno is that it operates on 3.3 volts instead of 5 volts. This might be an issue for some older sensors or actuators, but most modern ones will operate on 3.3V. For most projects, you’ll supply 3.3V from the Nano’s +3V3 pin (physical pin 2) and ground from one of the ground pins (physical pins 13 or 18).

If you’re powering the Nano 33 IoT from USB, then the Vin pin (physical pin 14) will supply 5V from the USB connection. You can also supply power the Nano 33 IoT on this pin, up to 21V. If power is fed through this pin, the USB power source is disconnected. If you need 5V power when you’re powered via the Vin pin, you can solder the VUSB jumper on the back, behind pin 19. When you do this, then the VUSB pin will supply 5V whenever the board is powered via the Vin pin.

Processor

The Nano 33 IoT has an ARM Cortex-M0 32-bit SAMD21 processor. It’s considerably faster than the Uno’s processor (48MHz clock speed compared to the Uno’s 16MHz, and a 32-bit processor compared to the Uno’s 8-bit processor) and has more memory (32KB SRAM/256KB flash compared to the Uno’s 2KB/32KB). That makes for more programming space at a faster speed.

Uploading to the Nano 33 IoT

If you’ve used an Uno before, and are migrating to the Nano board, you may notice that the serial connection behaves differently. When you reset the MKR, Nano, or Leonardo boards,  or upload code to them, the serial port seems to disappear and re-appear. Here’s why:

There is a difference between the Uno and most of the newer boards like the MKR boards, the Nano 33 IoT and BLE, the Leonardo: the Uno has a USB-to-serial chip on the board which is separate from the microcontroller that you’re programming. The Uno’s processor, an ATMega328, cannot communicate natively via USB, so it needs the separate processor. That USB-to-serial chip is not reset when you upload a new sketch, so the port appears to be there all the time, even when your Uno is being reset.

The newer boards can communicate natively using USB. They don’t need a separate USB-to-serial chip. Because of this, they can be programmed to operate as a mouse, as a keyboard, or as a USB MIDI device.  Since they are USB-native, their USB connection gets reset when you upload new code or reset the processor. That’s normal behavior for them; it’s as if you turned off the device, then turned it back on. Once it’s reset, it will let your computer’s operating system know that it’s ready for action, and your serial port will reappear. This takes a few seconds. It means you can’t reset the board and then open the serial port in the next second. You have to wait those few seconds until the Arduino board has made itself visible to the computer’s operating system again.

If you’re doing MIDI or keyboard or mouse, the serial port number will also change when you add those functions. You’ll still be able to send and receive serial data as usual, but you’ll have to re-choose the port in the Boards -> Port submenu after you program your Nano to be a MIDI or HID device.

If you have trouble getting the Nano 33 IoT to appear in the Arduino IDE, double-tap the reset button at the top center of the board. This will put the board into bootloader mode, meaning that it will show up as a serial device, but not start running the sketch yet. This mode also makes it easier to recover your board if you write a sketch you can’t control, such as a runaway mouse sketch.

Input and Output (GPIO) Pins

The Nano 33 IoT’s got 14 digital I/O pins and 8 analog input pins. The analog in pins can also be used for digital in and out, for a total of 22 digital I/O pins. Of those, 11 can be used for PWM out (pseudo-analog out): digital pins 2, 3, 5, 6, 9, 10, 11, 12, A2, A3, and A5. One pin A0, can also be used as a true analog out, because it has a digital-to-analog converter (DAC) attached (here’s an example of how to use it). There are also more hardware interrupt pins than the Uno; pins 2, 3, 9, 10, 11, 13, A1, A5, and A7 can be used as hardware interrupts. Hardware interrupts make it possible to read very fast changes in digital input and output. For example, rotary encoders work best when attached to interrupt pins.

Serial and USB

The Nano 33 IoT is USB-native. That means it can operate as a few different USB devices: asynchronous serial, keyboard or mouse (also known as Human Interface Device, or HID), and USB MIDI. This is different than the Uno, which has a dedicated USB-to-serial chip on the board, but can only operate as a USB serial device.

There’s also a second asynchronous serial port on pins 0 and 1 that you can use for connecting to other serial devices while still connecting to your personal compuuter. The serial port on pins 0 and 1 is called Serial1, so you’d type Serial1.begin(9600) to initialize it, for example.

Synchronous Serial

Like the other Arduinos, the Nano 33 IoT can communicate via Synchronous serial communications using I2C or SPI. The SPI pins are:

  • SDI- 12
  • SDO – 11
  • SCK – 13
  • CS – 10

The I2C pins are:

  • SDA – A4
  • SCL – A5

Inertial Measurement Unit (IMU)

There is an Inertial Measurement Unit (IMU) on the board, combining a 3-axis accelerometer with a 3-axis gyrometer. This enables gesture-based sensing or tap sensing with no extra hardware. The Arduino_LSM6DS3 library supports this sensor. There are some notes at this link and a lab at this link introducing the IMU.

Real-Time Clock

The Nano 33 IoT also has a real-time clock module built into the processor, which is accessible using the RTCZero library. With this, you can keep track of hours, minutes and seconds much easier. As long as the board is powered, the realtime clock will keep time. Like all libraries, it comes with examples when you install it. You can find several additional examples in this gitHub repository.

WiFi and Bluetooth

WiFi and Bluetooth connectivity are available on the Nano 33 IoT via a low-power 2.4GHz radio. Secure communication is ensured through an on-board crypto chip as well. The WiFiNINA library supports the WiFi on this board, and it’s compatible with the WiFi101 library written for the MKR1000. Any examples written for WiFi101 should be able to run just by changing WiFi101.h to WiFiNINA.h. You can find additional WiFi examples at these links:

The ArduinoBLE library supports Bluetooth LE on this board, and with it you can run the board as a BLE peripheral or a central. Here’s an introduction to connecting ArduinoBLE and p5.ble. Here’s a pair of sketches that let you connect two Nano 33 IoTs to each other as a central and peripheral pair.

Scheduler

The Nano 33 IoT can run multiple loops at once, using the Scheduler library. When you’ve got an application that needs two or more independent loop functions, this can be a quick way to do it.

For more on using the Nano 33 IoT, see the various microcontroller Labs on this site, for example:

A few slightly more advanced examples:

Lab: Bluetooth LE and p5.ble

This exercise introduces you to how to communicate between a Bluetooth LE-equipped microcontroller and p5.js using the p5.ble library.

Introduction

Bluetooth has been a popular method for wireless communication between devices for many years now. It’s a good way to communicate between two devices directly over a distance of 10 meters or less. Version 4.0 of the Bluetooth specification, also known as Bluetooth LE, introduced some changes to Bluetooth, and made it more power-efficient. There are many Bluetooth LE-equipped microcontroller modules on the market, and they all follow the same general patterns of communication. This exercise introduces you to how to communicate between a Bluetooth LE-equipped microcontroller and p5.js using the p5.ble library.

What You’ll Need to Know

To get the most out of this tutorial, you should know what a microcontroller is and how to program them. You should also understand asynchronous serial communication between microcontrollers and personal computers. You should also understand the basics of P5.js. For greater background on Bluetooth LE, see the BLEDocs repository, or the book Make: Bluetooth by Alasdair Allan, Don Coleman, and Sandeep Mistry.

Here are a few additional usedul Bluetooth LE references:

Things You’ll Need

In order to use the ArduinoBLE library, as shown in Figure 1-2, both Arduino  MKR 1010 and the Arduino Nano 33 IoT boards, among others, work for this tutorial. You could also do this on the Nano 33 BLE.

You might need external components for your own Bluetooth LE project, but for this introduction, you won’t need any external components.

Photo of an Arduino Nano 33 IoT module. The USB connector is at the top of the image, and the physical pins are numbered in a U-shape from top left to bottom left, then from bottom right to top right.
Figure 1. Arduino Nano 33 IoT or Nano 33 BLE or…
Photo of an Arduino MKR 1010 module. The USB connector is at the top of the image, and the physical pins are numbered in a U-shape from top left to bottom left, then from bottom right to top right.
Figure 2. Arduino MKR 1010 module.

Bluetooth LE Concepts

Bluetooth LE devices can be either central devices, or peripherals. Peripheral devices offer Bluetooth services that central devices can receive. For example, your fitness device is a peripheral device and the mobile phone or laptop that connects to it is a central device.

Peripherals offer services, which consist of characteristics. For example, a light controller might offer a light service, with four characteristics: red, green, blue, and white channels. Characteristics have values, and central devices can connect to a peripheral and read, write, or subscribe to those changing values. Characteristics can be assigned any of these three capabilities.

Bluetooth LE devices, services, and characteristics are described using Universally Unique Identifiers, or UUIDs. UUIDs are 128-bit numbers, and are generally formatted like this: cc3e5f6f-9d50-43fb-86e3-1f69e3916064. You can generate UUIDs using uuidgenerator.net. You can also do it on a MacOS or Posix command line by typing uuidgen.

There are certain short UUIDs defined by the Bluetooth LE specification for well-known services and characteristics, such as battery level, Human Interface Device, and so forth. A list of the more well-known UUIDs can be found on the Bluetooth SIG Assigned Numbers page. When you’re making your own services and characteristics, you should generate long UUIDs.

All good Bluetooth LE libraries follow the device, service, characteristic model.  The general process from the peripheral side is as follows:

  • Set peripheral name
  • Establish advertised services
  • Add characteristics to services
  • Start advertising

From the central side, the process is:

  • Scan for peripherals
  • Connect to a given peripheral
  • Query for services
  • Query for characteristics
  • Read, write, or subscribe to characteristics

Bluetooth LE Central Apps

There are a number of good Bluetooth LE Central apps that let you scan for peripherals and interact with their services and characteristics. When you’re developing Bluetooth LE applications, it’s essential to have one on hand. Here are several:

Figure 3 below shows the initial scan for peripherals using BlueSee on macOS. You can see a variety of devices listed by UUID in the first column (note: this is not your service UUID, it’s an ID that MacOS assigns to the BLE device); the received signal strength (RSSI) in the second column; peripheral’s local name in the third column; and manufacturer name and info in the remaining columns. Most central scanning apps will list at least the device UUID and name, and let you connect to one device at a time.

Screenshot of the BlueSee app on MacOS scanning for peripherals.
Figure 3. BlueSee app scanning for peripherals.

Figure 4 shows the characteristic detail from BlueSee when it’s connected to a particular peripheral’s characteristic. In most apps, like in this one, if a characteristic is writable, you can write to it in either hexadecimal or text.

Screenshot of the BlueSee app's Characteristic detail screen.
Figure 4. BlueSee Characteristic detail screen.

Program the Arduino

Make sure you’re using the Arduino IDE version 1.8.10 or later. If you’ve never used the type of Arduino module that you’re using here (for example, a Nano 33 IoT), you may need to install the board definitions. Go to the Tools Menu –> Board –> Board Manager. A new window will pop up. Search for your board’s name (for example, Nano 33 IoT), and the Boards manager will filter for the correct board. Click install and it will install the board definition.

You’ll need to install the ArduinoBLE library too. Go to the Sketch menu –> Include Library… –> Manage Libraries. A new window will pop up. Search for your the name of the library (ArduinoBLE) and click the Install button. The Library manager will install the library.

Once you’ve installed the library, look in the File –> Examples submenu for the ArduinoBLE submenu. In there, look for the Peripherals submenu and open the sketch labeled LED. This sketch turns your board into a peripheral with one service called LED. That service has one characteristic, called switchCharacteristic, that is readable and writable by connected central devices. When you write the value 1 to this characteristic, the on-board LED turns on. When you write 0 to the characteristic, the LED turns off.

The beginning of the sketch establishes the service and characteristic as global variables:

1
2
3
4
5
6
7
8
#include "ArduinoBLE.h"
 
BLEService ledService("19B10000-E8F2-537E-4F6C-D104768A1214"); // BLE LED Service
 
// BLE LED Switch Characteristic - custom 128-bit UUID, read and writable by central
BLEByteCharacteristic switchCharacteristic("19B10001-E8F2-537E-4F6C-D104768A1214", BLERead | BLEWrite);
 
const int ledPin = LED_BUILTIN; // pin to use for the LED

In the setup(), you’ll follow the steps outlined above: set the name and the services, add characteristics, and advertise:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
void setup() {
  // initialize serial and wait for serial monitor to be opened:
  Serial.begin(9600);
  while (!Serial);
 
  // set LED pin to output mode:
  pinMode(ledPin, OUTPUT);
 
  // begin initialization:
  if (!BLE.begin()) {
    Serial.println("starting BLE failed!");
    while (true);
  }
 
  // set advertised local name and service UUID:
  BLE.setLocalName("LED");
  BLE.setAdvertisedService(ledService);
 
  // add the characteristic to the service
  ledService.addCharacteristic(switchCharacteristic);
 
  // add service:
  BLE.addService(ledService);
 
  // set the initial value for the characteristic:
  switchCharacteristic.writeValue(0);
 
  // start advertising
  BLE.advertise();
 
  Serial.println("BLE LED Peripheral");
}

In the loop(), you wait for a central device to connect, and only take action if it does:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
void loop() {
  // listen for BLE peripherals to connect:
  BLEDevice central = BLE.central();
 
  // if a central is connected:
  if (central) {
    Serial.print("Connected to central: ");
    // print the central's MAC address:
    Serial.println(central.address());
 
    // while the central is still connected to peripheral:
    while (central.connected()) {
      // if the central device wrote to the characteristic,
      // use the value to control the LED:
      if (switchCharacteristic.written()) {
        if (switchCharacteristic.value()) {   // any value other than 0
          Serial.println("LED on");
          digitalWrite(ledPin, HIGH);         // will turn the LED on
        } else {                              // a 0 value
          Serial.println("LED off");
          digitalWrite(ledPin, LOW);          // will turn the LED off
        }
      }
    }
 
    // when the central disconnects, print it out:
    Serial.print("Disconnected from central: ");
    Serial.println(central.address());
  }
}

Upload this to your board, then scan for it with a BLE central scanner like BlueSee or LightBlue. When you find it, connect and try to open the characteristic. Then try writing 1 and 0 to it. You should see the LED going on and off.

The general pattern of this sketch is similar for other Bluetooth LE sketches with this library; check out the other examples and you’ll see. Generally, you wait for a central to connect, then all action takes place after that. If the central is driving the action, then your Arduino sketch waits for characteristics to be written to. If your central app is waiting for action from the Arduino, then you’ll write to characteristics in your Arduino sketch, and the central app will see those changes and take action.

A Central App in p5.ble

The Chrome browser has a web bluetooth extension that enables web pages in Chrome to act as Bluetooth LE central devices. The p5.ble library is based on web-bluetooth, and compatible with p5.js. To get started quickly, disconnect your central app from your board if you’re still connected from the section above, and go to the p5.ble write one characteristic example. Click the connect button in that example, and you’ll get a popup scanner. When you see the LED peripheral, connect to it. Once you’re connected, try writing 0 or 1 to the LED. You should be able to control the LED.  The source code for this example is embedded in the example page. You can borrow from it to write your own custom BLE central p5.js sketch. You’ll need to include the p5.ble library in your index.html page as shown on the quickstart page.

In the write one characteristic sketch, you can see the pattern of activity for a central device described above:

Scan for peripherals is handled when you click the Connect button. The scan is filtered to look only for devices with the desired service UUID.

Connect to a given peripheral is handled by the connectToBle function. It connects to a device and the desired service, then runs the gotCharacteristics function as a callback to query for characteristics.

When you click the write button, the writeToBLE function writes to the characteristic to which it’s connected.

Reading and Writing Sensors in p5.ble

The Read From One Characteristic example shows how to read from a peripheral device that’s outputting a changing sensor value. Similarly, the Start and Stop Notifications example shows how to subscribe to a peripheral’s characteristic so as to get notification when it changes. Try these out along with their associated Arduino sketches to get an understanding of how to get sensor data via Bluetooth LE.

You can set up multiple characteristics in a given service, and often this is the best way to handle things. For example, if you were using the built-in accelerometer on the Nano 33 IoT, you might have three characteristics for x, y, and z acceleration all in a single accelerometer service.

Characteristic Data Types

When you initialize your peripheral’s characteristics in your Arduino sketch, you set the data type for the characteristic. Just as there are byte, bool, int, char, String and float data types, there are BLEByteCharacteristic, BLEBoolCharacteristic, BLEIntCharacteristic, BLECharCharacteristic, BLEStringCharacteristic, and BLEFloatCharacteristic data types in the ArduinoBLE library. You should pick the type appropriate for what you’re using it to do. An analog sensor might want an int, for example. A sensor value that you’ve converted to a floating point value like voltage or acceleration might want a float.

Similarly, you can read the characteristics in p5.ble differently when you know what type they might be.  You’ve got  unit8, uint16 or uint32, int8, int16, int32, float32, float64, and string. When you read, you choose the type like so:

1
myBLE.read(myCharacteristic, 'string', gotValue);

You need to match the type you read with on the central side to the type you sent with on the peripheral side. If you’re not sure what type is correct, set up your Arduino sketch to send a constant value using a type you know. Then read  it in p5.ble using the different types until the value you receive matches the value you’re sending. Make sure to test the limits of your data type. For example, in Arduino, an int can store a 16-bit value from -32,768 to 32,767 on an Uno, or a 32-bit value on a Nano 33 IoT or MKR board, from -2,147,483,648 to 2,147,483,647. A 16-bit int would be int16 in p5.ble, and a 32-bit int would be an int32. If you’re using unsigned ints on the Arduino side, then your ranges are different. A 16-bit unsigned int ranges from 0 to 65,535, and a 32-bit unsigned int goes from 0 to 4,294,967,295.

Further Reading

The ArduinoBLE reference is useful if you want to know all the commands that the library can offer. Likewise, the p5.ble reference is a valuable read as well.

The ArduinoBLE library supports both peripheral and central modes on the Nano33’s and the MKR1010. Here’s a pair of sketches that shows how to connect from a central to a peripheral.

Components at the ER

A list of components available for checkout from the ITP equipment room. Unlike the components in the shop, these are not expendable, and should be returned. But if you wanthttps://itp.nyu.edu/physcomp/itp/checkout-components-at-itp/ to get a feel for how they’ll work in your project before you buy one of your own, then check them out from the equipment room.

Pcomp Accessories in Equipment Room

Name Quantity
Arduino 101 62
Micro 1
Uno 6
MKR1000 18
MKRZERO 14
ZERO 15
Starter Kit 2
Raspberry Pi 3
Raspberry Pi Camera 1
Feather Huzzah ESP8266 28
Feather Basic Proto 47
Flora 5
XBee Radio Module 15
USB Adapter 26
Breakout Board 5
9 V battery holder 3
5.25V 2.4A Power Supply 4
DC adaper jack 2
RF ID Reader specifications 2
IR sensor datasheet 1
Bluefruit EZlink vendor page 1
Little Bits Arduino vendor page 4
Accelerometer vendor page
datasheet
16
Range Finder datasheet
tutorial
1
FSR (Large) Sensor 2
FSR (Small) Sensor 33
Flex Sensor
tutorial
24
Ultrasonic Sensor 2
Stretch Sensor 1
Door Sensor vendor page 0
Sensor Tag wiki 22
Ethernet Shield 2
Proto Shield 1
Beagle Board 1
Bone 2
Polar Heart Reference
Datasheet
 1
AVR(?) 2
Heatit 2
DSO Nano 6
Super Bright LED Yellow 16
Blue 9
Red 20
Neopixel datasheet 34+
Stepper Motor Servo 0
6 wire Stepper (general guide) 8
Power tail  4
Wire Switch very similar to this in principle 9
Micro 10
Vernier Temperature Probe vendor page
datasheet
Solar Panel Grade B 1
Joystick  2 Axis 1
Ble nano 1
Ble nano kit 19
RFduino w/ adapter 6
w/o adapter 3
Bluetooth modules 0