We recently had the pleasure of Jen being in the 'Meet the Maker' article of HackSpace magazine, where everything from starting the business to the latest client work is covered.

We may be biased but it's certainly worth a read, so pickup the latest September copy of HackSpace to check it out or alternatively read it online!

Recently at DefProc there's been a shift towards organising, a late 'spring clean' if you will. As more projects get taken on, more parts and bits appear around the office and there comes a point where you're hunting around for a particular thing and you realise that enough is enough!

So, with that in mind, Alex and Pat set out to organise all the stock using partsbox.io. For more information on how they went about it, a handy guide from partsbox themselves explains it perfectly.

Part of the new storage plan is labelling all the components with a custom printed label that contains the relevant information for us, including a QR code that when scanned responds with the partsbox URL for that particular part so you can immediately view all the information on it. The problem with this, and the Dymo label printer, is the software for it... isn't great. It's clunky to use and more importantly it's a hassle trying to get it to automate printing labels. Partsbox lets you download a CSV file containing all the information about the selected parts, so ideally we wanted a way to import the CSV and have the Dymo print out a label for each part, no fuss!

The software that comes with the printer does include a way to print from a CSV file, but it requires importing it and going through a wizard each time. By automating it we could save time on not selecting the correct paper-size and printer, going through a wizard and assigning data to label fields etc.

So lets discuss how we can automate our printing! Since August 2016, the Dymo Label Web Service is automatically installed along with the Dymo Label Software. Using this web service we can talk directly to the printer.

So first;

• Install the Dymo Label Software and Dymo Label Web Service.
• Save a copy of the Dymo JavaScript Framework.

You can check if you have the web service correctly installed by following this blog post from Dymo themselves. (Sadly this is for Mac and Windows only as Linux is not supported).

The SDK, SDK documentation and framework overview aren't great from Dymo and commonly are either outdated or don't work. The very few examples it gives for JavaScript aren't event complete. The one reference that does have some benefit is the documentation for the JavaScript framework we downloaded. With that in mind, we should be able to get this printing.

The first step is we need a layout for the label. This is the only time we have to open up and use the included software. Well, it's not required but it is easier if you don't fancy writing out all the layout XML yourself. Opening the 'Dymo Label v.8' and selecting a label type / size, you're ready to add the components you need.

One important step here is that each component of the label needs a reference name setting. This can usually be found by right clicking > properties > advanced. Here I would advise that you preface each of the reference names with a constant in case you need to search through the XML for adjustments. Additionally make a note of these as you'll need the reference names later.

After the layout is done save it somewhere safe so we can import it later and close down the Dymo software. From here we can start creating our process for printing the labels. As we're using the web service pack we're going to create a basic web page (styling can be saved for another day). On the page a user can import or drag a downloaded CSV file from partsbox and then upon clicking the print button the page prints a label for each part included in the CSV. No pop up menus, no selecting the right printer, no import wizards. Just plug and print!

Because the web page is talking to a locally plugged in printer, this won't work if hosted online (security issues). Instead I recommend having the web page hosted on GitLab and then if changes are made the user can pull the latest version before opening the page locally in their browser.

For the basic web page I created a single html file. At the top I imported Bootstrap for some very quick and easy styling (optional) and then imported two JavaScript files, the first being the download Dymo framework from earlier and the second being a custom JavaScript file where we will write our code to tie it all together.

<!DOCTYPE html>
<html>
  <head>
    <title>DefBox</title>
    <link rel="stylesheet" href="./assets/css/Bootstrap.min.css">

    <script src="./assets/js/jquery-3.4.1.min.js" type="text/javascript" charset="UTF-8"></script>
    <script src="./assets/js/bootstrap.bundle.min.js" type="text/javascript" charset="UTF-8"></script>
    <script src="./assets/js/DYMO.Label.Framework.latest.js" type="text/javascript" charset="UTF-8"></script>
    <script src="./assets/js/defbox.js" type="text/javascript" charset="UTF-8"></script>
  </head>

For the body, I used a Jumbotron from Bootstrap and after adding a title, subheading and logo it was mostly done in terms of layout and styling. I finished it off with a file input so we can get access to the CSV file with an id of partsbox_csv_file so we can access it later from the custom JavaScript, and a button with an on click call to CheckEnv(), our first function.

  <body>
    <div class="container">
      <div class="jumbotron">
        <div class="container">
          <div class="row">
            <div class="col-8">
                <h1 class="display-4">DefBox</h1>
                <p class="lead">This is a basic web app to print downloaded parts data from partsbox.io as labels.</p>
            </div>
            <div class="col-4">
                <img class="img-fluid" src="assets/img/dpeLogoBlack.png"/>
            </div>
          </div>
        </div>
        <hr class="my-4">
        <p>Drag the downloaded csv data here or select it with choose file.</p>
        <input class="btn btn-primary btn-lg" type="file" name="file" id="partsbox_csv_file"/>
      </div>
      <button type="button" class="btn btn-success btn-lg btn-block" onClick="CheckEnv()">Print Labels</button>
    </div>

    <div class="upload fs-upload-element fs-upload fs-light"></div>
  </body>
</html>

All of that gives us a simple but functional web page that does all we need it to.

With the web page done, we need to do the behind the scenes code to actually parse the CSV and tell the printer to create a label. One of the first things is define a global variable var df;. This is so we can attribute dymo.label.framework to it, due to it being used frequently, so this saves time and formats the code nicely.

Then, as mentioned earlier, the first function we set up is CheckEnv(). Here we check that there's a printer connected otherwise throw an alert to the user (quick albeit alerts aren't the nicest UX). If everything is okay then call the next function to get the CSV file input.

function CheckEnv() {
  df = dymo.label.framework;

  var printers = df.getPrinters();
  if (printers.length == 0) {
    alert("No DYMO printers are installed. Install DYMO printers.");
    return;
  }

  if (!printers[0].isConnected) {
    alert("DYMO printer is not connected.");
    return;
  }

  GetFileInput();
}

