Pages

Particle Photon Batman lamp

Introduction

This project is to upgrade a basic looking Batman Lamp and create a WiFi Connected lamp. The original lamp was plain white in colour and not very interesting. The idea was to add a microcontroller with WiFi capabilities and a number of RGB LEDs. This is to be controlled via a MQTT message topic. This would then allow There are a number of micros that could have been chosen such as a Raspberry Pi, ESP8266 module, mbed or any of the other Arduino boards and an addon WiFi module.

Parts

In addition, soldering, drilling and cutting tools are required. A hot melt glue gun is required to finish the lamp off.

Hardware build

The photos below show the steps involved in upgrading the lamp.

2016-05-22 10.16.30 The Batman Hero Lamp that is going to be the base for this upgrade.
2016-05-23 09.52.08 Lamp base includes space for batteries, micro USB power connector, On/Off switch and a row of white LEDs. The laser cut and etched Batman is removable, which is handy.
2016-05-23 09.52.24 The white LEDs are not very interesting.
2016-05-23 09.52.43 On the inside there are three small boards, the USB connector, switch and LED strip. For this project the LED strip is to be replaced.
2016-05-23 09.56.13 The USB socket and switch are being reused, the LEDs are removed by unsoldering the wires from the switch and USB connector.
2016-05-23 11.47.11 A short NeoPixel strip will be the replacement light source.
2016-05-23 11.59.58 A strip of 5 Neopixels fit the space perfectly.
2016-05-23 12.00.06 The holes for the original LEDs were enlarged or re-drilled with a 8mm drill bit in a drill press. A handheld drill can be used but you risk damaging the case if you’re not steady.
2016-05-23 16.43.11 A socket for the Particle Photon is soldered to a piece of stripboard. The wires to the Neopixel strip, switch and USB connector are soldered to the stripboard. Two slots are cut into the battery compartment using an electric rotary tool. The can be finished off with a small file. The stripboard is then mounted through slots cut into the base of the battery compartment. Hot melt glue was used to secure the sockets.
2016-05-23 16.43.42 Once the glue has set, the Particle Photon can be fitted into its sockets.
2016-05-23 16.44.12 The USB cable should be connected to a suitable power source. Either a dedicated USB power plug, USB hub or a laptop socket can be used. The LEDs should illuminate, first red, then blue and green. Afterwards it should settle on the currently selected Cheerlight colour.
2016-05-23 16.44.30 Testing the completed lamp.

Software

The software on the Particle Photon will subscribe to a topic on my local MQTT broker, then whatever colour is published will be used to set the colour of the lamp. Using a simple Node-RED flow, I am able to retrieve the latest Chearlights colour and publish it on the lamps MQTT topic. This then sets the lamp colour.

Home made reflow oven in use

Building the reflow oven is the easy part, but how do you use it to produce PCBs?

2016-01-21 19.15.32-1 When getting PCBs produced, if you plan to build more than one board, then getting a stencil at the same time is a good idea. The one here is made from stainless steel.
2016-01-23 14.32.30 Using a flat surface, surround the PCB with a number of spare PCBs that are the same thickness.
2016-01-23 14.32.42 The stencil was lined up and a strip of tape placed at one end to produce a simple hinge. Another small piece is used to attached the opposite end.
2016-01-23 14.36.19 Apply solder paste to the stencil and while holding the stencil firmly in place spread the solder paste into the openings. If the stencil lifts up then paste will fill the gaps between the pads. Any pads not required to be soldered, for example in this case the connector on the edge of the board, the holes can be taped up or the paste can be carefully removed afterwards.
2016-01-23 14.37.28 After carefully lifting the stencil, you should see the pads covered with the solder pasted.
2016-01-23 15.08.45-1 The components were removed from their packaging and put into groups ready for placement. Fortunately for this design there are only 3 small components, resistors, FETs and capacitors all of the same value. The larger RN2483 module is not shown.
2016-01-23 15.04.22 Components placed, close view. When placing them by hand I used a fine pair of tweezers and a cocktail stick to just push the component down into the solder paste.
2016-01-23 15.41.56-1 A number of boards ready for the reflow oven.
2016-01-23 15.51.57 The boards were cooked in small batches in the centre of the oven. In total 10 boards were made in two batches of four and one batch of two. The thermocouple was positioned so that it was touching one of the PCBs to get an accurate as possible temperature on the PCB.
2016-01-23 15.52.11 The simple controller shows the progress.
2016-01-23 15.53.57-1 When completed, the boards are allowed to cool slowly in the oven before removing them and letting them completely cool prior to inspection.
2016-01-23 16.34.22-1 Stack of boards ready for the next phase – hand solder the headers and through hole components.

