Forem: Brandon Satrom

The Strings of Cellular IoT

Brandon Satrom — Fri, 19 Feb 2021 00:00:00 +0000

I’ve spent the last decade of my career working on software and hardware tools for developers. Tools designed to foster collaboration, and lower the learning-curve of complex technologies so that teams and companies can solve problems faster. Every product I’ve worked on – from web UI tools and mobile app dev services, to developer-biased IoT tools – was created to help developers get something done, faster. And every product was focused on untangling all of the complexity associated with building solutions in that space.

In the IoT, we have more than our share of complexity. We get all of the complexity of the software world, mixed-in with a healthy dose from the physical world around us.

In cellular IoT, I like to refer to this complexity as “the strings of cellular IoT.” They are the things that developers often cannot control about building IoT solutions, or which exist by pure inertia. They are things that slow developers down, cut off choice, or provide unnecessary duplication of effort. They are things that lead us to search for alternatives that may be less than ideal, but which feel worth the tradeoff in our frantic efforts to reduce friction.

And while there are many such strings in the cellular space, these are the ones I tend to see most often:

Difficult-to-program modems.
Developer Guardrails.
Device lifecycle management pitfalls.
Security not included.
The meandering path from prototype to scale.

Difficult-to-program modems

If you’ve ever had to work directly with a cellular or Wi-Fi modem, you’re no doubt familiar with the Hayes command set. This command set – often referred to as the “AT command set” because many of the commands start with the string “AT” – was developed by Dennis Hayes in 1981 as a standard command set for interfacing with dial-up modems. It’s terse, and was created in a time when instruction sets were designed to save space. As a result, it’s about as developer-friendly as machine code.

It’s also still in use on many modems, including most cellular IoT devices.

For those unfamiliar with the AT command set, here’s a brief example of the commands needed to turn on a cellular IoT module, set its APN, configure an LTE band, and start scanning for towers:

For many developers, myself included, AT commands are cryptic and inaccessible. They are non-intuitive, and differ from one module to the next. It’s a painful way to add a connectivity module to your application, and yet it’s still the way of the modern world if you’re looking to integrate a cellular modem into your IoT solution.

Developer Guardrails

The challenge of working with cellular IoT modems is well-known, and solutions do exist to create developer-friendly abstractions on top. The problem is that these abstractions often come with guardrails that do too much, or too little, to help accelerate building a connected solution.

Some vendors create narrow guardrails and abstract away the complexity into developer-friendly APIs. The problem is, they also force you to adopt their Host microcontroller, their RTOS, and even a particular programming language. As nice as it is to abstract away the AT command set, cutting off developer choice in the rest of the stack is a steep price to pay, in exchange.

Other vendors give you wide guardrails. They sell you only a SIM or a piece of hardware that requires you to furnish your own SIM and plan. This approach has certainly brought down the cost of IoT and M2M data plans, but it swings too far into the other direction. Developers get cheaper connectivity, but are left to build up the rest of their solution stack themselves. As a result, the developer ends up with the equivalent of “writer’s block” or “blank page syndrome” because there is so much to choose.

The either-or nature of the guardrails in place today leaves developers with a difficult selection: accept too much restriction, or forge ahead with too little guidance?

Device lifecycle management pitfalls

How do you design a real world IoT device when the cost model isn’t built to account for real world use?

Beyond cryptic interfaces and guardrails, developers must also contend with the cost of managing devices and data, much of which is hidden from view. Every device has a price, but some have multiple: the price you pay up-front, the price you pay for data, and the price you pay for a device to change its state, for instance when activated or deactivated.

When a device has multiple price components, or shadow costs, it can be hard to know exactly what your IoT solution is going to cost you. Especially since the reality is that IoT products don’t follow a happy path where they fly off the shelf, are deployed into the field immediately, and are used forever and ever without end.

Instead, most IoT devices tend to go through a pretty consistent lifecycle:

A inventory and distribution stage where they sit idle.
Activation when they are first used.
A period where they fall into less than regular use, but the device is still “online” and accruing fees.
A period of temporary breakage, and it can often take months before the issue is identified and fixed.
Re-commissioning after the device is fixed.
A period where the device is decommissioned permanently.

The typical device lifecycle

Now imagine that, for every one of these stages, you’re paying the same monthly data fee, regardless of actual use, as well as charges for activation, re-commissioning, and decommissioning. The challenge in the cellular IoT space is that each of these phases in the device lifecycle come with carrier fees and transaction costs that can be difficult to plan and budget for. As a result, when most developers look at an IoT device, they don’t know what its true cost is.

How do you design a real world IoT device when the cost model isn’t built to account for real world use?

Security not included

There’s also the string of security, a topic that developers are ever conscious of, but which many providers don’t bake into their products. Key and certificate management is an essential part of every IoT solution. And with all major IoT cloud services now requiring TLS, in the absence of baked-in security, developers are forced to store keys and certificates in firmware in order to connect their devices to cloud services.

With keys and certs in firmware, your IoT devices become yet another sensitive vector that an attacker can use to get the (literal) keys to your kingdom.

The meandering path from prototype to scale

Finally, there’s the string of the disconnect between prototype and production solutions, even as developer-friendly tools abound. As developers, we should consider ourselves fortunate that prototyping is as accessible as it is today, thanks to companies like Arduino, Adafruit, SparkFun, and the Raspberry Pi Foundation. But because much attention has been paid to how “maker friendly” these devices are, they are often dismissed as not production ready. IoT engineers will gladly use these accessible tools to prove an idea at the prototype stage, but throw those prototypes away and start over when it comes time to build a “real” solution.

But if these tools are good enough for the Mars Ingenuity helicopter, they should be good enough for our solutions. And IoT solution vendors can absolutely do more to minimize the throwaway mindset with tools that make prototyping easy from the start, and which level-up to pilot and production scale just as seamlessly.

Complexity Kills

When taken together, the strings of cellular IoT create a developer-hostile environment where complexity rules. From the start, the path of selecting a board to building a prototype to deploying and scaling a pilot is filled with hurdles and roadblocks that make it hard for many initiatives to succeed.

When I think about complexity, I think of a quote from our Founder and CEO, Ray Ozzie. It’s something that he said long before setting out to start Blues Wireless, but which applies very much to the IoT of the present.

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test. - Ray Ozzie

Introducing the Notecard

It should come as no surprise that Ray was motivated to start Blues Wireless after experiencing the pain and complexity of building an IoT solution himself. As Ray detailed in his recent post, that journey started with the Fukushima Daiichi nuclear disaster and led to the Notecard.

The Notecard is a developer-friendly, production-ready cellular IoT device. It was built by developers, for developers, to address every one of the strings of cellular IoT. The Notecard:

Is easy to program, with a built-in developer-friendly API.
Let’s you set your own guardrails with your own host MCU or SBC.
Has no hidden fees, and a built-in 10-year data plan (with no fees) bundled into the cost of the device.
Includes baked-in keys and a secure connection to our Notehub.io cloud service.
And is built on a form-factor that’s ready to move to a pilot or deployment in a snap.

The Notecard is an uncomplicated cellular IoT device. It comes with 500 MB of data and a ten-year plan built-in, and starts at $49. If you’re evaluating cellular IoT solutions, you should check it out, and you can learn more at blues.io, our Developer Portal, or our Shop.

With the Notecard, we aim to cut the strings of cellular and allow the next generation of IoT solutions to be truly wireless.

Learn about mesh networking by building this swarm of Particle-powered robots

Brandon Satrom — Mon, 08 Jul 2019 20:32:15 +0000

Hacking a toy is a fun form of electronics exploration. It’s a great way learn how real-world products are designed and built, and tinker without worrying about rendering expensive electronics useless in the pursuit of knowledge. Inexpensive consumer electronics are a fantastic platform for learning, exploration, and even building new, innovative solutions.

Remote-controlled (RC) vehicles are a common target for makers, and cars with the “Thunder Tumbler” name provide a cheap, accessible platform for RC car hacking. The Tumbler has been hacked a number of times before, but I don’t think it’s ever been used in a mesh network. That is, until now. Using a couple of Tumblers that you can find online or in stores like CVS, and a few of Particle’s new, mesh-ready hardware, I created a swarmbot network of Tumblers that move in synchronized fashion at my every command!

Note: This post originally appeared in Make: Magazine, volume 68 and online here. It is reprinted here with the author’s permission. |

Materials needed

For this project, you’ll need the following items:

(2-3) “Thunder Tumbler” RC Cars, available at many chain drug stores or online — here in the states both Walgreens and CVS carry these cars. Note there are multiple versions of this product, but I’ll cover how you can handle these subtle variations.
(1) Particle Argon
(3) Particle Xenons
(3) breadboards — included with the Argon and Xenon kits
Assorted jumper wires for connecting each Xenon to the RC Car’s PCB
A multimeter for inspecting IC pin functions (as the pinout may vary from one cheap RC car to the next)
Soldering iron and solder

How does mesh networking work?

