Forem: Particle

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.

Build this Wi-Fi thermometer for your workshop using a Gen 3 Argon and a Grove Starter Kit

Jordy Moors — Fri, 14 Jun 2019 13:00:30 +0000

In this tutorial, you’ll make a simple Wi-Fi thermometer using the Particle Argon and the Grove Starter Kit for Particle Mesh. The goal is to measure the current temperature, display that value on a display, and an RGB LED to give a visual warning if the temperature crosses a predefined threshold. Thanks to the ease of use of the Grove system, this should be an accessible project even if you’re just starting out.

Required hardware

In order to follow along with this guide, you’ll need the following items.

(1) Particle Argon — this project assumes you’ve set up your Argon. If you’ve not done that yet, follow the instructions here before you begin this project.
(1) Grove Starter Kit for Particle Mesh — the kit comes with a number of different sensors. This project will use the follow parts from the kit:
- (1) Grove shield for Particle Mesh
- (1) temperature and humidity sensor
- (1) chainable RGB LED V2
- (1) 4-digit display
- (3) Grove wires

Hardware assembly

Assembly of the project requires zero soldering. In my build, I got a bit fancy and decided to repurpose the Grove kit box as an enclosure. I won’t cover the exact steps to build the enclosure, but will say that when you work with cardboard, measure twice and cut with several passes of your cutting tool.

Connect your Grove sensors

I used the box from my Grove kit as an enclosure. Just add tape and a bit of patience.

The main step in this project is to connect all the sensors to the Grove FeatherWing. Building with the Grove system is quick and efficient. Plus, each of the Grove wires are notched with a small piece of plastic, so it’s physically impossible to connect the Grove cables the wrong way. Here’s a chart for the connections I used in the project.

Grove FeatherWing port	Sensor
D2	4-digit display
A2	Temperature & Humidity sensor
UART	RGB LED

Finally, add your Argon to the Grove FeatherWing and seat it snuggly. That’s it, all done with the physical build. Let’s get to the code.

Add code and you’ll be monitoring ambient temperature in no time

Even though assembling the hardware was rather trivial, your project won’t do much until you add code. Luckily, flashing your Argon isn’t overly complicated either. To make things even more streamlined, you can use existing firmware libraries for the Grove sensors and actuators, so you don’t have to start from scratch. Libraries are a great method to abstract away much of the code complexity. And by using the right libraries, you’ll basically only have to tie together the functions you want to use in your project, and add your own program logic.

Additionally, by clicking on this link, you’ll be taken to the Particle Web IDE with all of the code preloaded for you. All you’ll need to do is to duplicate the project.

Highlights from the code

While it’s convenient to duplicate the code and call the project done, it’s worth looking at some of the sections of the program logic to understand what’s is being run on your Argon.

Pre-setup: library includes and variable definitions

At the beginning of the code, you will see #include and #define declarations that specify the libraries used in the project and your pin configuration that is used for each sensor.

#include "Seeed_DHT11.h"
#include "TM1637.h"
#include "Grove_ChainableLED.h"
#define DHTPIN A2     // Temp&Humi pin
#define CLK D2    // 4-Digit Display pins
#define DIO D3    
DHT dht(DHTPIN);    // Temp/&Humi object
TM1637 tm1637(CLK,DIO);    // 4-Digit Display object
ChainableLED leds(RX, TX, 1);     // LED object with respective pins

Getting your code in order with the `Setup()` function

The setup function is used to initialise your libraries and configure their objects with settings that you’ll use later on in your code.

void setup()
{
tm1637.init();    // initialize Display library
tm1637.set(BRIGHTEST);    // BRIGHT_TYPICAL = 2,BRIGHT_DARKEST = 0,BRIGHTEST = 7;
tm1637.point(POINT_ON);    // Enable 'decimal' points
leds.init();    // initialize LED library
dht.begin();    // initialize DHT library
}

Understanding the main code `loop()`

In a sketch, the loop() function is run continuously. So this is the section of the code where you want to put the main program logic of your project. At a high level, loop() polls data from the sensors, processes the data, and outputs it in an actionable way. Let’s dive in.

Measuring the temperature and humidity

The main data for this project comes from the temperature and humidity sensor attached to A2. The first thing to do is to verify that the sensor data valid. Should there be any invalid data, the code will use the Serial.println() to output, “Failed to read from DHT11 sensor!” and exit the the loop() function.

//Read Humidity
float h = dht.getHumidity();

// Read temperature as Celsius
float t = dht.getTempCelcius();

// Read temperature as Farenheit
float f = dht.getTempFarenheit();

// Check if any reads failed
if (isnan(h) || isnan(t) || isnan(f))
{
Serial.println("Failed to read from DHT11 sensor!");
return;
}

Processing the temperature and humidity measurements

If the data is valid, you’ll move on and separate the temperature data out in to individual numbers so they can be displayed on the 4-Digit display.

// Separate the temperature to individual numbers to be used on the display.
int int_number = f * 100.0; // Two digits after decimal are kept. Turn the number into integer
int digits[10];             //Just in case I have 8 digits before decimal 
for (byte i=0; i<10; i++)
{
    digits[i]  = int_number % 10;
    if (int_number == 0) 
        break;
    int_number /= 10;
}

