Skip to main content


Showing posts from September, 2012

A water rocket made from household bits and bobs

Last year I made a 'Ponyo' boat out of an aluminium can and a juice carton following the instructions from Science Toy Maker . This summer when the weather was nice enough I followed his instructions for a simple water rocket launcher made from a pen and a piece of PVC tube. The nice thing about Science Toy Maker is that all the stuff he makes uses the minimum number of tools and a maximum of common items. The water rocket launcher needs the following: a bicycle pump, a "Bic" pen, a length of PVC tube, a candle, and some glue. Add a drinks bottle for the rocket. Here's the finished launcher. It's pretty simple. The length of PVC tube is pinched at the bottom end (on the right) to seal it, a hole is made for the bicycle pump connector made from the pen and a neck is made to rest the bottle on. Since the PVC melts at a low temperature he uses a candle to do all the work. The first job is to heat the PVC pipe at the point where the drinks bottle rocke

The UK has an entire IPv4 /8 that it isn't using (UPDATED)

IMPORTANT UPDATES BELOW If you take a look at the list of IPv4 allocated /8 blocks there's one interesting block in there: UK Government Department for Work and Pensions 1994-08 LEGACY That block of addresses, all 16.8 million of them, is completely unused. A check of the ASN database will show that there are no networks for that block of addresses. Right when IPv4 is running out there's a huge block sitting unused. That's an extremely valuable asset. One recent article valued an entire /8 at between "$500 million to $1.5 billion". So, Mr. Cameron, I'll accept a 10% finder's fee if you dispose of this asset :-) PS A comment draws my attention to a Freedom of Information Act response from the Department for Work and Pensions concerning this block. The FOI response says that the block is used internally by the government and there are no plans to release it. PPS This Cabinet Office document  says that is

The Joy of Bit-Banging

One of the joys of doing things with microcontrollers is the ability to bit-bang : to simulate the serial interface to a device so it can be controlled by the microcontroller without special hardware. The digital I/O pins on microcontrollers are ideal for interfacing to a variety of serial devices. For example, I've used software controlled serial to connect to various things... 1. A Lassen IQ GPS module as part of my high-altitude balloon flight . The code is here and used a software serial interface to communicate with Lassen's binary TSIP protocol. 2. On the same flight I bit-banged an interface to a DS1821 temperature sensor . This was typical of many small devices where the serial interface is entirely controlled (including the clock signal) by the microcontroller. Details here . 3. A string of addressable RGB LED Christmas lights for my home made 7x7 display . The code for that serial protocol is here . 4. Yesterday, I blogged about interfacing to an optical m

Conversion of cheap optical mouse to robot odometer

For a small robot project I'm working on I needed a way to measure the robot's progress across the floor. There are various possibilities, such as: use stepper motors (expensive and am recycling some old continuous run servos), add an encoder to the wheels (would need to go buy some parts for that), or use the optical sensor for a mouse. I had a really old PS/2 optical mouse lying around which contains an MCS-12085 optical sensor that has a rather simple serial interface suitable for connection to a microcontroller. Inside there are two separate areas of components. On the right in the picture above is the PS/2 interface chips and four nice extras that I desoldered for later use (three microswitches and a quadrature encoder). On the left is the red LED that illuminates the surface and the 8 pin square MCS-12085 that has the camera. The only description of the chip was for a related optical sensor, the MCS-12086 . The difference between the two appears to be that the MC

An intuition/reality clash in Go

The following Go code doesn't compile: package main import "log/syslog" type MyThing struct { writer *syslog.Writer } func NewMyThing() (thing *MyThing) { thing = new(MyThing) thing.writer, err := syslog.Dial("", "", syslog.LOG_ERR, "") return } func main() { } It fails with the error  prog.go:11: non-name thing.writer on left side of := .  You can try it yourself here . (Ignore the fact that if it did compile there would be a different error because err is not used; the goal here is a small example). The reason this fails is that := must be thought of as a declaration and not as an assignment. In fact, := is a declaration with the special exception that if one of the variables on the LHS is already declared in the same block then it is not redeclared it is assigned. If you think of := as an assignment that sometimes declares you run into trouble because thing.writer can never be declared there (it's already declare

A Go Gotcha that Got Me

Here's a little Go program that has a surprising output: package main import ( "fmt" "net" "crypto/tls" ) func main() { var c net.Conn c, err := tls.Dial("tcp", "", nil) fmt.Printf("%v %v\n", c, err) if c == nil { fmt.Printf("Nil\n") } else { fmt.Printf("Not nil\n") } } This program tries to connect to my web site using TLS on the non-TLS port 80. That's done to force there to be a TLS error. The output is a little surprising: <nil> local error: record overflow Not nil The Printf gives the value of c as but when the test c == nil is performed it's non-nil.  So, what's going on?  The answer is in the Go FAQ: Why is my nil error value not equal to nil? .  In short, c is an interface (a net.Conn ). The implementation of an interface is a type and a value. The type gives the actual type that implements that interface (in the case above