The end results were very good with all boards working correctly. The reflow oven is not insulated so this is an improvement to be made and may speed up the time it takes to get up to temperature.

Building a Reflow oven

I’ve recently had a need to produce a number of PCBs with a large number of surface mount components. After having struggled to hand solder the components, I decided to build a reflow oven and use solder paste. There are a number similar projects on the web, after looking at these I put together my own reflow oven based on a cheap toaster oven.

2016-01-16 15.23.19 The basic toaster oven from Argos, I got mine on special offer for £19.99
2016-01-16 15.26.25 Removal of the case is easy, a few screws on the rear and base.
2016-01-16 15.36.07 The thermostatic control is attached to the heating elements using spade connectors. These are easily removed. The knob and thermostatic control is then unscrewed. The replacement solid state relay is checked that it will fit.
2016-01-16 15.36.25 Marking out the position of the relay mounting holes.
2016-01-16 16.09.40 The relay is mounted onto a 4mm thick aluminium plate to provide a sort of heatsink for the relay.
2016-01-16 16.09.10 From the outside, the relay is hidden from view. The existing on-off-timer switch is preserved with the stay on position used to turn on the reflow oven.
2016-01-17 17.20.51-1 The controller is based on my wireless display module with the addition of a thermocouple amplifier and the relay control. The software goes through a heating and cooling sequence with the target and current temperatures displayed.
2016-01-17 17.22.24-1 The controller is showing it has turned of the relay and is not heating the oven.

Initial tests of the reflow oven have been favourable with single boards, 4 boards and 2 boards at a time.

There are still some improvements to make to the oven and these will be covered in a later update.

Arduino Yún WiFi Autobot Lamp

Introduction

This project is to create a WiFi Connected lamp from a Transformer themed lamp. The original lamp was plain white in colour and not very interesting. The idea was to add a microcontroller with WiFi capabilities and a number of RGB LEDs. This is to be controlled via a simple web page running on the microcontroller. There are a number of micros that could have been chosen such as a Raspberry Pi, ESP8266 module, mbed or any of the other Arduino boards and an addon WiFi module.

The board chosen is the Arduino Yún. The Yún consists to two parts, the first being a Linux based module providing the WiFi connectivity and Webserver. This also provides a management interface that allows the Yún WiFi to be configured remotely from a web browser. The second part being the Arduino part based on the Atmel 32u4 microcontroller and is the part that is programmed via the Arduino IDE and sketches. It is possible to run code on the Linux part but this is not covered here. Once the Arduino Yún has been connected to your WiFi it is then able to have sketches uploaded over to it remotely without a serial connection.

The finished lamp showing a rainbow effect.
2015-09-13 17.38.46

Parts

The main parts for the project are:

Other parts, usually found in your parts box include hookup wire, header connectors and heatshrink tubing. Tools required include a soldering iron, solder, screwdrivers, snips, wire stripper, hot glue gun and heat gun.

Hardware Build

The photographs below show the steps in building the WiFi Autobot lamp.

2015-09-13 11.28.10-1 The lamp in its original form glows white and is fairly uninteresting. It has an ON/OFF switch on the rear, a power socket and cable that plugs into a computer USB port.
2015-09-13 11.30.54-1

Opening the lamp is easy, it is held together by 6 small screws in the rear. Once the front has been removed, the lamps, switch and power socket are all accessible on the rear panel.
2015-09-13 11.34.45-1 The first task is to determine the position of the components. As the lamp is large and deep, the Arduino Yún is easy to place in the centre. A couple of LED strip offcuts are laid out to get an idea of where they can be positioned.
2015-09-13 16.57.04 A total of 14 LEDs were used from the WS2801 LED strip that I had available. This was cut into 2 lengths of 4 LEDs and 3 lengths of 2 LEDs. These were wired together to lay the strips in a circular pattern running around the outside and ending in the centre of the lamp.
2015-09-13 17.34.49 Once all the LEDs have been wired up and tested, they can then be stuck in place. The LED strips have a self adhesive backing which was used, along with hot glue that was used to secure the ends and the linking wires. The Arduino Yún is attached using double sided self adhesive pads. Once it has all been secured, the case can be screwed together and plugged into power and powered on.
2015-09-13 17.38.03 When the lamp is powered on it needs to connect to the pre-configured WiFi network. This can take some minutes. The lamp goes through a sequence of colours to indicate the state of the connection. Initially it is Red, then Blue and finally Green once connection has been established. After this the lamp will go into the previously set mode or steady colour. A this point, the webserver will be available and changes can be made.
2015-09-13 17.38.46 The current modes implemented are
  • Steady – All LEDs show the same colour.
  • Random – LEDs change to random colours in a random order.
  • Rainbow – LEDs change colours in a rainbow pattern, based on the example sketch in the Adafruit Neopixel library.