Most connected solutions tend to rely on Wi-Fi or cellular for connectivity. This typically means that each connected device maintains a direct connection to the Internet. While this is useful for connecting to the cloud for data storage or processing, some connected solutions need to be able to operate on a local network, with other devices, regardless of whether a connection to the Internet exists.

Mesh networking solutions enable these scenarios by allowing developers to create local networks of connected devices. The bulk of the network consists of endpoints that sense or actuate, and repeaters that help increase the size and reliability of the mesh by passing messages between devices. In addition, a small number of devices — often just one — serve as gateways to maintain a connection to the Internet. Critically, these local networks of devices can still communicate with one another when the connection to the network disappears. The Argon, Boron, and Xenon — all 3rd generation Particle devices — provide built-in mesh-networking capabilities.

For this build, I used mesh to create a network of RC cars, each controlled by a Particle Xenon. All of the Xenon RC cars are endpoints, and are connected to a mesh network with a single Particle Argon as the gateway. Once the network is established, I can use local network messaging to send low-latency commands to nodes on the network and make my RC cars dance.

First, however, I needed to hack the off-the-shelf Tumblers to Particle-power them!

Hacking the Thunder Tumbler

The first step of this process is hacking the RC car to add a Xenon. Regardless of the brand or style of RC car you’re using, the objective is to crack open the car to reveal the PCB inside, determine how the device sends commands to the motors to rotate the wheels, and connect pins from the Xenon to the corresponding motor driver pins on the car. Because these cars are inexpensive, you should expect to find some variation, even among those with the “Thunder Tumbler” name on the box.

Write-ups on Tumbler hacking can be found online going back over 9 years. That’s a lifetime in the electronics world, so be sure to test and verify the functionality of your own cars as you follow-along with the instructions below.

I suggest grabbing your favorite multi-meter and measuring voltages across various pins on the RC car PCB as you make the wheels spin with the remote control. Make sure to set your car somewhere where the wheels can rotate freely so that it doesn’t get away from you during testing.

R/C Tumbler with my trusty multimeter. Since these cars are inexpensive, a multimeter comes in handy to reverse engineer the IC pinouts.

Remove the two screws that hold the shell of the tumbler in place. Once these are out, you can lift the shell to expose the tumbler PCB. Inside, you should see 8-10 wires that run from the the car to the PCB, and a number of through-hole and surface-mount components.

The Tumbler uses a classic motor controller designed known as an H-bridge driver. By testing the pads with my multimeter, I was able to reverse engineer what combination drives the car forward and backward, plus left and right steering. Note that some Tumblers use a different pinout than mine, so you’ll want to have a meter nearby to test your car.

Understanding the various onboard ICs

The small surface-mount component on the top is a remote-controller receiver chip, the RX-2B. Its pair, the TX-2B transceiver chip sits in the remote control that ships with these cars. These ICs are commonly used for RC vehicles, and I was able to find their data sheets online to determine which pins map to forward, backward, left and right commands from the remote. I also used the data sheet to establish a known ground pin, which is needed to determine which pins power the car motors and can be controlled by a Xenon.

This ended up being critical because the main IC on these boards, through-hole mounted on the bottom of the car PCB, is one for which I couldn’t find a data sheet, in spite of many hours of searching. While I’m still not 100% certain of all the features on this chip, it functions primarily as an H-Bridge motor controller. Pulsing a signal into a certain pin on the IC results in a pulse out to one of the motor control pins, which makes a wheel spin forward or backwards.

Inserting the motor controller back into the Tumbler chassis.

By reverse-engineering, I was able to find that there are four pins I care about on this unknown IC: one that spins the left wheel forward, one that spins it back; one that spins the right wheel forward, and one that spins the right wheel back. I soldered one wire to the top of each of these pins, and one to a ground pin. Even though the Xenon and car are powered separately, they need to share a ground signal for everything to work, as needed.

Setting up a mesh network

Setting up a Particle Mesh network is a quick process with the Particle mobile app.

Because this project requires a mesh network, you’ll want to set one up with one gateway (a Particle Argon or Boron) and one Xenon-based node for each RC car. If you want to program each Xenon over-the-air without having to connect each to a computer, you’ll want to set up your network in advance. You can do this from the Particle mobile app, or follow the instructions here.

This image shows mobile flow you will go through when setting up a new Particle Mesh device.

Programming the tumblers

Once you have your first Xenon claimed and ready, the next step is to write firmware for controlling the actions of each car. Since the goal is to create a small mesh of swarmbots, you’re going to create a simple sequence that moves the car forward, back, left and right. The code for this sequence can be found below:

// Wheel pin mappings
int leftReverse = A0;
int leftForward = A1;
int rightForward = A2;
int rightReverse = A3;

// Speed and delay variables
int speed = 85;
int turnSpeed = 255;
int forwardDelay = 1000;
int backDelay = 1000;
int turnDelay = 2000;

void setup()
{
  // Set motor pins to outputs
  pinMode(leftReverse, OUTPUT);
  pinMode(leftForward, OUTPUT);
  pinMode(rightForward, OUTPUT);
  pinMode(rightReverse, OUTPUT);

  // Make sure each motor is off
  digitalWrite(leftReverse, LOW);
  digitalWrite(leftForward, LOW);
  digitalWrite(rightForward, LOW);
  digitalWrite(rightReverse, LOW);
}

void runDemo(const char *event, const char *data)
{
  allOff();

  goForward(speed);
  delay(forwardDelay);

  goBack(speed);
  delay(backDelay);

  // Max spin to raise up on the back tires
  turnLeft(turnSpeed);
  delay(turnDelay);

  allOff();
}

void allOff()
{
  analogWrite(leftReverse, 0);
  analogWrite(leftForward, 0);
  analogWrite(rightForward, 0);
  analogWrite(rightReverse, 0);

  delay(50);
}

void goForward(int speed)
{
  allOff();

  analogWrite(rightForward, speed);
  analogWrite(leftForward, speed);
}

void goBack(int speed)
{
  allOff();

  analogWrite(rightReverse, speed);
  analogWrite(leftReverse, speed);
}

void turnLeft(int speed)
{
  allOff();

  analogWrite(rightForward, speed);
}

void turnRight(int speed)
{
  allOff();

  analogWrite(leftForward, speed);
}

void loop()
{
  // Nothing needed here. 
}

You probably noticed that the meat of the demo is analogWrite commands to turn each wheel forward or backward by sending a voltage to a corresponding pin. Through testing, I determined that the cars I’m using are PWM-able, meaning that I can set a wheel pin to lower than digital HIGH (3.3 volts in the case of the Xenon) and have the wheel turn at lower speeds. Notice that I’m passing in different values for turning right or left vs forward and back. PWM enables pretty complex patterns and speeds for these inexpensive cars.

With the demo code done, the final piece you need on your RC cars is a subscription to a local network message that specifies the runDemo function as the handler. Particle enables local, in-mesh-network messaging between nodes on a network using a Mesh.publish and Mesh.subscribe API. Mesh.publish sends a broadcast message (with a name and payload) to all nodes on the network. Mesh.subscribe, on the other hand, listens for messages (by name) and specifies a handler to process and respond to those incoming messages.

Our Xenons will use Mesh.subscribe to listen for a network message, and then trigger the demo sequence.

// Add to setup functionMesh.subscribe("run-demo", runDemo);

Flash the completed code to each RC car Xenon and you’re ready for the final piece: programming the gateway to coordinate the movements of the car swarm.

Programming the mesh gateway

The mesh gateway is less complex than the code that runs on each Xenon, but still needs two pieces for the purposes of our demo:

a Mesh.publish call to trigger the RC car demo sequence and
a way to tell the controller to fire the message to the mesh network.

We could skip the second step by just firing the message when the gateway comes online, or regularly on a delay, but what fun would that be? Instead, we can use another Particle API Particle.function, to allow us to trigger the cars from a mobile phone.

void setup() {
  Particle.function("runDemo", runDemo);
}

int runDemo (String command)
{
  Mesh.publish("run-demo", NULL);

  return 1;
}

void loop() {
  // Nothing needed here
}

Particle.function takes a string value name of the function (used when calling that function from a mobile or web app or through the cloud) and a handler function to execute when called. That function contains our Mesh.publish call, which sends a broadcast message with the name “run-demo” to all listeners (i.e. our RC cars) on the network. Once you’ve added the code above to your gateway, you’re ready to control some swarmbots!

Putting it all together

Once you’ve built your RC cars and have them configured in a mesh network, you’ll be able to control them from the Particle Console.

Particle functions can be called from any device that has a secure connection to the Particle Device Cloud, which could be the Particle Console, the CLI, or even your own applications. They can also be called from the Particle mobile app, which seems like a fitting place to finish this project. The Particle mobile app shows a listing of every Particle device you own. Click on your gateway, then the “Data” tab menu, and you should see a “runDemo” function. Put your Xenons in position with plenty of space, and click the function to trigger some RC swarming!

The demo code above illustrated a simple, coordinated sequence of actions. But with PWM and a bit of trial and error, there are a number of cool synchronized dances you can create with mesh-networked RC cars.

