Simple — like, really simple — Arduino periodic timer with Brett’s MillisTimer library

I don’t know how many times I’ve written bad Arduino code to call a function every few milliseconds. Sometimes this bad code works well enough for my sketch to actually work. Often, it either doesn’t work at all or does something I really didn’t expect.

So on Arduino Day 2017, I’m glad I found out about bhagman/MillisTimer: A Wiring and Arduino library for working with millis(). It couldn’t be simpler to use: include the library, write the function you want to call every N milliseconds, set up the timer to run every N millis, and put in a loop that’s called frequently. The library handles the timing and resetting all by itself.

As an example, here’s the eternal “Hello, World!” of the embedded world, Blink, rewritten to use MillisTimer:

// MillisTimerBlink - blink LED every second
//  using Brett Hagman's MillisTimer library
//  (or use Sketch → Include Library → Manage Libraries … to install)
// scruss - 2017-04-01

#include <MillisTimer.h>
MillisTimer timer1;               // new empty timer object
const int led_pin = LED_BUILTIN;  // use the built-in LED

void flash() {                    // function called by timer
  static boolean output = HIGH;
  digitalWrite(led_pin, output);  // set LED on or off
  output = !output;               // toggle variable state High/Low

void setup() {
  pinMode(led_pin, OUTPUT);       // use built-in LED for output
  timer1.setInterval(1000);       // set timer to trigger every 1000 millis
  timer1.expiredHandler(flash);   // call flash() function when timer runs out
  timer1.setRepeats(0);           // repeat forever if set to 0
  timer1.start();                 // start the timer when the sketch starts

void loop() {;                   // trigger the timer only if it has run out
  // note that run() has to be called more frequently than the timer interval
  //  or timings will not be accurate

Note that MillisTimer only triggers when is called. Sticking a delay(2000) in the main loop will cause it to fire far less frequently than the interval you set. So it’s not technically a true periodic timer, but is good enough for most of my purposes. If you want a true interrupt-driven timer, use the MsTimer2 library. It relies on the timer interrupts built into the Arduino hardware, and isn’t quite as easy to use as MillisTimer.

μ̈ — the net-connected cowbell for your Internet of Tings … #arduinod17

μ̈ — the net-connected cowbell for your Internet of Tings … #arduinod17

View in Instagram ⇒

Futile Devices, pt 2940


You could say I overthought this “minimal” ATmega328 µcontroller build: switchable USB/external power, reset button, optional D13 LED for your blink() needs, high efficiency LM2940 LDO voltage regulator …

In the age of cheap 32-bit microcontroller boards available for a couple of dollars, there’s absolutely no reason to build one of these semi-custom 8-bit Arduino clones. I did it because I had all (well, nearly all —the 0.33µF tantalum cap needed on the output side of the the regulator I bought in) the bits in the house, and I wanted to see how few connections a modern microcontroller really needed. Once I’d seen just how few, I thought I’d make this thing easy to use … and got a bit carried away.

The EMSL breakout boards are really easy to work with, though they are thin and need care when soldered lead-free. The Minimalist Arduino (archive copy) is a good start, or you can work through the derived Instructable: Arduino from Evil Mad Scientist ATmegaxx8 Target Board.

I do kind of miss the diversity of form in the µc board market these days. Everything looks like an Arduino now. Tiny variants like the Solarbotics Ardweeny kept creative interest up. But with boards and chips so cheap these days, why bother?

Blinking on and off with the 74LS42

I want to make an edge-lit numeric display. These were a common technology before numeric LEDs were available. They use 10 illuminated slides to display individual numbers. Here’s my first try at the display:

Homebrew edge lit numeralsThe 74LS42 logic chip (4-Line BCD to 10-Line Decimal Decoder) seems a likely candidate to drive such a display. You feed it a 4-bit binary-coded decimal input, and the chip activates one of ten outputs. It’s a low-voltage version of the old 7441 chip used for driving Nixie tubes. Here’s what I got working as a demo of the 7442, driven by an Arduino:

(Video link for the iframe-averse:

From the video you can see that:

  1. The 7442 only passes inputs from 0 (0000b) to 9 (1001b). All other inputs result in no output.
  2. The outputs are really more like 1–10 than 0–9, as a zero input activates the first output.

Making a clean breadboard layout for this circuit was a little more work than I’d anticipated. It just fits on a half-sized breadboard:

Simple 7442 demo circuit, showing BCD inputs (green) and decimal outputs (orange)
Simple 7442 demo circuit, showing BCD inputs (green) and decimal outputs (orange)

Because the 7442 will only activate one output at a time, it’s okay to use a single current-limiting resistor for all ten output LEDs. The chip also uses active low outputs: the outputs go from high to low when activated. The negative side of each LED goes to an output pin, and the chip sinks current when an output is selected, lighting the LED.

The components get in the way of seeing the wiring, so here’s another picture from Fritzing with just the wires and the breadboard:

7442-no_componentsApart from the 74LS42 chip itself, the components I used were 10× 3mm orange LEDs on the outputs and 4× 3mm green LEDs on the inputs. I don’t have a spec for them (they were from a bargain selection box from so my use of ridiculously precise 332 Ω 1% resistors to limit current is a little unnecessary. (I have a bunch of these precision resistors from a project that didn’t go ahead, so using them is cheaper for me than digging about for a 5% one.)

Finally, here’s the Arduino sketch I wrote to drive the chip for the demo video. All it does is cycle through digital outputs 4–7, incrementing a bit every half second.

   SeventyfourFortytwo - Arduino demo of a
   74LS42 - 4-line BCD to 10-line decimal decoder
   Steps through 0-15, two steps per second
   Shows the 74LS42's blocking of values 10-15 as invalid

   Arduino  74LS42
   ======== =======
    4      - 15  Input A (bit 0)
    5      - 14  Input B (bit 1)
    6      - 13  Input C (bit 2)
    7      - 12  Input D (bit 3)

   scruss - 2016-09-23

int n = 0;

void setup() {
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);
  digitalWrite(4, LOW);
  digitalWrite(5, LOW);
  digitalWrite(6, LOW);
  digitalWrite(7, LOW);

void loop() {
  digitalWrite(4, n & 1);
  digitalWrite(5, n & 2);
  digitalWrite(6, n & 4);
  digitalWrite(7, n & 8);
  if (n > 15) n = 0;

If you felt really fancy, you could drive the LED inputs through PWM, and come up with just the right of flicker to make this look like a Nixie tube. You should also be able to chain the inputs through some shift registers, too.

ESP8266 BASIC is seriously neat!

screenshot-from-2016-09-19-22-27-57That picture might not look much, but it’s doing something rather wonderful. It’s a tiny ESP8266 BASIC script running on a super-cheap ESP8266 wifi module. The code draws a clock that’s synced to an NTP server. ESP8266 BASIC graphic commands are built from SVG, so anything you can draw on the screen can also be saved as a vector graphic:

The runtime includes a simple textarea editor that saves code to the board’s flash:

screenshot-from-2016-09-19-22-28-53(and yes, that first line is all you need to set up NTP sync)

Among other features, ESP8266 BASIC has a simple but useful variable display:

screenshot-from-2016-09-19-22-30-17I’d picked up a (possible knock-off of a) WeMos D1 ESP8266 board in Arduino form factor a few months ago. The Software now supports ESP8266 directly, so it’s much easier to program. Flashing the BASIC code to the board was very simple, as I’d noticed that the Arduino IDE printed all of its commands to the console. All I needed to do was download an ESP8266 BASIC Binary, and then run a modified Arduino upload line from the terminal:

~/.arduino15/packages/esp8266/tools/esptool/0.4.9/esptool -vv -cd nodemcu -cb 921600 -cp /dev/ttyUSB2 -ca 0x00000 -cf ESP8266Basic.cpp.bin

ESP8266 BASIC starts in wireless access point mode, so you’ll have to connect to the network it provides initially. Under Settings you can enter your normal network details, and it will join your wifi network on next reboot. I just hope it doesn’t wander around my network looking for things to steal …

Log your electricity consumption with Powermon433

NB: this is in the  early stages of development, but does work. It’s by no means a plug-and-play solution. You’re going to have to do some coding, and perhaps some soldering. Undaunted? Read on …

I really like the Blue Line Innovations PowerCost Monitor™ (aka the Black & Decker Power Monitor EM100B). I bought one long before the OPA started to give them away free to Ontario households as part of their peaksaver PLUS program. It’s a little device that clamps to your hydro meter and sends instantaneous power readings to a display.

Power Monitor displays — Black & Decker on the left, Blueline on the right

Wouldn’t it be so much better if you could log and analyze these data? So a day’s power consumption might graph to something like this:

PowerMonitor-20140929Yup, this is my real electricity consumption, as logged from the PowerCost Monitor. You can see the fridge cycling on and off, and I think the big mid-day spike was either the AC or the dryer; someone was home on that Monday. The rather blocky green line is Toronto Hydro’s hourly smart meter data. It really hasn’t got the resolution to show really detailed power use.

That spike at 06:30; what’s that? Let’s take a look:

PowerMonitor-20140929-kettleThat’s me boiling the kettle. You can see that the time resolution is better than a minute, and the power is to the watt. Mmm, coffee …

All of this is recorded using a simple Arduino-based solution, originally cooked up by Bryan Mayland. I’ve forked his code and added some instructions: scruss/Powermon433. Here’s the rig I’ve been using to log data over a USB serial link:

Arduino FIO compatible + RFM69W board + FTDI serial
Arduino FIO compatible + RFM69W board + FTDI serial

That’s a particularly ugly rig, due to the limitations of the 3.3 V receiver board I was using. There are other options that work with more normal Arduino boards up on github.

Here’s a sample of the data I’m logging, including the kettle incident:

Datetime Elapsed_s Energy_Wh Power_W Temp_C
2014-09-29T06:27:44 23241.7 25876 289 15
2014-09-29T06:28:16 23273.6 25876 290 15
2014-09-29T06:28:48 23305.5 25876 291 15
2014-09-29T06:29:20 23337.4 25892 294 15
2014-09-29T06:29:52 23369.2 25892 286 15
2014-09-29T06:30:24 23401.1 25892 277 15
2014-09-29T06:30:56 23433.0 25892 357 15
2014-09-29T06:31:28 23464.9 25892 1844 15
2014-09-29T06:32:00 23496.8 25892 1836 15
2014-09-29T06:32:31 23528.5 25952 1829 15
2014-09-29T06:33:03 23560.2 25952 1818 15
2014-09-29T06:33:35 23592.1 25952 1836 15
2014-09-29T06:34:07 23624.0 25952 1836 15
2014-09-29T06:34:39 23655.8 25952 1836 15
2014-09-29T06:35:11 23687.7 25952 1848 15
2014-09-29T06:35:43 23719.6 26048 1832 15
2014-09-29T06:36:15 23751.5 26048 2000 15
2014-09-29T06:36:46 23783.4 26048 2000 15
2014-09-29T06:37:18 23815.2 26048 2000 15
2014-09-29T06:37:50 23846.9 26048 368 15

You’ll see that I’m recording:

  • a system timestamp
  • the elapsed logging time, from the Arduino’s clock
  • instantaneous meter readings in watt-hours. Note that not every row has an update
  • the average power since the last record. The product of this and the time between records adds up to the energy consumption
  • the outside temperature in °C. This is not very accurate (in full sun it over-reads vastly) but better than nothing.

Compare that to the smart meter data:

DateTime Hour KwhUsage Cost Rate
2014-09-29 05:00:00 5 0.29 $0.02 $0.075
2014-09-29 06:00:00 6 0.31 $0.02 $0.075
2014-09-29 07:00:00 7 0.59 $0.04 $0.075

Not much data there, is there? Certainly not enough resolution to tell if a kettle has been running.

Even though this interface is homebrew and cheap, it is accurate. Here’s how four days of continuous readings stack up against Toronto Hydro’s meter:

  Power Monitor ndToronto Hydro Smart Meter
Day First Reading / Wh Last Reading / Wh Total Consumption / kWh No of readings Daily Total / kWh No of readings
2014-09-29 23896 43668 19.772 2711 19.77 24
2014-09-30 43668 52500 8.832 2710 8.82 24
2014-10-01 52500 68004 15.504 2711 15.51 24
2014-10-02 68004 81996 13.992 2712 13.99 24

The difference looks to me like aliasing; THES’s reporting is much more granular.

I’m going to develop this further to turn it into an easy (or at least, easier) to use logging platform. It’s taken us a few years to get here, but there’s nothing quite like a project finally working!

Screamingly fast HWRNG on Arduino Due

Well, look at this:

$ stty -F /dev/ttyACM0 speed 115200 raw cs8
$ rngtest -t 6 < /dev/ttyACM0
  … much snippage …
rngtest: bits received from input: 312368864
rngtest: FIPS 140-2 successes: 15602
rngtest: FIPS 140-2 failures: 16
rngtest: FIPS 140-2(2001-10-10) Monobit: 2
rngtest: FIPS 140-2(2001-10-10) Poker: 2
rngtest: FIPS 140-2(2001-10-10) Runs: 8
rngtest: FIPS 140-2(2001-10-10) Long run: 4
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=837.317; avg=1168.033; max=1948.060)Kibits/s
rngtest: FIPS tests speed: (min=16.834; avg=27.779; max=77.221)Mibits/s
rngtest: Program run time: 271917796 microseconds

Over a megabit/second of decent quality random data. This is from an Arduino Due, which has an Atmel SAM3X8E ARM Cortex-M3 microcontroller on board. I hadn’t found much use for this board previously, as it fell between a regular 8-bit Arduino and my (many!) Raspberry Pis.

This changed when I found out about Walter Anderson’s Entropy library, which uses µc timer jitter as a source of entropy. Originally designed as a slow but true source of random integers on the Atmel AVR chips, it’s been extended to use the SAM3X8E‘s built-in hardware RNG. Since the Due has a native USB port, you’re not limited to standard baud rates.

Here’s the code, trivially modified from one of Walter’s examples:

// Generate_Random_Bytes_Due - speedy demo of Arduino Due's HWRNG
// based on Generate_Random_Bytes, for Entropy, an Arduino library.
// Copyright 2012 by Walter Anderson
//  modified - scruss - 2014-08-13
// remember to reconnect to native USB port

#include <Entropy.h>

void setup() {
  while (!SerialUSB) {
    ; // wait for serial port to connect.

void loop() {
  uint16_t r = Entropy.random();

It’s a minor pain to have to reconnect the USB cable to the other port on the Arduino Due after programming, but it’s worth it just to see an 84 MHz µc belting out random bytes 37½% faster than an 800 MHz Raspberry Pi

An Intel Galileo running without wires

An Intel Galileo running without wires

Pretty much did everything here: Intel Galileo Meets Wireless, except I used one of the supported cards. These are the components that I bought on eBay:

Instagram filter used: Lo-fi

View in Instagram ⇒

Processing 2.1 + Oracle Java + Raspberry Pi + Serial + Arduino = ☺

Hey! This is very old and there’s an officially supported version out now coming out very soon.

Update for Raspberry Pi 2/Processing 2.2.1/Processing 3.0.5: Raspbian now ships with Java 8, and Processing only likes Java 7. oracle-java7-jdk is still in the repos, so install that, and follow the instructions below. It’s a bit flakey, but when it runs, runs quite fast on the Raspberry Pi 2. You might have more luck running Processing.js or p5.js in the browser.

With Sun Oracle hardfloat Java now available, Processing now runs at a decent clip on the Raspberry Pi. My old instructions are now very obsolete. Here are current, tested instructions for installing it under Raspbian.

[This is a particular solution to installing a Serial/Firmata-enabled Processing 2.1 distribution on a Raspberry Pi. Processing still has issues with other aspects of visual programming (particularly video) that I’m not addressing here.]

A lot of software is installed here, and much of it depends on previous steps. Don’t jump in mid-way and expect it to work.

Update the system

Always a good plan if you’re doing major upgrades:

sudo apt-get update
sudo apt-get dist-upgrade

Install Sun Oracle Java

sudo apt-get install oracle-java7-jdk

Check if the right version is installed as default: java -version should give

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)

If you get anything else, you need to make Sun Oracle’s version the default:

sudo update-alternatives --config java

Download & Install Processing

Go to Download \ and get the Linux 32-bit version.  It’s big; about 100 MB. I’m going to install it in my home directory, so the base path will be ~/processing-2.1. Extract it:

tar xvzf processing-2.1-linux32.tgz

Now you have to remove the included x86 Java runtime, and replace it with the Raspberry Pi’s armhf one:

rm -rf ~/processing-2.1/java 
ln -s /usr/lib/jvm/jdk-7-oracle-armhf ~/processing-2.1/java

You should now have a Processing installation that will run, but there’s some more we need to get serial and Arduino support.

Install the  java Simple Serial connector

Download and extract it:


Now overwrite the jssc.jar that ships with Processing with the one you just downloaded:

mv jSSC-2.6.0-Release/jssc.jar ~/processing-2.1/modes/java/libraries/serial/library/

(You can remove the jSSC folder now: rm -r jSSC-2.6.0-Release)

Test Processing’s serial support

You’re almost there! Fire up Processing:


and try Perhaps the World’s Most Boring Processing Sketch:

// Example by Tom Igoe

import processing.serial.*;

// The serial port
Serial myPort;

// List all the available serial ports

Screenshot from 2014-01-07 20:08:32When this runs (it’s a little slow), you should get a single line of output, which should start /dev/tty___:


(I have an Arduino Leonardo attached, which usually appears as an ACM device.)

Installing Arduino/Firmata support

(I’m not going to go into uploading Firmata onto your Arduino here. All I can recommend is that you use the newest version at firmata/arduino, rather than the old code bundled with your Arduino distribution.)

Exit Processing, and download from firmata/processing. Extract it into your Processing sketchbook:

unzip -d ~/sketchbook/libraries/

For tedious reasons, you also have to rename one of the files:

mv  ~/sketchbook/libraries/arduino/library/Arduino.jar  ~/sketchbook/libraries/arduino/library/arduino.jar

Start up Processing again, and  save Most Probably the World’s Second Least Interesting Processing Program™:

import processing.serial.*;
import cc.arduino.*;
Arduino arduino;
int ledPin = 13;

void setup()
  arduino = new Arduino(this, Arduino.list()[0], 57600);
  arduino.pinMode(ledPin, Arduino.OUTPUT);

void draw()
  arduino.digitalWrite(ledPin, Arduino.HIGH);
  arduino.digitalWrite(ledPin, Arduino.LOW);

Screenshot from 2014-01-07 21:13:54
What this sketch does is emulate the µC’s “Hello World” program, Blink. It flashes the board’s LED once per second. Boring? Yes. But if it worked, you have a working Processing 2.1 installation on your Raspberry Pi. Go forth and make more interesting things.
(Props to bitcraftlab/wolfing for the basic outline for installing Processing, and for samaygoenka for the prodding needed to update and test the Processing installation process. If you’re still stuck, the Processing 2.0 Forum and the Raspberry Pi Forum are good places to ask.)

Blueline / Black & Decker Power Monitor RF Packets

Update 2014-10-02: I’ve forked Bryan’s Arduino code and added some instructions: scruss/Powermon433 (though use Bryan’s, srsly)

Update 2014-08-19: Bryan Mayland has decoded the data on Arduino! More details here: CapnBry/Powermon433

Given that I first started thinking about reverse-engineering the Blueline Powercost Monitor‘s data stream in September 2010, I hardly win any awards for rapid development. Here’s what I know so far about the device and its transmissions:

  • The Blueline unit and the (now discontinued) Black & Decker Power Monitor (EM100B) appear to be functionally identical. Both transmit data using simple ASK/OOK at 433.92 MHz in the ISM band.
  • It is, however, completely different from the Norgo NGE101 meter, dammit.
  • The display unit is made by Hideki Electronic Limited, who make many small weather stations and wireless displays. [Pictures of the display circuit boards]
    Inside a Black & Decker Power Meter
  • The transmitter unit was designed by Intectus in Ottawa for Blueline. It uses a TI MSP430 µcontroller. [Transmitter board picture]
    Black & Decker Power Monitor: Meter Transmitter board
  • The transmitter can be triggered by simulating a power meter if you flash a 940 nm IR Emitter LED for 50 ms into its sensor. 1× 50 ms flash represents 1 Wh of power consumed. A pulse frequency of 1 Hz represents 3.6 kW consumption.
    Arduino-based domestic power meter simulator
  • The transmitter sends a bundle of three (seemingly) identical packets every 31.8 seconds. These appear to contain consumption data, as the display updates approximately every 32 seconds.
    a data packet bundle
  • A series of contiguous packets, recorded as audio using a simple circuit described by the Protocol Analyzer project: audio201311182215-silenced (FLAC; please note that interstitial silences have been blanked to reduce file size).
  • Temperature packets may be sent separately from power, as the display updates temperature much more slowly than power use.
  • Power packets only appear to contain use data (along with a transmitter ID). If the sensor receives an absolutely constant input, the packets transmitted 32 s apart can be identical.
  • The packets appear to be Manchester-encoded.

Some rough notes on mark/space timing (all times in µs):

Mark : Mean    529.4 Min    499.0 Max    590.0 StdDev:   15.03 
Space: Mean    694.5 Min    385.0 Max   1474.0 StdDev:  281.57

Mark/space times, by frequency (all times in µs):


Rank     Value   Count
-------- ------- -----
     1         522  498
     2         544  206
     3         567   32
     4         499   32
     5         590    8


Rank     Value   Count
-------- ------- -----
     1         476  279
     2         975  223
     3         454   99
     4         952   65
     5         431   26
     6        1474   22
     7         408   21
     8         499   17
     9         998   12
    10      199000    8
    11         385    2
    12        1451    2

More later, including raw packet data.

Thanks to Randy Simons and Bryan Mayland for the recent help. Thanks too to Brett “Wiring” Hagman for asking just why I was trying to do this …

A little basic Arduino kit

little arduino kit

A friend asked me what the whole Arduino thing was about. Rather than handwave, I thought I’d put together a little kit he could try. It comprises:

Rather worryingly, almost all of this was stuff that was lying spare on my (very small) workbench. This might explain why very little electronics were getting done there.

Artisanal Hardware Random Number Generator

Artisanal Hardware Random Number Generator

Artisanal Hardware Random Number Generator — scruss
(the Flickr page has popup notes about the circuit.)

Trickles out a few thousand made-with-love organic random numbers per second to the attached Arduino. The circuit is essentially Rob Seward’s True Random Number Generator v1 (after Will Ware, et al) which uses a MAX232 to power two reverse-biased 2N3904s to create avalanche noise. Another 2N3904 amplifies the resulting noise into something an Arduino can sample using AnalogRead(). Many modern processors include hardware RNGs (such as RdRand in recent Intel chipsets) so this circuit is just a toy now.

My interest in random number generators didn’t just arise from yesterday’s post. I’ve had various circuits breadboarded for months gathering dust, so I thought I’d pull out the most successful one and photograph it. Hardware RNGs seem to be a popular hobby electronics obsession, and there are many designs out there in variable states of “working” and/or “documented”. I wanted one that could be powered from the 5V rail of an Arduino, and didn’t use too many expensive components. Rob’s RNG Version 2 circuit and code is the basis, but I replaced the 12V external supply with the MAX232 circuit he used in version 1.

Perhaps the reason that there are so many RNG projects out there in various states of abandonment is that making a good, reliable hardware RNG is hard. Just a few of the things you have to think about are:

  • Analogue sources of noise can fade over time; power supplies droop as capacitors age, contacts can corrode, … How do you deal with this fade? If the output becomes so small, can you rely on those few bits from your A→D converter to be useful noise?
  • Could someone try to attack your RNG so they can influence the results of your secure transactions? How would you detect it? How would you signal to the data user that something is amiss securely, such that an attacker couldn’t fake distress behaviour?
  • What if the generator just stops? How do you flag that in a trusted “no really i mean it and it’s really me saying this not some attacker honest no” way? There may still be a tiny bit of noise that your circuit picks up; are you sure it’s your kind of noise, or some attacker trying to inject noise into your system? Remember, testing for real noise is exceptionally hard, and you can’t guarantee that a hardware RNG that worked today will work properly tomorrow.

(I’d like to thank Peter Todd for providing most of those issues over a pint and a chat during from a keysigning event. Peter saved me from spending too many hours working on this by hinting that — just maybe — I didn’t actually know what I was doing…)

If you want to read more on how to build a proper hardware RNG, the article “Understanding Intel’s Ivy Bridge Random Number Generator” and its references make a good (if very technical in places) introduction. I’m nowhere near paranoid enough to experiment further with RNG design, although I do have all the components to build an LM393-based XR232USB

USB Fart Detector (unfortunately)

It is a truth universally acknowledged, that an engineer in possession of a solid-state flammable gas detector, will shortly make a fart detector with it. I’m sorry, but call it childishness, simple-minded curiosity, or the results of a diet high in polysaccharides, but this is something I have to get out of my system. (It’s okay; I’ll waft the door.)

This all started when our carbon monoxide detector decided it was past its best, and started to emit an ear-splitting shriek. Thinking there might be some cool parts inside, I took it apart. Inside, in amongst the other stuff, I found this:

gas sensor boardThankfully, David Cook of Robot Room had once had the same idea as me (well, minus the puerile bits), and he documented the sensor board very well: Explosive Gas Detector Board. Here are the four pins that you really need to get the thing going:

 Pin # (from left)    Function
===================  ==========
       1              Vcc
       2              /Enable
       3              /Gas
       5              Gnd

Pins 2 and 3 are active low signals. To be typographically correct, I’d write them as Enable and Gas, but that’s hard to do in fixed-pitch ASCII. I can understand why the Gas signal should be active low (think about it; if the Figaro TGS 2611 sensor fails or shorts, it will likely fail to an alarm state, so you’ll still be alive to curse the bloody noise that woke you at 03h00), but the Enable being active low? Dunno.

I was hoping to have presented a little sketch for the Digispark that would have typed something unhelpful every time that gas was detected, but it was not to be. It seems that Macs and Digispark keyboard emulation is a thing of great wobbliness, so I had to resort to an Arduino and a serial connection.

Here’s the code:

 gas_detector - uses board scavenged from CO detector
 scruss - 2013-02-18 (unfortunately)

int gas     = 2;               // /Gas line on pin 2
int val     = 0;
int lastval = 0;

void setup() {                
  pinMode(gas, INPUT);

void loop() {
  val = digitalRead(gas);
  if (val != lastval) {
    if (val == LOW) {          // LOW means gas detected
      delay(1000);             // wait 1s for air to clear
  lastval = val;

Before you ask, I tested the circuit by briefly hitting the button on a gas lighter. Honest.

I’ll keep working on the Digispark; it’s such a nifty little device, and this is such a worthy project …

Ever heard the term “Appropriate Use of Technology”?

Well, this is not that: For He’s a Jolly Good Fellow [mp3], as played on this:

— an Arduino driving a stepper motor driving a Sankyo musical box. And yes, heat-shrink tubing ‘reinforced’ with dental floss doesn’t make a very robust flexible coupling.

python + Arduino + Tk: Toggling an LED

Phil sent me a note last week asking how to turn an LED on or off using Python talking through Firmata to an Arduino. This was harder than it looked.

It turns out the hard part is getting the value from the Tkinter Checkbutton itself. It seems that some widgets don’t return values directly, so you must read the widget’s value with a get() method. This appears to work:

# turn an LED on/off with a Tk Checkbutton - scruss 2012/11/13
# Connection:
# - small LED connected from D3, through a resistor, to GND

import pyfirmata
from Tkinter import *

# Create a new board, specifying serial port
# board = pyfirmata.Arduino('/dev/ttyACM0') # Raspberry Pi
board = pyfirmata.Arduino('/dev/tty.usbmodem411') # Mac

root = Tk()
var = BooleanVar()

# set up pins
pin3 = board.get_pin('d:3:o') # D3 On/Off Output (LED)

def set_led():  # set LED on/off
    ledval = var.get()
    print "Toggled", ledval

# now set up GUI
b = Checkbutton(root, text = "LED", command = set_led,
                variable = var)
b.pack(anchor = CENTER)


This is explained quite well here: Tkinter Checkbutton doesn’t change my variable – Stack Overflow. I also learnt a couple of things about my previous programs:

  • You don’t really need to set up an Iterator unless you’re reading analogue inputs
  • My “clever” cleanup-on-exit code actually made the script hang on Mac OS.

Power Cost Monitor signals — for reals!

After doing almost nothing with the Arduino and the elusive Power Cost Monitor signal, I’m finally getting something from it. Matt Colyer’s Power Monitor sketch does all the heavy lifting, for he managed to reverse engineer the protocol. His solution is a rather complex one, involving ethernet shields and Ruby. All I wanted was a simple serial logger, so I cut down Matt’s code, and modified the network output to simple print statements:

== Waiting (38464857ms, 1676 bytes) ==
== Sending (38467858ms, 1668 bytes) ==
== Waiting (38467863ms, 1676 bytes) ==
== Received (38592156ms, 1670 bytes) ==
== Waiting (38592157ms, 1676 bytes) ==
== Sending (38595158ms, 1668 bytes) ==
== Waiting (38595159ms, 1676 bytes) ==
== Received (38624334ms, 1670 bytes) ==
== Waiting (38624335ms, 1676 bytes) ==
== Sending (38627336ms, 1668 bytes) ==
== Waiting (38627337ms, 1676 bytes) ==
== Received (38688007ms, 1670 bytes) ==
== Waiting (38688009ms, 1676 bytes) ==
== Received (38688045ms, 1670 bytes) ==
== Waiting (38688046ms, 1676 bytes) ==
== Sending (38691047ms, 1668 bytes) ==
== Waiting (38691052ms, 1676 bytes) ==
== Received (38720026ms, 1670 bytes) ==
== Waiting (38720027ms, 1676 bytes) ==
== Sending (38723028ms, 1668 bytes) ==
== Waiting (38723030ms, 1676 bytes) ==
== Received (38783686ms, 1670 bytes) ==
== Waiting (38783687ms, 1676 bytes) ==
== Sending (38786688ms, 1668 bytes) ==
== Waiting (38786689ms, 1676 bytes) ==
== Received (38815636ms, 1670 bytes) ==
== Waiting (38815637ms, 1676 bytes) ==
== Sending (38818638ms, 1668 bytes) ==
== Waiting (38818639ms, 1676 bytes) ==
== Received (38847547ms, 1670 bytes) ==
== Waiting (38847548ms, 1676 bytes) ==
== Sending (38850549ms, 1668 bytes) ==
== Waiting (38850550ms, 1676 bytes) ==
== Received (38879444ms, 1670 bytes) ==
== Waiting (38879446ms, 1676 bytes) ==
== Sending (38882445ms, 1668 bytes) ==
== Waiting (38882446ms, 1676 bytes) ==
== Received (38911210ms, 1670 bytes) ==
== Waiting (38911211ms, 1676 bytes) ==
== Sending (38914212ms, 1668 bytes) ==
== Waiting (38914213ms, 1676 bytes) ==
== Received (39006981ms, 1670 bytes) ==
== Waiting (39006982ms, 1676 bytes) ==
== Sending (39009982ms, 1668 bytes) ==
== Waiting (39009983ms, 1676 bytes) ==
== Received (39038895ms, 1670 bytes) ==
== Waiting (39038896ms, 1676 bytes) ==
== Sending (39041897ms, 1668 bytes) ==
== Waiting (39041898ms, 1676 bytes) ==
== Received (39102999ms, 1670 bytes) ==
== Waiting (39103000ms, 1676 bytes) ==
== Sending (39106001ms, 1668 bytes) ==
== Waiting (39106002ms, 1676 bytes) ==
== Received (39134880ms, 1670 bytes) ==
== Waiting (39134881ms, 1676 bytes) ==
== Sending (39137882ms, 1668 bytes) ==
== Waiting (39137883ms, 1676 bytes) ==

Now it’s just a small matter of programming to work out what Matt’s Ruby code does. Ruby always looks to me like two programmers started coding at different ends of the same line, and collided in the middle. I’m hoping there’s enough processing power in the Arduino to do the conversion in the chip, and output useful log data as a serial stream.

More later …



pretty-printing Arduino sketches

I don’t often need it, but the code printing facility in the Arduino IDE is very weak. It has some colour highlighting, but no page numbering, no line numbering, and no headers at all.

a2ps will sort you right out here. Years back, it was a simple text to PostScript filter, but now it has many wonderful filters for pretty-printing code. The Wiring/Arduino language is basically C++, and a2ps knows how to deal with that. So, to create a PostScript file with a nice version of the the most basic Blink sketch:

a2ps --pro=color -C -1 -M letter -g --pretty-print='c++' -o ~/Desktop/ Blink.ino

If you’re somewhere that uses sensible paper sizes (in other words, not North America), you probably don’t want the -M letter option. a2ps is supposed to have a PDF print option (-P pdf), but it doesn’t work on my installation, so I just splat the output through ps2pdf. The results are linked below:

Not bad, eh?

(Update: think I must have written this post on a Mac with a case-insensitive filesystem. Using the --pretty-print='C++' option I had before failed on Linux.)

yay tiny stepper motor!

Active Surplus Electronics is the best. I was wanting to learn about driving stepper motors from a microcontroller, but didn’t want to spend a lot or rig up a complex power supply. Active Surplus had a bin of tiny 5V stepper motors at under $3 each. The one I bought is marked:

50-03500-    028
 MALAYSIA   7115

I have no data sheet, but I’ve been able to work out that it’s a unipolar stepper motor, 20 steps/revolution (18°/step; quite coarse), wired:

  • Centre tap: Brown
  • Coil A: White, Red
  • Coil B: Orange, Blue

It’s small enough to be driven directly by USB power through an Arduino and the Adafruit Motor Shield. No idea how much torque this thing puts out, but it can’t be much.

(Setting up my motor shield was a pain, as I’d accidentally put non-stacking headers on it. This required an hour of swearing-filled desoldering; lead-free through-hole desoldering is just the worst*. With wick and solder pump, I finally managed to clear everything up well enough to fit the new headers.)
Continue reading “yay tiny stepper motor!”

The MagPi

Yay! My article on Arduino and Raspberry Pi is this month’s cover of The MagPi! Read it on Issuu, or download the PDF.

Thanks to Ash and the rest of the team at the magazine.

Servo Control from pyfirmata + arduino

pyFirmata‘s documentation is, to be charitable, sparse. After writing Raspberry Pi, Python & Arduino *and* a GUI (which should be making an appearance in The MagPi soon, w00t w00t!), I looked at pyFirmata again to see what it could do. That pretty much meant digging through the source.

Firmata can drive hobby servos, and if you’re not driving too many, you can run them straight from the Arduino with no additional power. I used a standard cheapo-but-decent Futaba S3003, which gives you about 180° of motion. The particular one I tried started to make little growly noises past 175°, so in the example below, that’s hardcoded as the limit.

# -*- coding: utf-8 -*-
# move a servo from a Tk slider - scruss 2012-10-28

import pyfirmata
from Tkinter import *

# don't forget to change the serial port to suit
board = pyfirmata.Arduino('/dev/tty.usbmodem26271')

# start an iterator thread so
# serial buffer doesn't overflow
iter8 = pyfirmata.util.Iterator(board)

# set up pin D9 as Servo Output
pin9 = board.get_pin('d:9:s')

def move_servo(a):

# set up GUI
root = Tk()

# draw a nice big slider for servo position
scale = Scale(root,
    command = move_servo,
    to = 175,
    orient = HORIZONTAL,
    length = 400,
    label = 'Angle')
scale.pack(anchor = CENTER)

# run Tk event loop

The code above makes a slider (oh, okay, a Tkinter Scale widget) that moves the servo connected to Arduino pin D9 through its whole range. To set the servo position, you just need to write the angle value to the pin.

I haven’t tried this with the Raspberry Pi yet. It wouldn’t surprise me if it needed external power to drive the Arduino and the servo. This might be a good excuse to use my Omega-328U board — it’s Arduino code compatible, runs from an external power supply, and has Signal-Voltage-Ground (SVG) connectors that the servo cable would just plug straight into.