04 Mar

Coffee Machine Water Filter Monitor

Recently we have been working on a Water Monitor for Coffee Machine filters.

The problem: Coffee Machine water filters stop working after x number of liters of water have been filtered. That varies depending on the hardness of the water which can vary over time. It takes time for an engineer to visit each site and test the water quality and assess the effectiveness of the water filter, so filters may be replaced days or weeks after they are no longer effective or could be replaced prematurely if based on usage estimates.

The solution? Measure the difference between the input and output of the water filter and the volume of water that has passed through the water filter. In addition, we can measure the water temperature to try and calculate the Total Dissolved Solids (TDS). We need the water temperature as it is required in the TDS calculations. Send that data to a backend system for processing and presentation allowing proactive management of all deployed water filters.

We based our prototype solution on off the shelf modules and components. At its heart is an ESP32 devkitc with two DFRobot TDS modules, a (modified) flow meter and a DS18B20 temperature sensor. A custom PCB & 3D printed case.


The firmware waits for data from the flow meter and then records input & output TDS values in turn and sends that data via MQTT over TLS for back-end processing and presentation.

Node-RED example dashboard presenting water quality information.

The firmware presents a password protected hotspot for configuring the device wifi connection credentials & ssl certificates as well as presenting current water quality readings.

22 Apr

Drawing machine (vPiP)

We’ve decided to take a break from the Wireless RGB Pixels project and revisit the hanging v plotter.

We are looking at making the various parts of the system independent services that talk over MQTT. This allows us to change the various bits of the system in a modular fashion.

Starting with the communication between the current Python vPiP scripts and the hardware. This will be a c/c++ binary that subscribes to the MQTT broker and listens for messages that it should pass to the hardware. The existing Python scripts will publish the relevant plotter data to the MQTT broker. This allows us to potentially control many drawing machines at the same time. It should also make the task of adding a GUI or app a bit easier. The GUI or app will publish messages to the machines and subscribe to messages that they can act on.

As a side note, if you have been following this project, you may have seen (or experienced) the glitchy stepper motor problem recently. This was due to the duplication of python processes and has been fixed in the existing version. Get the latest code from github.

08 Jan

Wireless RGB Pixels – Prototype PCB (v1.2)

The prototype PCB for the wireless RGB pixel is at v1.2.

Front of v1.2 PCB pinout (top) and back of PCB showing NRF module (bottom)

This version fixes a mistake I made with the power pins (I misread the data sheet) and does away with the RC pin multiplexing simplfying and standardizing the SPI comms with the NRF24L01. This also means there is no serial debug output from the ATtiny.

Initial radio range tests with the test firmware are disappointing. Comms was spotty and random. I experimented with the various power levels and have tried removing some of the PCB material and re-orienting the NRF module at an angle to see if that made any difference but it didn’t appear to.

Cropped PCB material near NRF PCB antenna on left, NRF soldered at an angle on back of PCB on right.

Cheap amplified NRF modules from ebay actually reduced the range compared to a standard PCB antenna version.

It will be interesting to compare the non Arduino-IDE based firmware with the test code in terms of radio range and comms reliability. I will update when available.

26 Aug

Wireless RGB Pixels

Taking a break from the hanging v-plotter we decided to work on a project that has been discussed for a long while now… The RGB Wireless Pixel.

The idea is these are self contained full colour lights that can be placed anywhere within radio range and controlled from a master. That is, we command the lights all together or individually to change colour or brightness. With that we can create a pop-up light show that could potentially be synced to music or react to passers by. It may even be possible to put them into the windows of a large building and create a massive display… all without wires!


Prototype Wireless RGB Pixels.

We currently have a working prototype based on an ATtiny85 microcontroller, an NRF24L01+ radio module that you can find on ebay for ~£1 each, a WS-2811/2812 programmable LED and some extra passive components. The circuit diagram is available on github and there are more details on our wiki.

