Table of contents

RoadTest: AVNET Azure Sphere MT3620 Starter Kit

Author: stevesmythe

Creation date: 11 Oct 2019

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?: Seeed Azure Sphere MT3620 Development Kit

What were the biggest problems encountered?: Avoiding racking up daily bills with Microsoft Azure

Detailed Review:

Introduction

Thanks to element14 and AVNET for providing me with the AVNET Azure Sphere MT3620 Starter Kit to review.

After I applied for this RoadTest (but before I was selected), element14 and AVNET launched their Sensing the World Challenge, as a result of which almost everybody seems to have an AVNET Azure Sphere MT3620 Starter Kit (and I now have two)!

Consequently, I think the focus of my RoadTest has to change a little – so I won’t be repeating the instructions for getting started and sending data to the Azure cloud. Anybody who wants to know about that can easily find ample documentation on the element14 site.

My overall aim for this RoadTest is to provide a potential purchaser with a fair and realistic appraisal of the AVNET Azure Sphere MT3620 Starter Kit but also to draw comparisons with another Internet of Things (“IoT”) kit I have RoadTested recently – the Particle Mesh IoT kit.

Generally, my testing and report will be aimed at giving potential buyers of this kit a good understanding of what it can and can't do, and how straightforward it is to use, based on the documentation provided.

What is included in the kit?

Unboxing

The kit consists of the Azure Sphere MT3620 development board and a short USB cable which is used to communicate with the board when setting up and programming and can also provide power.

{gallery} Unboxing
REPLACE THIS TEXT WITH YOUR IMAGE IMAGE TITLE: THEN IMAGE DESCRIPTION

Target market

This is a development board and it is aimed at developers looking to produce a secure IoT application device that can easily be scaled. It costs around £60. Nobody is expecting you to deploy thousands of the development boards.

The idea is that you use one of these boards to develop your prototype, then build your own board using a separate Azure Sphere MT3620 Module (the part edged in red in the picture below) and just the peripherals that you need for your application.

Once you have developed your prototype on the development board and built your own board and associated software, you can deploy your devices into the field very easily, knowing that they will be supported with firmware /security updates (for 13 years from Microsoft).

Key differentiators

• Security. The Azure Sphere uses a very secure model, where the device itself is linked with your Azure credentials and cannot be used with other accounts or platforms. The basis of this security model is the “Pluton Security Subsystem”. To simplify somewhat, this uses an asymmetric key pair which is generated at the factory; the private key is embedded in the device MCU and the public key is stored by Microsoft so that the device can be tied to an Azure AD account later.
• Large scale provisioning. Microsoft Azure IoT Hub Device Provisioning Service (“DPS”) is designed to allow you to deploy hundreds or thousands of devices securely by simply claiming your device to your Microsoft Azure credentials. Once claimed, all of your devices will receive OTA updates. The DPS allows you to choose which IoT hub your devices are connected to, enabling you to deploy different solutions in the field and perform load-balancing.

Specification

Avnet Azure Sphere MT3620 Module

• 1x 500MHz ARM Cortex A7, 4MB SRAM
• 2x 200MHz ARM Cortex M4F cores, 64KB SRAM
• OS: Azure Sphere Operating System for end-to-end security
• ISU interfaces: 3 of 5 available: Pre-configured for UART, SPI, I2C (max interface rates are: UART=3Mbps, SPI=40MHz, I2C=1MHz)
• ADC/GPIO: 3x 12bit ADC inputs (or can be used as GPIOs)
• PWM/GPIO: 9x PWM outputs, or can be used as GPIOs (for a total of up to 24 GPIOs)
• RTC : On-chip, requires VBAT supply
• Wi-Fi: Dual-band 2.4/5GHz 802.11 a/b/g/n
• Antenna: On-board dual-band 2.4/5GHz chip antenna (Pulse W3006)
• Operating Temperature: -30°C ~ 85°C
• Dimensions: 33mm x 22mm x 3.68mm
• Certification: FCC, IC, CE, MIC (pending), RoHS

USB to Serial 4-Port Interface

• Debug, Service, Recovery UARTs
• SWD Interface
• System Reset and Recovery Signals

On-board Sensors

• Ambient Light Sensor: Analog (sampled by 12 bit ADC)
• LSM6DSO: 3-axis Accelerometer, 3-axis Gyro and Temperature sensor
• LPS22HH: Barometric Pressure and Temperature sensor

Hardware Expansion Interfaces (multiple standards supported)

• MikroE Click Board Expansion Sockets (two sockets. I2C,SPI,UART,ADC,etc interfaces)
• UART/BLE connector (2x6 pin R/A connector, compatible with a subset of Pmod boards)
• Grove Expansion Connector (I2C)
• OLED 128x64 Display Interface (I2C), - option not fitted