Software

Before starting to write any code the Arduino Yún was initially setup as per the instructions in the Getting started guide. The examples were tried to ensure the Yún was functioning properly and able to connect to my WiFi without problems.

The software for the lamp consists of an Arduino sketch running on the Atmel 32u4 microcontroller and a simple web page and images being served by the Linux portion of the Yún. The web pages are kept in a folder/directory called www within the Arduino sketch folder. This will then be sent to the Yún when the sketch is uploaded over WiFi. It doesn’t appear to do this if the sketch is uploaded via the serial port, presumably this is because over WiFi the portion is handling the files and able to access the micro SD card.

The sketch is based on the Yún Bridge example with extensions to interpret the rgb command. Example command URLs are: (If you have problems using the .local domain, for instance if using Microsoft Windows, then you would need to use the IP address for the lamp.

  • http://lamp.local/arduino/TransformerLamp/rgb/off – Turn off the lamp
  • http://lamp.local/arduino/TransformerLamp/rgb/ff0000 – Set lamp colour to red
  • http://lamp.local/arduino/TransformerLamp/rgb/random – Set random colour mode
  • http://lamp.local/arduino/TransformerLamp/rgb/rainbow – set rainbow mode

The web page is accessible http://lamp.local/sd/TransformerLamp where lamp is the name I’ve assigned to the lamp and TransformerLamp is the name of the sketch. The actual html, css and images for the web page were downloaded from an Ajax colour picker I found and was based on http://www.w3schools.com/tags/ref_colorpicker.asp.

Example of the web page controlling the lamp
transformerweb

The code is available on GitHub

Thing Innovations

Its been a little while since there has been any updates here, but I’ve mainly been working on the IoT Consultancy part of my company which is over at thinginnovations.uk. This is trying to work in the IoT area with new and innovative solutions. The first major project that I’m involved with is the Oxford Flood Network providing river level monitoring using many cheap sensors in and around Oxford. Other projects include the investigation and use of hardware based crypto-authentication on low power microcontroller devices.

Resin.io and the OpenPi

Introduction

Following on from a previous post on Using Redin.io with Node-RED I have been given a Wireless Things OpenPi device. This is based on the Raspberry Pi Compute Module and hence is a different beast to put software on compared to the regular Raspberry Pi models. The big difference here is that there is no SD or uSD card slot available on the Compute Module or on the OpenPi itself. Instead the eMMC flash memory is installed on the Compute Module and must be programmed by connecting the device to another computer, for example another Raspberry Pi.

Preparation

Build rpiboot – CM eMMC flashing pages.

Connect OpenPi programming port to USB port on host Pi, I’m using a Raspberry Pi 2 here.

sudo bash
root@raspberrypi2:~# /home/pi/tools/usbboot/rpiboot
Waiting for BCM2835 ...
Found serial = 0: writing file /usr/share/rpiboot/usbbootcode.bin
Waiting for BCM2835 ...
Found serial = 1: writing file /usr/share/rpiboot/msd.elf
root@raspberrypi2:~#

Flashing software

Partitioning

root@raspberrypi2:~# fdisk -l /dev/sda

Disk /dev/sda: 3909 MB, 3909091328 bytes
4 heads, 16 sectors/track, 119296 cylinders, total 7634944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00012301

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 7634943 3816448 6 FAT16
root@raspberrypi2:~# fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 3909 MB, 3909091328 bytes
4 heads, 16 sectors/track, 119296 cylinders, total 7634944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00012301

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 7634943 3816448 6 FAT16

Command (m for help): d
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7634943, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-7634943, default 7634943):
Using default value 7634943

Command (m for help): a
Partition number (1-4): 1

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Command (m for help): p

Disk /dev/sda: 3909 MB, 3909091328 bytes
4 heads, 16 sectors/track, 119296 cylinders, total 7634944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00012301

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 7634943 3816448 c W95 FAT32 (LBA)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
root@raspberrypi2:~#

Formatting

Format the partition

root@raspberrypi2:~# mkfs.vfat /dev/sda1
mkfs.vfat 3.0.13 (30 Jun 2012)
root@raspberrypi2:~#

Mounting and transferring files

Mount device

root@raspberrypi2:~# mount -t vfat /dev/sda1 /mnt
root@raspberrypi2:~# cd /mnt
root@raspberrypi2:~# scp -pr andrew@192.168.1.4:noobs/NewOpenPi/* .

