Microchip AVR-IoT Cellular Mini Dev Board for LTE-M and NB-IOT with Prepaid SIM

Table of contents

RoadTest: Microchip AVR-IoT Cellular Mini Dev Board for LTE-M and NB-IOT Prepaid SIM

Author: ischonfeld

Creation date: 27 Nov 2022

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?: Particle Boron LTE, Arduino NB MKR1500

What were the biggest problems encountered?: Documentation has basically been pretty accurate (although missing some technical details) and the board performed well. The only significant problem I encountered was in issuing REST POST requests and how to format the function calls under the Arduino IDE

Detailed Review:

Introduction

I have been working with Arduino and similar boards for several years. Most of the projects I've worked on are Wifi based, but recently I built a project where Wifi was not available and required cellular connectivity. Particle.io's Boron LTE board served the purpose and worked. When I saw the Roadtest for Microchip’s AVR-IoT Cellular board, I saw it as an opportunity to evaluate another board that might substitute or replace the Boron LTE. In particular, I also wanted to see how well this board was supported by the Arduino IDE.

Quick Summary

If you're looking for a board with cellular connectivity, this is a good board to consider. Documentation is basically accurate although spread out over several sources. I have yet to find some technical details, such as pinout current limits.  

I typically work in the Arduino IDE environment, and this board integrates well into the IDE including core and support libraries. The board also has interfaces for AWS, however I did not evaluate those capabilities. The board also follows the Feather physical layout including Liion battery and QWIIC connectors. The board also comes with 90 days/150 MB of Truphone cellular coverage to use while developing your project.

I want to be fair and accurate, so if I’ve missed or misrepresented something, please let me know. I'm not going to repeat a whole list of specs that you can find elsewhere, but rather I'm concentrating on my experience with this board. 

Unboxing and initial physical setup

The Microchip box contains 4 static protection pouches comprising the AVR-IoT board, a SIM card good for 150MB of free data to test with, the antenna, and a set of Feather pins. SIM card installation was simple. Connecting the antenna caused the usual apprehension that goes with this kind of connector - they're too easy to damage if you're not careful, get things lined up correctly and press down evenly - nothing unique to the Microchip board but always exciting.

The pin spacing was kind of unusual - they are staggered slightly rather than all being directly in a line. Pressing them in prior to soldering took some force and the pins stayed in place prior to soldering. Perhaps this is the reason for the staggered layout. Once soldered in place the staggered layout was still somewhat visible, but did not hinder insertion into a breadboard. 

Starting with the device

Setting up the Truphone account was straightforward. You select the SIM and need to click ACTIVATE on the second screen even if you clicked it on the prior screen.

I then figured I’d run through the demo to get a feel for the board. Once powered up, I found the CURIOSITY drive. You can copy a file to run to the drive and the firmware will load and run it. I downloaded the latest version of Sandbox.hex and copied to the drive. Had to click CLICK-ME since autorun didn’t auto run.  Went through the steps (repeat of above). Blue light flashed for a few minutes, then solid, then CONN light. DATA light flashed when trying USER LED & ERROR LED. Interesting note: you can interact with the board from any computer, not just what it’s plugged into. So it was now time to get to work with the board in my intended application.

Setting up the Development Environment

Setting up the Arduino environment for this board was also straightforward, although there is one area with conflicting information. I added the core information in the Preferences section - http://drazzy.com/package_drazzy.com_index.json The instructions refer you to GITHUB, which tell you to install megaTinyCore by Spence Konde.  This is the conflicting part – you should ignore the GITHUB instructions and instead just install DxCore by Spence Konde. Once you have this, the settings are Board -> DxCore -> AVR DB-series (no bootloader), Chip -> AVR128DB48, Wire Library mode -> 2x Wire, Master or Slave, Port -> your port, Programmer -> Curiosity Nano. I provide this just as a quick reference. As I said earlier, all of this information is spread out over several documents. Next install the library: AVR-IOT Cellular. When asked about dependencies, I answered Install All.

At this time I did not install the MPLAB Data Visualizer. I [erroneously] thought I could use Arduino’s Serial Monitor. Things don’t work that way for seeing the Log display. So I went back and installed it, you should. NOTE: MPLAB and the Arduino IDE work side-by-side just fine. However, if you are in the practice of hibernating your computer until you come back the next day, you’ll need to restart MPLAB the next day to get it to display Log records.