The second if to check if the printer is connected (assuming there's only one printer connected which we do throughout) might seem redundant compared to the first check but, upon testing, getPrinters() will be successful after first time it runs even if you unplug the printer. Checking isConnected on the printer actively checks the connection.

For getting the file input we can use FileReader. We read the uploaded file name using the partsbox_csv_file id, pass it into a FileReader, and the determine two functions for it. One for successfully reading the file and one for it throwing an error. Finally we have to actively start reading the file to get one of these functions to fire.

function GetFileInput() {
  // Read the 'uploaded' file name and pass into file reader
  var fileInput = document.getElementById("partsbox_csv_file").files[0];
  if (fileInput == undefined) {
    alert("No uploaded file detected.");
    return;
  }
  const reader = new FileReader();

  // Error function for reading the file
  reader.onerror = function(error) {
    console.log(error);
    alert("Error with uploaded file");
    return;
  };

  // Success function for reading the file
  reader.onload = function(event) {
    var csvString = event.target.result;
    var csvArray = ConvertCsvStringTo3dArray(csvString);
    GetDYMOPrinters(csvArray);
  };

  // Start reading the file
  reader.readAsText(fileInput);
}

On success, due to reading the file input as a string, we need to convert the string to an array we can use. This function initially splits the string by each newline (as each line in the CSV represents the info on one part from partsbox) and adds it to an array newLineArray. Then for each line in the array it;

• Removes the quotes at the start & end
• Splits it by each section into an array using split('","')
• Pushes it to csvArray

Finally, we remove the first element in the array as this contains the CSV headers, which we don't want to print.

function ConvertCsvStringTo3dArray(csvString) {
  // Split by newline to get each line of the csv in an array
  var newlineArray = csvString.split('\n');
  var csvArray = [];

  // Split each line into its individual components
  newlineArray.forEach(line => {
    if (line !== "") {
      // Remove the quotes on each end of the line
      contentLine = line.substring(1, line.length-1);
      splitLine = contentLine.split('","');
      csvArray.push(splitLine);
    }
  });

  // Remove the first line of csv headers
  csvArray.shift();
  return csvArray;
}

From here we setup what we need to print the label. This includes getting the printer and loading the label XML (as .label format). Then for each line in the CSV array we call the PrintLabel() function. Here we replace the label components (using the reference name we setup on each component earlier) with our CSV data before then creating the print settings, and firing off printLabel to send it to the Dymo printer.

function GetDYMOPrinters(csvArray) {
  // Get the first printer
  var printer = df.getPrinters()[0].modelName;

  // Load the label layout file
  var currentLoc = window.location.pathname;
  var currentDir = currentLoc.substring(0, currentLoc.lastIndexOf('/'));
  var labelDir = "/assets/layouts/LabelLayout.label";
  var labelUri = "file:///" + currentDir + labelDir;
  var label = df.openLabelFile(labelUri);

  // For each line in the csv, print a label
  csvArray.forEach(csvLine => {
    PrintLabel(label, csvLine, printer)
  });
}

function PrintLabel(label, labelInfo, printer) {
  // Replace the label objects with the CSV data
  // 0) Name 1) Description 2) Footprint 3) Manufacturer 4) MPN 5) Storage 6) Total Stock 7) URL 8) Meta-Parts
  console.log(labelInfo);
  label.setObjectText('PF_DESCRIPTION', labelInfo[1]);
  label.setObjectText('PF_MPN_BARCODE', labelInfo[4]);
  label.setObjectText('PF_PART_TITLE', labelInfo[0]);
  label.setObjectText('PF_MFN', labelInfo[3]);
  label.setObjectText('PF_LOCATION', labelInfo[5]);
  label.setObjectText('PF_QRCODE', labelInfo[7]);

  // Set the print options
  var labelXml = label.getLabelXml();
  var printQuality = df.LabelWriterPrintQuality.Auto;
  var paramsXml = df.createLabelWriterPrintParamsXml({ copies: 1, printQuality: printQuality});

  // Print
  df.printLabel(printer, paramsXml, labelXml);
}

If this is all done successfully, you should get a printed label (or a few) when running through the web page!

Every so often, I try to do some short projects that don't take too long, but let me learn something new. When the new Nerf Laser Ops range came out in September 2018, I had a pair of blasters on the first day — because they seemed to be using targeted infra-red signals and that looked very hackable.

I had an Adafruit Circuit Playground Express from some teaching classes that we'd been doing recently, and the onboard infra-red (IR) receiver and sender, plus the onboard RGB LEDs, looked like a nice way of duplicating the foam dart sensors but this time, for the new IR blasters.

While I'd been meaning to write this up for a while, Les Pounder's article in issue 14 of Hackspace Magazine (page 120) reminded me that I'd never actually published it! [Thanks Les!]

TL;DR

Without having to know the exact infra-red sending pattern that Nerf use for the Laser Ops series, the following hash values are enough to use IRLib2 on Arduino with the Hash Decoder functions to identify which colour team last "hit" the IR receiver with an Alphapoint blaster. It's not known if this works for the Deltaburst, as I don't have one to try at the time of writing.

/* IR hashes for Nerf LaserOps standard game */
static const long PURPLE = 0x67228B44;
static const long RED = 0x78653B0E;
static const long BLUE = 0x2FFEA610;

Receiving IR

While it would be entirely possible that Nerf/Hasbro would use a completely custom IR sending arrangement, most IR signals are sent by modulating the signal using a common frequency to prevent interference from other devices (eg. incandescent bulbs). The receiver then minuses the known frequency from the received signal, and the result comes out as a set of pulses of specific length.

A quick check by firing the blaster at a TV IR receiver I have that always lights up as long as it's receiving any signal, confirmed to me that the blaster uses the same IR hardware as every other common remote or IR device.

Then it was on to finding out the exact signal that the blasters use.

IRLib2

A quick google found Chris Young's IR library for Arduino, and it is especially suitable because it has example Arduino sketches to show the raw timing of incoming signals — useful in this case because (spoiler alert) the Nerf Laser Ops signal doesn't use TV manufacturer codes for the blasters.

The first order of business then is to see what the incoming signals actually look like.

By using a raw receiver example from the library that's lightly modified to match the pin assignments for the Circuit Playground Express (rawRecv) and starting the Alphapoint blaster as the purple team and firing at the IR sensor; the results look something like this:

#define RAW_DATA_LEN 36
uint16_t rawData[RAW_DATA_LEN]={
	2895, 5992, 2897, 2053, 841, 2059, 846, 2054,
	851, 2061, 824, 2076, 1817, 2108, 787, 2112,
	844, 2056, 838, 2062, 1863, 2062, 842, 2057,
	848, 2052, 843, 2057, 848, 2051, 843, 2070,
	825, 2074, 790, 1000};

In the raw results from the library, each number in the array indicates either the number of microseconds of a mark (signal high) or a space (signal low).

The stream starts with the length of the first mark (2895µs), followed by the length of the next space (5992µs). The sequence continues with alternating marks and spaces until the final recorded mark (790µs) and the sketch adds a trailing space of a set length (1000µs) to allow it to be used in another program without needing to worry about running into the start of the next sent signal.

Now, these results would be fine to just copy and paste into a sketch if we just wanted to resend these to another blaster, but with a little guess work, I figured it might be reasonable to make an educated guess to the structure of the message.

Decoding

The numbers from rawRecv are alternating mark & space times, in microseconds, so assuming some variation on the exact timings of the received signals, they are likely to actually be sent as a round number of microseconds. Eg.

uint16_t rawData[RAW_DATA_LEN]={
	3000, 6000, 3000, 2000, 800, 2000, 800, 2000,
	800, 2000, 800, 2000, 1800, 2000, 800, 2000,
	800, 2000, 800, 2000, 1800, 2000, 800, 2000,
	800, 2000, 800, 2000, 800, 2000, 800, 2000,
	800, 2000, 800, 1000};

And knowing that lots of signals start with a preamble to allow the receiver to identify the start of the signal, the rest starts to look a lot like two possible length marks that each follow a fixed length space.

If the preamble is:

• (mark)3000, (space)6000, (mark)3000

The rest of the message looks a lot more regular. And I'm guessing that the rest of the mark lengths will indicate either a binary 0 or 1. Assuming that zeros make up more of the message, that would suggest that after the preamble:

• (space)2000, (mark)800 is a 0, and
• (space)2000, (mark)1800 is a 1.

So this could be translated as:

uint16_t rawData[RAW_DATA_LEN]={
  3000, 6000, 3000, // preamble (3ms mark, 6ms space, 3ms mark)
  2000, 800, 2000, 800, 2000, 800, 2000, 800,  // 0, 0, 0, 0
  2000, 1800, 2000, 800, 2000, 800, 2000, 800, // 1, 0, 0, 0
  2000, 1800, 2000, 800, 2000, 800, 2000, 800, // 1, 0, 0, 0
  2000, 800, 2000, 800, 2000, 800, 2000, 800,  // 0, 0, 0, 0
  1000 // added by the sketch
};

I've broken these up in to 4 bits lines (a nybble), on a hunch. The position of those 1 bits suggests that there might be 4 fields of 4 bytes each, encoded with the least significant bit to the earliest bit (least significant bit to the left).

Running each of the colour in the same mode gives us some more information:

// PURPLE
#define RAW_DATA_LEN 36
uint16_t rawData[RAW_DATA_LEN]={
  2888, 5987, 2893,
  2058, 848, 2052, 843, 2069, 795, 2104, 791,  // 0, 0, 0, 0
  2109, 1816, 2109, 837, 2063, 842, 2057, 848, // 1, 0, 0, 0
  2052, 1873, 2055, 840, 2059, 846, 2054, 841, // 1, 0, 0, 0
  2071, 794, 2106, 789, 2111, 795, 2105, 841,  // 0, 0, 0, 0
  1000
};

// RED
#define RAW_DATA_LEN 36
uint16_t rawData[RAW_DATA_LEN]={
  2899, 5977, 2897,
  2065, 842, 2058, 849, 2051, 845, 2055, 842,  // 0, 0, 0, 0
  2058, 1869, 2056, 851, 2061, 826, 2074, 792, // 1, 0, 0, 0
  2108, 789, 2111, 836, 2064, 843, 2057, 840,  // 0, 0, 0, 0
  2060, 846, 2054, 843, 2057, 850, 2050, 847,  // 0, 0, 0, 0
  1000
};

// BLUE
#define RAW_DATA_LEN 36
uint16_t rawData[RAW_DATA_LEN]={
  2896, 5979, 2902,
  2060, 836, 2064, 843, 2057, 848, 2052, 844,  // 0, 0, 0, 0
  2055, 1870, 2055, 851, 2052, 844, 2065, 820, // 1, 0, 0, 0
  2080, 795, 2105, 1821, 2104, 792, 2111, 836, // 0, 1, 0, 0
  2063, 843, 2057, 838, 2062, 845, 2055, 840,  // 0, 0, 0, 0
  1000
};

While this doesn't give all the answers, it strongly suggests that the number of the ID for the team that sent the pulse is encoded in the third data line.

If I assume that it is nybbles with the least significant bit sent first:

Hash

While having this information is good, and sending identical codes back out of the Circuit Playground Express IR sender will "hit" a blaster of the appropriate team, there's not enough information yet to fully decode the signal, and because it's not a known encoding in the library, it would need specific decoder writing for the library to use.

But because, the library can only identify a limited set of "standard" IR patterns, it also includes a way of identifying any signal, even an unknown one by generating a 32 bit "hash" of the sequence. I've not looked to closely at the hash algorithm used, but it's designed to allow for the intrinsic timing jitter in the received IR signals and it's expected to be robust enough that repeated sends of the same message will always give the same hash.

Using the hashDecode sketch, the hash code will be printed on the serial monitor.

The values for each team I got are:

/* IR hashes for Nerf LaserOps standard game */
static const long PURPLE = 0x67228B44;
static const long RED    = 0x78653B0E;
static const long BLUE   = 0x2FFEA610;

And as we know the hashes, checking for these values specifically will allow identification of the team who's signal has been received:

if (myDecoder.value == PURPLE) {
  // indicate Purple on the LEDs...
}

I've already created an example sketch that uses these hashes, and lights up the LEDs on the Circuit Playground, depending on the incoming signal. As with the other sketches, I've included a UF2 file, that can just be downloaded, dragged and dropped onto the CPLAYBOOT drive to flash onto the Circuit Playground Express:

TODO

There's enough here to be able to identify incoming signals, and send replica signals out, so it's possible to create alternate game components that interact with the blasters.

Still outstanding questions include:

• What do the other fields in the IR signal relate to?
• Does the message change for other game types? Especially, does an ID for each blaster get included in games using the app for scoring?
• Does the Deltaburst signal change to indicate its "double shot" mode?
• What's the best approach to write an IRLib2 library file for decoding these signals?

Welcome The Things Conference UK workshop participants, and others on the internet. This workshop guide is designed to let you start from very simple beginnings, and take you through creating a simple temperature sensor that sends data at regular intervals through to The Things Network via LoRaWAN.

You will need:

• A computer with the Arduino software installed,
• A Things Uno (or similar), Arduino compatible board with a LoRaWAN modem attached. The Things Uno comes with a USB cable to connect to the computer, otherwise you may need your own.
• A DS18B20 One-Wire Temperature sensor to connect to the arduino
• A 4.7k resistor is recommended for power stability for the One-Wire sensor..
• A small breadboard to connect all the components into.
• 3 jumper wires, one red, one black, and one another colour of your choice (yellow in this guide). Ensure that they're long enough to reach beween the Arduino ports around the side, and the breadboard you're using.
• To be in an area with LoRaWAN coverage from The Things Network (if you're at The Things Conference UK, you will have plenty of coverage!).

Circuit construction

With the arduino software installed, and the all the parts available, place the DS18B20 temperature sensor into the breadboard.

Connect the 4.7k resistor between pin 2 and pin 3 of the temperature sensor.

Connect a red jumper wire to pin 3, a black jumper wire to pin 1, and the other jumper wire (pictured in yellow) to pin 2.

Pin 1 is Ground on the temperature sensor, so connect the other end of the black wire to a GND port on the Things Uno.

Pin 2 is the Data line on the temperature sensor, so connect the yellow jumper wire to Digital pin 6 on the Things Uno.

Pin 3 is the power line on the temperature sensor, so connect the red wire to the 5V port on the Things Uno.

Installing the Software and libraries

Install the Arduino IDE if it isn't already, and open a new window.

Then install the following Arduino libraries in the IDE from the top menu, by following: Sketch → Include Library → Manage Libraries → The Things Network → install and typing each library name into the serch box. Click install for each choice before repeating with the next.

• The Thing Network
• OneWire
• DallasTemperature

Then you're ready to start programming.

Connecting to The Things Network

Because each device on LoRaWAN needs to be authenticated with the service and application that we will be sending to, you will need to know the unique ID number of the device that you're using now - its DeviceEUI.

To get your device to report the radio ID, copy and paste the following in to a new Arduino sketch, and upload to the board.

#include <TheThingsNetwork.h>
#define lora Serial1

#define debugSerial Serial
#define loraSerial lora

TheThingsNetwork ttn(loraSerial, Serial, TTN_FP_EU868);

void setup()
{
  debugSerial.begin(115200);
  loraSerial.begin(57600);
  delay(1000);
}   

void loop()
{
   debugSerial.println("Device Information");
   debugSerial.println();
   ttn.showStatus();
   debugSerial.println();
   debugSerial.println("Use the EUI to register the device for OTAA");
   debugSerial.println("-------------------------------------------");
   debugSerial.println();
   delay(10000);
}

Ensure the board is set to be an Arduino Leonardo (from Tools → Board), and the port is set correctly once the Things Uno board is plugged in (from Tools → Port, select the Arduino in the list).

Once uploaded, open the serial monitor (click the magnifying glass in the top right of the Arduino IDE window). Check that the baud rate (from the drop down box in the bottom right of the serial monitor window) is set to 115200. Then the device EUI should be printed out in the window.

Then create a TTN application and register your device:

• Make an account on The Things Network,
• go to the TTN console
• select applications and + add application
• Set
  • Description (a name to describe the application to yourself later),
  • Handler registration to ttn-handler-eu
• From your application page, + register device
  • Device ID (a name to describe this device to yourself later),
  • Device EUI (copy and paste from the serial monitor),

Test the LoRaWAN connection

Before adding the temperature sensor, the sketch below will send a single value to over LoRaWAN that you can watch on the TTN Console connetion to verify that your device is actually making a connection to The Things Network.

In a new sketch window, copy and paste the following code:

#include <TheThingsNetwork.h>

// Set your AppEUI and AppKey
const char *appEui = "0000000000000000"; // replace with your `App EUI`
const char *appKey = "00000000000000000000000000000000"; // replace with your `App Key`

#define lora Serial1
#define debugSerial Serial
#define loraSerial lora

TheThingsNetwork ttn(loraSerial, Serial, TTN_FP_EU868);

void setup()
{
   debugSerial.begin(115200);
   loraSerial.begin(57600);

   // Wait a maximum of 10s for Serial Monitor
   while (!debugSerial && millis() < 10000);

   debugSerial.println("-- STATUS");
   ttn.showStatus();

   debugSerial.println("-- JOIN");
   ttn.join(appEui, appKey);
}

void loop()
{
   debugSerial.println("-- LOOP");

   // Prepare payload of 1 byte to indicate LED status
   byte payload[1];
   payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;

   // Send it off
   ttn.sendBytes(payload, sizeof(payload));

   delay(10000);
}

To make this device send data to your new application, and not anyone else's, you will need to change the two lines to match your own device setting for the application:

const char *appEui = "0000000000000000";
const char *appKey = "00000000000000000000000000000000";

Each application has a unique appEui, and each device on each application has a unique appKey. These are used to authenticate and verify each device against its deviceEui when it performs its join request to the LoRaWAN network. If successful, these are also used derive the unique session keys that encrypt all the traffic sent from the device to TTN application.

This information is available from the TTN Console page for the chosen application. Follow Devices → [click on a device] → settings shows the AppEUI and AppKey. Copy and paste the values for the device you just created into the sketch, and upload to the board.

You can watch the data being sent on the serial monitor, and being received on the data tab of the TTN Console for your application.

Send Temperature

With the connection to the application confirmed, the next step is to send the readings from the temperature sensor, and set the TTN application to decode the values into JSON to make reading easier, and to allow them to be passed on to another service.

This example uses the Cayenne LPP format so it can be recreated back into a JSON objects without having to do any custom float to byte array translation or javascript re-building. You can also create your own encoding and decoding schemes dependent on your application requirements.

To decode each message when received in the TTN Console, set the Payload Formats to be CayenneLPP from the dropdown.

Copy and paste the following code in to a new Arduino sketch, changing the appEui and appKey to the same values as used in the previous sketch.

#include <TheThingsNetwork.h>
#include <CayenneLPP.h>
#include <OneWire.h>
#include <DallasTemperature.h>

// Set your AppEUI and AppKey
const char *appEui = "0000000000000000";
const char *appKey = "00000000000000000000000000000000";

// Data wire is plugged into port 6 on the Arduino
#define ONE_WIRE_BUS 6

#define lora Serial1
#define loraSerial lora
#define debugSerial Serial

TheThingsNetwork ttn(loraSerial, debugSerial, TTN_FP_EU868);
CayenneLPP lpp(51);

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);

// arrays to hold device address
DeviceAddress deviceAddress;

void setup()
{
   debugSerial.begin(115200);
   loraSerial.begin(57600);

   // Wait a maximum of 10s for Serial Monitor
   while (!debugSerial && millis() < 10000);

   // Get device address
   if (!sensors.getAddress(deviceAddress, 0)) Serial.println("Unable to find address for Device 0");

   // set the resolution to 9 bit (Each Dallas/Maxim device is capable of several different resolutions)
   sensors.setResolution(deviceAddress, 12);

   debugSerial.println("-- STATUS");
   ttn.showStatus();

   debugSerial.println("-- JOIN");
   ttn.join(appEui, appKey);
}

void loop()
{
   debugSerial.println("-- LOOP");

   // get the current temperature
   sensors.requestTemperatures();
   float degC = sensors.getTempC(deviceAddress);
   debugSerial.println(degC, 6);

   lpp.reset();
   lpp.addTemperature(1, degC);

   // Send it off
   ttn.sendBytes(lpp.getBuffer(), lpp.getSize());

   delay(30000);
}

New messages should appear in the applicaton, and the incoming data should show a "temperature_1": 00.0 in the processed payload. This then appears as a value:key pair in any JSON messages that are passed on to other services.

External Data

While there is a specific workshop during The Things Conference UK 2018 on this topic, there are some services that connect very easily to The Things Network, especially for dashboards. While the conference workshop with Dave Mee focusses on Node-Red, the myDevices Cayenne service (of CayenneLPP fame) is an easy first step, if ultimately less flexible.

Creating a myDevices Cayenne dashboard:

• Ensure the 'Payload Format' in the TTN application is set to 'CayenneLPP',
• create an account at myDevices Cayenne
• Add new → Devices & Wigets → LoRa (beta) → The Things Network → Cayenne LPP
• Enter the Device EUI from the TTN console,
• Back on the TTN console for the application → Applications → + add integration → choose Cayenne,
  • Enter a Process ID of your choice (anything),
  • Select an Access Key (one of the allowed MQTT passwords on the application to pass to Cayenne)
• new data from this device will automatically propogate to myDevices Cayenne, so entries for temperature, RSSI and SNR for this device will appear when it next sends.

Since our foundation five years ago, we at DefProc have always tried to be at the bleeding edge of new developments, both socially and in tech, so we’re delighted to announce that we have recently moved into new accommodation in the LJMU/UoL joint venture; Sensor City.

This brand new building right next to Liverpool’s main Lime Street Station is home to some awesome people as well as some very exciting machinery, both of which we hope to be able to utilise in our ongoing quest to design, create and manufacture the most interesting, fun and useful things we can. At this point, Patrick’s major concern is just how he’s going to find the time to fit in all the playing he wants to do around the work that needs to get done!

We’re really excited about this move, for a few reasons. Firstly, it means we have our own dedicated office space with lots of room for testing, building and other far less interesting things, and which we might even manage to avoid being taken over by boxes and NERF guns. Secondly, it’s helping us to meet some very cool people that we hope to be able to collaborate with on projects in the future. And thirdly, this extra space, coupled with the work that has made it both necessary and possible, means that we’ll be able to take on new staff to do some of the stuff that we just don’t find that interesting. Job creation makes us very happy.

Oh, and of course all the exciting machinery. You can never forget about the exciting machinery.

We’ve been lucky enough to work on some very interesting and challenging projects in the recent past, from developing low cost river level sensors for the Environment Agency, building a replica Minimum Wage Machine installation for FACT, to our current work tackling social isolation as part of the Liverpool 5G Health and Social Care Consortium, and we’re looking forward to continuing to do so here. Other than our address, the art on the walls and the plants on the bookshelves, nothing has changed - we’re still the same company with the same ethos, work ethic and stupendous abilities, and we will keep on developing and making the kind of kit that makes lives easier.

The opening of Sensor City is yet another step on the road towards Liverpool becoming THE place to be in the UK when it comes to technology, IoT and digital manufacturing, and we are really proud to be among its first residents. We’re just looking forward to the day the blue plaque bearing our names goes up outside.

Do have an idea for a product?

Do you have a proof of concept or prototype that you are developing but aren’t sure on the next steps?

We are offering free, friendly advice at our drop-in session at Liverpool Central Library from 5:30pm until 7:30pm on the second Tuesday of every second month.

Each session is 45 mins long and you can talk about your ideas in confidence and explore the possibilities for the next steps. Patrick, our Design Engineer, hosts these events and can offer you advice from quick and easy ways to get started creating your proof of concept to what the process is for getting your product ready for manufacture.

We have already helped a wide range of people through these sessions and are really enjoying being part of their process to realising their big ideas.

Sign up by emailing libraries.enquiries@liverpool.gov.uk, or take a look at the Eventbrite listing for the Business & IP Centre Liverpool.

Sometimes you have to use an Arduino UNO, instead of something more efficient like an Arduino Pro Mini — maybe you're using an Arduino shield…

Sometimes you have to run that same project from battery power, and every milliAmp counts…

Sometimes that means that you'll have to adjust the UNO to be much more power efficient, so you pick up a sharp scalpel, bring over the big loupe, and warm up the fine tipped soldering iron…

The post formed part of development work performed for the Environment Agency. It has been re-published here with their kind permission, as part of the project commitment to open source development.

The Arduino UNO is designed as a development board, instead of a specific low power device, it is built with several design choices that mean it uses more power that the minimum necessary.

TL;DR: To reduce the overall power usage of the Arduino UNO board significantly:

• replace the linear regulator with a DC-DC converter,
• adjust the USB-to-Serial circuit so it's only powered from the USB port,
• cut out (or desolder) the always-on LED's on the board,
• use the processor sleep mode.

Using on-board circuit changes, selective replacement of components and the use of microcontroller sleep mode can reduce the continuous idle power usage of an Arduino UNO to only 5% of the default draw.

Experimental Set Up

Current measurements were made using the blink sketch that forms part of the standard Arduino Optiboot bootloader. This ensures the results are comparable across any board, and may be tested on other controllers using the default sketch. Additionally, a blink sketch is available in the examples provided with the Arduino IDE, and can be loaded on to a board without any additional software libraries.

Current measurements were all made the same way, with the same equipment. A "µCurrent Gold" was inserted between the 12V supply and the DC jack on the Arduino UNO on the 12V line. The same DC supply was used for all tests, a PowerPax SW4298D 12V, 2A mains to DC supply.

The µCurrent Gold is a precision current adaptor converts the current measurement across a sense resistor and amplifies the voltage to provide very accurate measurements (±0.1%) with very low voltage drop on the input (20µV/mA) to minimise the supply change. The output signal is 1mV/mA, so it can be read manually as milliAmps with a multimeter on the milliVolts range.

Initial readings were taken over several cycles and averaged to give a single value, and values are given for both the built-in LED off and LED on condition during the LED blink sketch.

Table 1: Base Arduino Uno current measurement.

Voltage Regulator

The biggest power loss in the standard Arduino UNO board is from the voltage regulator that limits the input voltage to the DC input jack. The board uses a linear regulator, which dissipates any supply voltage above the target voltage as heat. With a 12V input, and a 5V output, around 58% of the input energy is lost, either dissipated as heat, or used for the internal supply of the regulator.

Changing the regulator for a more efficient "buck" converter will reduce the power losses — as DC-DC step-down converters can be as high as 92% efficient, depending on the specific usage.

Unfortunately there is no pin-equivalent buck converter that matches the SOT-223 footprint of the NCP1117 linear regulator used on the board; particularly as it has a non-standard regulator pin assignment (1. Ground, 2. Output, 3. Input). However a leaded DC-DC converter can be made to fit the available footprint.

The Traco TSRN-1-2450 is a 5V switching regulator with built in capacitors. As a pin compatible replacement, it can be used in place of 78xx series linear regulators with out requiring any external components. Efficiency of the switching regulator is up from the linear, with a typical 83% transmission of power, although this depends on supply voltage.

Although the Traco TSRN-1 is not a pin compatible replacement, by bending the legs, it can be placed on and soldered to the surface mount pads where the NCP1117 has been removed from.

Changing the regulator reduces the current usage of the board by 48%. Although this reduction may vary, as the efficiency of the regulator varies, depending on the current demands of any driven circuit.

Table 2: Replacing the linear regulator.

USB to Serial converter

In addition to the main ATmega328 microcontroller on the Arduino UNO board, there is also a USB-to-Serial converter chip, the ATmega16U2. This is a general purpose microcontroller with on-board USB capability that is programmed to act in this job.

Although the chip is suitable for use as a USB-to-Serial (UART) converter, no power saving measures are implemented on the chip, meaning that it remains in a full power idle when not being used. If the chip could be automatically powered down when not in use, this could significantly reduce the idle current draw of the whole board.

We decided not to investigate if the chip can be put into a low power mode via the firmware as updating the firmware on this chip requires a separate ISCP programmer and would not be as simple as uploading a new program to the main microcontroller via the Arduino IDE. Instead only hardware changes were investigated; though the restriction of maintaining functionality is required.

Like the main microcontroller, the UART chip is powered from the regulated 5V line, so it is powered from the USB line when only USB power is supplied, and is powered from the regulated DC input when present. A comparator and MOSFET perfect diode switch ensure only one source is selected.

From the Arduino UNO schematic, the ATmega16U2 (U3 on the board) is powered through pins 32 & 4 from the rectified 5V line. As this line is physically close to the USBVCC bus, the tracks on the PCB to pins 32 and 4 can be cut, and reconnected to USBVCC so the chip is only powered when voltage is present on the USB connection. Athough this is not a recommended power connection for the chip, as the USB supply voltage must be 5V ±0.2V, there should not be enough difference between the supply and any signal voltages to damage the chip.

First cut the 5V supply on the bottom of the board that supplies 5V to the 16U2 (to pin 32). This chip is a in a 32 pin package, where the pins are numbered anti-clockwise from the top left corner — indicated by a dot on the top of the package. The cut is made on a trace on the reverse, so the capacitor between pin 32 and ground is not separated from pin 32.

Pin 4 also needs to be separated from the 5V line, and can be done on the top layer of the board. At the same time, the track from pin 32 should be exposed along with an area of the track connected to pin 31, so pin 4 & 32 can be connected to the USBVCC line of pin 31.

Pin 4 & 32 can be connected back to pin 31 with a single jumper wire. By using 30AWG "wire wrap" solid core wire, cut to 13mm long with 2mm stripped back on each end and turned at 90 degrees in plane, the three connections can be made with one jumper wire.

Please note that just changing the supply source is not sufficient to completely remove the power usage from the chip. Because the RX and TX LEDs are connected to 5V and sink power through the ATmega16U2 when lit, removing power from the microcontroller means they will always be lit. The only choices then are to cut the traces to the LEDs or desolder them, so they cannot be used.

Changing the board so the UART converter is only powered from the USB connection — and therefore only uses power when the programming connection is made — reduces the power usage by 44.7%. This change does not affect the programming of the board; when a computer is connected by USB, the chip is powered by the computer only, and the main ATmega328 can be programmed by the Arduino IDE as normal (although resetting the board can now cause the USB port to be renumbered by a connected computer).

Table 3: Remove power to the ATmega16U2 UART converter.

Power LED

As the Arduino UNO is designed to be a development board, it has a continuous indicator that the board is powered using an always on LED. For low power usage, this continuous current drain is not required, but the LED can only be disabled by cutting a track on the PCB, or desoldering it from the board.

Table 4: Disconnect the power indicator LED to lower current by 7mA.

Combined

For the voltage regulator change, this is a largely geometric change, as the overall efficiency of voltage conversion is increased, although note that this is very non-linear. Total power reduction with all changes is 76.8%.

Table 5: Changing regulator, UART power and indicator LED.

Sleep mode

The power reduction from all three of the previous improvements is quite significant. The savings from the changes to the UART chip and power indicator LED both add up, as they are arithmetic reductions in the used power, as the components are no longer being powered by the source.

It is possible to make further savings though. Using all the above changes , and adding the lowest sleep mode for the ATmega328 micocontroller, the LED-off current usage of the board is reduced to 2.5mA, a 95% reduction compared to the standard board.

There are some great resources already for using sleep mode on the UNO. Here are some from my bookmarks:

• engblaze.com/hush-little-microprocessor-avr-and-arduino-sleep-mode-basics/
• nongnu.org/avr-libc/user-manual/group__avr__sleep.html
• jeelabs.org/pub/docs/jeelib/classSleepy.html

Happy battery powering…

Now there's a larger coverage area of LoRaWAN in Liverpool that provides free access to the public The Things Network service, it's the ideal time to start connecting more devices, more sensors, and taking advantage of this long range, low power, low cost way of connecting devices to the internet.

The great Arduino library from The Things Network means that getting started with using LoRaWAN is just a matter of finding coverage and a LoRaWAN modem. At the current time though, the TTN hardware has not started shipping, so we made some LoRaWAN shields, and ran a hackday at DoES Liverpool to get more people connected.

As is traditional in hackdays, progress on the day was captured in a shared document. While the main focus for many was on setting up their first LoRaWAN connection, and finding out how LoRaWAN might fit in with their project ideas, there were some great projects taking shape.

Links to the shared document:

• Original Hackmd.io document
• Github Gist at the end of the day

Temperature Sensor

One of my focuses of the day was to complete an initial hello world for those new to Arduino, or those looking for a base to start using LoRaWAN that goes from sensor to online recording.

Using a DS18B20 temperature sensor, take a reading, report it over LoRaWAN to The Things Network (TTN) using the Cayenne payload structure, set the payload interpreter to Cayenne, connect to myDevices Cayenne, and create a dashboard to show current temperature.

Getting started:

• Arduino IDE
• TTN library
• Sketch → Include Library → Manage Libraries → The Things Network → install

Device Info sketch for the Uno & shield:

#include <TheThingsNetwork.h>
#include "SoftwareSerial.h"

// RN2483 pins on the LoRaWAN shield
#define RN_RX 2
#define RN_TX 3

//#define lora Serial1
SoftwareSerial lora(RN_RX, RN_TX); // RX, TX

#define debugSerial Serial
#define loraSerial lora

TheThingsNetwork ttn(loraSerial, Serial, TTN_FP_EU868);

void setup()
{
  debugSerial.begin(115200);
  loraSerial.begin(57600);
  delay(1000);
}   

void loop()
{
   debugSerial.println("Device Information");
   debugSerial.println();
   ttn.showStatus();
   debugSerial.println();
   debugSerial.println("Use the EUI to register the device for OTAA");
   debugSerial.println("-------------------------------------------");
   debugSerial.println();
   delay(10000);
}

• Make an account on The Things Network,
• go to the TTN console
• select applications and + add application
• Set
  • Application ID (you'll need to use when you use the application),
  • Description (up to you)
  • Handler registration to ttn-handler-eu
• From your application page, + register device
  • Device ID (something you can uniquely identify that radio with),
  • Device EUI (reported from the sketch above),
• Then load a basic sketch onto your device to test the data transfer:

#include <TheThingsNetwork.h>
#include "SoftwareSerial.h"

// Set your AppEUI and AppKey
const char *appEui = "0000000000000000"; // replace with your `App EUI`
const char *appKey = "00000000000000000000000000000000"; // replace with your `App Key`

// RN2483 pins on the LoRaWAN shield
#define RN_RX 2
#define RN_TX 3

//#define lora Serial1
SoftwareSerial lora(RN_RX, RN_TX); // RX, TX

#define debugSerial Serial
#define loraSerial lora

TheThingsNetwork ttn(loraSerial, Serial, TTN_FP_EU868);


void setup()
{
   loraSerial.begin(57600);
   debugSerial.begin(115200);

   // Wait a maximum of 10s for Serial Monitor
   while (!debugSerial && millis() < 10000)
     ;

   debugSerial.println("-- STATUS");
   ttn.showStatus();

   debugSerial.println("-- JOIN");
   ttn.join(appEui, appKey);
}

void loop()
{
   debugSerial.println("-- LOOP");

   // Prepare payload of 1 byte to indicate LED status
   byte payload[1];
   payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;

   // Send it off
   ttn.sendBytes(payload, sizeof(payload));

   delay(10000);
}

• Load the sketch and watch on the serial monitor
• Also watch on the data tab to see the incoming data

Send temperature:

• Add the OneWire and DallasTemperature libraries to the Arduino IDE,
• Connect the DS18B20 sensor to power, ground, and the signal wire to pin D6 on the arduino (or another of your choice),
• connect a 4.7k resistor between power and the signal line (this is requred for proper opperation of the sensor, but in a pinch you'll probably get away with two 10k resistors in parallel),
• load the following sketch (after changing the appEui and appKey) to match your application:

This example uses the Cayenne LPP format so it can be recreated back into a JSON objects without having to do any custom float to byte array translation or javascript re-building

#include <SoftwareSerial.h>
#include <TheThingsNetwork.h>
#include <CayenneLPP.h>
#include <OneWire.h>
#include <DallasTemperature.h>

// Set your AppEUI and AppKey
const char *appEui = "0000000000000000";
const char *appKey = "00000000000000000000000000000000";

// RN2483 pins on the sensor dev shield
#define RN_RX 3
#define RN_TX 4

// Data wire is plugged into port 6 on the Arduino
#define ONE_WIRE_BUS 6

SoftwareSerial lora(RN_RX, RN_TX); // RX, TX

#define loraSerial lora
#define debugSerial Serial

TheThingsNetwork ttn(loraSerial, debugSerial, TTN_FP_EU868);
CayenneLPP lpp(51);

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);

// arrays to hold device address
DeviceAddress deviceAddress;

void setup()
{
   loraSerial.begin(57600);
   debugSerial.begin(115200);

   // Wait a maximum of 10s for Serial Monitor
   while (!debugSerial && millis() < 10000)
     ;

   // Get device address
   if (!sensors.getAddress(deviceAddress, 0)) Serial.println("Unable to find address for Device 0");

   // set the resolution to 9 bit (Each Dallas/Maxim device is capable of several different resolutions)
   sensors.setResolution(deviceAddress, 12);

   debugSerial.println("-- STATUS");
   ttn.showStatus();

   debugSerial.println("-- JOIN");
   ttn.join(appEui, appKey);
}

void loop()
{
   debugSerial.println("-- LOOP");

   // get the current temperature
   sensors.requestTemperatures();
   float degC = sensors.getTempC(deviceAddress);
   debugSerial.println(degC, 6);

   lpp.reset();
   lpp.addTemperature(1, degC);

   // Send it off
   ttn.sendBytes(lpp.getBuffer(), lpp.getSize());

   delay(30000);
}

• New messages should appear in the application, data on the console with the a "temperature_1: xx.x" visible in the processed payload,
• In the Things Network Console for your application set the Payload Formats to be Cayenne LPP,
• Create an account at myDevices Cayenne
• Add new → Devices & Wigets → LoRa (beta) → The Things Network → Cayenne LPP
• Enter the Device EUI from the TTN console,
• Back on the TTN console for the application → Applications → + add integration → choose Cayenne,
  • Enter a Process ID of your choice (anything),
  • Select an Access Key (one of the allowed MQTT passwords on the application to pass to Cayenne)
• New data from this device will automatically propogate to myDevices Cayenne, so entries for temperature, RSSI and SNR for this device will appear when it next sends.
• Many attendees found that receiving mesages using node-red provided more flexibility in pricessing and using messages.

If you're going to build a foam dart range, then at some point you're going to have to build a some kind of sensor to be able to register the hits at the target. When we originally started this (with MFUKLC), we started by looking around at what other people had already done.

• Pringle can MIDI drums, which uses raw piezo input to trigger MIDI signals;
• Reactive Targets for 6mm Airsoft and NERF™, which actually uses the sensor from some earlier work on piezo transducer signal conditioning from Leucos — this has since fallen off the web and was only available via the Internet Archive Wayback Machine — to produce contitioned pulses from piezo input.

After seeing his presentation at Wuthering Bytes 2016, I found out about a slightly different approach in Seb Lee-Delisle's Lazer Arcade, which uses piezo contact microphones and multi-lateration to locate the exact position of a hit on a 2D area.

Since we built Made Invaders, we've also seen other approaches to sensing foam dart impacts:

• Star Wars Nerf targets, which again use raw piezo input,
• Arduino Nerf target alarm clock — this actually counts the signal pulses and timing to differentiate between a finger press and a weighted impact.

While there are newer approaches, we still feel that the one-board analog conditioned signal provides (derived form piezo-transducer-signal-conditioning) the most reliable and robust foam dart impact sensing. Our tests with thousands of impacts in public facing events has shown that the sensor described below registers every valid impact, while rejecting pushes, presses, and even many finger taps.

Piezo impact signal

The first part in all these sensors is using a piezo element that is attached to the impact area. When the target object is hit, this causes the piezo element to vibrate, and this results in a voltage signal across the piezo.

When a voltage is applied across a piezo element, the different charge between the two metal plates either side of the piezo crystal causes the crystal to change shape slightly, making the plates get slightly closer together, or slightly further apart. By changing the voltage at a set frequency, the piezo will induce air pressure changes around it at the same rate, giving out a horrible, square wave sound with that note.

Like many electronic devices though, a piezo element can work as an input as well. If the distance between the two plates changes, this will cause the charges on the plates to change, causing a voltage difference between the two leads. If the piezo is stuck to a surface and then tapped, the output voltage might look something like the image below.

In this raw form, the main problem that we have with this signal is that it contains both positive and negative voltages. While the energy involved is very small, microcontrollers (as a rule) don't like negative voltages, so before passing this signal into the input pin of a device, it should at least be rectified to be positive voltages only.

Rectified signal

Making sure there is only positive voltage is the job of diodes D1 and D2.

We could force all the voltage to be positive with by using a full bridge rectifier, but I'm not too worried about efficiency. Here, D2 makes sure that the voltage in the upper line is always higher than the bottom (otherwise D2) conducts to equalise the voltage. And D1 makes sure that the signal goes towards the output signal line, rather than just shorting across the piezo.

The circuit uses Shottky diodes for these as they have a low forward voltage (so they don't reduce the voltage of the signal too much) and they are fast recovery diodes, so they are particularly suited to rapidly inverting voltages.

Voltage clipping

The signal is much better now that there are no negative voltages, but the possibility still remains of having very large voltages as part of the impact signal. While the pulse duration is very short, and therefore the risk of any damage to an attached device is low, we want any sensor output to be safe to go into a microcontroller in all situations, so it would be remiss to leave large voltage inputs as possibility.

In testing, I did see peaks of 30 and 40V from just tapping a piezo with my nail. As the signal is very noisy, the values were not repeatable, but voltages in that range were very common during testing.

A zener diode is specifically designed to allow current to pass in the reverse direction once the voltage passes a set threshold. While this happens with all diodes (the reverse breakdown voltage), zeners are particularly designed so that this happens at a specific, tuned voltage (depending on the specification) and can happen repeatedly, without damage to the diode.

For the circuit I used, I chose a 5.1V zener, to limit the voltage to go directly into a 5V Arduino, but a 3.3V zener would be appropriate for a 3.3V powered device.

Pulse signal

While the noise signal is now safe to pass into a microcontroller; as it is currently, the microcontroller will still need to do an amount of signal processing to determine the characteristics of the hit. In my initial install, I was feeding the result from 16 sensors into a single Arduino Mega, and wanted to be able to scan through each sensor every 10ms to make sure that I didn't miss any impacts.

Rather than using the raw signal, the sensor circuit includes a parallel resistor and capacitor pair. Having the capacitor there gives a "charge bucket" into which electrical energy can be stored. And having a high resitance path across the capacitor means that the capacitor will discharge "slowly" at a known rate.

Having this resitor-capacitor (RC) pair allows the incoming voltage signal to charge up the capacitor, while the resistor will slowly equalise the voltage across the lines. The specific pair here (4.7nF & 1MΩ) will cause the capacitor to have discharged by 90% over 10ms, meaning that any input signal will have mostly decayed over 10ms, ready for another signal to be received.

Using the RC pair like this changes the noisy signal into a charge and decay pulse that can be ready by a high impedance (input mode) microcontroller pin.

Reliability

We actually used this imput directly into the 16 analog inputs of an Arduino Mega for the first version of the foam dart range — although that did require speeding up the analog to digital converter to it's maximum rate to be able to scan all 16 inputs every 10ms. The code then looked for the signal going above a certain threshold, and counting a hit if it hadn't already done so within the last 10ms.

This all worked fine for most of the installations, but we were continually re-tuning the threshold level for reliability. For the second version we added a FET buffer on the receiving board, so the signal would be digitally triggered once the voltage reached the on-voltage of the FET (around 0.7V) and fed that into an interrupt pin on the Arduino. As we'd changed to having a controller on each target to run the LED display, and report hits via radio back to the main controller, changing to an interrupt means we always read hits over the impact threshold.

The FET buffer gives a clear logic low when the sensor pulse goes above 0.7V, which returns to logic high when the sensor pulse drops below 0.7V. And because of this threshold, coupled with the size of the capacitor, it will only trigger from a sharp pulse of a high enough energy. If you hit this sensor with a dart (or flick it very hard with your finger) it will trigger reliably, but if pressed or pushed, the voltage in the capacitor doesn't reach the trigger threshold, and no signal is passed.

The other change for installation that we did make was to add a single M6 nut glued to the back plate of the piezo. While it does work without, the additional mass across the piezo causes larger deflections in it, giving more energy to the signal and increasing the reliability of the input.

With the placement of Liverpool's first permanent LoRaWAN gateway, and the launch announcement of The Things Network Liverpool at IoT Liverpool just over a week ago, there's been a clear movement forward at the Liverpool outpost of The Things Network. The additional interest from the event, coupled with setting up a dedicated slack channel and announcement forum post, the Liverpool community has now passed the thresholds to become registered as an official Things Network community.

This has made us the 5th established community in the UK, out of 35 towns and cities that have set up communities so far around the country. I think that it is a measure of the level of interest in Internet of Things in Liverpool, and particularly the businesses and individuals working out of and around DoES Liverpool that we have a fledgling LoRaWAN network off the ground and in use without any public funding so far.

On to the building the next set of gateways!

“There’s a LoRa LoRA...WAN in Liverpool”

We are the initiator for the Things Network Liverpool community and we shall be launching in February 2017, at the IoT Liverpool event , our first outdoor LoRaWAN gateway, offering enhanced coverage across Liverpool. We would love to hear from anyone looking to start their own gateway, especially if they have a high roof offering a greater range for the service.

Connecting a device to the Internet has become easier in recent years. Now we see appliances such as refrigerators and washing machines offering online connectivity to fit into our ever busy lives. Typically these devices need an always on connection to the Internet via WiFi or Ethernet, but one network offers long range connectivity using radio, and can be powered for upto 10 years using a battery!

The Things Network a project that started life in the Dutch city of Amsterdam, was founded to create a community led city wide Internet of things network using approximately ten LoRaWAN (Long Range Wireless Area Network) gateways that provide a connection back to the Internet. These gateways offered long distance connections for Internet of Things (IoT) devices, often referred to as "nodes" that can report data from many types of sensors and then transmit the information using a LoRaWAN radio to the nearest gateway. The project then crowdsourced funds to produce lower cost hardware, lowering the barrier of entry for those interested in connecting their devices to the network. By encouraging the public to fund the project, it helped the community take ownership of the gateways, providing a low cost point of entry where the community provide access to other projects using the LoRaWAN platform.

Getting on to the Things Network using LoRaWAN is becoming simpler, and now you just need the right hardware, which can be powered by Arduino or Raspberry Pi, and an account on the Things Network website where you can setup a receiving channel, enabling your device to broadcast to the nearest Things Network gateway, which then handles sending the data over the network, via a simple console or something more advanced such as MQTT, to listening devices.

But what if there isn't a gateway near you? Well the cost of the equipment is a one off expense, you can buy a prebuilt unit from The Things Network for around £300, or build your own using a Raspberry Pi and an add on condenser board for around £500, this is for an external unit with a waterproof case and antenna, but you can get the internal version for around £300. A Raspberry Pi based gateway can comfortably handle up to 20000 nodes! Enough capacity for a town or a small city. There are also units available from companies such as Microchip but at a much higher cost.

Liverpool has had their own LoRaWAN gateway for nine months, "soft launched" as part of an IoT Liverpool event in March 2016. For 2017 we see more gateways being added to the Liverpool network, but this time they will mounted outdoors and used by interested parties and as part of making Liverpool “sensor city”. We are helping businesses and interested parties to take their first steps using LoRaWAN in their projects, so that everyone can get their device on the network and benefit from additional gateways.

But why does Liverpool need LoRaWAN? Well LoRaWAN is the easiest option as the hardware does not require a special NDA, and you can deploy your own gateway for easy access to the Internet. Others such as Sigbox, and another solution called NarrowBand IOT, offer similar services but can involve proprietary technologies protected by NDA (Non Disclosure Agreements). For Liverpool the LoRaWAN option was the ideal solution, offering low power radio connections between 2km (urban) and 12km (line of sight) and an easy method where the devices connect using a predefined code, without the need for passwords or login, the devices connect by themselves and can be moved from one gateway to another with no changes to their setup, truly remarkable and once again lowering the barrier to entry!

So using LoRaWAN what can you send over the network? Well being a low bandwidth platform, video and voice data are out of the question, but you can easily send up to a maximum of 60 bytes, but ideally 12 bytes of data, plenty of capacity for sensor data to be transmitted to The Things Network where it can be translated into JSON data. Data can also be sent back to devices on the LoRaWAN network, though there is a slight delay.

The need for a large LoRaWAN network in Liverpool exists for businesses looking to use LoRaWAN in their products, and this is something that can be easily addressed with a small amount of investment and it would benefit businesses and interested individuals accordingly. There are services that operate a "paid for" model, but there are also free services available. Currently we are standardising a build process that uses the Raspberry Pi computer housed inside of a waterproof container with an aerial to make it even easier to deploy your own outdoor gateway. If there isn't access near you then we can help you setup access!

In the 1970s and 80s shooting galleries that used simple light detection were everywhere. The rifle would emit a simple pulse of light, and if that light happened to strike a sensor it would trigger a sequence of automated actions, typically involving sound a simple movement of mannequins. This humble game was brought into the 21st century using microcontrollers, Raspberry Pi and wireless radio communications. But why was it made and what did it take to bring it to life?

Made Invaders was a research and development project that was created to showcase the skills and talents of the makers that make up DoES Liverpool. Costing £1000 this project came to life as we wanted to create a another large project that would accurately show the diverse skills that DoES contains. We worked on electronics, laser cut construction pieces, player registration software, vinyl art decoration. All of this was made possible thanks to the makers, hackers and artists that make up our community at DoES.

Made Invaders is a real life, full size shooting range, a cross between Space Invaders and Time Crisis. Housed inside of a 3㎡ enclosure we have a firing range full of reactive targets designed and built using a laser cutter and housing electronics that react to impacts and display digital explosions. Players receive 30 seconds to hit as many targets as possible using safe foam darts, enabling even young children to play safely.

To control the game there is a main controller, housed inside a custom laser cut frame, which uses the radio module from a Low Power Labs Moteino MEGA microcontroller board. The Arduino IDE was used to program the Moteino and the targets, a widely supported application with an extensive community of makers, artists and hackers. The Arduino platform is used throughout this project to power the controller and targets. We also have a Raspberry Pi running Node-RED, a visual language that uses a flowchart type interface to connect devices across a local or worldwide network. The Raspberry Pi is used to power a registration system, enabling the player to start the game by entering their name and Twitter handle, which is then linked to an RFID tag and used to uniquely identify the player and ensure that their score is recorded correctly. Once ready the player will hit the start button, triggering 15 targets to life and setting the countdown timer to 30 seconds. The countdown timer and the score display each have a Moteino inside and drives a series of 7 segment display to show the game time and player score. To signal the start of the game we play a quick piece of audio and then the players are ready to fire! After 30 seconds of action, involving many foam darts being fired, the player's score is displayed and the player's receive a tweet containing their personal score. We even added the facility for players photographs to be taken, and while this feature was fun, we found that players weren't as interested, so we pulled it from the final version.

The targets themselves are pixelated characters created using a 9 x 9 grid of LED lights. The target characters are created using over 40 bitmap images that are converted for use with the lights. This gives the player multiple targets that change when they are hit. Inside the targets we have a custom printed circuit board (PCB) which replicates some of the Moteino functionality, using a compatible microcontroller and an RFM69 radio module used to send data over packet radio to the main controller. The connection from the controller to the targets is completely wireless enabling easy transportation and storage. The PCB also has an SD card slot and a connection for the grid of LEDs. To register an impact we use a piezo element to detect the impact, generating a slight increase in voltage which is then manipulated to create a pulse so that the player can "see" the impact in much the same manner as a drum sensor operates.

This superb project was made possible thanks to the hard work and dedication of those that make up DoES Liverpool. If you would like to know more about DoES then come along and say hi. If you would like to have a go on Made Invaders then keep an eye on our Twitter account @MadeInvaders to see where it will pop up next.

As is traditional at Christmas here at DefProc, we attempt a small project to build a new fun, festive item. While this is spuriously titled as a 5 minute project, they typically take a few days to pull everything together.

We've previously done projects such as the cheertree, using the Cheerlights protocol for globally synchronised Christmas lights, and I still really like this as an easy way to get internet input to something that is also being used by others around the world. But we've already built tree structures, and even run light strings up the centre of a full size tree.

This year, we've taken the DoES Tower — normally twitter controlled through its own account @DoES Tower — and included the cheerlights protocol to make a festive addition to the office in DoES Liverpool.

Control

The DoES Tower has 3 sets of addressable RGB LED strings inside (actually WS2812b based strip, which is the same as off-brand Neopixels), two sit behind the letter blocks that spell out "DoES Liverpool" around the circumference of the tower cupola and the third that faces downwards through floodlight holes that are present on the full size tower. Inside, an Arduino Uno and WiFi shield cycle through a lovely set of random colour changes for the letters, and read an MQTT stream and set the downlight colours to the retreived hex value.

Having an MQTT stream means that the Arduino gets push messaging, and is much more flexible that reading the Cheerlights page regularly, because any of the 16 million possible colour combinations can be set directly via MQTT, rather that relying on rapid polling of the 9 colours available from Cheerlights.

To perform the actions of checking the twitter stream for messages, setting the MQTT colour, taking pictures of the tower and then replying to incoming tweets is not handled by the Arduino on board. Instead, a Raspberry Pi that is physically nearby runs a node-red flow. This means the logic is handed by a small computer, rather than being shoehorned into a small microcontroller, and the tower acts as a device that just sets the colour it's instructed to, and the programming logic is handled elsewhere.

Making Cheerbeacon

Other that replacing the Arduino WiFi shield with a spare — as the 3.3V regulator on the board had burned out in use(!) — I didn't want to change anything in the tower or tower firmware. The original firmware from @brettlempereur is already fantastic, and does everything that's needed from the tower.

Instead, I adjusted the original node-red flow to change the program logic. As we're not at a show, I removed the image code, and added in a regular check of the cheerlights api page to forward any of the cheerlights changes to the same MQTT feed that the Tower normally listens to. And just for testing, added a few inject nodes to be able to locally set the colour to red, green or blue.

Because this is MQTT, the tower gets a push message every time the broker gets an updated message, and this happens immediately. This is unlike the cheerlights, where the lights will only update when the controller next polls the cheerlights api page.

If you'd like to use the same MQTT feed (with no guarantees of uptime), the settings are stored in the Arduino sketch file:

MQTT_ID = "arduino-beaconbot";
MQTT_SERVER = "m20.cloudmqtt.com";
MQTT_PORT = 11475;
MQTT_USER = "arduino";
MQTT_PASSWORD = "arduinopassword";
MQTT_TOPIC = "beacon/colour";

The flow downloads the colour definitions and response messages from github, so I also uploaded messages in the beaconbot repo to make it more #cheerlights related.

The flow is available to import directly from the beaconbot github repo.