Command your swarm!

With the project complete, it’s time for an RC Tumbler dance party!

Now that your bots are meshed, let’s turn them into real swarmbots that can communicate with each other. A common swarm scenario is the leader-follower pattern. The leader determines movements for the swarm, and communicates these directly to all followers. One example would be to control the leader with the out-of-box remote control, read pin voltages off the leader car, and send these as instructions to all followers listening for a Mesh event.

To build this demo, I designated one of my three cars as a leader, and added firmware to control the fleet. Instead of writing to my motor pins, the leader simply reads the analog values sent by the remote control and sends these to listeners on the network with a Mesh.publish that includes the wheel, direction and analog value to apply to follower cars.

int32_t lastLeftRVal = 0;
int32_t lastLeftFVal = 0;
int32_t lastRightRVal = 0;
int32_t lastRightFVal = 0;

#define MIN_PIN_VAL 150
#define DRIVE_VAL 200

void setup()
{
  pinMode(leftReverse, INPUT);
  pinMode(leftForward, INPUT);
  pinMode(rightForward, INPUT);
  pinMode(rightReverse, INPUT);
}

void loop()
{
  checkPin(leftReverse, &lastLeftRVal, "leftR");
  checkPin(leftForward, &lastLeftFVal, "leftF");
  checkPin(rightReverse, &lastRightRVal, "rightR");
  checkPin(rightForward, &lastRightFVal, "rightF");
}

void checkPin(int pin, int32_t *lastVal, const char *event)
{
  int32_t pinVal = analogRead(pin) / 16;

  if (pinVal > MIN_PIN_VAL)
    pinVal = DRIVE_VAL;
  else
    pinVal = 0;

  if (pinVal != *lastVal && pinVal == DRIVE_VAL)

    *lastVal = pinVal;

    Mesh.publish(event, String(DRIVE_VAL));
  } else if (pinVal == 0 && *lastVal != 0) {
    *lastVal = 0;

    Mesh.publish(event, String(0));

}

Code for the follower robots

On the follower side, I added firmware that listens for a Mesh event for each pin, and performs an analogWrite with the passed-in value. On the cars themselves, I also removed the antenna on each board and cut the traces from the remote RX IC just to make sure that movement commands were only coming from the leader.

void setup()
{
  pinMode(leftReverse, OUTPUT);
  pinMode(leftForward, OUTPUT);
  pinMode(rightForward, OUTPUT);
  pinMode(rightReverse, OUTPUT);

  digitalWrite(leftReverse, LOW);
  digitalWrite(leftForward, LOW);
  digitalWrite(rightForward, LOW);
  digitalWrite(rightReverse, LOW);

  Mesh.subscribe("leftR", leftR);
  Mesh.subscribe("leftF", leftF);
  Mesh.subscribe("rightR", rightR);
  Mesh.subscribe("rightF", rightF);
}

void leftR(const char *event, const char *data)
{
  move(leftReverse, data);
}

void leftF(const char *event, const char *data)
{
  move(leftForward, data);
}

void rightR(const char *event, const char *data)
{
  move(rightReverse, data);
}

void rightF(const char *event, const char *data)
{
  move(rightForward, data);
}

void move(int pin, const char *speed)
{
  int32_t speedVal = atoi(speed);

  if (speedVal > 16) // Filter out noise from the leader
  {
    analogWrite(pin, speedVal);
  }
  else
  {
    analogWrite(pin, 0);
  }
}

void loop() {}

With this simple R/C-controlled swarm as our foundation, we built a bunch more swarm sequences:

Follow the leader — basic forward and back demo with ending spin️
Splinter — cars separate in three different directions and come back together
Follow the leader and push — leader tells followers to stop, goes forward 2 seconds, turns around, goes back 2 seconds, then tells followers to move backward as it keeps moving forward
Sentry mode — square path with right-angle turns
Orbit — followers orbit a stationary leader.

You can grab the complete project source code, including these more complex demos, from the repository on Gihub. I’ve also done a number of Twitch streams focused on building the demos for this project; check them out on my Twitch channel.

Hack It and Share It

Ready to rule the world with my new RC Tumbler swarm robots.

We’d love to see makers extend and modify this project with sensors and new behaviors. You could add collision detection to the leader with a PIR or ultrasonic sensor, or even use the remote to log predefined sequences that could then be repeated automatically. And if you’ve built your own mesh-style swarmbot project, or anything else with Particle’s new hardware, we’d love to hear from you! Share with us on Twitter, Instagram, or in our community of 160,000 developers.

Swarm on, makers!

The post Learn about mesh networking by building this swarm of Particle-powered robots appeared first on Particle Blog.

Get up to speed with Particle Variable and Function Primitives

Brandon Satrom — Thu, 16 May 2019 19:29:19 +0000

IoT Projects often need to share the data they collect, or enable external systems to trigger actions. That’s the “I” in IoT, after all. To make connectivity easier, Particle provides a number of “primitives” in the built-in Device OS, including variables, functions and messaging with Particle publish and subscribe.

In this video, I walk through a simple project that shows you how to use the Particle Variable and Function primitives with a Particle Argon, and two Grove sensors from the Grove Starter Kit for Particle Mesh.

With the variable and function primitives, developers can access local device state, for instance, to retrieve the latest reading from a connected sensor, or call firmware functions to take action on the device, for instance, to turn on a light or move a servo. Because these primitives are mediated securely through the Particle Device Cloud, they can be accessed from other devices, the Particle console, or even in web and mobile applications.

For other videos covering the basics of working with Particle devices, check out our Particle 101 series on YouTube. If you have questions about using Particle variables, functions, or anything else in the Particle platform, visit us in the Particle Community.

The post Get up to speed with Particle Variable and Function Primitives appeared first on Particle Blog.

Three things I learned about Microsoft's IoT vision at Build

Brandon Satrom — Fri, 10 May 2019 19:08:54 +0000

Photo by Leio McLaren (@leiomclaren) on Unsplash

This week, I attended Microsoft's annual Build conference. It was my first trip back to build since the very first iteration many years ago—when I was a Microsoft employee and the star of the show was Windows 8!—and I was excited to see Microsoft's vision for developers, up close.

There were a whirlwind of announcements across the three days in all areas of Microsoft's business, but as a maker and embedded developer, my primary interest was in the company's ever-increasing attention on the IoT. Here are three major things I learned about Microsoft's vision for the IoT from my time at Build.

Note: The views and opinions expressed here are mine, and do not represent those of my employer, Particle. Nor are they meant to indicate any public statement about Particle product features, integrations, roadmap changes or shifts in strategy. This post is merely one developer's opinion and should be treated as such.

"The Intelligent Edge" is an extension of Microsoft's long commitment to a hybrid cloud computing model

Satya Nadella's keynote on day one of Build was a tight, two-hour whirlwind that touched on almost every area of Microsoft's business. Nadella framed his remarks around what he referred to as "four distinct platform opportunities" for Microsoft, each of which drove a section of the keynote. They were:

Intelligent Cloud & Edge
Business Process Automation
Office 365
Gaming

The Microsoft CEO made only passing mention of "the IoT" in name during his keynote. Instead, he spent the first segment talking about edge computing, and the role he sees Azure playing in "extending the cloud to the edge." He invoked the term "hybrid cloud" more than a few times, and emphasized that a successful hybrid cloud environment requires "consistency between the cloud and the edge."

ABInBev and Srarbucks

With those remarks as the frame, Nadella went on to share customers already using Azure to enable this form of edge-to-cloud hybrid computing, including ABInBev and Starbucks. Starbucks had an extensive expo hall demo of their Azure-powered products, including an Azure Machine Learning-powered customized ordering engine (Deep Brew) and an Azure IoT Central And Azure Sphere-powered system for monitoring and management of Starbuck's Mastrena II espresso machines.

Starbucks' AzureML powered DeepBrew recommendation system

Starbucks' white-labeled Azure IoT Central dashboard for espresso machine monitoring

If you've been a Microsoft-watcher for the last decade, the term "hybrid cloud" will sound familiar. It's one that Microsoft has been using since the very early days of Azure, when Ballmer's vision for hybrid was a mix of public cloud and private cloud compute resources that were seamlessly connected. The idea then was to ease the transition of wary enterprise customers into cloud computing, while enabling those same customers to explore the benefits of elastic compute resources without pivoting solely to the cloud. Whereas Amazon's AWS grew in its early days on the compute needs of startups averse to "owning iron," Microsoft's bread-and-butter was EA-signing enterprises who already had plenty of iron.

Given that history—and as far as I'm aware Microsoft never really pivoted away from this narrative even as Azure has evolved in the last decade—it should come as no surprise that Microsoft sees the "IoT edge" as just another spoke in the hybrid cloud. In this world, your factory, farm, retail store, or truck is its own computing environment, and should sense, actuate and compute seamlessly with the rest of your business.

The "hybrid cloud" is a powerful narrative that I'm sure has served the company well with traditional businesses in the last decade. After Build, I can see how it would be compelling to those same businesses as they pursue somewhat unfamiliar connectivity (read IoT) solutions.

