Motorola MC68020 Processor Board from 1987

In 1987 a company I worked for (Epoch Systems; it no longer exists) designed and built this custom 68020-based processor board for a file server. I did the Unix port (4.2bsd from vax) for this system.


A few notes for the hard core nerds. Bring up the full resolution version to see some of these details. Note: when downloading the full picture, the preview comes up quickly (and is blurry); wait for the full download.

  • The main processor (MC68020) is bottom center-right.
  • To the right of that is the memory management unit: XC68851. That’s supposed to be “MC” not “XC” but we were building these boards before Motorola released the final MMU chips so some of our early boards were built with the “experimental” MMU chips. I believe these made it into the field at customer sites but I’m not sure.
  • There was a separate dedicated I/O processor and that’s the second MC68020 top left.
  • The board was part of a custom NFS fileserver, which used optical jukeboxes and supported a whopping 30GB of storage in the base configuration; expandable up to 150GB. We called this “Infinite Storage” (really!)
  • The yellow arrow stickies in various places point to areas where ECOs were done (bug fixes; this board is serial #6)
  • The processor cycle was 25MHz, which was fast at the time, and the board is an early example of surface mount technology. The engineers were debating whether to use surface mount or not, but in the end that was the only way they could cram all that stuff onto the “small” form factor board. I think there were 12 layers of traces in the printed circuit board but I don’t remember for certain.

Traffic Light shows … Numerous is still dead

A while ago I built a simple visual display for the current Austin-area air quality index:

The light was green for good AQI, yellow for medium, and red for bad air quality. For the AQI data I leveraged a “metric” that I had already developed using the Numerous service. Being a hard core nerd I also covered the case where the Numerous server could not be contacted; the display is red and yellow for that.

As you can see here, the error handling code works. Numerous shut down operations permanently on May 1, 2016 and my traffic light display is now simply a reminder of their demise. 🙁

Numerous is down


Making a simple systemd file for Raspberry Pi jessie

I wanted to write a systemd service file for a daemon I wanted started automatically at boot on my Raspberry Pi running Debian Jessie.

This used to be a lot simpler in the old hardcore Unix days. Well, no, actually, it’s simpler now. But figuring out how to do it was anything but simple and took me the better part of a day. Maybe I’m just bad at google, but I couldn’t find a simple “just do THIS” recipe; all I could find was hopelessly detailed and complex descriptions of systemd stuff that exceeded my newbie level of understanding and exceeded my geezer level of interest in reading lots of stuff.

So, here, in the hope that someone else will find this via google someday and find it useful, is how to do it. Or, at least, one way that works.

Step 1: Make a clown.service file

Assume you want /usr/local/bin/clown started at boot time, with the arguments: -name bozo

Make a file in /lib/system/systemd, called “clown.service”. Whatever you call this file (the “clown” part in this example) becomes the name of the service. Here’s what you need in the file:

Description=Clown server for jessie

ExecStart=/usr/local/bin/clown -name bozo


The key things you may need to change (besides the obvious command name and arguments) are the Type and the Restart entries.

Type=simple says your program doesn’t fork (i.e., needs to be “daemonized” by systemd). There are other options; look these up in the systemd documentation yourself if you have a more complex scenario.

Restart=always says that any time the program exits it should be started right back up again. This is exactly what I needed as my program isn’t supposed to die, but if it does I want it started again. The systemd program implements throttles on how often this happens in case things have gone haywire.

The [Install] section tells it to run the service whenever the system is in multi-user mode, and the After= part up top tells it not to start the service until the network is up.

Step 2: Tell systemd about this file

It’s not enough to just drop this file into the /lib/systemd/system directory. You also need to execute this command (just once, ever, for a new service file):

% sudo systemctl enable clown.service

You need to do that as root (hence the sudo, or just be root). You’ll get a message about it creating some symbolic links, which is good.

And … that’s it.  Reboot and pray!

User Interface Rant

I have one of these:


You get it from these guys:

It is, in fact, the simplest internet user interface in the world. It’s just a big red button with WiFi. Without doing any programming you can set it up to send an email, a text, tweet, interface with IFTTT/Zapier, etc. And if you are a programmer it has a REST API and can do web hooks. So, basically, you can use this button for almost anything.

It’s simple. It’s pretty (it’s Scandinavian). It works. It’s awesome.

Except now we get to the rant. The configuration interface.

Like most devices of this nature, you configure it by surfing to the device, which brings up the chicken-and-egg problem of how you tell the device what WiFi network (and password) to use. Bttn uses a fairly common approach (Chromecast also does this) of having the device itself be an access point with a custom WiFi network “bttnconf” in this case.

So, to configure it, you power it up in configuration mode (hold button down while inserting batteries), set your computer onto the bttnconf WiFi network, and surf to the device which is always the “.1” IP address on the local network it establishes (in particular, it is

Rant: and then you see this:


which, besides being rather techie and obscure looking (in contrast to the beauty of the physical button), ISN’T THE CONFIGURATION INTERFACE YOU WANT/NEED.

Nope. The home page of the button is some internal configuration page (looks like you are configuring the bttnconf WiFi itself).

The page you need to surf instead is:

Why? Why?? Sure, when I read the instructions the first time (months ago) I “got it right”. But now I needed to redo the configuration, and I thought I remembered how to do it. Power up while holding down the button. Check. See bttnconf WiFi network. Check. Surf to the device.

Not check. Confusion.

In my case, because I was already having problems with the button, this caused me to file a trouble ticket with their support, who very politely reminded me that surfing to was wrong and that I needed to surf to


and then I got the expected, graphically-oriented,interface for filling in my WiFi network name and password.

Shouldn’t the home page of the device be the nice interface, and the internal configuration page be at /config or something like that? Shouldn’t the config page also have a link “If you are trying to set up your button click HERE” or something like that?

Kind of disappointing given all the “design” (meaning appearance/UI) that went into the overall product.

Traffic Light shows Air Quality Index

I recently saw this project: Traffic Light Shows Internet Status at the “WTH” (whiskey tango hotel) website and decided it would be fun to build. So here we go.

I found the same traffic light available on Amazon:

I decided (of course) to make a few changes to the project:

  • I used a BeagleBone Black (BBB), simply because it was something I had sitting in the “random leftover stuff” bin. It’s the same idea as a Raspberry Pi – it’s a small inexpensive box running Linux.
  • I completely redid the internal wiring of my toy traffic light to separate out each LED connection individually (six wires total) whereas WTH implemented his project leaving the original common anode wiring intact (4 wires total coming out of the traffic light). I’d like to say I rewired for a particularly good reason but I didn’t really; I just did it during debugging because I was confused. But, as a result, I am presenting an alternate implementation of the circuitry.
  • I hooked my traffic light up to Numerous (of course) and it is currently displaying my Austin Air Quality Index metric. It displays the red light for bad air quality, yellow for moderate, and green for good.

Modifying the Traffic Light

As WTH did, I opened the base of the light (four screws) and removed the small circuit board inside by cutting its connections.

I then opened the back of the traffic light itself (another four screws). The original connections look like this:

2015-10-21 19.24.29


Schematically, the light is wired like this:


original-led copy

Notice how they oriented the LEDs to make the common-anode setup easier to wire.

I cut all these connections, took a cat5 cable, separated out three pairs (6 wires) and brought the individual anode/cathode connections from each LED out of the traffic light. Beware software engineers with soldering irons! But it seemed to work out ok.

To help me keep track of what was going on, I was careful to set up this color code:

  • Brown – anode (positive) side of the red LED
  • Brown/white – cathode (negative) side of the red LED
  • Orange – yellow LED anode
  • Orange/white – yellow LED cathode
  • Green – green LED anode
  • Green/white – green LED cathode

Obviously the color choices don’t matter – but if you do rewire your entire light make sure you keep track of which ones are the anodes and cathodes in some methodical manner.

The LEDs need to be wired in series with a resistor (for current-limiting) and connected to the BBB. On the BBB I used GPIO outputs 1-16, 1-17, and 1-18, which are also known in the /sys/class/gpio filesystem as gpio48, gpio49, and gpio50. The BBB has three GPIO chips; chip 0 occupies gpio0..gpio31, so each input/output on GPIO chip 1 is numbered as “n + 32”. Thus GPIO 1-16 is known as “gpio48” in the /sys/class/gpio filesystem.

The pins for gpio48, 49, and 50 are on connector P9 as shown here:


You’ll also need to make a GND connection, which can be common across all three LEDs. I connected it all up according to this schematic:


The BBB GPIO outputs only supply 3.3V whereas the design used by WTH supplies 5V. 3.3V is still enough to light the LEDs but the calculation for the total amount of current (which determines brightness) will be different. The fixed voltage drop across an LED varies by color, but using 1.9V as an approximate average value the amperage calculation for 470Ω looks like this:

(3.3V – 1.9V) / 470Ω = approximately 3ma

This is within the current that the BBB can supply on these particular output pins. The corresponding current flow from the Pi at 5V is:

(5V – 1.9V) / 470Ω = 6.6ma

I decided to try 470Ω and see if it was bright enough for my purposes; it was. If you want to try experimenting you could reduce the 470Ω resistor. Be careful not to overdrive the LED nor overdraw the GPIO outputs.

I stuck with 470Ω as I already mentioned; this has the added advantage of my trivial little circuit board still being ok if I move it to a Pi at 5V.

Controlling the lights

Now to write some software. While I was changing everything else about the WTH approach, I decided to also just use the /sys/class/gpio “special text files” to control the outputs. To do this first you have to “export” the pins you want to control this way. At the shell you do this:

    root# echo 48 > /sys/class/gpio/export
    root# echo 49 > /sys/class/gpio/export
    root# echo 50 > /sys/class/gpio/export

which tells the kernel you’ll be using the filesystem interface for pins 48, 49, and 50. You only have to do this once per boot (assuming no one ever unexports them after you export them).

Then you have to set their direction. You can also give an initial setting (high or low) at the same time:

    root# GP=/sys/class/gpio
    root# echo high > $GP/gpio48/direction
    root# echo high > $GP/gpio49/direction
    root# echo high > $GP/gpio50/direction

At this point you turn an individual GPIO on or off like this:

    root# GP=/sys/class/gpio
    root# echo 1 > $GP/gpio48/value

Writing 1 turns it on; writing 0 turns it off.

I wrote python code to do exactly this. Note that you have to be prepared for the export requests to fail if the pins have already been exported by a previous run. My code for setting up the pins looks like this:

gp = '/sys/class/gpio'
gpdir = gp + '/gpio{}/direction'

pins = {'red':'48', 'yellow':'49', 'green':'50' }

for color in pins:
    with open(gp + '/export', 'w') as f:
      f.write(pins[color] + '\n')
    with open(gpdir.format(pins[color]), 'w') as dirf:
  except OSError:

If you want, you could check the OSError and make sure that if something fails it was because the export was already done a previous time. But pragmatically this suffices.

I wrote a python function to turn an individual light on or off:

gpio_v = gp + '/gpio{}/value'

# call with, for example:
#    color == 'red' 
#    onoff == 1
# to turn on the red LED
def light_onoff(color, onoff):
  with open(gpio_v.format(pins[color]), 'w') as f:

# convenience function:
def alllightsoff():
  light_onoff('red', 0)
  light_onoff('yellow', 0)
  light_onoff('green', 0)

Now that we have the basic tools for manipulating the lights, we’re ready for the final code.

Connecting to Numerous

I used my Numerous class library ( and/or “pip install numerous”) to get the value of a metric I wanted to display; in this case I am reading my Austin Air Quality Index . This is a public metric, anyone who wants to read it is permitted to do so.

The government defines an AQI value of 50 or less as “Good”, a value of 51 to 100 as “moderate”, and values above 100 as various increasing levels of “bad”. I’m displaying those on my light with the obvious mapping to red/yellow/green. The code for doing this looks approximately like this (simplified for presentation here):

import numerous
m = numerous.NumerousMetric('7896524241619416448')

  q =
except numerous.NumerousError:
  q = -1

if q == -1:
  light_onoff('red', 1)
  light_onoff('yellow', 1)
elif q < 51:
  light_onoff('green', 1)
elif q < 101:
  light_onoff('yellow', 1)
  light_onoff('red', 1)

Notice that if there was an error talking to the Numerous server I display both a red and yellow light simultaneously.

The actual code loops around this, reading from Numerous once every three minutes to get any new values.

Bells and Whistles

Right after I get a (possibly) new value from Numerous I run a loop that “rolls” the traffic lights, rapidly looping green, yellow, red, green, yellow, red, etc. This lets you know that the system is working and also turned out to be a cool looking effect. The code for doing this looks like this:

dt = 0.03
for i in range(30):
  light_onoff('green', 1)
  light_onoff('green', 0)
  light_onoff('yellow', 1)
  light_onoff('yellow', 0)
  light_onoff('red', 1)
  light_onoff('red', 0)

# ... now update the light based on Numerous

It almost looks visually as if the lights are “spinning” and finally settling on whatever the new value dictates.

In addition to rolling the lights when updating from Numerous, every thirty seconds I blink whichever light happens to be turned on as another way for you to know that the system is still alive and well.

The Actual Code

For presentation purposes here I’ve simplified the code snippets shown in the discussion and edited them to make it fit the screen better. The full source code I am running for my traffic light is here.

Buttoning it all back up

The cat5 wire I used fits very well into the tube/base of the toy traffic light. I did drill a hole in the side of the plastic base so that the light could stand up and the wire could come out through the side of the base. I did this by hand using a pin vise starting with a small bit and basically reaming the hole gradually larger with increasing bit sizes. I’m not 100% sure if that amount of care was necessary, but it worked.

I also wedged some hex nuts into the (now unused/disconnected) battery compartment in the base to weight the traffic light better. I really want to go get some better lead weights for this but for now the hex nuts seem to work reasonably well at keeping the light upright despite the new leverage point from the cable sticking out of the base.

My “circuit” which consists of a whopping three resistors is sitting on a tiny project breadboard that I just double-sticky-taped to the top of the BBB case. The whole thing *almost* fit inside the case; I’m tempted to just hand-solder and hand-construct a small assembly that can in fact be jammed into the case leaving nothing but the cat5 wire coming out of the case and running to the traffic light.

Here’s the result – before I was able to add some cable dressing/management:


Air quality was good ( < 50) at the time this picture was taken.

Geeking out even more with Pythagoras and Lego triangles

In case my previous musings on lego triangles weren’t geeky enough for you, here’s some more.

60 degree 3-7-8 / 5-7-8 math

In my prior note I pointed out that you could construct an exact 60 degree angle with a 3-7-8 or 5-7-8 construction, such as this one:


The blue technic beam is the “7” unit leg. Building this within an 8-8-8 equilateral triangle helps convince us that the angle opposite the 7 unit beam is a 60 degree angle.

In the prior post I wrote “This construction is probably demonstrating some deep mathematical relationship between the 3-7-8 60 degree construction and the 5-7-8 construction; perhaps someone will point it out to me and I’ll add it back into this note.”

Well I’ve worked it out for myself.

Review: Trigonometry says that if we know sides a, b, and c and we want to know the angle B opposite side b, we can start with the law of cosines:

b^2 = a^2 + c^2 – 2*a*c * cos B

In the case where angle B is 60 degrees, cosine(60) is exactly 1/2, so this formula becomes:

b^2 = a^2 + c^2 – a*c

Now we can see why (a,b,c) = (3,7,8) forms a 60 degree angle opposite the 7 side:

7^2 = 3^2 + 8^2 – (3*8)
49 = 9 + 64 – 24

The numbers work; (3,7,8) is consistent with that equation and therefore the angle opposite the b side is a 60 degree angle.

It follows from this that if (a, b, c) is a solution then (c – a, b, c) is also a solution. To see this, work the substitution of c-a for a through the equation.

Thus once we know (3,7,8) has the 60 degree angle in it we could find (x, 7, 8) where:

x = c – a
x = 8 – 3

which gets us the (5, 7, 8) solution.

Some other integer solution pairs to this are:

  • (5, 19, 21) and (16, 19, 21)
  • (7, 13, 15) and (8, 13, 15)
  • (11, 31, 35) and (24, 31, 35)

That last pair is huge but might be useful if divided in two using half-unit construction.

I built a nice looking 5,7,8 connection inside a 9-9-9 equilataral, all built using system bricks just as a demo.

5-7-8 inside equilateral; top view
5-7-8 inside equilateral; top view
5-7-8 inside equilateral; bottom view
5-7-8 inside equilateral; bottom view

I had to use “pylons” (visible in the bottom view) to make this work because, as usually happens with the system brick triangle constructions, the adjacent studs will interfere unless you build up using a pylon/riser construction.

Other Fractional Construction Techniques

Lego CAD tools that make use of the LDraw system define brick geometry in units called LDU (an “LDraw Unit” I suppose). A standard system brick is 24 LDU high and the stud-to-stud (or hole-to-hole in technic) spacing is 20LDU. So far we have been talking about constructions using an integer number of holes (20LDU) or half-holes (10LDU).

Because of the 24:20 (6:5) ratio of stud-spacing vs brick height, turning bricks on their side gives offsets other than just integers and halves. Bricks on their sides is called SNOT: “Studs Not On Top”

This allows resolution down to 4LDU for offsets, corresponding to 0.2 of the stud-to-stud distance. By using system bricks (with technic holes as required) we open up many more angle possibilities, including some new Pythagorean triples such as:

(6.6, 11.2, 13)

Of course, that triple was already “available” as an integer construction, with the original Pythagorean triple being an enormous (33,56,65). It could be reduced to (16.5, 28, 32.5) using half-unit construction, but the SNOT techniques allow us to realize that particular construction this way:


It may be easier to see this in an LDraw:


I left the pins out of this rendering just for clarity so you could see all the holes.

Look at the vertical element in more detail:


This shows the general technique for achieving fractional distance at 0.2 resolutions. Every “system” brick laid on its side adds 24 LDU (or 1.2 “holes”) to the distance. As with the technic beams you have to be mindful of the +1 factor because what matters is the center-to-center distance. So it takes a stack of four system bricks on their side to add a total of three times the height of a single system brick. The net of this construction is that the vertical segment is 6.6 units in length. The math for the other part of the construction works similarly.

Recap: Complete Pythagorean Triangle List

Taking all these techniques together, here is the complete list of Pythagorean Triangles you can make with the maximum dimension being less than 25 (there are more above that point), and the angle you get for the hypotenuse. The table is sorted by angle A, the smaller angle of the two non-right angles (the other angle is always 90 – A).

Table without using any SNOT techniques:

 4.5   20 20.5   12.680
   7   24   25   16.260
   6 17.5 18.5   18.925
   5   12   13   22.620
   8   15   17   28.072
   3    4    5   36.870
  10 10.5 14.5   43.603

Table including SNOT triangles:

 2.6 16.8   17    8.797
 4.5   20 20.5   12.680
 3.2 12.6   13   14.250
   7   24   25   16.260   
    ... SNOT version: 2.8, 9.6, 10
   6 17.5 18.5   18.925
 8.8 23.4   25   20.610
   5   12   13   22.620
 7.2 15.4   17   25.058
   8   15   17   28.072
 6.6 11.2   13   30.510
   3    4    5   36.870
  10 10.5 14.5   43.603

Of course you can scale entries in the table. So, for example. you could make the SNOT version of (7,24,25) at (5.6, 19.2, 20) though at that point you probably might as well make it using the integer (7,24,25) construction.

New versions of API libraries

Released new versions of both the Python and Ruby interfaces to the Numerous APIs. This update allows you to call write() with the “only write it if the value changed” feature and just ignore any exception that comes (when the value hasn’t changed). This is probably a more common usage pattern. So now, for example, you can do this in python:

m.write(newvalue, onlyIf="IGNORE")

where before you would have had to write:

    m.write(newvalue, onlyIf=True)
except NumerousMetricConflictError:

to handle the reported “no change” exception even when you didn’t care about it. Specifying onlyIf as True gives you this older behavior and specifying the string ‘IGNORE’ (must be UPPER CASE) gives the newer behavior.

The ruby library has the same enhancement.

As a reminder of typical installation methods:

% sudo pip install numerous

You may need to do “pip2” or “pip3” instead, depending on your specific environment and which flavor of python you are installing. Also if you are upgrading from an already installed version:

% sudo pip install –upgrade numerous

Similarly you install the ruby gem via “sudo gem install numerousapp” (note slight name difference here).

Github sources:

Documentation for either library can be found on its wiki page (accessible from the github home page links given above).

Arduino JSON Web Server

I wrote a small program to implement a web server with a JSON/HTTP interface for accessing I/O pins on the Arduino.

Of course to use this you have to have an Ethernet shield (wired or WiFi) on your Arduino; a standard bare Arduino by itself has no network interface. But if you have the shield, then this software gives you a network-ready interface to the analog and digital I/O capabilities of the board.

You can, for example, do a GET on /v1/analogRead/5 to read pin 5 from your Arduino, or POST a JSON object to /v1/digitalWrite to set a pin HIGH or LOW, etc. See the README file at for details and source code.

Arduino and Numerous, with help from IFTTT

Here’s one way to connect an Arduino to a Numerous metric.

The best solution would be to port the Numerous API to the Arduino; however, there is a footprint problem especially with SSL: there is only 2K of RAM on a standard Arduino. I could not find any Arduino ports of SSL (which is required by Numerous).

Maybe Numerous needs to provide a port 80 (non-SSL) interface, though that risks exposing your API key “to the world” in transit. In the meantime, that leaves two alternatives:

  1. Use another computer, local to the Arduino, as a bridge.
  2. Send data directly from the Arduino to Numerous another way.

Option 1 is what I’ve been doing up until now. You write Arduino code to send data out the USB port and write “bridge” code on a small Linux box (e.g., a Raspberry Pi). The Linux code reads the USB data and processes it further (e.g., sends it to NumerousApp). A variation of this can be done with a tiny web server (or other TCP server) on an Arduino instead using USB (I’ve done that too).

With IFTTT integration we can go the option 2 route and eliminate the Linux box, at the cost of giving up some security (more on this later).

You will need:

  • An IFTTT account (free).
  • Connect the Maker channel to your IFTTT account (free).
  • An Ethernet shield (wired or WiFi) on your Arduino.

Go sign up for IFTTT if you haven’t already, and connect the Maker channel.

When you connect the Maker channel you will see a page that looks like this:


You need the key as shown; this will go into your Arduino code in a moment.

[ No, of course that’s not my real key shown above ]

Next you need to create an event that will be triggered from the Arduino. Go back to your home IFTTT page and create a new recipe, using the Maker channel as the IF part. Give your event a name, in this case I used “arduino_example”


When you press Create Trigger you’ll be taken to the “THAT” part of the recipe. Find the Numerous channel and select it (you will have to “connect” it if this is your first time), then for this example choose “Update a Number”:


You will next see a screen where you can select one of your Numerous metrics to be updated, and select what value to update it with. You want to use an “ingredient” (click on the beaker/test-tube thing) and you should select one of the Value fields like “value1”. Whatever you select here is what you will code into your Arduino code; as you can see you can return up to three different values to use with one single event.


That’s it … now to write some Arduino code to generate this event.

You need to know the secret key you were given when you connected the Maker channel, the name of the event you created (“arduino_example” in this case), and which of the values you decided to connect to the metric (“Value1” in this case). Then “all” you need to do is generate a simple POST request from your Arduino in the appropriate format.  That format can be found from (you can also recover your key from there). Click on “How to Trigger events” and it will show you the request format you need to generate.

I’ve written some example Arduino code to do this and made it available as a Gist:

As you can see from that code, the format of the URL that you POST to is:


With the server being at “” (port 80 for standard HTTP)

You POST a JSON object that looks like this:

{ "value1" : "123", 
  "value2" : "456", 
  "value3" : "values can be strings too" }

As you can see from the code itself, squeezing this into the primitives available in the Arduino environment isn’t always pretty; you especially need to be very careful about using up too much memory for “programming niceness”. But the code shows you one way to construct the POST, with the minimal set of HTTP headers that will work, and some example values. You can put this into your own Arduino application and modify it as necessary.

A few tricky points worth noting:

  • I don’t know how often you can generate an IFTTT/Maker event without triggering some kind of limit. In this code I limited the updates to once every five minutes.
  • Don’t forget that all-important “L” on your delay() constants if they are “large” (larger then 32000 milliseconds). Arduino is a 16 bit machine and you won’t get the result you want if you say delay(300*1000) with no “L” on the constant.
  • All those string literals use up RAM. You probably already understand this (or will soon) if you are an Arduino programmer. You might want to look up PROGMEM and ways of getting those literals into flash (program) memory instead of RAM.

About security: we’ve bypassed SSL on the path from the Arduino to IFTTT. The path between IFTTT/Maker and our Numerous account is still secure (via SSL) but the POST request that we are transmitting to IFTTT is plain text and potentially viewable “in transit” if you are inclined to worry about such things. This means your IFTTT/Maker key will be visible to anyone who has access to the intermediate routers. If this matters to you, you will need to go back to Option 1 (local bridge/Linux machine and secure connection to the outside world). On the other hand, if all you are doing is exporting the current temperature of your fridge to a Numerous metric, it’s not clear you need to worry so much about this. You should also keep in mind that the IFTTT key doesn’t really let anyone “do” anything other than post bogus events to your trigger. If you are worried that someone would do that to confuse you about your refrigerator temperature, then you need to go back to the “option 1” architecture which uses SSL to communicate to the outside world. But for a lot of applications this will be a handy way to easily connect an Arduino to Numerous (or anything else IFTTT can connect to).

Lego Technic Triangle Geometry

Time for some fun with Pythagoras!

Lego tends towards rectangular constructs, but sometimes we might want to make triangular connections. Technic beams especially lend themselves to this.

Right-angled pythagorean triangles are fairly easy to construct. Here’s a 3,4,5 triangle:


Notice that when you build it you build it as 4,5,6. That’s because it’s the distance between the pin centers that has to be in the 3-4-5 ratio. Two pins separated by 2 holes are a total distance (center-to-center) of three holes apart. Or said another way, two pins right next to each other are distance “one unit” apart, not two. Thus: A two-hole beam would be a distance of “one unit” in this analysis.

There are many pythagorean integer triangles. Here’s the complete list up to a reasonable size:

  • 3-4-5 (also 6-8-10, 9-12-15, 12-16-20 etc)
  • 5-12-13
  • 7-24-25
  • 8-15-17

If you try to build these don’t forget the +1 factor for counting holes.

If we allow half unit offsets there are some more pythagorean triangles available. Obviously any of the above constructs can be divided in two; beyond those we also have:

  • 4.5-20-20.5
  • 6-17.5-18.5
  • 7.5-18-19.5
  • 10-10.5-14.5
  • 12-22.5-25.5
  • 13.5-18-22.5

In the 3-4-5 family the angle opposite the “4” side is 53.13 degrees. The reason this is good to know is that the standard bent beams are at that same angle (53.130) and now you know why:


If you build this you will see that the angles match up perfectly.

If you combine a pythagorean triangle with its mirror you will get an isosceles triangle. Here, for example, is a 6-5-5 construction which is two mirrored 3-4-5 triangles


Notice, once again, you build 6-5-5 as 7-6-6 if you are counting the total number of holes in each side. This kind of construction will be very strong and also has the advantage of being able to attach things to the vertical riser in the spine of the triangle and have them be “on grid” whereas the holes in the angled beams are rarely ever “on grid” except at the vertices.

Trapezoid Extension – Pythagorean

Once you can make a triangle, you can make a corresponding trapezoid by extending it evenly in one dimension. This is easy to do for right (pythagorean) triangles:


Here I took a 3-4-5 triangle and extended out the base (by 4 in this case; “n” as shown in the diagram). I have to extend the connection point up top out the same amount. The geometry still works and everything lines up.

We’ll revisit this topic for non-pythagorean triangles in a moment; there are some triangles that you can extend into trapezoids and some that you can’t (easily).

System Brick Triangles

You can make triangles using system (“standard lego”) bricks too:


Note how I used two 1×1 bricks to create “pylons” for the angled brick. You have to do this, or something similar, because the neighboring studs will interfere with the angled piece.

General Triangles

Any three beams that satisfy the triangle inequality can be formed into a triangle. In general you will need to use four beams in the construction because you need to “jump” up/down one level to make the last connection work. Look at the construction of the 3-4-5 pythagorean triangle to see an example of why 4 beams are needed (and in that case since one of the joints is a 90 degree angle I used a T piece but in general you will want to use just straight beams when making angles that are not 90 degrees).

The lengths of the triangle sides will determine the angles according to standard triangle side-side-side (SSS) solutions. Just hook them together and let the angles fall where they may.

Of course, we might like to know what those angles actually are. I wrote a small python program that calculates Lego triangle angle information for a given configuration of sides. The source is available here:

If you prefer, here is the table of output it generates for full-unit constructions and half-units:

You can use the command line options (read the source) or just peruse the uploaded table and see that there are some other useful angles you can construct, though in some cases you will have to settle for close approximations. For example, there is no 45 degree construction but there are two that come close:

  • 5-12-15 will generate an angle of 45.036 degrees.
  • 13-17-17 generates 44.959

Any equilateral construction generates 60 degrees but so do these:

  • 3-7-8
  • 5-7-8

Here’s a 3-7-8 construction. The angle between the blue and red beams is 60 degrees.


This construction also more clearly illustrates the need to use four beams (not just three) to make a triangle because of how the “levels” at the vertices work out. One of the sides has to jump back down in order to join with the remaining side.

Because of that 60 degree angle, that implies you can build a 3-7-8 connection across an 8-8-8 equilateral triangle:


The angles opposite the blue beam (both above it and below it) are both 60 degree angles (by definition because the outer frame is an equilateral triangle). This construction is probably demonstrating some deep mathematical relationship between the 3-7-8 60 degree construction and the 5-7-8 construction; perhaps someone will point it out to me and I’ll add it back into this note.

If you have a larger equilateral triangle you can still make this connection at this point near the vertices or of course you could scale up the 3-7-8 or 5-7-8 as appropriate (possibly using half unit constructions too if necessary).

Don’t forget (in case you are confused again): building something with a 3-7-8 relationship takes hole counts of 4-8-9. You can count the holes in the above picture and verify this.

Non-pythagorean Trapezoids

Let’s look at a 4-8-10 triangle (which would be equivalent to a 2-4-5 triangle but this is easier to construct):


As always: built as 5-9-11.

The angles on this triangle are 22.332 (between blue and yellow), 49.458 (between blue and red), and 108.21 (between red and yellow).

Let’s say we want to make a trapezoid out of this. We can, for example, extend the blue beam to the right by making it longer, and finish out the rest of the trapezoid with right angles:


but, as you can see, we have a problem with the final joint at the red/yellow (and pink) vertex. That point isn’t on grid, whereas the pink beam, the black “riser” L piece, as well as the blue base are all on grid.

We can calculate the location of the red/yellow vertex using standard trigonmetry. Using the yellow/blue vertex as the origin, the X and Y coordinates (X along the blue beam) of the end of the yellow beam will be:

X = 8 * cos(22.332°) = 7.4

Y = 8 * sin(22.332°) = 3.04

NOTE: It’s “8” because that’s the length of the yellow side of the triangle.

The vertex doesn’t even line up vertically even though it looks like it might. It’s just close. It definitely doesn’t line up horizontally. We have no way to make that final connection.

Generally speaking you can’t easily extend non-pythagorean triangles into grid-legal trapezoid constructions.

A few constructions come very close; whether you want to use them in your models is up to you. They aren’t “on grid” but any given construction always has a certain amount of play in it and if they are close enough then things will appear to work. I believe the Lego corporation would refuse to accept these constructions as part of a design for a set, so in that sense they are “illegal”.

Here’s one that comes very close. Take the 3-7-8 triangle we saw before:


Taking the blue base as the X axis and the blue-red vertex as the origin, we can calculate the location of the red-yellow vertex. We already know that the angle between the red and blue is 60 degrees (you can reverify this using my tables or perform your own SSS triangle solution for 3-7-8; the angle opposite the 7 side is 60 degrees). Since the red leg is 8 units in length the location of the red-yellow vertex is:

X = 8 * cos(60°) = 4.00

Y = 8 * sin(60°) = 6.93


The X coordinate works out evenly on-grid, thanks to the cosine of 60 degrees being exactly one half. The Y coordinate is off grid but close enough that the following construction will appear to work:


In reality the pink beam is at (relative) height 6.93 on its left end and 7.00 on its right, thus there is some stress/flexing in the construction to make it work. You might reduce that stress slightly by only pinning the pink beam with one pin at the right end (vs the two shown in this build).

This just happens to work out as a case where the off-grid amount is smaller than the inherent flex in the pieces. Your mileage may vary; personally I don’t use these non-aligned constructions in my models but I present this as being one that is very close to ok. You can find others generally by doing math or by just trying things to see what works within reason.

Going back to the 4-8-10 (5-9-11) construction, there is a way to make a trapezoid out of it, like this:


because what I did here is just extend the base, then insert a parallel corresponding extension (the black beam), and connect them with a beam (the second red beam) that is parallel to the original side of the triangle. This preserves all the geometry and gets everything lined up in the right spot; however, in this entire construction only the blue beam is “on grid”; everything else is at non-standard locations.

This structure is quite stable and reasonably strong though I’d be cautious about putting too much weight or pressure on it from top (perhaps someone will work out the statics on this one; just going by feel it seems reasonably strong but I’m not sure exactly where the forces are going when it is put into compression that way).

Approximate “standard” angles

I already listed two constructions that are very close to a 45 degree angle; here is a more complete list of approximations to common/useful angles.

30 degrees (approximate)

a b c ∠° Error Comments
3 5 6 ∠A = 29.9264  0.0736°  should prefer 4 7 8 usually
4 7 8 ∠A = 29.9947  0.0053° closest / smallest
7 12 14 ∠A = 29.9947  0.0053° same angle as 4-7-8; larger

Of course multiples of those triples works, so for example 8-14-16 is another good 30 degree approximation (doubled from 4-7-8).

Half-unit constructions can get even closer:

a b c ∠° Error Comments
5.5 9.5 11 ∠A = 29.9996  0.0004°
5.5 14.5 19 ∠B = 29.9996  0.0004° same angle as 5.5-9.5-11 which is easier to build.
7.5 13 15 ∠A = 29.99997  0.00003° nearly “exact” for all practical purposes.

The 7.5-13-15 triple can be looked at as half of a 15-15-15 equilateral triangle. A point 7.5 along one leg is halfway; if we then went exactly 90 degrees up to the other vertex we should have a height of:

  h = 15 * sin(pi/3)                     # (pi/3 = 60 degrees in radians)

which computes out to h = 12.9904. So our actual height of 13 won’t form a true half of a true equilateral triangle; it will resolve to angles that are slightly off in all spots, but based on how close 13 is to 12.99 you can see why building the triangle at 7.5-13-15 gets so close to the 30 degrees.

If you really need an exact 30 degrees you can get it from the complementary angle on an equilateral construction or from any of the other exact 60 degree constructions (see table lower down).

45 degrees (approximate)

There aren’t any 45 degree approximations that are as close as the 30 degree ones unless we allow half unit constructions. Here is the table of some useful ones including half-units:

a b c ∠° Error Comments
3 19 21 ∠B = 45.06135 0.061°
5 12 15 ∠B = 45.03565 0.036° best/smallest integer construction.
6 12.5 16 ∠B = 45.00612 0.006° very good; see 8-8.5-12.
8 8.5 12 ∠B = 45.00612 0.006° Same ∠ as 6-12.5-16 but smaller. Second best known.
9.5 14 19 ∠B = 45.00349 0.0035° Best (but uses half-units).
11 18 24 ∠B = 45.05405 0.054° 5-12-15 is a better integer construct.

60 degrees

You can, of course, easily get 60 degrees from any equilateral triangle construction (all sides equal). You can also get it from the complementary angle on any of the above 30 degree constructions.

There are quite a few triples that lead to exact 60 degree angles. Here are a few of the simpler and more likely useful ones (including half units):

a b c Comments
1.5 3.5 4
2.5 3.5 4
2.5 9.5 10.5
3 7 8 Just double 1.5-3.5-4
4 6.5 7.5
5 7 8 Just double 2.5-3.5-4

NOTE: In all of these, it is angle B that is the 60 degree (exact) angle.

41.4096 degrees

Say what? Well, the cosine of 41.4096 is 0.75, which means that a beam on this angle will generate a half-unit offset at two holes and every four holes thereafter.

Is this useful? I’m not sure. There is a problem that the sine (0.6614) is nothing useful, so this means that while your beam will have holes at half-unit offsets in one dimension, the other dimension will never be on-grid. Nevertheless, for your amusement, I present this table:

a b c cosine Comments
2 2 3 cos(∠A) = 0.75 exact Isoceles; angle B also works.
3 8 10 cos(∠B) = 0.75 exact Note this one is angle B
4 5 6 cos(∠A) = 0.75 exact

Here’s an example 2-2-3 construction, with the orange lines showing which holes (in the blue beam) are on half-unit offsets from the adjacent beam. Any appearance of not being in alignment is an artifact of the 3D rendering; the math works. However, as already pointed out, the holes are definitely off-grid in the other dimension so I’m not sure how this sort of construction might be useful. I present it anyway just as food for thought.



If for some unusual reason you needed to get a very specific offset, you could use this cosine concept to figure out what angle you’d need to get you there. Let’s say you need an 0.6 offset and you’ve decided (usually for construction reasons) you want to go three units along the hypotenuse to get there. You need an angle that has a cosine of 0.2, which, after you’ve gone three units along the angled beam will have moved you 0.6 on the rectilinear grid.  You find the angle using arccos; that angle would be 78.463 and you could build it using (per the table or the program) 5-6-7.

Admittedly, it’s going to be a very unusual set of circumstances that makes you want special offsets — probably involving integrating with other non-Lego parts, or desparately trying to make a non-standard trapezoidal construction work out. Regardless, you’ll still have the problem of the other dimension which just won’t be where you want it anyway. In reality you’ll probably just use an axle and one piece slid along the axle (thus taking on a non-grid position) to get there; thus all this math is probably a waste of space.  But maybe it will inspire someone to do something particularly clever one day.

53.130 degrees

We already saw that this angle (more precisely it is 53.130102) appears in the 3-4-5 family of pythagorean triangles and is the angle of one of the standard lego “bent” beams.

Are there any other triples that generate this angle? Yes, there are. First of all, any isoceles triangle constructed using a mirrored pythagorean 3-4-5 (or multiples of this) will have this angle. We already saw that in the 6-5-5 example.

Other combinations (that are not 3-4-5 in disguise) that give a 53.1301 angle are:

a b c Comments
2 6.5 7.5
4 13 15 Just double 2-6.5-7.5
5 8.5 10.5
6.5 7 7.5 Angle A

There are actually quite a few of these; I’ve only listed some above. All of those except the last form the 53.130 angle at B.

Half Unit Construction

There are many ways to generate half-unit offsets with technic; here’s one construction you may find handy when trying to make these triangles:


That’s probably the best one I’ve found so far. You can build this with the 1×2 bricks with pins, as shown, or the 1×2 technic bricks (with holes) and separate pins.

Here’s another technique that isn’t quite as elegant but might be handy at times:


The yellow beam and the holes the yellow connector (usually red in real life) form a beam of total length 7.5 (the two holes in the connector are at 6.5 and 7.5).

As shown above the half offset connector is held in place by an axle pin and isn’t necessarily completely stable. You can brace it in a variety of ways if necessary:


That’s it for today’s Lego rambling. Happy Building!

The drawings in posting were created with Bricksmith and rendered using LDView all made possible via LDraw

I can't complain but sometimes I still do