Push-Button Switches (3)

• Reset, User-A, User-B

User and Status LEDs (7)

• RGB User LED
• APP. User LED
• WLAN User LED
• USB Status LED
• PWR Status LED

5V to 3.3V DC Power Regulation (with over/under voltage protection) and Power Interfaces

• USB 5V DC from Development Computer (or 5V DC adaptor, option not included)
• AUX 5V DC (compact terminal, option not fitted)
• VBAT Battery Backup (compact terminal, option not fitted)
• ADC VREF External Reference Input (2-pin header)

Operating Temperature

• 30°C ~ 85°C

Dimensions

• 75mm x 55mm

Certification

• FCC, IC, CE, MIC (pending), RoHS

The annoted diagram above shows the location of the onboard sensors, LEDs, push switches and connectors as well as the MT3620 module itself.

Here is the block diagram

Getting started

Once you have your device, there are a few things you need to do before you can get started. I followed the Microsoft guide.

• Get yourself a PC with Windows 10 (Anniversary edition or later) and at least one spare USB port
• Plug in your MT3620 and check that Windows 10 has detected it and installed the FTDI drivers to allow communication with the board via the micro USB connection.
• Install Visual Studio (2019)
• Install Azure Sphere SDK Preview for Visual Studio
• Set up Wi-Fi on your Azure Sphere device using the Azure Sphere Developer Command Prompt (installed as part of the SDK)
• Update the OS on the MT3620
• Setup an account on Microsoft Azure Active Directory (this bit has been tricky for some people) and setup an Azure Sphere tenant
• Claim your MT3620 device to your Azure Sphere tenant (i.e. link the device to your account)

Then you can start coding in Visual Studio.

A quick way to get started with coding is to clone an existing project from GitHub. Initially, I worked my way through Brian Willess’ three-part element14 guides plus his Advanced Tutorial (see weblinks below).

Testing - how does it perform?

Documentation

Since the "big give-away", there is now plenty of documentation to refer to when using this kit. The most useful for me were:

• The Microsoft Getting Started Guide
• Brian Willess' tutorials on element14. Avnet's Azure Sphere Starter-Kit (Out of Box Demo) Parts 1 to 3
• Peter Fenn's Advanced Tutorial.This covers the use of A7 and M4 cores (and how they communicate with each other), all on-board sensors, ADC, OLED display, IoT Central dashboards, rules & actions for notifications and more...
• The Hackster Technical Training Course (videos plus "Lab Guides") - also by Brian Willess

Connecting components

The photo below shows the RoadTest board (below) and the Sensing the World Challenge board (above), to which I had I soldered a JST socket on the VBAT connector for a real time clock battery and a 4x1 2.54mm pitch female socket for an OLED display. Notice also that the RoadTest board must have been made before obtaining any certifications.

The two MikroBUS sockets are for using MikroElektronika Click boards, of which there are several hundred. There were no Click boards provided with the RoadTest and I didn't already have any, so I was unable to test this feature. Although there isn't a nice row of GPIO sockets like on an Arduino or Raspberry Pi, you can use the (empty) MikroBUS sockets to connect to the GPIO/I2C/SPI ports that you need by using jumper wires. You can also access the I2C bus via the built-in Grove socket. Note that this socket will only work with Grove components that communicate via I2C (so no Grove analogue sensors or Grove LEDs). You can access UART via the Pmod connections in the middle of the MikroBUS 2 sockets.

I already had a cheap OLED display with the right pinout to connect to the MT3260's OLED connections. The picture below shows the onboard accelerometer readings displayed on the OLED.

Coding options

There is only one coding option - because the Azure Sphere SDK is written in C, you have to code your applications in C. Because the SDK only integrates with Microsoft Visual Studio 2017 or 2019, you have to use one of those as your IDE. Visual Studio is a very powerful and well-written IDE but it does take up a lot of disk space and is one more thing to learn if you come from, say, an Eclipse/MCUXpresso background.

Device to cloud connectivity - integrations

Not surprisingly, the Azure Sphere device is designed to integrate with the Microsoft Azure platform. If either Amazon Web Service or Google Cloud is your preferred public cloud platform, hard luck! The two basic connectivity options within Azure are the Azure IoT Hub or the Azure IoT Central SaaS application (but not both at the same time). The IoT Central application allows further integration using webhooks (so you can create automations using IFTTT etc). I tested all of these options (see below).

Example projects

In the photo below, I have used "device twins" to toggle the Blue LED on.

Having set up your IoT Hub, you can display measurements using Azure Time Series Insights