Scott Guthrie shared the MSFT vision of ML on the edge with options

After Nadella's keynote, the Build audience was invited to choose between two deep dive technical keynotes: one focused on Azure, and another the Office 365 and Dynamics platform. I opted for the Scott Guthrie-helmed Azure keynote, hoping for a bit more depth around the Intelligent Edge and IoT narratives from the keynote.

As with the keynote, Guthrie's session covered a lot of ground, with product announcements and demos across all of the Azure stack and its associated developer tools. In the IoT realm, the conversation was again focused on hybrid cloud computing and their customers increased attention to building solutions that offload processing and decision-making "to the edge." This was especially apparent in amount of attention paid to the demos and solutions that featured an edge Machine Learning (ML) component. It was in that discussion that I learned something interesting about Microsoft's perspective on the edge and IoT.

In the IoT universe of 2019, much of the focus on edge computing—especially as it relates to ML—is how to do ML on the edge using Single Board Computers and Microcontrollers. As SBCs and MCUs get beefier, it's becoming possible to perform ML inference—that is, performing a prediction against a pre-trained model; model training is still in the domain of more powerful computers—on constrained devices.

In the world of Edge ML products, SBCs and MCUs have dominated. Google's TPU-based Coral DevBoard and the NVIDIA Jetson Nano are two examples of recently-released Pi-like SBCs with ML inference skills. SparkFun has released an Edge MCU that runs TensorFlow lite models, and the announcement just this week at Google I/O of a unification between the TensorFlow Lite and uTensor projects are strong signals that MCU-based inference is a reality.

However, Microsoft seems to view edge ML a bit differently. The company didn't announce an ML-capable SBC or MCU at Build, nor did they disparage the existence of these products as frivolous. Instead, where much of the ML narrative of today seems to be heading toward a continuum of training in the cloud and inference on constrained devices, Microsoft painted a picture where a third computing option sits in the middle: one of edge servers and stacks that offload training from the cloud and inference from devices, while offering the same speed and security that makes edge ML so enticing in the first place.

In floor demos and videos, they featured products like the Azure Stack, a rack of FPGA-powered cards for edge processing, the Azure DataBox for ingesting data by the terabyte into the cloud, and the Vision AI DevKit. The latter is probably the closest thing to an SBC-style ML device that Microsoft has, but even it was featured working in concert with other, higher-powered edge devices.

The featured floor demo in this space was from Kroger, who is using the Vision AI DevKit, Azure Stack and DataBox Edge to perform out-of-stock detection on supermarket shelves without needing to backhaul streaming video to the cloud for ML processing and inference.

A mockup booth of the Kroger stock detection system.

Microsoft didn't explicitly paint this story as an either-or between ML-capable SBCs or MCUs and their products, and they may very well have a product or two in the works as we speak. But one thing that was apparent to me is that when Microsoft thinks about the edge and the hybrid cloud, they think their customers need a variety of options to choose from when building IoT solutions, not just ML-capable SBCs/MCUs.

Microsoft's vision of the IoT is plug-and-play

Perhaps you noticed that Microsoft made a few product announcements in the days and weeks leading up to Build this year. There's one you might have missed as it was buried under a few others: IoT Plug and Play.