We are calling this version 1. The idea is to get people to design their own version of the hardware for this and get PCBs (Printed Circuit Boards) manufactured. To that end we have been running kicad tutorials (kicad is an open source PCB design program) which can be supplemented with the excellent ‘Getting to Blinky‘ youtube tutorials by ‘Contextual Electronics’. Check out our meetups page for details of what we will be doing at future meetings.

Wireless RGB Pixel_ping_pong_smt

Example Wireless RGB Pixel PCB deisgn with KiCad to fit inside a ping pong ball.

When everyones PCBs are deisgned and manufactured we will then assemble, program and test them and eventually, design enclosures and at some point, if everything works, put on a few light shows somewhere!

Right now the software for v1 is pretty basic and more or less a proof of concept. I hope the software will improve as people build their own Wireless RGB Pixels and start programming them! The PoC code is also on github.

Future plans for the project  are already being discussed for v2 which will allow the use of sensors in each Wireless RGB Pixel as well as an upgraded micro-controller to allow for these and other features.

26 Apr

Hanging V-Plotters at the Arts Uni – Part 3

We’re online! Check out the details of the event here!





Gallery staff Joseph has been a great help – getting the machines plotting most mornings.  The above image is his work – the poster design for the exhibition realised using the machines, in the style of Norwegian Pixel.

Cheated the process here by plotting text (black fill) – so it renders it out at its most dense – perhaps we need to implement plotting vector in fills.


Got the large machine fixed – changed the gear wheel on the right motor – just need to get some bad ass vectors in place.


Multi layered image – black Hi-Techpoint 0.5 fine over Neon (magenta) Stabilo fine 0.4


To get the plots completed at A2, I changed the pixel size from 3 to 10 – so the spiral is large. I then later dialled it back to 7. I think Changing the speed would also be helpful (slower) – will get the resolution of the spiral that much tighter.


Colour change mid plot


Drawing studio interior rendered with Norwegian Pixel


19 Apr

Hanging V plotters at the Arts University Bournemouth – Part 2

After a lot of faffing, things breaking and some head scratching, the machines are all working as anticipated and we’re almost ready to start doing some drawings!

This post shows the result of running some calibration tests and some test drawings.


The Pylargraph machine is finally plotting a graph of tweets for the chosen disaster related keywords. For some reason the code had defaulted to scaling all tweets to a height of 1mm. This produced straight lines which wasn’t very interesting. Now its producing interesting line graphs.


Then we have a vPiP machine rendering a Vulcan bomber. The grid is the result of a test program that we use to check the machine is properly calibrated and will be drawing things where we think it should.


And the large format landscape vPiP machine drawing a vector of the exploded view of the Gondola (the thing that holds the pen) that this machine uses. Again, the grid is drawn by a test program.

14 Apr

Hanging V plotters at the Arts University Bournemouth – Part1

Our trio of hanging V plotters at the AUB


The machine on the left is running Pylargraph and is plotting a graph based on the number of twitter search results it gets back for a series of keywords related to the theme of disaster.

The two on the right are running vPiP (which produced the framed images).

We hope to get the large machine on the right plotting large format vector images.

21 Mar

Installing and configuring Pycupi

There has been some interest in Pycupi from the wider community so I figured an install/configuration guide might be handy.

IMG_7041 (2)

Tank Girl – v-plotter CMY (3 pass) Pycupi spiral arc render A2 Stabilo Point 88 Fineliner

First off this guide assumes you are using a configured Raspberry Pi that is running a recent version of Raspbian Jessie.


Python should already be installed along with PySerial. However we still need the Pillow library for image processing.

From the command line run:

pip install Pillow

If that completes without error you can move on to the install.


From the command line (and somewhere in your home directory) run

git clone https://github.com/brianinnes/pycupi.git

That will get Pycupi. Inside the Pycupi directory you will find an Arduino/Stepper directory which contains the firmware for the Eggbot/Spherebot/Polargraph controller. A Python directory which contains the core Pycupi program and test scripts. A testImages folder that contains a few images. And a wikiResources dir which contains stuff that lives on the wiki.