root@raspberrypi2:/mnt# ls
bootcode.bin os recovery.img
BUILD-DATA recovery7.img recovery.rfs
config.json recovery.cmdline resin
defaults recovery.elf riscos-boot.bin
INSTRUCTIONS-README.txt RECOVERY_FILES_DO_NOT_EDIT

Finishing up

TODO….

Using Resin.io with Node-RED

I’ve been involved with Oxford Flood Network which is currently one of the showcase projects in the recently opened Digital Catapult Centre. For about a year now I’ve been using Node-RED, including developing the Twilio node for sending SMS. Node-RED is being used on the Raspberry Pi as a gateway between the sensor nodes and the backend systems. Building and managing one or two Raspberry Pi is a fairly simple task, but trying to replicate the build for each individual gateway soon becomes a major challenge.

I was at a recent IoT London meetup 37 where it had moved to a new venue and new sponsors. One of the new sponsors is Resin.io who claim to be Making hardware as easy to hack on as the cloud!. I was interested in seeing how Resin.io could be used to deploy changes to multiple Raspberry pi simultaneously and how it could be used with the Oxford Flood network deployments.

To get started you need to follow the basic getting started guide, I’m not going to repeat these steps here as they are documented well by Resin.io themselves. This will ensure that you have a working system and all your ssh keys are correct. They also provide example projects that demonstrate how to create applications running in Node.Js, Python, Java or .NET. What I am describing here is how you can develop Node-RED flows on one Raspberry Pi and push it to multiple Raspberry Pi with a few commands. It is possible to develop using another linux or windows system providing you don’t use any Pi specific file locations and features. As this project uses both of these, the development platform will be a Raspberry Pi.

Requirements

  • Raspberry Pi for development, Model B or B+ is recommended as we are using Ethernet
  • One or more Raspberry Pi for target deployment testing.
  • Compatible USB WiFi modules. I’ve used the Edimax modules successfully
  • SD and microSD memory cards for all the Pi, min 4GB, preferably Class 10 for speed.
  • Any additional hardware, e.g. wireless modules, LEDs etc that are used by your application

Setup Development environment

To develop your Node-RED flows you need your Raspberry Pi working correctly on your network, either connected via WiFi or Ethernet. If you’ve not got Node-RED installed then the instructions at Node-RED describe how to install it.

The git command is needed to manage the code repository and push the code to the Resin.io repository. If its not installed then install with:

sudo apt-get install git

You need SSH keys to authenticate against the Resin.io repository, again this is documented elsewhere, this time at Github. Skip the part where you add the keys to Github. Instead copy the contents of /home/pi//ssh/id_rsa.pub to the SSH key section of the Resin.io preferences option. If you have other keys on Resin.io, for example your github keys from when you initially registered then these can be either removed or left as is.

Create Resin.io App

Create the Resin.io app, in this case I’ve called it NodeRED. Currently only Raspberry Pi is available as the target device.

createapp

To create your devices you need to download a zip file containing the initial base system. This doesn’t do much other than indicate the device is online and able to talk to the Resin.io systems.

newdevice

The download has two options, Ethernet or WiFi. If WiFi is selected then you need to enter the connection details for your WiFi network.

downloadzip

When the zip files have been downloaded, add wifi or eth to the filename to indicate which version was downloaded. The files need to be written to a FAT32 formatted SD card. I have found using a tool called SDFormatter on Windows (link?) and selecting the resize options will restore previously used cards to the full size. Using something like 7-Zip on Windows you can extract the contents of the zip files to the root of the freshly formatted SD card.

Install to target device

The prepared SD cards should be put into a Raspberry Pi and then it can be powered on. The ACT or OK LEDs should flash occasionally as its preparing the SD card. If using a WiFi adaptor, then the LED in this should start to flash when it is connecting to the network. After a few minutes (upto 10!) a new device should appear on the Resin.io dashboard for your application, provided you entered the correct SSID and passphrase.

newdevices

The devices seem to be given random names which can be changed if you dont like what has been given as a default. Clicking through to the device will show more detail. For some reason its not showing an IP address, this could be because its on a local LAN. Something to check with Resin.io.

devicedetail

The page also has a log window which will show application logs when you have your application loaded onto the device. There is a handy IDENTIFY DEVICE button that causes the LED to flash on the selected device. Useful if you have number of identical looking devices.

devicedetail2

Setup Node-RED for device

The way applications are built is not the traditional package it up and deploy to the target. The scripts presented here are used to build an image that is created on the Resin.io system and transferred to the device once its been built. This is how I understand it to work.