Moving on to IoT Central, you get a nice dashboard that is easily configurable. The screenshot below shows the "Measurements" tab displaying gyrometer data over the previous 10 minutes during which I had swung the board around several times.

Here is the board sending the data over wifi and the laptop receiving the data via wifi from IoT Central.

You can control onboard components like the LEDs using the "Properties" tab.

Since I have two Azure Sphere development kits, I thought I'd try streaming data from both of them and viewing the output together in IoT Central. You can split the measurements by "Device ID" and compare the two, one above the other. Notice that, wih IoT Central you can easily pick which data to display by clicking on the relevant sensor in the middle panel "Measurements". In the chart below I covered up the light sensor on one board (see the dip in the upper yellow trace). I then put the other board on the window sill in the sun (see the light level (yellow) and temperature (blue) rise on the lower traces).

Next, I used IoT Central "Rules" with a Webhook action and IFTTT to use the Azure Sphere board to trigger my Philips Hue lights when the room lighting falls below 30lux averaged over the previous 5 minutes.

The video below shows the webhook action working when I press button A on the Azure Sphere board (to save you having to watch a 5-minute video!). There's a bit of latency (a couple of seconds), but it's not too bad.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

AVNET Azure Sphere MT3620 Starter Kit - Review

Poster

Upload Preview

Ok

Cancel

Issues

• Occasionally, the sensors don’t initiate properly but powering down/up again seems to fix it.

Remote debugging from host 192.168.35.1

Version String: Avnet-Starter-Kit-reference-V1.0

Avnet Starter Kit Simple Reference Application starting.

OLED found!

LSM6DSO not found!

Closing file descriptors.

Application exiting.

Child exited with status 0

• Initially I couldn’t get the light intensity rule in IoT Central to trigger until I worked out that you have to average the light intensity over a period (this makes sense anyway).
• The main difference between the element14 tutorials and the Hackster training course is that the Hackster course demonstrates the Azure Device Provisioning Service (“DPS”), which is the method you would use to deploy many devices into the field at the same time. The usefulness of this process was slightly diminished by the fact that Visual Studio 2019 doesn’t quite support Azure DPS yet and some of the slick parts had to be hand-coded. Also, because I had already claimed the devices, they were effectively already provisioned and I didn’t have any unclaimed devices to test the process with.
• One other problem with the Hackster course it that I had to use an S1 tier instead of the Free tier I had already created to follow Lab 3 because the free tier IoT hub doesn’t support “device twins”. What was especially annoying was that you can’t just change the pricing tier of a free tier to an S1 tier – it’s not allowed. So, I had to delete the IoT hub I had just created, then create a new one on the S1 tier and link it back in with the DPS and device. Although this was a bit of a pain, Azure made it easier than I thought because the device details and certificates were already stored in the DPS and didn’t need to be re-added. It was just a case of re-linking the device to the new IoT hub.
• I had to give up halfway through Lab 5 (an alternative way to authenticate into IoT Central) because the tool that was supposed to help didn't work and left me with nowhere else to go.

Conclusions

• Getting started with this board involves a lot of steps. Without the element14 guides by Brian Willess, I think it would have been very difficult to do anything much.
• Once you get over the initial learning "hump", it's great fun with lots of possibilities for IoT projects.
• If you want to use this device, you need to use Windows 10, Visual Studio and C. If any of those prerequisites puts you off, this device is not for you.
• The Mikroelektronika Click sockets encourage you to use Click boards but, although there are hundreds to choose from, they are a bit pricey and although they publish C drivers on their GitHub site, you will still need to port them to the MT3620.
• The Grove connector is welcome, but it only gives access to the I2C bus, so you can’t use Grove analogue sensors.
• Using this board “online” means you will have to be very careful to avoid racking up regular bills with Microsoft for their cloud services. Some are more expensive than others. If you use the MT3620 with a “free” account, there are limitations as to what you can do.
• If you deploy this board, nobody else will be able to use it, so if someone steals it (or you give it away or sell it), it won’t work with anybody else’s Microsoft Azure credentials. That could be a good thing, or a bad thing depending on your point of view.
• I think that, if you are a hobbyist, the Particle Mesh kit is much easier to use and, "out of the box" it supports far more devices. You can lend it to a friend (or sell it). You can attach a device to one of the Mesh boards and have it up and running in five minutes, whereas it's a much more complicated process with the Azure Sphere board. The Azure Sphere approach has a lot going for it, but you would need to build your own boards to keep the costs down.
• The MT3620 uses around four times the power of the Particle Mesh Xenon board. This is a consequence of using WiFi as opposed to Thread mesh.
• Overall, I think it's a great kit if you are in the target market of people who want an extremely secure IoT device that can be deployed on a widescale basis.