// display the numbers on the display
tm1637.display(0,digits[3]);
tm1637.display(1,digits[2]);
tm1637.display(2,digits[1]);
tm1637.display(3,digits[0]);

Outputting the temperature and humidity readings

Up next, you’ll take the data you collected and push it out. Using both a serial connection as well as a Particle.publish() makes sure you can read it locally and remotely, respectively.

// Print the measured values over a Serial connection
Serial.print("Temp: ");
Serial.print(f);
Serial.println("*F ");
Serial.println();
Serial.println();

// Publis the temperature to the Cloud using Server Sent Events (SSE)
Particle.publish("tempF", String(f));

Changing the RGB LED color based on the temperature

When the temperature exceeds 75.0F, the RGB LED illuminates in red. This is handled in the logic of the loop() function.

The last bit of code is to control the color of the LED based on the current temperature. For this to work, the code uses conditional statements to evaluate if the current temperature is above or below 75F. If the temperature is above 75F, the RGB LED will turn red. If the temp is below that, the LED will illuminate blue. You can tweak the temperature thresholds simply by altering the 75.0 in the code. Try it out for yourself. You’ll need to reflash your Argon to see your new code in action.

/ Temperature warning. Over 75F -> red. Under 75F -> Cyan.
if (f > 75.0){
leds.setColorRGB(0, 255, 0, 0); // red
}
if (f < 75.0){
leds.setColorRGB(0, 0, 0, 255); // cyan
}
delay(1000);

The last line of this snippet is not to be overlooked. The line delay(1000) slows the execution of the loop() function down by 1000ms. I added this so the code doesn’t exceed the Particle.publish rate limit. Also, the sensor can’t read faster than 1000ms anyhow, so there’s no advantage in excluding the loop delay.

Know the temperature even when you’re not in the room with `Particle.publish()`

Provided you’ve followed the instructions correctly, you should now have a working thermometer with a local display. Thanks to the Particle.publish however, you can also see that temperature remotely by going to the Particle Console and selecting the device on the my devices tab or by checking the Events tab (where you will be able to see publishes from all your devices at once).

Customizing this project to suite your needs

Particle-powered conference room temperature monitor deployed in a conference room.

Now you’ve got your project broadcasting data to the internet, you can take that data and act upon it. For inspiration, take a look at Hackster for some inspirational projects and ideas for how you can extend this project. For example, you could use an IFTTT recipe for Particle to automate an email to send when the room temperature exceeds your predefined max.

Be sure that however you modify this project, you share your work in the Particle forum and tweet your project photos at us.

The post Build this Wi-Fi thermometer for your workshop using a Gen 3 Argon and a Grove Starter Kit appeared first on Particle Blog.

Exploring & Understanding Our Connected World: A new contest from Particle on Hackster

Joe Quinn — Fri, 17 May 2019 18:48:42 +0000

The Internet of Things has given us a chance to explore the world around us like never before. From smart scooters on city streets to connected devices that track weather patterns in the heart of Central America, we’re learning more and more all over the world through the power of IoT. Now, with our 3rd generation of IoT hardware, powered by Particle Mesh, being used far and wide, we have a chance to learn and discover even more.

That’s why we’re thrilled to launch our latest contest on Hackster: Exploring & Understanding Our Connected World.

Here’s all you need to know

Scoot over to our contest page on Hackster to register and pitch your project no later than June 3, 2019 to enter for a chance to win free hardware to kick your work into gear. We’ll be awarding an Argon Kit to the first 50 people to register high quality projects — so don’t wait to submit!
Make sure your project aligns with the contest rules and uses at least one device from our 3rd Generation of IoT hardware.
Now it’s time to get building! Make some magic, document all of your work and get your project submitted by the completion deadline: July 21, 2019.
Our judges will look over the submissions and choose winners no later than July 26, 2019.

Gimme the Loot

We’ll be awarding prizes for the best projects that address issues in three distinct categories: cities, the environment, and device fleets. While you can submit your project to more than one category, you’re only able to win one prize from this contest.

Speaking of winning, we’re handing out seven fantastic prizes! Drones, campaign gear, electric scooters and more.

So what are you waiting for? Get started on your project today.

The post Exploring & Understanding Our Connected World: A new contest from Particle on Hackster appeared first on Particle Blog.

Learn how-to build this cellular asset tracker with a Particle Boron

Jordy Moors — Fri, 17 May 2019 18:00:32 +0000

At some point in your life, you’ve probably been in a situation where you wished you could use a cellular asset tracker to help keep tabs on your stuff. Where you parked the car at a concert, the actual location of that package you ordered three weeks ago, or the whereabouts of that scooter you that’s been helping get you that last mile to work, knowing where the things you care about in life is a valuable thing.

While there might be some generic solutions available, I’m going to show you how to build an all-purpose cellular asset tracker, with features that you can quikcly adapt to suit your specific needs. To build this tracker, the project uses FeatherWing accessory boards from the Adafruit Feather system to allow you to easily customize the project by swapping out different sensors or actuators — no jumper-wires necessary.