The files to build a node.js application, which is what Node-RED is, are created in a git repository on your development Raspberry Pi. Firstly, create your git repository.

pi@raspberrypi ~ $ mkdir resin
pi@raspberrypi ~ $ cd resin
pi@raspberrypi ~/resin $ mkdir nodered
pi@raspberrypi ~/resin $ cd nodered
pi@raspberrypi ~/resin/nodered $ git init
Initialized empty Git repository in /home/pi/resin/nodered/.git/

Files can then be created in the repository using your favourite text editor.

pi@raspberrypi ~/resin/nodered $ ls
deps.sh flows_raspberrypi.json package.json README.md settings.js

deps.sh – This is basically a series of commands to install all the dependancies and packages required to get Node-RED running on the target device. The commands follow the installation instructions from the Node-RED Raspberry Pi page along with a number of other packages to resolve dependancy issues.

#!/bin/bash

set -o errexit

apt-get -q update
apt-get -q -y upgrade
apt-get -q -y install python build-essential python-dev python-pip
# Install python modules
#pip install RPi.GPIO
dpkg -i python-rpi.gpio_0.5.8-1_armhf.deb

git clone git://git.drogon.net/wiringPi
cd wiringPi
./build
cd ..
git clone https://github.com/node-red/node-red.git
cd node-red
cd nodes
git clone https://github.com/node-red/node-red-nodes.git
cd ..
npm install wiring-pi
npm install js2xmlparser
npm install serialport
npm install feedparser
npm install –production

cp -f ../settings.js .
cp -f ../flows_raspberrypi.json .

flows_raspberrypi.json – Copy from your working flows file on your development Pi. The example flow I’ve used is to blink a LED connected to pins 6 and 11, once a second. If you have one connected you should see it start blinking when the application is fully loaded.

package.json – Copy from the Node-RED directory and make the follwoing change:

“scripts” : {
“preinstall”: “bash deps.sh”,
“start”: “node red.js”,
“test”: “./node_modules/.bin/grunt”
},

to

“scripts” : {
“preinstall”: “bash deps.sh”,
“start”: “node node-red/red.js -v”,
“test”: “./node_modules/.bin/grunt”
},

README.md – Simple readme to say what the project is.

settings.js – Copy from the Node-RED directory and make the following change to add the WiringPi functionality:

functionGlobalContext: {
// os:require(‘os’),
// bonescript:require(‘bonescript’),
// arduino:require(‘duino’)
}

to

functionGlobalContext: {
wpi: require(‘wiring-pi’)
// os:require(‘os’),
// bonescript:require(‘bonescript’),
// arduino:require(‘duino’)
}

The files should be added to the git repository:

pi@raspberrypi ~/resin/nodered $ ls
deps.sh flows_raspberrypi.json package.json README.md settings.js
pi@raspberrypi ~/resin/nodered $ git add *
pi@raspberrypi ~/resin/nodered $ git commit -m “First commit” [master (root-commit) 03a4c2d] First commit
5 files changed, 223 insertions(+)
create mode 100644 README.md
create mode 100644 deps.sh
create mode 100644 flows_raspberrypi.json
create mode 100644 package.json
create mode 100644 settings.js
pi@raspberrypi ~/resin/nodered $

The Resin.io remote endpoint needs to be added, the command for this is shown at the top of the Resin.io application page and looks something like this:

git remote add resin git@git.resin.io:yourusername/nodered.git

Next you can push your application to your devices. The first time you use this you may have to confirm the key from the host git.resin.io:

pi@raspberrypi ~/resin/nodered $ git push resin master
The authenticity of host ‘git.resin.io (54.165.162.194)’ can’t be established.
ECDSA key fingerprint is f3:d9:38:97:47.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘git.resin.io,54.165.162.194’ (ECDSA) to the list of known hosts.
Enter passphrase for key ‘/home/pi/.ssh/id_rsa’:
Counting objects: 7, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 3.94 KiB, done.
Total 7 (delta 0), reused 0 (delta 0)

At this point there may be a pause of a few minutes before anything else happens. It then starts to build the image and runs through the deps.sh script which may produce familiar output. Keep an eye out for any errors that could make the build fail. So far with this scripts I’ve not had a failure. If all is successful you should see:

—–> Image created successfully!
—–> Uploading image..
Image uploaded successfully!
To git@git.resin.io:yourusername/nodered.git
* [new branch] master -> master
pi@raspberrypi ~/resin/nodered $

The device status should change to downloading and the log window on the Resin.io device page should start to show that it is installing the application.

When complete you should then be greeted by a unicorn and a LED flashing on your Raspberry Pi!

unicorn

