RoadTest: AVNET Azure Sphere MT3620 Starter Kit
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
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.
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.
REPLACE THIS TEXT WITH YOUR IMAGE
IMAGE TITLE: THEN IMAGE DESCRIPTION
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).
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
Once you have your device, there are a few things you need to do before you can get started. I followed the Microsoft guide.
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).
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 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.
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.
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).
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.
Remote debugging from host 192.168.35.1
Version String: Avnet-Starter-Kit-reference-V1.0
Avnet Starter Kit Simple Reference Application starting.
LSM6DSO not found!
Closing file descriptors.
Child exited with status 0
Yes, perhaps I should have explained more about that power supply. The Azure Sphere is connected via an Adafruit PowerBoost 500 charger to a 2000mAh LiPo. I added an off-on switch to the PowerBoost…
Nice road test review stevesmythe I think we are lucky to get the Particle road test first followed by this.
Thanks! Yes, we are indeed lucky. We are spoilt for choice now when it comes to IoT devices.
Yes, perhaps I should have explained more about that power supply. The Azure Sphere is connected via an Adafruit PowerBoost 500 charger to a 2000mAh LiPo. I added an off-on switch to the PowerBoost, which I find convenient. You certainly can charge the battery while the Azure Sphere is connected; indeed, if you have a bit of a ropey mains supply, it would act as a sort of mini-UPS. I found the setup very useful for testing the Azure Sphere away from my laptop. Although it is quite a large capacity LiPo, it didn't last that long but I was blasting out data continuously. I think it lasted about 8 hours. In contrast, the Particle Xenon board that I RoadTested recently lasted over 30 hours from a 1000mAh LiPo. That's (partly) the difference between using WiFi and Thread mesh. Maybe I should update my Roadtest to mention that.
The IoT hub doesn't seem to cost anything but, on its own, it doesn't do anything either. Think of it as a gateway to other Azure services like Time Series Insights, or Blob Storage or Machine Learning (all of which cost money).
[Postscript - I have now added the power consumption point to my review]