This project will be a relatively simple cellular asset tracking solution, but it’s a great base to customize to your needs. It starts with a Particle Boron as the brains of the build. The Boron queries location data from an attached GPS module and displays the coordinates on a small OLED display. All three of the FeatherWing compatible devices attach together using a FeatherWing Tripler, and means zero wiring is required. And since there are hundreds of FeatherWings, you can easily expand the functionality just by swapping out a Wing and modifying your code.

Note : If you’re unfamiliar with GPS and other geolocation technologies used in IoT, the Ultimate Guide to Geolocation can help. Learn what every IoT engineer needs to know about GPS, dead reckoning, cellular, Wi-Fi, and BLE all in one place.

Project parts & tools

Required parts:

Particle Boron — this project assumes you’ve set up your Boron. If you’ve not done that yet, follow the instructions here before you begin this project.
Particle FeatherWing Tripler
Adafruit FeatherWing OLED
Adafruit Ultimate GPS FeatherWing

Optional, but highly recommended parts

CR1220 3V lithium coin cell battery — used with the GPS module to keep the real-time clock (RTC) powered and allow warm starts.
SMA-to-uFL RF adapter cable — Most GPS antennas use an SMA connector, but most boards use smaller uFL connectors. This cable lets you connect them together.
GPS antenna — A bigger, more powerful antenna that will get you a better satellite fix more quickly.

Tools

Soldering equipment is needed to connect some of the headers to the FeatherWings and Tripler board.

Note: You’ll most likely also want an enclosure of some kind. In this project, we’ve used a custom laser cut enclosure, but you could 3D print something, or go with an off the shelf solution just as easily. You can download my design files here.

Hardware assembly

Step 1. Soldering the headers

Some of the FeatherWings in this project will require you to solder the header pins to the boards. To keep the headers square to the board. Place them in a spare breadboard, with the board you want to add pins to on top. This will help you’ll get proper alignment as well as it’s a lot more convenient to solder with the parts firmly in place.

You’ll need to solder the headers onto the Adafruit OLED FeatherWing.

The FeatherWing Tripler uses female headers, but you can use a similar trick as you used with the breadboard. Place the female headers over their respective pins on one of the other FeatherWings, and then place them in the Tripler on top to solder. That way the headers will all line up correctly, and it’s a lot easier to solder.

Attention: make sure you solder the Tripler correctly, or you risk damaging your boards.

Soldering the Tripler can be done without helping hands, but a steady hand is requited.

Step 2. Assembling your FeatherWings

With the soldering out of the way, you can move on to assembling the project. FeatherWing placement matters. In order to ensure access to the battery port on the Boron, you must place it on the right-hand side of the Tripler. In the middle comes the OLED Feather, and the GPS Wing will be on the left side.

Note: If you don’t use this ordering, you’ll have trouble routing the antenna and battery cables.

At this point, you can carefully attach the antennas to their respective connectors — make sure you use the cellular connector on the top side — and plug in the battery to the Boron.

Step 3. Laser-cut your enclosure or build your own

If you’ve made or purchased an enclosure, you can start fitting the project in there now.

Navigating the Boron asset tracker source code

The code for this project is kept relatively simple, so it can easily be customized to suit your individual needs. The code makes use of the TinyGPS++ library to abstract the hard parts of dealing with GPS data and gives you easy to use functions to extract the data you need. That way, you don’t have to reinvent the wheel and go through the hassle of dealing with raw GPS data.

In a bird’s eye view, the code loops to see if there is GPS data available and hands it to the tinyGPS library for parsing if so. It then checks whether the data coming out is sensible. When that’s not the case, it will give an error output on the display, informing you a fix hasn’t been found. If the data does make sense, it will package it in a nice format and will display the GPS coordinates on the display. That’s also where you could make changes to the information that gets displayed.

Finally, the code will publish a message to the cloud with the GPS information, which can be acted upon on that end using webhooks, or other integrations.

Click here to load the code in your WebIDE — no extra typing required.

If you’re not using the Web IDE share link, make sure to manually include the TinyGPS++ and the oled-wing-adafruit libraries.

Code highlights and commentary

The code for this project is all open source, but I wanted to quickly highlight a few of the most important sections to help give you ideas for where you can modify to suit your needs. Take special note of the line numbers as I’m covering snippets of code below.

The following code will run in a continuous loop, checking to see if new GPS information is available. If there is new data, it will call the displayInfo() function to start processing.

void loop()
{
    display.loop();
    while (Serial1.available() > 0) {
        if (gps.encode(Serial1.read())) {
            displayInfo();
        }
    }
}

The code shown below is taken from the displayInfo() function.

After getting the GPS data and making sure it’s valid, the information is packed into a buffer and displayed on the OLED.

display.clearDisplay();
display.setTextSize(2);
display.setTextColor(WHITE);
display.setCursor(0,0);
snprintf(buf, sizeof(buf), "%f", gps.location.lat());
display.println(buf);
snprintf(buf, sizeof(buf), "%f", gps.location.lng());
display.println(buf);
display.display();

Up next, the code packages the data in new buffers so it has a nice format for output over Serial.

snprintf(buf, sizeof(buf), "%f,%f,%f", gps.location.lat(), gps.location.lng(), gps.altitude.meters()); // Format for Serial logging