cd into the Pycupi/Python directory and run

python test1.py

which will probably throw an error complaining about the serial port. Thats ok, we needed to run this to have Pycupi create the default config. The default config lives in your users dir (/home/some_user/.polargraph/config.cfg). You will need to edit a few settings to match your machine before you can do any drawing.

Note: A semi-colon denotes a comment in the config file. Any line starting with a semi-colon will be ignored.

Under the [Polargraph] section, configure the following (any settings not mentioned here, which are present in the config should be left as default):

  • pensize – not currently implemented – will be ignored.
  • machinewidth – This should be set to the distance in mm between your pulleys.
  • machineheight – The physical height of you machine measured in mm from the centre of your pulleys.
  • mmperrev – The circumference of your pulleys (in mm) or how much chord or chain (in mm) is played out for each whole revolution of a pulley.
  • setsperrev – The number of steps your motors make in each whole revolution.
  • stepmultiplier – The step multiplier applied by your stepper drivers (Pycupi firmware defaults this to 8).
  • serialport – The serial port your stepper control board is attached to (/dev/ttyUSB0 on a RaspberryPi connected to the ‘Arduino Nano dual stepper board v2.1’).
  • motoraccel – A time value in seconds that determines how long it takes the motors to accelerate to their fastest speed.
  • motormaxspeed – The maximum speed the motors are allowed to move in mm/sec (needs confirmation).
  • penup & pendown – not currently implemented. Configuration angles for servo are set in the firmware.
  • homex – The home position in the (horizontal) x axis, measured in mm from the top left pulley. This position can be anywhere you like. Suggested value would be in the middle of your machine.
  • homey – The home position in the (vertical) y axis, measured in mm from the centre line of the pulleys (imaging a line drawn between the centre of the pulleys, homey will be some distance below this). This position can be anywhere you like. Suggested value would be 120mm down from the centre line, but will be dependant on your machine.

For a graphical representation of machine size measurements, see this post.

Under the [Paper] section you can define your paper size and its position.

An example A3 page would be as follows:

  • size = A3 – The name of the paper size.
  • width = 297 – Width in mm.
  • height = 420 – Height in mm.
  • posx = 175 – The position (in mm) from the left edge of your machine to the left edge of the paper.
  • posy = 240 – The position (in mm) from the top edge (centre line) of your machine to the top edge of the paper.
  • margin = 20 – A margin (in mm) around the edge of the paper where the machine will not draw (usually where you tape the paper to the machine). The specified margin will be applied on all sides of the page.
  • pixels = 3000 – The resolution for this paper in pixels.
  • rotate = false – If false the image is not rotated. If true the image will be rotated.

Under the screen section:

  • screenX = 5000 – The resolution the plot simulations will be. When generating simulations (bitmap images of a plot), you can specify a higher resolution that your final plot so you can see more detail to spot potential issues before running a plot.
  • showImage = false – not currently implemented.
  • saveImage = false – not currently implemented.

Now when you run

python test1.py

the machine should spring into life and draw a rectangle filled with smaller rectangles.

29 Feb


MakeBmth has manged to get 3 Polargraphs working! (Technically 2 v-plotters running the Polargraph.co.uk software and 1 running a Gocupi/Python mashup)


The one on the left is running the Gocupi firmware and is being run with Pycupi a Python port/rewrite of the Gocupi ‘Go‘ control software.

The other two are running the Polargraph.co.uk  a1_server firmware variant modified to run on our electronics.

The one in the middle is running with Pylargraph which is a Python script to control the original firmware with the intention of plotting or graphing the result of a regular twitter search.

The other is running with the Polargraph.co.uk control software.

The various 3d printed parts are our own designs or modified versions of existing designs.

My own designs are available on github and thingiverse but not everything is finished.