Expanding the device logs should give you a full log of what has been going on. The -v option was added to the node command line in order to output any missing module dependencies.

devicelog

Pushing new version of Node-RED

If you find there is an update to Node-RED but your flows haven’t changed then the easiest way to get the latest Node-RED onto your devices is to fake a change by adding a line to the README.md file, committing it and pushing to resin.io.

pi@raspberrypi ~/resin/nodered $ vi README.md
pi@raspberrypi ~/resin/nodered $ git commit -m “refresh” README.md
[master ffb8ae6] refresh
1 file changed, 2 insertions(+)
pi@raspberrypi ~/resin/nodered $ git push resin master
Enter passphrase for key ‘/home/pi/.ssh/id_rsa’:
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 300 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)

Then sit back and watch the build happen.

And finally

As a final test, you can locate the IP addresses of your target devices and using a web browser access the IP address and port 1880 to view the Node-RED screen and the flow that was created.

In future, when you develop new flows on your development Raspberry Pi, to deploy them to all the connected devices its just a matter of updating the flows_raspberrypi.json file in the git repository, committing the changes and pushing the new version to Resin.io. If additional Node-RED modules are needed then these can be added to the deps.sh file in the same way as a regular Node-RED installation.

As Resin.io is still being developed, the screen layouts may be slightly different to those shown here.

The files used in my test repository are available on Github

Oxford Flood Network Sensor build

These are the first draft of the detailed build instructions for the V3 Oxford Flood Network river level sensor. The sensor uses an ultrasonic transceiver measure the distance from the sensor to the water. The changes in the water level are registered as changes in the distance measured. This can then be used to calculate the river depth at that point and over time can be used to track changes in the levels.

2014-06-16 19.46.09 2014-06-16 20.55.46
A kit of parts. THis includes the external antenna options and waterproof outdoor sensor. other parts needed are some hookup wire for the temperature sensor. Start by soldering the lowest components first, this is the u.FL connector that is only needed if you are using the external antenna.
2014-06-16 20.58.00 2014-06-16 21.00.33
Solder the R1 which is the 4K7, 1/4W resistor used with the temperature sensor. Followed by 100nF capacitors C4 and C5 (I forgot to renumber the parts before manufacture so some numbers appear missing)
2014-06-16 21.01.19 2014-06-16 21.02.46
The pair of 10 way header sockets should be soldered next. A tip is to only solder one end then make sure that it is straight and upright before soldering the rest of the pins. If not straight, just touch the soldering iron on the joint to re-align it. It should now look like this with the socket for the Ciseco RFu-328 module.
2014-06-16 21.03.28 2014-06-16 21.04.40
To use the external antenna, an additional pin and header must be cut from a spare socket/pin headers. This single pin and header should be fitted together. Insert the Ciseco RFu-328 module then put the header/pin into the PCB so it connects to the antenna pad on the RFu module. Solder the RFu module end first then turn other the PCB to solder the other side. The RFu-328 module can now be removed until assembly has been completed.
2014-06-16 21.05.46 2014-06-16 21.05.55
The new antenna connection header socket should look like this now. Another photo of build so far.
2014-06-16 21.06.59 2014-06-16 21.11.29
Not a clear photo of the new pin on the RFu-328 module. Continue the build soldering the 2N7000 Mosfet, header strip, FTDI connector, 100uF 10V electrolytic capacitor, temperature sensor connector and battery clips.
2014-06-16 20.43.26 2014-06-16 21.28.10
Completed board with RFu-328 fitted. Solder the 7 way right angle header pins to the ultrasonic sensor. It can go in from either side but having it over the label is the way it was done here.
2014-06-16 21.30.13 2014-06-18 21.40.13
Mark which end of the header pins is the GND connection as this should mate with the correct end of the The case, its lid and rubber seal.
2014-06-18 21.40.34 2014-06-18 21.43.54
The inside of the lid has ribs that will need to be partially removed later to allow the sensor to be mounted properly. Marking the centre of the lid ready for drilling. The lower mark is for the temperature sensor and should be towards the edge so as not to foul the ultrasonic sensor mounting nut.
2014-06-18 21.44.49 2014-06-18 21.55.06
A further mark on the side of the box for the external antenna hole. The sensor hole is best made with a 26mm or 27mm hole saw mounted in a pillar drill. I used 27mm as it is what I had available but 26mm would be a better fit.
2014-06-18 21.56.14 2014-06-18 21.56.55
Cutting the main hole. Inside the lid.
2014-06-18 21.58.07 2014-06-18 22.09.14
Both holes made in the lid. The temperature sensor hole is 6mm. The ribs were removed around the hole using a rotary tool with a cutting disk. Appropriate eye and dust protection should be worn as this can be a messy operation.
2014-06-18 22.14.07 2014-06-18 21.59.35
Fit the sensor with the rubber seal on the outside and the O Ring on the inside Fitting the antenna SMA connector. This is a 6mm hole.
2014-06-18 22.18.05 2014-06-18 21.20.05
SMA connector fitted. Use the shakeproof washers provided. (?? May need a spot of silicone sealant around it to make it watertight ??) Almost finished.
2014-06-23 20.14.45 2014-06-23 20.28.44
Parts to build the temperature sensor probe Solder blue wire to centre pin of DS18B20 temperature sensor and cover with heatshrink tubing then shrink using your preferred method (lighter, heat gun etc). Bend one of the outer pins over to meet the other and snip off a piece of pin.
2014-06-23 20.29.35 2014-06-23 20.31.39
Soler the two outer pins together and solder on the brown wire. Use the wider heatshrink tubing to cover all exposed pins and soldered joints.
2014-06-23 20.36.04 2014-06-23 20.38.42
Strip 3mm from the other end of the wires, crimp then solder the connections. Insert into the JST plug housing as shown.
2014-06-23 20.39.10  
When plugged in, the brown wore goes to and the blue wire to +.  