Finally, there’s a check to see if we’re not publishing too often. If that’s not the case, then publish the data to the cloud.

if (Particle.connected()) {
    if (millis() - lastPublish >= PUBLISH_PERIOD) {
        lastPublish = millis();
        Particle.publish("gps", pubbuf, PRIVATE);
    }
}

Visualizing your data with Ubidots

To take this project a step further than displaying the coordinates on the OLED, you can send the data to an online platform to display it on a map. There are various services available that offer functionality like this, such as the Particle Google Maps integration.

For this tutorial, I chose to use Ubidots. They offer a great service for ingesting data and plotting it on a map. Plus it’s easy to integrate. You can get the data to them by using a webhook in the Console, and a specific Particle.publish() on the device.

First, create an account on Ubidots. For Ubidots to accept the data as a GPS location, it will look for a specific format in the data it receives. It expects to find a JSON object containing a lat and lng key, with their respective values.

On the device:

To get the data in the format Ubidots expects it, you’ll have to add some bits to the code. The key lines to look at here are line 71 and 86, which create and fill a buffer for Ubidots.

char pubbuf[120];
if (gps.location.isValid() && gps.location.age() < MAX_GPS_AGE_MS) {
    display.clearDisplay();
    display.setTextSize(2);
    display.setTextColor(WHITE);
    display.setCursor(0,0);
    snprintf(buf, sizeof(buf), "%f", gps.location.lat());
    display.println(buf);
    snprintf(buf, sizeof(buf), "%f", gps.location.lng());
    display.println(buf);
    display.display();
    snprintf(buf, sizeof(buf), "%f,%f,%f", gps.location.lat(), gps.location.lng(), gps.altitude.meters());
    snprintf(pubbuf, sizeof(pubbuf), "{\"position\": {\"value\":1, \"context\":{\"lat\": \"%f\", \"lng\": \"%f\"}}}", gps.location.lat(), gps.location.lng());

Create a new buffer to store the Ubidots formatted data in. Then, fill that buffer with the JSON content and the GPS data. Finally, Publish that buffer as a Particle.publish().

In the console:

To get the published data to Ubidots, you can use their API. To do so, you’ll have to create a webhook. Go to the Console, and find the integrations tab on the left. Create a new integration and select a webhook. In the top left, find and select the custom template option. Copy and paste in the following snippet.

{
    "event": "gps",
    "url": "https://industrial.api.ubidots.com/api/v1.6/devices/{{{PARTICLE_DEVICE_ID}}}",
    "requestType": "POST",
    "noDefaults": false,
    "rejectUnauthorized": true,
    "headers": {
        "X-Auth-Token": "replace-this-with-your-token",
        "Content-Type": "application/json"
    },
    "body": "{{{PARTICLE_EVENT_VALUE}}}"
}

Make sure to replace the highlighted X-Auth-Token with your own. You can find said token by going to your Ubidots account, clicking on your profile icon and selecting API credentials.

After you've successfully completed each of the steps, you should now have a functioning cellular asset tracker that will display its GPS coordinates on the screen, as well as publish them to the cloud, where you can work with them in different ways to serve your purpose.

Where will you take you take your asset tracker?

Starting with this project, you can use it as the basis of a car tracking system, a geofence for your pets or kids, track shipping containers or do something as mundane as making internet connected scooters. The possibilities are certainly there and so are the basics to start from.

Take a look over at Hackster to get inspiration for projects you could build next. Additionally, share your thoughts and ideas on our Particle forum, where you can brainstorm and get project advice. It’s also a great place to ask questions, with many of our members being eager to help out.

Now go forth and track something that matters to you.

The post Learn how-to build this cellular asset tracker with a Particle Boron 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.

What every IoT engineer needs to know about navigation: GPS, dead reckoning, cellular, Wi-Fi, and BLE

David Scheltema — Wed, 15 May 2019 21:18:31 +0000

Personal navigation has never been easier. With numerous options from GPS and cellular to Wi-Fi and Bluetooth, it can be challenging to select the right one for your product be it micromobility scooter or a fleet of logging trucks. To understand which solution is right for you, it’s helpful to have a high-level perspective on the most popular and widespread geolocation technologies.

Most geolocation solutions should start with GPS since it’s a system designed from the start to answer the question, where am I? With close to ~4-meter accuracy, it’s a no brainer to start any navigation solution here, unless of course, your use-case is underground.

Unsurprisingly, no single navigation solution is right for every product use-case or fleet deployment. What works for a micromobility scooter — a combination of GPS, cellular, and Bluetooth — would be an over-engineered solution to keep track of your keys. For that, something like Bluetooth beacons are more appropriate.

This guide will provide you with information about commonly radio technology used for navigation. After reading, you should be familiar with the different available technologies as well as a high-level awareness of the significant trade-offs between the options. In many cases, the best solution is a robust combination of technologies.

Navigation options at a glance

Determining the right option for your geolocation needs is a balancing act between the cost of the silicon and the accuracy of the location data it provides. Battery life is not covered in this overview, however, it’s good to keep in mind that the number of times you send location data from your device to the cloud will affect your battery performance. Additionally, specific radio power performance will vary by vendor and part.

GPS — The Global Positioning System (GPS) is generally the most accurate, and it can provide device location continuously. This option is moderate to high priced depending on features such as onboard RTKs. It is widely used used as the basis for any geolocation solution.

Cellular — Cellular geolocation uses known cell tower location to approximate where you are. Of course, cellular requires an active service plan and proximity to cellular towers. Cellular is predominately used as a supplement to GPS, as it lacks the accuracy to be an independent solution.

Wi-Fi — Wi-Fi is not advisable for use-cases that move a lot, but is commonly found in smartphones and laptops as a way to supplement location data or give approximate location inside of buildings using 3rd party databases of Wi-Fi access point locations.

Bluetooth 5/BLE — Great for small tracking devices such as key fobs and assets in a contained, small location. Typically deployments use a mobile phone in conjunction with Bluetooth beacons that broadcast location information.

Getting started: Weighing cost vs accuracy with GPS

Unless your use-case is subterranean, your navigation solution should begin with GPS. Thanks to smartphones, the cost of GPS modules is lower than it’s ever been, but that means there are a lot of module options to consider for your design. A helpful way to cut through the options is by balancing between unit cost and location accuracy.

As a general rule of thumb as GPS accuracy increases, so too does the cost. Inexpensive GPS modules can be purchased for under $40 and typically support UART or I2C depending on the module. More expensive, featureful GPS modules can run upwards of $200, but offer advanced capabilities like onboard RTKs. However, there’s also a bit of a middle ground. To supplement the accuracy of GPS, it’s not uncommon to see silicon vendors and product designers add additional hardware or using software to help gain higher accuracy.

Using cellular plus geofencing for robust geolocation

Cellular is typically a medium for voice and data, but you can also use it to determine approximate location. Note that a cellular-only navigation system will only provide you with your location relative to the towers your cellular device is communicating with. For more in-depth information on cellular, please see our cellular guide in the Particle docs.

Every cell tower has an identifier, and this can be looked up using Google’s Geolocation API to find where it is on the globe. This process is fast and provides a general location, usually within 4,000 meters or a couple of miles. Of course, you need a cellular signal for this to happen.

Pairing cellular connectivity with GPS-based geofencing provides a solid solution for IoT deployments that may go in and out of hard to reach places such as lumber trucks across the state of South Carolina. Particle’s customer Worthwhile combines these two technologies to provide a more robust navigation solution. Using a Particle cellular solution their open-source Geo-Bound software caches up to 2,000 GPS coordinates locally in their asset trackers memory and stores them until back in cellular range. While cellular here is not used for the navigation per se, the combinational approach of cellular plus GPS highlights a robust geolocation solution.

Improving GPS accuracy with IMU-based dead reckoning

In some situations, GPS alone cannot provide a full navigation solution. Take a fleet of scooters for example. In big cities they don’t always have a clear line of sight to the sky for GPS to work efficiently — gaining a lock on satellites takes time and consumes power, both challenging in urban environments.

By augmenting a GPS module with additional geolocational data and using techniques like dead reckoning — a navigation technique that uses information about your past position, speed, duration, and heading to calculate where you currently are — a fleet for scooters can still be found even if they can’t see the sky.

Developers use dead reckoning to supplement GPS data and help with error correction. To cost effective achieve dead reckoning, it’s not uncommon to see prototypers add an inertial measurement unit (IMU), a specialized sensor that’s packaged in a single integrated circuit, to collect information about the heading and speed information as a supplement the available GPS coordinates.

Dead reckoning works best with micromobility, specifically when tracking mobile assets around an urban area, with inexpensive non-GPS navigation devices, and it’s very accessible for DIY robotics projects.

While alone, an IMU-based dead reckoning solution isn’t recommended for high-value asset tracking, supplementing a GPS with an IMU can result in a more robust geolocation solution.

Dead reckoning in silicon: high-end GPS modules with built-in real-time kinematic engines

Land surveying and autopilot systems use GPS that include real-time kinematic engines (RTK) that perform dead reckoning inside the GPS module and boast centimeter accuracy. No extra ICs required. One example of such a module is the ublox NEO-M8P-2, which SparkFun offers in a sub-$200 breakout board.

The only problem is GPS modules with RTKs is the cost. Single quantity pricing for GPS modules with integrated RTK run upwards of $200 per unit, making them too expensive for most use-cases. Unless you’re building a centimeter accurate navigation solution like surveying a building site or autonomously assisting an autopilot system, using a GPS with RTK is over-engineering your solution.

As you can probably guess, due to the higher per unit cost, GPS modules with on-die RTKs are almost non-existent in micromobility markets, but more common in industries small measurements matter. For those undeterred by the unit price, Sparkfun electronics has an excellent primer on GPS with RTK, which also covers more advanced navigation techniques such as error correction using Radio Technical Commission for Maritime.

Wi-Fi provides supplemental navigation

Smartphones are a fantastic example of Wi-Fi supplementing other radios for geolocation. You’ve probably experienced your smartphone reminding you to turn on WI-Fi to help improve your location accuracy.

Wi-Fi assisted navigation works by using special 3rd-party API service such as Google’s Geolocation API that provides access to an enormous database of Wi-Fi access point locations. Given the scale of their enterprise and given enough data points of Wi-FI APs, the information is helpful for indoor navigation.

Problems with using Wi-Fi for navigation

One enormous challenge with using Wi-Fi as a navigational aid is that as soon as you move out of range of a Wi-Fi access point, your access to the Wi-Fi location database is lost. Smartphones do a fantastic job of obscuring this limitation since they have cellular, GPS, and Wi-Fi that work seamlessly together and require near-zero user configuration.

Much like cellular, it’s not uncommon to see early prototype projects attempting to combine Wi-Fi with an IMU to approximate a navigation system. These systems are architecturally similar to cellular plus IMU approach, but with one major drawback: limited range bound by Wi-Fi signal coverage. Without a Wi-Fi signal, there is no way for the device to connect to a cloud for dashboards, fleet management, or even access the geolocation APIs.

Don’t combine cellular and Wi-Fi to navigate unless you absolutely must

Some might think to add cellular and have a Wi-Fi and cellular solution, however, unless you’re making a smartphone, this is not an advisable approach to navigation. Adding a second radio interface such as cellular means you effectively double your power draw, increased bill of materials cost, your software integration time and rigor, and your antenna design just got a lot more complicated. Instead, a navigation solution that combines GPS with Wi-Fi is a much more appropriate path.

Bluetooth navigation handles the small stuff like finding your keys

Geolocation isn’t just about getting you from your home to office. In some use-cases, it’s about finding your misplaced keys. With a limited range of 10 meters, Bluetooth is great for helping you track down things you know are nearby but needs some help finding.

Increasingly Bluetooth 5 based devices featuring ICs like the Nordic nRF82540 found in all Particle 3rd Gen devices are used for key-finding solutions. Of particular interest to designers is the improved and descriptively named Bluetooth broadcast and beacon modes. These allow for information-rich interactions between non-paired Bluetooth devices.

For example, imagine a rideshare bike that could broadcast its battery state directly to the customer. No need to send data to the cloud, simply use a beacon mode to advertise to the rideshare app the charge level. For more on the use of Bluetooth in navigation, please see the Bluetooth SIG documentation here.

Navigating your way to the right solution for your use-case

Ultimately, the best way to understand each of these technologies is with hands-on experience. As you’ve learned, the most reliable geolocation and navigation solutions use a robust combination of radio technologies. For your own prototyping journey using a Gen 3 Particle device with an Adafruit Ultimate GPS FeatherWing is a great place to start. From there, it’s very easy to transition to an enterprise-grade module like our B Series SoM for scale.

For more on how Particle solutions can help with your geolocation and navigation products see our product suite overview or contact us and talk with an expert.

The post What every IoT engineer needs to know about navigation: GPS, dead reckoning, cellular, Wi-Fi, and BLE appeared first on Particle Blog.

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.

Particle Workbench: supercharge your IoT development with professional tools

David Scheltema — Tue, 16 Apr 2019 15:45:42 +0000

Particle Workbench brings everything you need for IoT development into a single tool. Built on Microsoft Visual Studio Code, Workbench adds Particle-specific integrations to help make you more productive. This our most powerful, professional IoT development environment yet and starting today, it’s now generally available with our custom, cross-platform Particle installer with support for Windows, Linux (Ubuntu), and macOS — download your copy right now.

Code faster, work more efficiently, compile where you want, and say goodbye to the frustration of toolchain management. Particle Workbench includes these features right out of the box with a hassle-free installation.

Compile where you want: local or cloud
Stress-free toolchain management
Built-in version control and debugging
Flexible deployment: over-the-wire or over-the-air
Code complete with IntelliSense for Particle device libraries
Quick installation experience for Windows, Linux, and macOS

Download now and supercharge your IoT development here.

Professional tools to support your product development

When your job is to build connected solutions, it’s essential to use professional tools to help you along the way. Workbench builds upon all the great features you already love about Particle and adds even more powerful, professional tools to help you succeed.

Take for example Workbench support for cloud and local compilation. You decide where your code is built, but that’s just the beginning. Thanks to a powerful Dependency Manager, your toolchain automatically stays up-to-date no matter the compile location you choose.

Native support for git and debugging, giving you the ability to collaborate with colleagues and more efficiently troubleshoot bugs. And flexible deployment options mean you can use over-the-wire or over-the-air device flashing depending on your project requirements.

Open source, customized for you

Under the hood, Workbench takes advantage of all the great features you already know and love about Visual Studio Code and adds powerful, Particle specific capabilities.

Workbench is built on Visual Studio Code not just because it’s the experience developers love for a desktop environment, but also because of Microsoft’s commitment to open source. Visual Studio Code enables an ecosystem of customizable themes and extensions all with continued investment in powerful features that support both embedded and web development.

Get started with Workbench now

Whether you’ve tried a Workbench Developer Preview or this is your first time using the tools, the new installer is quick and doesn’t require a deep understanding of cross-compilers or development toolchains. Installation takes a few clicks of the mouse before you’ll be coding.

The installer is smart enough to check your system to determine if you have Visual Studio Code installed or not and knows what to install without any need for user action. Because of this, the installer is safe to use if you already have Visual Studio Code on your machine.

Download Particle Workbench here, dive into the docs, and let us know what you think in the community forum.

The post Particle Workbench: supercharge your IoT development with professional tools 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.

Take your IoT career to new heights with these 3 instructive IoT video playlists

David Scheltema — Mon, 25 Mar 2019 21:10:50 +0000

I might not bring the intensity quite like Steve Ballmer famously did while chanting “Developers! Developers! Developers!” during the Microsoft 25 Anniversary Celebration in 2000, but that doesn’t mean I’m not super excited for great IoT videos for developers.

Whether you consume your videos at work or watch them with a big tub of popcorn from the comfort of your home, you can’t go wrong learning about new technical topics from instructive IoT videos. Here are three new Particle videos series that you’ll not want to miss.

Particle 101: the video series designed to help you become an IoT pro

Over the past few months, Brandon Satrom our Developer Advocate has been busy putting together a series of videos covering the essentials to help you get the most out of your Particle products. Most of the videos in the series focus on Gen 3 hardware — that’s the Argon, Boron, and Xenon — however many of the non-mesh content is applicable to Gen 2 hardware like the Photon and Electron as well.

In the latest Particle 101 video, Brandon tackles how you can use publish() and subscribe() to send messages between different devices on your local, mesh network. This video is one of seven (at the time of publication) Particle 101 videos to help you get started with IoT and Particle. Here’s the link to the full Particle 101 playlist.

Introducing Particle: Interviews with the people building Particle

Equal parts Terry Gross and Steve Ballmer, Brandon’s newest video series focuses on getting to know the people powering Particle. Get ready for great conversations and tune in live for a chance to have your question answered.

In the first episode of the series, Brandon sat down with Mohit Bhoite to talk circuits, rapid prototyping, and what it feels like to have designed every piece of Particle hardware ever released. Mohit’s interest span from low-level electrical engineering to gorgeous solder sculptures that should rightly be called art.

Twitching for more videos: here’s a live solution

A typical Twitch streaming setup from Brandon. Catch him weekly on Monday and Thursday.

And if you’re still looking for more video content, Brandon has you covered. Each Monday and Thursday he livestreams on Twitch. While you never know exactly what Brandon will be working on, his livestream is a fantastic way to get clues on what cool new things are coming next.

Most recently, Brandon upcycled an old Photon DIY brewing project to use an Argon and hacked inexpensive Drug Store remote controlled cars to use Particle Gen 3 hardware — you can see his full instructions in the annual Make: magazine board’s issue here. Here’s a quick link to the start of the brewing playlist and to the R/C car hacking.

IoT Developers, IoT Developers, IoT Developers!

Whew, it does feel good! Perhaps Ballmer was onto something here. Regardless of your intensity level, be sure to watch the videos and let us know what you think. Comments, suggestions, and constructive criticism are always welcome. Oh, and don’t miss the next Particle livestream.

Finally, be sure to share what you’re working on in the community forum or on Twitter. I can’t wait to see what you’re making.

The post Take your IoT career to new heights with these 3 instructive IoT video playlists appeared first on Particle Blog.

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.

How to Select the Right IoT Hardware: From Prototype to Production

Jeffrey — Mon, 23 Jul 2018 11:06:01 +0000

A comprehensive guide that explores the difference between IoT development kits, MPM kits, and mass production modules

IoT development boards and modules are at the center of every connected product. As IoT has developed, the variety and technical capabilities of these boards has only become more complex. When building an IoT product, you’ll want to start with a simple prototyping kit, but as you progress through the hardware development and design process, you’ll need to invest in hardware boards that are designed for scaling and manufacturing.

But what is the difference between prototyping and production hardware? This article aims to clean up some of the noise and make it easier for you to choose the right hardware solution for your IoT product.

What is the difference between prototyping and production hardware?

In general, you can easily differentiate between prototype and production hardware based on these features:

Prototyping hardware is optimized for:

Flexibility — usually breadboardable and has an open SIM card slot
Affordability — low cost
Modularity — compatibility with other hardware ecosystems
Ease of use — can be setup in minutes and comes with tools
Beginner audiences — content and examples optimized for beginners

Mass production hardware is optimized for:

Reliability — Has SMT(surface-mount-technology) components, can withstand extreme temperatures, and comes with hardware warranties
Manufacturability — pick and place machine ready
High volumes — Can be purchased in bulk via a reliable distribution partner
Ease of integration — should have complete product certifications
Advanced audiences — comprehensive datasheets and application notes

Prototype & production hardware examples

For instance, Particle produces three basic kinds of hardware — Development kits (DKs), Evaluation kits (EVKs), and Mass production modules (MPMs). These are defined below:

Development kits (DKs)

Development kits are breadboard friendly and optimized for expandability, modularity, and ease-of-use. As a result, they can be used for scaling depending on the use case and application, but maybe best used as short term PoCs in friendly environments.

Intended use — Useful for iterating/prototyping hardware and firmware systems quickly. It provides a quick start solution and gets an IoT project rolling.
Features — USB connectivity, ecosystem of hardware accessories, breadboard-able headers, RGB status LED, on-board antenna, affordable costs
Audience — Hobbyist developers, engineers very new to hardware
Examples — Argon, Boron

Mass production modules (MPMs)

Mass production modules are optimized for deployment in a mass production product, not for development. These are the real deal, intended for deployment for 5–10 years in hostile environments and small spaces. These products have little utility until they are soldered into your end product.

Intended use — Deployment in a mass production product
Features — Certifications, hardware warranty and support, environmental robustness, optimized for size and manufacturability
Audience — Companies manufacturing products at scale
Examples — P0 / P1 / E Series MPMs

MPM evaluation kits (EVKs)

MPM Evaluation kits are expansion boards for mass production modules and allow you to develop, iterate, and debug your IoT solution quickly and easily. In other words, they provide a friendlier development experience for mass production hardware solutions. They have a MPM soldered to them, and in many ways can act as a good reference design.

Intended use — Companies designing a product for deployment at scale, companies iterating from DKs to MPMs. Useful for iterating and refining production firmware in the context of production hardware (MPMs).
Features — Largest number of GPIO and peripherals, large/comfortable debugging-optimized board layout, application notes and professional documentation
Audience — Professional engineers who are comfortable designing custom circuit boards, companies with intentions to deploy at scale
Example — E Series Evaluation Kit

Other factors to consider when choosing IoT hardware

When you’re sourcing hardware for prototyping or production, you should also look at the platform, tools, and support that comes with it:

1. Consistent platform, infrastructure, firmware, and development tools

You’ll want to continue using the same cloud infrastructure and development tools as you scale. Switching between different hardware designs is enough of a task, you don’t want to carry this over to the software you are using. The same firmware application, when compiled on your DKs and MPMs, should perform exactly the same way. There should never be a need to tweak or modify the firmware application to get it running on a MPM.

2. Domain experts & support

When selecting a hardware-solution, it’s also important to consider the community surrounding it. Hardware solutions with limited adoption will have fewer resources available to aid you in development. For example, Particle’s development kits have a large developer community surrounding it, which makes it easier to find information and support when needed.

3. Ease of deployment

You want to be able to get your product up and running as quickly as possible. When sourcing hardware, check the articles and documentation that comes with it. Having these resources at the ready will make it easy for you to get your questions answered immediately.

The bottom line

When sourcing prototyping and production hardware, you want to examine its accessibility, affordability, integrations, and manufacturing features. Whether you’re prototyping or building a scalable IoT product, you want to choose hardware that offers a consistent platform environment and ease-of-deployment.

Forem: Particle

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

Materials needed

How does mesh networking work?

Hacking the Thunder Tumbler

Understanding the various onboard ICs

Setting up a mesh network

Programming the tumblers

Programming the mesh gateway

Putting it all together

Command your swarm!

Code for the follower robots

Hack It and Share It

Build this Wi-Fi thermometer for your workshop using a Gen 3 Argon and a Grove Starter Kit

Required hardware

Hardware assembly

Connect your Grove sensors

Add code and you’ll be monitoring ambient temperature in no time

Highlights from the code

Pre-setup: library includes and variable definitions

Getting your code in order with the Setup() function

Understanding the main code loop()

Measuring the temperature and humidity

Processing the temperature and humidity measurements

Outputting the temperature and humidity readings

Changing the RGB LED color based on the temperature

Know the temperature even when you’re not in the room with Particle.publish()

Customizing this project to suite your needs

Exploring & Understanding Our Connected World: A new contest from Particle on Hackster

Here’s all you need to know

Gimme the Loot

Learn how-to build this cellular asset tracker with a Particle Boron

Project parts & tools

Hardware assembly

Step 1. Soldering the headers

Step 2. Assembling your FeatherWings

Step 3. Laser-cut your enclosure or build your own

Navigating the Boron asset tracker source code

Code highlights and commentary

Visualizing your data with Ubidots

On the device:

In the console:

Where will you take you take your asset tracker?

Get up to speed with Particle Variable and Function Primitives

What every IoT engineer needs to know about navigation: GPS, dead reckoning, cellular, Wi-Fi, and BLE

Navigation options at a glance

Getting started: Weighing cost vs accuracy with GPS

Using cellular plus geofencing for robust geolocation

Improving GPS accuracy with IMU-based dead reckoning

Dead reckoning in silicon: high-end GPS modules with built-in real-time kinematic engines

Wi-Fi provides supplemental navigation

Problems with using Wi-Fi for navigation

Don’t combine cellular and Wi-Fi to navigate unless you absolutely must

Bluetooth navigation handles the small stuff like finding your keys

Navigating your way to the right solution for your use-case

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

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

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

Debugging with Particle Workbench: Easy like the browser dev tools

Workbench Debugging Basics

Starting a Debug Session

Setting Breakpoints

Stepping through code

Inspecting variables

Watching values

Navigating the call stack

Advanced Debugging Features

Additional Tips and Tricks

Particle Workbench: supercharge your IoT development with professional tools

Professional tools to support your product development

Open source, customized for you

Get started with Workbench now

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

Designing a new PCB with Eagle and OSH park

Creating PCBs in Autodesk Eagle

Ordering PCBs from OSH Park

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

Using MQTT to listen for Azure IoT Hub Messages

Sending Messages from Electric IO to a Particle-powered project

What’s next?

Getting your code in order with the `Setup()` function

Understanding the main code `loop()`

Know the temperature even when you’re not in the room with `Particle.publish()`