With everything set up, I tried DRAGNDROP.hex by drag/drop into CURIOSITY.  The Log now showed going out to get time successfully. Unlike the Sandbox, the CONN and DATA lights are not active – they are only there for the Sandbox – they don’t show SIM activity for this demo. That is, they are under program control and basically just LEDs available to the program for whatever you want, and DRAGNDROP doesn’t happen to use them.

As a last test of the Arduino IDE, I uploaded the Blink sketch – or at least I tried. Since I wanted to start with a clean slate, I had chosen to use Version 2.0 of Arduino’s IDE. I forgot about the important note in the AVR IoT’s instructions  - the UPLOAD function in the IDE doesn’t work. Under IDE 2.0 you need to go through the menu and use Sketch -> Upload Using Programmer. All was good.

Getting to work

Now that the development environment was working, I was able to get to work. I have an existing project that runs on a Particle Boron LTE board. It basically takes in some real world information [the details of which aren’t relevant to this Roadtest] and sends SMS. I use a Twilio API to actually get the SMS sent. With the Particle board, I needed to communicate through their cloud – you can’t actually directly send REST GET/POST requests. One benefit of the AVR IoT board is that you can directly talk to the outside world. Conversion of my project from the Particle ecosystem to the Arduino ecosystem only involved changing the API calls. This being done, time to test.

Twilio requires accessing their API as “https” instead of “http”, and the AVR-IoT board supports secure protocol. I wanted to confirm this was true so one of the AVR-IoT examples is an https demo that does GET/POST and I tried it. When you run it (or read the instructions), there is a configuration you need to run first (one time only). So I loaded their https_configure_ca example, which gives you a nice, reassuring, DONE! The https demo now ran as intended.

The Twilio API required that you send authentication information as part of the POST header. I was unable to get the httpclient.post() call to work with this. After spending some time trying various parameter formats, I posted the issue on the Element14 forum and on GITHUB. I cannot express how amazing the responses were. The first response I received was from Dr. Gough Lui. He confirmed that the original .post call did not support passing header information. So he took the time to code up an alternate function call for .post2() and test it! And it worked first time for me.  Subsequent to that I received an answer on GITHUB that the official library was also updated to support passing header information. These 2 responses were a level of support I was not expecting. THANK YOU!

With this hurdle cleared, the project conversion from Particle’s Boron LTE board to the AVR-IoT Cellunar board was complete and working. I have continued to test it over several weeks with great success.

What I learned along the way about this board (in no particular order):

• Support for this board on the Element14 Forum is great.
• If you’re using Arduino IDE 2.0, remember to use Sketch -> Upload Using Programmer
• There are 5 on-board LEDs. Although there are pre-designated descriptions for them, you can use them however you want.
• There are 2 on-board user push buttons. Strangely, they are not debounced.
• There are handy on-board temperature and color sensors, but my testing did not include them.
• Pin names are not the standard D5, A3 etc. You need to use the pin designations from the board layout diagram, such as PIN_PD0, PIN_PD3, etc.
• PWM output is not supported at all.
• The cellular link is very stable and will maintain itself over several weeks (probably longer, but that’s how long I’ve had it up).
• 5 traces can be cut to get accurate current draw readings for various sections of the board
• You can add a file (any name?) to the CURIOSITY drive with content CMD:RESET to reset device

How does it compare with similar boards

As I said at the beginning, I was looking at this board as an alternative to Particle’s Boron LTE board. For my purposes, it is a success. It works. It’s stable. And it doesn’t depend on a 3^rd party Cloud service for its cellular connection to the outside world. At some point I would also like to compare it to Arduino’s Maker NB1500, which appears to be both higher end and more expensive. Here are some of the more key points on each board:

Obviously the AVR-IoT Board is slower and has less memory, but it also removes the reliance on a 3^rd party Cloud service. For those who can live within the speed and memory constraints, this is a board to consider.

The AVR-IoT board also has AWS native support. This isn’t something I had a need for nor did I test it, but for those who do, this could be a deal maker.