Still to do:

  • Wiring and mounting Temperature sensor.
  • Alternative antenna options – Integrated and whip antennas
  • Alternative power options – 2AA cells with power pod or Single Tadiran cell
  • Mounting options – Internal magnets for steel bridges, brackets for bolting/screwing.
  • Configuring the sensor node address using the jumper links
  • Publish all the design files – Eagle schematic, PCB layout, Gerbers and Bill of materials.

What to do with surplus dev boards

I’ve been using Arduino boards for a few years now and it re-kindled my interest in microcontroller systems after having worked in the field quite a few years ago. Since then I’ve also used various Arduino compatible boards, shields and d-i-y boards, I’ve created libraries, published code and generally had a lot of fun with them. I’ve also used the ethernet connected Arduino compatible Nanode, dabbled with 32bit ARM architectures of the mbed products, tried the BeagleBone Black, had a brief affair with the Raspberry Pi and other development boards. With all these dev boards I’ve acquired quite a collection. With new boards coming along almost monthly and a change in my focus to more wireless connected devices, there is always something new to try. A lot of the older boards that I have stopped using still have a lot more life in them and would make ideal tools for a novice to learn about embedded micros if they find the purchase of new kit is outside of their means. Or for a small community group providing educational services based on Arduino and similar hardware. This is no way an attempt to undermine any sales of new boards but a way to provide new life for surplus boards. I’d urge everyone to buy at least one original Arduino board if you can afford it to show your support and enable them to continue the good work they are doing.

In the past year I’ve already given away at least 2 Arduino compatibe boards, the most recent was to a fellow attendee of the Thingmonk conference last year.

I’m sure I’m not the only one that has a large collection of boards that are feeling unloved and gathering dust in a box or drawer. After a few exchanges on Twitter I started to have an idea.

The Idea

After seeing the replies to my initial tweet it was going to be a difficult choice of what to do with the boards, who to send them to and what was a deserving cause. The replies included donating them to:

  • Local Hackspaces or Makerspace list of UK based spaces here
  • Schools for extra-curriculum clubs
  • Arduino workshops
  • Community projects
  • Just sell them on eBay
  • Give them to the first person who puts their hand in the air and says Me…Me…Me…

I’ve no idea if this is already being done anywhere in the UK or even the world. So lets see how much interest there is.

As it’s Arduino Day on 29th March 2014, celebrating 10 years of the Arduino I’d like to propose a global Donate a Dev Board scheme or event. The name probably needs work as I’m no marketing expert. There are numerous events going on around the world so this would be an ideal opportunity to share your used boards. If organisers of these events, or even if the Arduino ‘management’ would give the OK or even promote the donation of used boards to worthy causes this would help encourage less privileged people and especially youngsters to take an interest in this exciting world of Arduino and embedded micro controller boards. Although the idea is not limited to Arduino boards, they are ideal for teaching novices the basics and beyond. The range of mbed boards I would say are aimed more towards the more experienced user and are ideal for someone who has experience of the Arduino platform and wants to expand their knowledge and create bigger and better things with a more powerful platform.

The only rules I’d suggest for the dev boards being donated is that they must be fully functional, come with their original bootloader and sockets must not be damaged. Any shields donated must also include a link to where the new user can obtain the required library if it is not part of the core IDE.