I saw the [announcement when it dropped the Thursday before Build, but I'll admit that I was skeptical. I read the announcement, and took a quick scan around the Azure IoT Device Catalog, but the entire thing felt like a marketing ploy to me: clever naming, but little news of value for the IoT developer.

Turns out, I was wrong. In a few sessions from Sam George, Peter Provost and Briton Zurcher on Monday and Tuesday, I realized that the Plug and Play naming was more than branding. As it turns out, a plug and play model might just be exactly what the IoT needs to make solution development easier.

Think about a typical IoT solution of today. You select an MCU or SBC to be the brains of the project, then populate it with sensors and actuators to do something. In some cases, you might even buy a self-contained product like a dashcam or streaming video camera and connect it directly to Wi-Fi. You write firmware to interface with devices, and then you connect the product and its various sensors and actuators to the cloud.

Often, this step of wiring a physical product up to a cloud solution is the challenging part. Connectivity, security and messaging (MQTT, TCP, AMQP, etc.) aside, even the act of defining the telemetry data that your solution will capture and send, or the cloud to device commands it responds to requires manual work in firmware and in cloud solutions like Azure IoT Central.

IoT Plug and Play is Microsoft's open source, standards-based answer to this problem. The secret sauce here is a JSON-LD schema called a Device Capability Model, which can be used to define device metadata like who makes it, what firmware version it's running, what telemetry it sends and collects, and what cloud-side commands it responds to. Here's an example of a capability model from the capability model spec:

{
    "@id": "http://example.com/thermostatDevice/1.0.0",
    "@type": "CapabilityModel",
    "displayName": "Thermostat T-1000",
    "implements": [
        {
            "@id": "http://example.com/thermostat/1.0.0",
            "@type": "Interface",
            "displayName": "Thermostat",
            "contents": [
                {
                    "@type": "Telemetry",
                    "name": "temp",
                    "schema": "double"
                },
                {
                    "@type": "Property",
                    "name": "setPointTemp",
                    "writable": true,
                    "schema": "double"
                }
            ],
            "@context": "http://azureiot.com/v0/contexts/Interface.json"
        },
        "http://azureiot.com/interfaces/deviceInformation/1.1.3"
    ],
    "@context": [
        "http://azureiot.com/v0/contexts/CapabilityModel.json",
        "http://azureiot.com/v0/contexts/Interface.json"
    ]
}

The advantage of a capability model like this is that it creates a contract between the disparate systems in an IoT solution. It can be plugged into a SaaS product like Azure IoT Central and recognize telemetry and commands automatically. It can be used to generate C/C++ code to collect telemetry or respond to commands. It can even be used by developer tools and IDEs (like VS Code) to auto-generate capability models based on implementation-specific firmware.

An overview of how IoT Plug and Play enables various aspects of the solution development process.

And much as Plug and Play of 90s-era Microsoft Windows enabled consumers to buy third-party peripherals and trust that they would "just work," IoT Plug and Play seeks to enable the same experiences for IoT solution builders and device manufacturers alike. And because the underlying definition language is open source, I'm quite hopeful that this will be picked up and leveraged well-beyond the Microsoft ecosystem.

I meet a lot of makers, embedded and hardware engineers in my work for Particle. One of the things we often find ourselves saying to each other is that there's never been a better time to do what we do. Dev kits are cheaper than ever; resources abound on places like YouTube, Twitch, Hackster, and Hackaday; IoT vendors like Particle continue to build simple, secure and scale-ready platforms; and Adafruit is there to make sure we never stop having fun while building things.

If you're looking to solve a real-world problem in the IoT space, there's never been a better time to dig in. Microsoft seems to agree, and after what I've seen this week, I think all of us working in this space stand to benefit, now and in the future.

Professional debugging for IoT with VS Code & Particle Workbench: going beyond Serial.print()

Brandon Satrom — Fri, 03 May 2019 18:45:31 +0000

I started my career in technology as a web developer back in 1999. Those halcyon days of the early web were much different than today, with no browser dev tools, not a sniff of HTML5, and JavaScript was still in its pre-AJAX infancy. But I pinned for a world where on-device debugging would be as easy as my browser dev tools.

Today I pine no more, and with the recent launch of Particle Workbench, I’ve finally found a tool that makes hardware device debugging as easy to use as the browser dev tools. In this post, I’ll walk through how you can do the same with your Particle devices today!

Note: this post covers the basics of debugging with 3rd Generation particle devices, like the Argon, Boron, and Xenon. The Particle docs have an excellent, comprehensive guide for 3rd generation debugging, as well as a guide for debugging 2nd Generation devices (Photon, Electron).

Brief history of my debugging experience: it’s an art

In my early development days, the state of the art in JavaScript debugging was the alert command, which would pop a UI box on ones screen with whatever value you wanted it to. Need to know the current state of a loop counter variable? alert(i); Wondering what the ADDRESS_ONE column looks like when retrieved from your SQL Server database? alert(address_one).

The state of the art in debugging, circa 1999.

Desperately trying to figure out where that heisenbug is in your new user auth flow that you swore to your boss up and down you tested thoroughly before deploying on a Friday at 4pm?

alert(“HERE”); 

alert(“HERE 2”);

alert(“WHAT ARE WEEKENDS ANYWAY? I LIVE IN THIS CUBICLE NOW.”);

In the years since, the state of debugging in the web has come a long way. With the advent of console.log(), we got the unobtrusive replacement for the alertbox. It was a move in the right direction, but still a Crocodile Dundee-sized knife when one needed a scalpel.

Then came browser developer tools, first in Firefox via Firebug, then built-in in Chrome, Firefox, IE, and Opera. Finally, web developers everywhere could set breakpoints, watches, and inspect running client-side applications like our server-focused colleagues had been doing for years.

Serial.print(), the alert() of embedded development

Many years later, I got into hardware and embedded development, and I discovered that a similar trial and error debugging process dominated the field in a way not unlike the early web. There, instead of alert() and console.log(), the tendency was to litter ones firmware with Serial.print() and Serial.println() commands as a way of logging the progress and state of an embedded application.

And much like my early use of alert(), I found myself using Serial.print() as a blunt instrument when things went awry and I had no idea where the self-induced error was to be found. Sure, professional, on-device debugging tools were available, but as a newbie in this intimidating world of hardware, I, like many others, reached for the solution that felt comfortable and familiar.

With the launch of Particle Workbench, I’m happy to report that the built-in debugging capabilities are just what we firmware developers need to go beyond Serial.print().

Debugging with Particle Workbench: Easy like the browser dev tools

Before getting started, you’ll need to gather a few materials, including:

Particle Workbench, a new VS Code-based IDE optimized for IoT;
One 3rd Generation Particle device. I use the Argon Kit for this post;
One Particle Debugger;
One USB Micro cable (included in the Argon Kit I used).

Both the Debugger and the Particle device must be connected to the same computer via USB, so make sure you have enough ports available. Connect the debugger to the debug port on your Particle device using the provided ribbon cable, and plug both into your computer. The debug port consists of ten exposed pins protected by some plastic, and you can find it next to the LiPo battery port near the top of the device.

The debugger cable plugs into the 10-pin JTAG port on the top left of the device.

Once everything is connected and powered on, you’ll need to put your Particle device into Device Firmware Update (DFU) mode. In order for Workbench to facilitate on-device debugging, it needs to compile and flash a debug build of your application and the Particle Device OS firmware in a single binary. You’ll sometimes see this referred to as a “monolithic” build because this differs from the normal build process, where Device OS and your application firmware can be updated independent of one another.

To put your device in DFU mode, press and hold the MODE and RESET buttons on the device. Then, release the RESET button, while continuing to hold the MODE button until the RGB LED on the device starts blinking yellow.

Put your device into DFU mode before starting the debug process.

Note: Step debugging 3rd generation devices with Mesh features enabled is currently unsupported due to requirements of the Nordic SoftDevice in the nrf52840. Devices in standalone mode, which is configurable during mobile setup, can be debugged with no issues.

Workbench Debugging Basics

Now that you’re setup on the hardware side, let’s start a debugging session and cover some Workbench basics. First, you’ll need to open a firmware project with Particle Workbench. I won’t cover the specifics of creating or importing projects in Workbench, so be sure to consult the docs if you need more info.

Starting a Debug Session

To start a debug session, click on the Debug icon to open the debug sidebar. Then click the debug dropdown and select the “Particle Debugger (argon, boron, xenon)” option.

The debug sidebar icon is… a bug. Pretty easy to spot, which is more than I can say for the bugs I tend to create in my code.

Now, get ready to wait a bit as Workbench creates a debug binary for your project. This will go much faster on repeat runs, but the first run is a good time to grab a cup of coffee, take a stretch break, or practice your sword-fighting in the hallway.

Once the debug binary is built and flashed to your device, Workbench will halt and your device will power down, which you’ll see once the onboard RGB LED turns off. You’ll also see the following message in the Debug Console, which is expected.

The message here is normal when starting a debug session

Click the continue button to power your device back up. Once you’re breathing cyan again, you’re ready to debug!

The continue button is the play button at the left of the step debugging box.

Setting Breakpoints

The first thing you’ll likely want to do is set some breakpoints so you can pause and inspect running code. You can set breakpoints by clicking in the gutter next to an individual line, or from the “Breakpoints” section of the debug sidebar. When a breakpoint is set, a red circle will appear next to the line on which to break.

Click on the gutter next to any line to set a breakpoint

You can also add breakpoints in the sidebar by referencing a function by name

It’s also possible to set breakpoints that only break code when a condition you define is met. You can set conditional breakpoints that pause execution when a condition is true, or when a hit counter is passed. In the screenshot below, I’ve set a breakpoint to pause when an Ultrasonic distance sensor reads a value less than 100 cm.

Use conditional breakpoints when you want to fine-tune how and when to break on a line of code.

Stepping through code

Once a breakpoint is hit, the line in question will be highlighted in yellow. From here, you can use the Debug menu at the top of the screen to step through your code. From left to right in the image below, those buttons allow you to continue, step over the current line, step into the current line, step out of the current scope, restart the debug session (you’ll need to put the device back in DFU mode for this to work) and finally, to disconnect the session.

During debugging, this handy menu will appear at the top of your Workbench screen.

Hitting continue resumes execution until the next breakpoint is hit. Most of the time, you’ll end up using the step into, over and out buttons to explore your code.

When paused on a breakpoint, the current line will be highlighted in yellow.

Let’s consider the difference between stepping over and into the following line of code.

range = ultrasonic.MeasureInCentimeters();

Clicking step over will move execution to the next line, Serial.print() and pause again. From here, you can inspect variables, the call stack, and more. If the line in question is a function, you can also step into the source of that function. This is really handy when debugging in firmware libraries, like in the case of the MeasureInCentimeters function, which is part of the Grove-Ultrasonic-Ranger library!

The debugger can step into locally-installed firmware libraries

Once inside a function, you can use the “Step Out” option to continue execution through the rest of the current function and break again on the next line after that function returns.

Step debugging allows you to inspect your code, code in firmware libraries, and even sources in the Device OS firmware! Ever wanted to explore the internals of how Particle’s brilliant firmware team implemented Particle.publish()? With Workbench debugging, you can!

You can also step-debug into Device OS internals!

Inspecting variables

Step debugging is magical in itself, I know. Often, however, the reason we need to debug in the first place is to check the state of our application when it reaches a breakpoint. Workbench provides a number of ways for you to do this. To begin with, when paused on a breakpoint, you can hover over a variable or object and a tooltip will appear with information about its state. You can also inspect the values of local and global variables using the Variables panel.

The variables panel contains information about local, global and static state

Watching values

Beyond inspecting local and global variables, you can use the watch panel to tell the debugger to keep track of the state of a given variable or object. This can be quite useful if you want to see how a portion of your application mutates or is affected by another variable, or if you want to take a closer look at when a given variable or object comes into or goes out of scope as your app is running.

The watch panel is useful for keeping track of state while you debug

Navigating the call stack

One of my favorite debugging features is the Call Stack navigator, which can come in quite handy when you’re spelunking the internals of a library or the Device OS firmware. The pane keeps running track of the stack from your current position up, and you can click on any entry in the stack to quickly navigate to that position.

With the Call Stack panel, you can move around anywhere in the stack of the current breakpoint

Advanced Debugging Features

In addition to the features covered in this post, the Workbench debugger provides access to several debug features built-in to VS Code and leveraged by the cortex-debug extension, including the ability to inspect and edit hardware registers, peripherals, and even direct memory locations. All of these are outside of the scope of this post, so check out the docs for these tools to learn more about how to use them.

Additional Tips and Tricks

Once you’re done debugging and ready to resume normal coding and flashing, you’ll need to get your device out of its debug state, meaning that you want to replace the “monolithic” debug build with the hybrid application and device OS firmware. To do this, put the device back into DFU mode and run the “Particle: Flash application & Device OS (local)” command in the Workbench command palette.

And if you ever run into weird errors while debugging or flashing, the Workbench clean commands are your friends! In my experience, when these things pop up, running “Particle: Clean application & Device OS (local)” and “Particle: Clean application for debug (local)” are usually enough to set things right again.

Much as the web has come a long way since the early days of alert()-based debugging, the built-in debugging capabilities of Particle Workbench will enable Particle developers everywhere to peer under the covers of their embedded applications with ease and confidence. Debugging with Particle Workbench is already a game-changer for me, and I bet it will be for you too.

The post Professional debugging for IoT with Particle Workbench: going beyond Serial.print() appeared first on Particle Blog.

How to build a control panel for your Particle-powered brewing projects

Brandon Satrom — Wed, 27 Mar 2019 21:13:02 +0000

A few weeks ago, I detailed my process for upcycling a Photon-based project of mine—the Brew Buddy—to the new Particle Argon. I covered creating a new breadboard prototype, adding a few new features not in the Photon version, and the process of converting the firmware to work with the Argon.

In this post, I’ll cover the second half of the project: from prototype to PCB and cloud-based control panel. As with the first part of this project, I’ve been live-streaming all my work on this project over on Twitch, so if you want to watch the replays, or join me for future projects, head over to my page and give me a follow to get notified.

Designing a new PCB with Eagle and OSH park

Having the ability to breadboard a new project is amazing, but once I get everything working, I can’t wait to get rid of that rats nest of wires and replace them with a fancy, custom-designed Printed Circuit Board (PCB). My original Brew Buddy project saw several PCB revisions over its early life, so of course I had to spin another board for this Argon-based iteration.

Various iterations of the Brew Buddy custom PCB that I’ve used over the years.

Creating PCBs in Autodesk Eagle

There are a number of tools out there for designing PCBs, including free tools like KiCAD and high-end tools like Altium and OrCAD. I tend to do my PCB design in Autodesk Eagle. It’s a powerful tool with a bit of a learning curve (like all tools of its ilk), but once you get the hang of it, it makes the process of bringing your breadboard prototypes to life a fun and rewarding process.

Since I had an existing version of the PCB for my Photon-based project, my process here was a relatively straightforward one:

Replace the Photon with the Argon
Re-route the pins to the proper places on the Argon
Add an additional pin for the SD card chip-select on the Adafruit TFT breakout
Add the Piezo disc (and resistor)

When creating custom PCBs, you could etch your own with dangerous chemicals, or let fabrication pros handle the process at a fairly affordable price. For the digital design of the final PCB, there are two key assets you’ll create: a schematic, and a layout. The schematic is the logical design of the board and is meant to show where all of the electrical connections are made between components on the board. Here’s a before and after view of how my schematic changed for this project:

A side-by-side comparison of the Brew Buddy schematic.

The layout describes the physical placement of the components on your PCB. It’s coupled tightly to the logical, schematic design so that your connections are logically, valid, but the layout is where you place components and draw copper traces between them. Here’s a before and after view of the physical layout of the PCB:

A side-by-side comparison of the Brew Buddy layout

My new Brew Buddy PCB is larger, partly to accommodate the larger Argon, and also to make room for the new Piezo. I could have made it smaller, but then I wouldn’t have an excuse to spin another rev of the boards, now would I?

The most time-consuming aspect of the four-step migration was the first: moving from the Photon to the Argon required a re-mapping of every logical and physical connection. Eagle does have a Swap Part tool that makes this a bit easier, but in the spirit of being careful and thorough, I didn’t use it so that I could verify every connection.

All in all, this part of the process took me just a couple of hours. If you’re interested in watching how this process played out, I live streamed it on Twitch, and you can find the recording below.

Ordering PCBs from OSH Park

With the board design done, it was time to order PCBs. There are a bevy of great, online PCB fabs around these days, but one of my personal favorites is OSH Park. They are inexpensive, quick, and if you like the color purple, you’ll love their PCBs.

Ordering PCBs from OSH Park is simple. All you need to do is drag the Eagle .brd file onto the “Let’s get started” drop zone and OSH Park will read the file, generate the layer instructions and give you a price estimate. If you have a Zip file with Gerber files (a set of individual files that represent the layers in a fabricated PCB, and pronounced like the baby food) you can upload those as well.

OSH park also allows you to make your PCBs publicly available for others to consume and even order. Here’s mine for the Brew Buddy if you’d like to take a look for yourself.

Once I had my PCBs ordered, I passed the time waiting by working on my web-based control panel, which we’ll cover in the rest of this post. When the PCBs arrived a week or so later, I did live stream the assembly (often called PCBa) and testing, which you can check out below.

Building a web-based control panel with Azure IoT and electric io

For the “cloud” portion of this project, I wanted to build a control panel, not just a dashboard. I wanted to be able to move between brew monitoring states (brewing vs. fermenting) and trigger actions from the same interface where I would view charts, graphs and the current state of my app. With the Azure IoT Hub and a great open source project called electric io, I was able to do just that.

My electric io dashboard for Brew Buddy

The entire process consisted of the following steps:

Wire my project up to Azure IoT Hub
Configure electric io to display device data
Add MQTT to my Firmware to receive cloud-to-device (C2D) messages from Azure
Configure electric io to Send C2D Messages

The first step is covered extensively in our Docs on setting up an Azure IoT Hub integration with the Particle Device Cloud, so I won’t repeat them here. In addition, Paul DeCarlo from Microsoft covered the second step in a recent blog post, so I’m going to gloss over that section as well. Key and unique to this project are steps three and four, which enabled me to turn electric io from a dashboard, into a true control panel.

Using MQTT to listen for Azure IoT Hub Messages

The Particle Device Cloud to Azure IoT Hub integration gives you a quick, painless connection between your Particle Device and Azure. It allows you to use the Particle.publish API as you would in any other project, and pipe that data into Azure directly.

In order to add Azure to Device communication, we need to do a bit more in our firmware. The Azure IoT Hub supports two modes of direct integration with the IoT hub: a language SDK, or through direct implementation of pub/sub through MQTT or AMQP. For this project, I opted to use MQTT.

For Particle devices, there are two great MQTT libraries to choose from, MQTT for basic support, and MQTT-TLS when a secure, certificate-based MQTT connection is needed. Azure IoT Hub requires a secure connection, so I installed the MQTT-TLS library and included it in my project:

#include “MQTT-TLS.h”

To create a TLS-based connection, you also need a client certificate, which Microsoft provides in their SDKs. I grabbed the DigiCert Baltimore Root certificate from their GitHub repo, and created a new file called certs/h in my project, which I included right after the MQTT library include.

#include "certs/certs.h"

The next step is to declare a callback function for all MQTT inbound messages, and create an MQTT client. I created a forward declaration for the callback and configured the client URI and port based on the online docs. Be sure to replace the {your hub name} string with the name of your own Azure IoT Hub, which you can find in the Azure Portal for your account.

void mqttCB(char \*topic, byte \*payload, unsigned int length);
MQTT client("{your hub name}.azure-devices.net", 8883, mqttCB);

The next step is to connect to the Azure MQTT server when the project starts up. In the setup function, I enabled TLS and pass in the certificate I downloaded and created earlier. Then, I called the connect method with my deviceID (deviceID = System.deviceID();) and a username and password.

client.enableTls(certificates, sizeof(certificates));
client.connect(deviceID, "{your hub name}.azure-devices.net/" + deviceID, 
  "SharedAccessSignature {your SAS Token here}");

In the case of the Azure IoT Hub, the username you provide should be your hub endpoint—like myhub.azure-devices.net—plus your Particle deviceID.

For the password, Azure requires that you provide a SharedAccessSignature, or SAS Token. You can generate these for your own hubs with the Azure device explorer, the Azure CLI or the Azure IoT Tools for VS Code, which is what I did. I was already in VSCode building my app with Particle Workbench, so it was easy!

The Azure IoT Hub VSCode extension in action

The next step is to check the isConnected method to determine if I successfully made an MQTT connection to the Azure IoT Hub. In either case, I added some Particle.publish calls so that I can double-check this from the console.

If I get a positive result, it’s time to set up a subscription. Azure IoT Hub provides two ways to receive communication on embedded devices, Direct Method calls (which always send a response) and Cloud-to-Device (or C2D) messages, which function more like fire-and-forget messages. I decided to use C2D messages. To receive these, the MQTT client needs to subscribe to the devices/{deviceID}/messages/devicebound/# topic filter.

if (client.isConnected())
{ 
  Particle.publish("mqtt/status", "connected");
  bool msgSubResult = client.subscribe("devices/" + deviceID + 
    "/messages/devicebound/#", MQTT::QOS0);

  Particle.publish("mqtt/message-sub-result", msgSubResult 
    ? "subscribed to hub messages" 
    : "subscription failed");
}
else
{
  Particle.publish("mqtt/status", "failed");
}

With the subscription set up, the last step is to define the callback. On the electric io side, my plan was to send a payload to the device that contained at least a property named methodName, which would correspond to a brewing mode on the device, like “brew,” “ferment,” or “stop.” On the firmware side, that meant I needed to receive and parse the payload to extract the methodName. Thankfully, there’s a great JsonParserGenerator library for just this purpose.

void mqttCB(char \*topic, byte \*payload, unsigned int length)
{ 
  char pload[length + 1]; 
  memcpy(pload, payload, length); 
  pload[length] = NULL; 

  jsonParser.clear(); 
  jsonParser.addString(pload); 

  if (jsonParser.parse()) { 
    String methodName = 
      jsonParser.getReference().key("methodName").valueString(); 

    Particle.publish("mqtt/message-method", methodName); 

    setBrewMode(methodName); 
  }
}

This method takes the payload byte array, converts it to a character array, loads it into the jsonParser, and extracts the methodName from the payload before calling the setBrewMode function, which [fires off a number of actions based on the mode string](http://(https://github.com/bsatrom/brew-buddy/blob/master/brew-buddy-firmware/src/brew-buddy-firmware.ino#L365).

With MQTT in place, I was able to turn my electric io dashboard into a control panel!

Sending Messages from Electric IO to a Particle-powered project

Electric Io provides a Button type that makes it easy to call functions and send messages. Just select “button” in the Card Type dropdown and click “create.”

Creating a new button card in electric io

Once you’ve created a button, you’ll need to choose the call type. If calling a Direct method on an Azure IoT device, you’ll want to specify the methodName and an optional payload. For a message, which is what I used, there’s no methodName, but you’ll want to specify a payload. In the example below, I define a payload of {‘methodName’: ‘brew’} to tell my device to move into brewing mode.

Defining the button call type and payload

After saving button settings, the card will change into just a title and button. To test, I can just click away!

Triggering a C2D Message with electric io

And if everything was configured on the firmware side correctly, I’ll see my device respond to the inbound message from Azure IoT!

Brewing begins when the message is received!

What’s next?

As an endless tinkerer, I’ll never claim that a project is done, but I feel pretty good about where this project is in terms of being on new Particle hardware and leveraging a sweet, cloud-based control panel.

I suppose the next logical step is to brew some beer!

If you’re interested in seeing the nitty-gritty as I assembled my custom PCB and built out the Azure IoT Hub integration with MQTT, you can check out the live stream replays below. I stream my IoT builds on Mondays and Thursdays on Twitch, so be sure to follow and join me for more Particle-powered fun!

The post How to build a control panel for your Particle-powered brewing projects appeared first on Particle Blog.

Building IoT Firmware with Azure Pipelines and Particle

Brandon Satrom — Tue, 19 Mar 2019 16:11:29 +0000

TL;DR With Azure Pipelines and the Particle CLI, it's easy to create pipelines to automatically build IoT device firmware, release binaries, and even run automated tests!

Ever have one of those hobby projects that keeps coming up again and again? You get inspired to start, frantically work on it for a while, then set it aside because life and work happen.

Or maybe you get spooked by the thing and slowly (or quickly) back away?

Why is the cat scared of the banana? Maybe he just went Keto.

I know that feeling of dread, especially when it comes to hobby projects.

And yet, there are some that never truly go away. You ruminate on them. You tinker with them a little every once in a while. You keep adding features to your wishlist. The inspiration (or fear) never truly fades, and some part of you just knows that you'll finish that thing one day.

One such project for me is the Brew Buddy. A Particle-powered homebrew monitoring rig that I started over three years ago. I started the project with the Particle Photon, an Adafruit TFT, and a K Type Thermocouple breakout from Sparkfun. I created my own PCBs on my Othermill before getting real PCBs from OSH Park.

I even made a few hacky YouTube videos about the process.

I'm not going to link to those YouTube videos. You're welcome. You can find them if you look hard enough, but don't say I didn't warn you.

As happens, after a flurry of activity, I put this project on the shelf and moved onto other things. Testing each iteration of the Brew Buddy requires "real world" testing, and believe it or not, there actually is a limit to the amount of beer a human being can drink.

Late last year, Brew Buddy clawed its way back into my head. Shortly after Particle released their new 3rd generation devices, the Argon, Boron and Xenon, a little voice ever so softly and gently said "You know, that Argon would be great for Brew Buddy. And you can add those new features you've been thinking about."

Powerless to resist the lure of new hardware, I picked the project back up in January. I live streamed a lot of my initial work on my Twitch channel and published a post of the Photon to Argon port on the Particle blog.

I was sucked back in.

Enter Azure DevOps

One of the things I love about hardware projects is that they give me an excuse to explore related topics or concepts that I've been itching to try. The original Brew Buddy, for instance, was a gateway into PCB design, which has become a bit of an obsession for me over the last few years.

// Detect dark theme var iframe = document.getElementById('tweet-1013890175355752448-97'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1013890175355752448&theme=dark" }

For this refresh, I really wanted to explore the DevOps side of firmware/IoT development. I'd been hearing a lot of good things about Azure DevOps and the new Pipelines feature, so I decided to give it a try.

Using Azure Pipelines and the Particle CLI, I was able to quickly automate the process of building BrewBuddy firmware, and releasing binaries, when needed. Here's a quick overview of the steps I took to get this working.

1. Set up Azure DevOps

To use Azure Pipelines, you need an Azure DevOps account. Microsoft has extensive docs on this process and I won't repeat them here. Head on over to dev.azure.com to get yourself all set-up. You'll need to create an Azure DevOps organization before creating a project, and a GitHub account so you can connect your Pipeline to a relevant repository.

2. Create your first pipeline

With an Azure DevOps organization created, you're ready to create your first Pipeline. If you're just exploring Pipelines, Microsoft has some quick-starts you can clone to try everything out.

When you create a pipeline, you'll be given two options for authoring: creating the pipeline definition in YAML, or through a visual editor. There are pros and cons to each. I opted for the YAML approach so that I could version the build process in my Brew Buddy repo.

If you're ready to roll on a real project, the first step is to select a source repo for your pipelines, which can be a repo in GitHub or Azure repos.

The next step is to choose a repository and then select a starter configuration. There are a ton of options here, so you should find something that works with what you're building.

Since I'm building a firmware project, you might think I chose the C/C++ with GCC option. Not so! While I could do that, I wanted to do cloud builds with the npm-based Particle CLI, which means I don't need to install a local GCC toolchain, even in my build environment. Instead, I picked the Node.js option, which gave me a nice pre-configured YAML file ready to be customized.

3. Set-up Triggers and define a VM Pool

The default pipeline will have a few things pre-defined for you, including a single trigger and pool. Triggers define when to run the build pipeline and pools specify in which types of virtual environments you want the pipeline to run. Here are the tweaks I made for my build.



trigger:
- master
- feature/*

pool:
  vmImage: 'macOS-10.13'

By default, builds will trigger on all branches. I changed this slightly to build on both master and any feature/ branches I create.

For the VM pool, I am building with macOS because this closely mirrors my development environment. The Particle CLI is supported across Windows, Mac and Linux, so I didn't really need to change this, but I couldn't resist. We live in a world where Microsoft provides automated build services on macOS in Azure. What a time to be alive.

4. Use Steps to facilitate dependency installation, builds, and more

In Azure Pipelines, Steps make the bulk of a job. Every pipeline can define one or more steps to install dependencies, run scripts, build artifacts, run tests, and more. For the purposes of this project, there are five steps I needed to take to get from sources to a firmware binary.

Install Node.js

First, I need to install Node.js. The template includes this task, but I tweaked it to include Node.js 9.x.



- task: NodeTool@0
  inputs:
    versionSpec: '9.x'
  displayName: 'Install Node.js'

Install the Particle CLI

With Node.js (and npm) installed, the next step is to globally install the Particle CLI.



- script: |
    npm install -g particle-cli
  displayName: 'Install the Particle CLI'

Login to the Particle CLI

The Particle CLI can perform cloud-based firmware builds, but one must be logged into one's Particle account in order to use this feature. I have an account and credentials that can be used by the pipeline for this job, but I wanted to specify those credentials in a secure manner (as opposed to committing my username and password to source). Thankfully, Azure Pipelines provides support for variables via a Library for every pipeline. I created a group called particle-secrets and added PARTICLE_USERNAME and PARTICLE_PASSWORD variables with the appropriate credentials.

To use variable groups, I can a reference to the group at the top of my YAML.



variables:
- group: particle-secrets

Which allows me to reference those variables in the particle login command.



- script: |
    particle login --username $(PARTICLE_USERNAME) --password $(PARTICLE_PASSWORD)
  displayName: 'Login to Particle CLI'

Build a firmware binary using the Particle CLI

Once logged in, I can use the particle compile command to build a binary that targets the Particle Argon and version 0.9.0 of the Device OS firmware.



- script: |
    particle compile argon --target 0.9.0 brew-buddy-firmware --saveTo brewBuddy.argon.bin
  displayName: 'Build Firmware'

Copy the firmware binary to a staging directory

With a binary in hand, I'll copy the .bin file into a staging directly. This allows me to pick up the binary for the last task.



- task: CopyFiles@2
  inputs:
    sourceFolder: '$(Build.SourcesDirectory)'
    contents: 'brewBuddy.argon.bin'
    targetFolder: '$(Build.ArtifactStagingDirectory)'

5. Create a GitHub release when merging to master

The steps above run on every check-in and against all my branches to ensure that I can always build firmware and breaking changes aren't committed to my project.

I do all of my development in feature/ branches, and while I want to continually run builds, I only want to release new firmware when a feature branch is merged to master. Using the condition statement, I can specify that I only want to run the release task if all prior steps are successful and the source branch is master.



# GitHub Release
- task: GithubRelease@0 
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
  displayName: 'Create GitHub Release'      
  inputs:
    gitHubConnection: bsatromBB
    repositoryName: bsatrom/brew-buddy
    tagSource: manual
    tag: $(Build.BuildNumber) 
    assets: $(Build.ArtifactStagingDirectory)/*.bin

As a part of this final task, the assets input will grab my firmware binary and include it as a part of the release.

6. Run the Pipeline!

With the pipeline in place, the next step it to run it, which can you can do via a check-in, or trigger manually in the DevOps portal. After a few (dozen) tweaks, I was pleased to see rows and rows of green in my builds.

And, every PR merged to master results in a new release with an auto-generated change list and a shiny new binary.

My full pipeline YAML is available in the Brew Buddy GitHub repo

What's next?

My experience with Azure Pipelines has been smooth so far. I had a few fits and starts with creating variable groups and getting the GitHub release task right, but no more than one would expect when using a new, unfamiliar service. I've been running the above pipeline for a couple of weeks, and it has been a great addition to my workflow.

Of course, as a constant tinkerer, there's much more I want to do. Now that I have automated firmware builds, why not use the Particle CLI to do an over-the-air (OTA) firmware update to a dedicated device? After that, why not run automated integration tests using Particle Variables, Functions and Pub/Sub primitives?

If all goes well, I'll check back in with another post on that phase of the project in a few weeks.

Or maybe I'll get distracted by something else.

To follow my progress on the BrewBuddy and other Particle-powered IoT projects, be sure to follow me on Twitch and join me for live streaming fun on Mondays and Thursdays!

bsatrom / brew-buddy

hardware, firmware and software projects for the Brew Buddy Project

Brew Buddy

Source for the BrewBuddy project. Contains sources for board hardware/layout, firmware and a 3d printed enclosure.

View on GitHub

Upcycling an old homebrewing project with a Particle Argon

Brandon Satrom — Mon, 04 Mar 2019 18:24:59 +0000

New 3rd generation Particle hardware is here, and there’s a lot to love. I have an old, Photon-based project that I’ve been itching to update and add a few new features to, so I decided to see just how easy it would be to migrate a Photon-based project to the new Argon, hardware, firmware and all.

In addition to this post, you can also go behind the scenes with this build in a series of Twitch live streams I’ve recorded and posted to YouTube over the last several weeks. Here’s the first video in the series.

Introducing the Brew Buddy

I’m a home brewer, which is no surprise given that I live in Austin, TX. Not only is homebrewing common in these parts, but every Austin area household must have at least one homebrewer in order to claim city residence.

That last statement is not true, but it should be.

I’ve been homebrewing for about eight years, and I’m drawn to it for the same reason many are: not so much for the end product but the process and chemistry of it all. As with cooking and baking, it’s fascinating to take discrete ingredients and—by alchemy—transform them into something enjoyable.

Current Brew Buddy Specs

As a techie and maker, it should come as no surprise that I’ve explored ways to incorporate technology into my brewing. One example is the Brew Buddy, a connected homebrew monitoring system that tracks wort—the pre-beer mixture of water, grains, malt, and hops — temperatures during the cooking stage of the brewing process. The current version of the project includes:

A Particle Photon as the brains of the project
One Type-K Thermocouple for measuring wort temperature
A 2.2 in TFT display for showing temperature readings and a historical temperature graph
A custom PCB designed in Eagle and fabricated by the fine folks at OSH Park

The original Brew Buddy build used a Photon with custom PCB.

The Photon powers and orchestrates the board, while also publishing temperature readings to the Particle cloud so that I can visualize trends from one brew to the next.

Brew Buddy began — as these things typically do — on a breadboard. Once my design was set, I CNC milled a few PCB revs (my first custom PCBs ever!) and when I was satisfied, contracted a PCB manufacturer for production. That was nearly four years ago, and Brew Buddy is ready for an upgrade.

Various iterations of the Brew Buddy custom PCB that I’ve used over the years.

I had a few ideas for things to add to the project, like a piezo-based knock sensor to detect when fermentation begins. Particle’s new 3rd generation hardware was the perfect motivation to add those features, design a new board, and explore just how easy it would be to port my project from the Photon to the Argon.

Spoiler alert: it was so easy! Like hitting that giant red office supply chain button easy.

Breadboarding a new prototype

Prototyping an Argon-powered Brew Buddy began with a breadboard and jumper wires.

With any new hardware project, even when updating or swapping out components or MCUs, I like to start with a rats nest of jumper wires a breadboard prototype. This an essential step in making sure that I’ve wired everything correctly before taking the time and expense to design and order a board.

As a bonus, the tangled mess of wires plugged into tiny, nearly invisible slots serves as a pleasant reminder of my ever-increasing age as I squint darkly between wires and try to get everything in the right place.

Also, turning a mess of wires into copper traces under the solder mask is pretty amazing. It evokes the same feeling like the things in that Monday.com commercial that I find myself not skipping every time I go to YouTube to watch a video about how to beat my kids at Super Smash Bros.

My approach to Brew Buddy hardware migration

For the Brew Buddy migration, there were two steps to my breadboard prototype:

Map the existing components (the TFT and Thermocouple) to new pins on the Argon
Add new connections for the SD Card on the TFT (so I can display bitmaps on the screen) and a thin piezo to function as a “knock sensor.”

All-told, I ended up using 11 GPIO pins on the Argon, up from 9 on the Photon and this was just to get to features packed into the project. There was a bit of trial and error when adding the new features, but I was able to get my prototype up and running in just a few hours.

Porting the firmware

Images showing the difference between the Photon and Argon source code changes — only three lines needed an update.

With the breadboard prototype all wired up, it was time to port the firmware. I expected that this would consist of three tasks:

Update pin-mappings from the Photon to the Argon.
Update firmware libraries I used, if needed.
Add libraries and new firmware for the knock sensor and displaying Images on the TFT.

Going into this stage, I wasn’t sure how long each step would take, especially the first two. I was confident that Device OS would ensure that the changes needed between boards would be minimal, but I had no idea what “minimal” would entail.

Your migration may vary…

And with the caveat that YMMV depending on the features and libraries that you’re using for an older project, I was pleasantly surprised to find that, in order to get my existing Photon-based project running on the Argon, I had to change a grand total of THREE lines of code. And all three were GPIO pin mappings for the thermocouple. You can see the diff here if you want proof.

Testing the Argon-powered Brew Buddy firmware.

The majority of the work was on the physical pin-mapping side as I was setting up the prototype. Since both the TFT and Thermocouple are SPI devices, I needed to make sure the jumper wires were connected to the Argon’s SPI pins (A6-A8) instead of A3-A5 for the Photon.

On the firmware libraries front, everything “just worked.” When I first started this project, I was manually including libraries for the TFT and Thermocouple, so my only real step here was adding references to the libraries in my project.properties file and removing the library source files from my project. Everything compiled on the first try, and I was off to add new features.

With the new features, I had a bit more work. The piezo is a simple analog sensor and was easy to add to my project. After a bit of trial and error, I was able to calibrate it to detect light movements for fermentation, and I even added Particle’s new sleep mode support so that my device can go offline during the 24-48 hours after cooking is done and wake up when the first sign of fermentation is detected.

const uint8_t KNOCK_PIN = A4; 

int setBrewMode(String command) 
{
  if (command == "brew" && !isBrewingMode) 
  { 
    // Start brewing 
  } 
  else if (command == "ferment") 
  { 
    isBrewingMode = false; 
    isFermentationMode = true; 
    fermentationModeStartTime = millis();

    clearScreen();
    tft.setCursor(0, 140);
    printSubheadingLine("Waiting for");
    printSubheadingLine("Fermentation...");

    System.sleep(KNOCK_PIN, CHANGE);

    return 1;
  } 
  else if (command == "stop") 
  { 
    // Stop
  } 

  return 0; 
}

void loop()
{ 
  if (isFermentationMode)
  { 
    int16_t knockVal = analogRead(KNOCK_PIN) / 16;

    if (knockVal >= 6) 
    { 
      if (!isFermenting)
      { 
        isFermenting = true;
        fermentationStartTime = millis();
        lastKnock = fermentationStartTime;

        clearScreen();
        tft.setCursor(0, 10);
        tft.setTextColor(ILI9341_YELLOW);
        tft.setTextSize(2);
        tft.print("Fermentation started"); 
        tft.setTextColor(ILI9341_WHITE); 

        displayFermentationHeading();

        waitUntil(Particle.connected); 
        Particle.publish("fermentation/state", "start");
      }
    }
  } 
  else if (isBrewingMode)
  { 
    // Brewing mode logic
  }
}

Brew Buddy now with bitmap support

Adding bitmaps to the TFT was a bit more complicated, and included porting the Adafruit_ImageReader library into the Particle Ecosystem (which is public, so please use it!). With a new library in hand, however, it was just a few more lines of code to get a nice fancy image on the splash screen of my project.

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST); 
Adafruit_ImageReader reader; 
SdFat sd; 

void setup()
{
  tft.begin(TFT_SPEED);

  if (!sd.begin(SD_CS))
  {
    sd.initErrorHalt();
  } 

  printSplash();
} 

void printSplash() 
{
  ImageReturnCode stat; 
  tft.setRotation(2);

  clearScreen();

  stat = reader.drawBMP("brew.bmp", tft, sd, 0, 0);

  delay(2000); tft.setCursor(0, 40); 
  printHeadingTextLine("BrewBuddy"); 
  printHeadingTextLine(APP_VERSION);
  printSubheadingLine("Created by"); 
  printSubheadingLine("Brandon Satrom");
  delay(3000);
}

What’s next?

I’m pleased to say that, so far, this Photon to Argon port has been a success! With minimal changes to firmware, I was able to take an older project, refresh it, and start adding new functionality.

And of course, a new working prototype means an excuse to spin a new board and add some cloud-based visualizations of my brews! Stay tuned for part two of this post, where I’ll share the rest of this project and the results of a test brew!

In the meantime, I’m streaming nearly every step of this project live on Twitch on Tuesdays and Thursdays. Be sure to follow me there, and click the links below for replays of the initial few streams:

See you in a few weeks!

The post Upcycling an old homebrewing project with a Particle Argon appeared first on Particle Blog.