I’m not sure if I’ll be able to attend an event, as much as I’d like to, so in support of this I have a number of boards that I’d like to donate. These are listed below.


Arduino Day 2014

My Boards

I have a number of Arduino, Arduino compatible and non-Arduino boards including:

2014-03-11 20.07.33

  • Arduino Due (not pictured)
  • Arduino Bluetooth
  • Mbed FRDM-KL25Z
  • Mbed NXP LPC800-MAX
  • ENC28J60 based ethernet shields for Arduino (x3)
  • 2.4″ TFT LCD Touchscreen
  • LPCXpresso 1768 board, not mbed abut uses version of eclipse ide
  • FEZ Mini .NET micro framework based

I’m sure I have more if I start digging deeper!

What’s next?

I’ve presented my idea, other ideas and suggestions are welcome. There are still a lot to work out, like who gets what, how to send or deliver it, who would run a scheme locally (hackspaces?), support etc. What’s the best way to continue this? Create a google group?

Comments appreciated.

Remote controlled LED Kitchen lights

Introduction

Over the Christmas and New year holiday I’ve been doing a little kitchen refurbishment. This included the usual repaint and replacement of cabinet doors and handles. As an extra I decided to add some additional lighting above the cabinets to illuminate the ceiling. This is achieved using a more than 5m of 12V RGB LED strips. This is the variety that produces the same colour for each LED and as a result is a much cheaper option than the individually addressable LED strips I have used previously. There are two parts to this project, the first being the LED driver, the second being the controller that sends new colour to the LED driver.

2014-01-04 20.54.25

Hardware

Prototype testing on breadboard with lots of jumper wires, IFRZ44N MOSFETs to drive the individual LED colours and 1K resistors for a bit of current limiting on the gate of the MOSFETs. The controller is a Ciseco XinoRF Arduino UNO compatible board with built in wireless transceiver module.
The LED strip is a commonly available on eBay, search for 5050 SMD RGB LED Strip. The ones I used are 5m in length with 150 RGB LEDs in total. It came with a small controller which can be used to test the strip is functioning.
2014-01-04 16.30.10
A quick layout done using Fritzing

Kitchen_LEDs_bb

Once the prototype was working on the breadboard, it was time to make it permanent on an Arduino compatible proto-shield from Ciseco. This sits on top of the Ciseco XinoRF board. As the LED strip required 12V I only wanted to use a single power supply. The XinoRF has a 3.3V regulator and 12V was at the top end of its range, to lower the voltage two IN4001 diodes were used to connect the 12V to the Xino RF VIN pin. This is then regulated by the 3.3V voltage regulator onboard. 2014-01-04 18.15.42
The device used to control the colour of the LED strip is yet another use of my wireless LCD display. This has software that described below. 2014-01-06 21.22.34

Control Commands

The communication between the LED Controller and the LED Driver is done using the Ciseco LLAP protocol. The commands implemented in the LED driver are:

Set new colour
Request:

aXXRGBrrggbb

Response:

aXXRGBOK—-

Request current colour
Request:

aXXRGB——

Response:

aXXRGBrrggbb

In the above, XX is the ID of the LED Driver, rrggbb is the hex value for the colour with each pair of values being in the hex range 00 to FF and representing the colours red, green and blue in that order.

Software

The software is in two parts, the LED driver and the LED controller.

LED Driver

The LED driver software receives commands wirelessly and sets the colour of the LEDs. The main features are:

  • Send starting message so that main hub knows this device is active
  • Responds to colour change commands by acknowledging them and changing the LED colour
  • Responds to current colour request command so that LED controller can determine what the current colour is
  • Saves the current colour in EEPROM and sets this colour when next powered on

LED Controller

The LED controller displays a set of 3 bars representing the three colours of the RGB LEDs. The colour is selected by moving the mini joystick up and down. The currently selected colour is highlighted. Moving the joystick left and right will increase or decrease the length of the coloured bar. This represents the intensity of the colour to be set on the LED driver. The colour change command is only sent to the LED driver when the joystick is released. The main features of the LED controller are:

  • Uses existing wireless hardware platform
  • Query LED Driver for current colours and set bars appropriately
  • Allow new colours to be selected and send them to the LED Driver

In use

A quick video showing the controller changing the colour of the LED strip.

Code

The code is not yet in a releasable state, there are a couple of things to tidy up such as the layout on the controller screen needs a few tweeks and the code needs clean up before I publish it.

Disclaimer

I use a lot of products from Ciseco but I don’t work for them, I’m just a customer who appreciates a good range of products that are developed in the UK. However I have over the years had a few freebies and samples from them. If you do want to get free stuff from their shop then check out this blog post.