inky phat draws a design

A bit dusty, and no sound, but worked out pretty well. (YouTube link if embed doesn’t work — inky phat draws a design)

Tiling based on plate 43, “a rotating motif …”, Wilson, Eva. Islamic designs for artists and craftspeople. New York: Dover Publications, 1988. ISBN: 978-0-486-25819-5

two-colour EPD displays are so pretty …

rotating tile pattern on Pimoroni Inky pHAT EPD display

This is a 600 dpi scan of a Pimoroni Inky pHAT EPD display. EPDs — electrophoretic displays, aka ‘e-ink’ or ‘e-paper’ — retain their image when turned off, so this Raspberry Pi had no power when I scanned it.

The image I made to fit the display is really small —

It’s a bit of a process making the images with just the right palette in GIMP, but I’m pleased how it turned out. I’d like to be able to write the vector images directly to the screen from SVG, but that might take some time.

Tiling based on plate 43, “a rotating motif …”, Wilson, Eva. Islamic designs for artists and craftspeople. New York: Dover Publications, 1988. ISBN: 978-0-486-25819-5

Easy Raspberry Pi framebuffer screenshots with raspi2png

I gave a talk about retro-gaming on the Raspberry Pi yesterday. I was describing RetroPie, and I really needed lots of screenshots to illustrate games. I’m used to grabbing screens under X, but RetroPie runs without it, so all my usual tools were of no use.

I’d just found out about raspi2png, and it works really well! Usage is simple: just call it like

raspi2png -p outfile.png

and it’ll save whatever’s on the screen. It doesn’t play well with X, but there are already tools to take screenshots with that. As I was playing games, I didn’t want to have to pause the computer to take a shot, so I ran the command every five seconds for 30*5 seconds like this:

for f in {1..30}; do raspi2png -p retro_$(date -Iseconds).png; sleep 5; done

Here are some quality shots via raspi2png from Deathchase, officially the best ZX Spectrum game ever:

VM-CLAP1 👏 sensor + gpiozero on Raspberry Pi

Well, that was easy!

Since the Verbal Machines VM-CLAP1 sensor is an open collector type — that is, it sinks current when triggered — it behaves like a simple button to gpiozero, the Raspberry Pi Python GPIO library. If you attach a callback function to the sensor’s when_pressed event, your Python script will call that function every time it registers a clap.

The wiring is as simple as it could be:

 VM-CLAP1: Raspberry Pi:
 ========= =============
      GND → GND
      PWR → 3V3
      OUT → GPIO 4

This example code just prints clap! when the board picks up a 👏:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

# Raspberry Pi gpiozero test for
# Verbal Machines VM-CLAP1 clap sensor
#   scruss - 2017-06
# Wiring:
#  VM-CLAP1:    Raspberry Pi:
#  =========    =============
#    GND     →   GND
#    PWR     →   3V3
#    OUT     →   GPIO 4

from gpiozero import Button
from signal import pause

def clapping():

clap = Button(4)
clap.when_pressed = clapping

This is a trivial example, but at least it shows that anything you can do with a button, you can also do with this hand-clap sensor.

Clap Sensor part for Fritzing

I have no idea if this wiring would work, but it’s pretty …

For work, I blogged about Verbal MachinesHand Clap Sensor VM-CLAP1 (“Clap on 👏👏, Clap off 👏👏 – Elmwood Electronics”). I’ve made a preliminary part for Fritzing for the board: VM-CLAP1 Clap Sensor for

It should work in Breadboard and Schematic mode, but absolutely doesn’t work in PCB mode. This shouldn’t be a problem, as it’s only available as a standalone board. Fritzing doesn’t have any way to create new parts from scratch any more, so I had to base it on a somewhat similar-looking board, the SparkFun Electret Microphone Breakout.

I’m looking forward to see what I can do with gpiozero and the clap sensor.

Headless Raspberry Pi + VNC: useful resolution

Breadboards of Canada …

I just set up a Raspberry Pi Zero to be a little breadboard computer. Running a headless machine only through SSH gets a bit dull at times, so the inclusion of VNC Connect in Raspbian is handy.

Only problem was that the default screen size — something like 720×480 — was too small for most dialogue windows. Here’s how to enable a more useful resolution of 1024 × 768.

All of these are enabled from the raspi-config tool, so open a terminal and start it with:

sudo raspi-config

Enable Boot to Desktop

Select 3 Boot OptionsB1 Desktop / CLIB4 Desktop Autologin:

Enable VNC on Startup

Select 5 Interfacing OptionsP3 VNC, and answer Yes to Would you like the VNC Server to be enabled?:

Set Screen Resolution

Select 7 Advanced OptionsA5 ResolutionDMT Mode 16 (1024×768) …:

Once you’ve enabled all of these, raspi-config will ask if you wish to reboot your Raspberry Pi. Once it has rebooted, you should have a usable remote desktop.

(All of the above screenshots were taken from a headless Raspberry Pi Zero via VNC.)

Before & After

These were taken later on a Raspberry Pi 2 I’m setting up for a maker festival booth:

decidedly smol: 720×480
fix it to 1024×768 …
so much better!

The Pocket DEC Pretender (PDP) Zero

PDP (Pocket DEC Pretender) Zero: lettering came out a bit more, um,  artisanal than I’d hoped …

Digital (aka DEC) used to make some very solid minicomputers back when a minicomputer was fridge-sized and people were still building nuclear power stations to be controlled by them. The Raspberry Pi Zero is a very mini computer indeed, and in USB gadget mode running SimH it makes a nice little emulation platform.

The case is from Thingiverse: One Piece Raspberry Pi Zero + Camera Case (with GPIO) by Superrei, but with the DEC PDP logo in relief on the top.

DEC minis were famous for their arrays of blinkenlights. The Pocket DEC Pretender, not so much: it has one tiny green light that flickers a bit now and again:

PDP (Pocket DEC Pretender) Zero: case open, very few blinkenlights

But it’s a genuinely useful (for my values of useful) emulation platform. Here it is pretending to be a PDP-8, running BASIC under OS-8:

PDP (Pocket DEC Pretender) Zero: PDP-8 BASIC!

(background in case pictures woven in Toronto by Deftly Weft)

Apple II on Raspberry Pi

C’mon let’s all die of dysentery on the Oregon Trail!

Building and installing the linapple-pie Apple IIe emulator is relatively easy on the Raspberry Pi:

sudo apt install libcurl4-openssl-dev libzip-dev zlib1g-dev libsdl1.2-dev libsdl-gfx1.2-dev libsdl-image1.2-dev libsdl-sound1.2-dev build-essential git
git clone
cd linapple-pie/src
sudo make install

This also works on an x86_64 Ubuntu machine. It does also install on a PocketCHIP (even if it takes a really long time) but I can’t get the display resolution to fit correctly.

Raspberry Pi Zero: avoiding random network addresses in Gadget Mode

The Raspberry Pi Zero can be set up to appear as one of several USB OTG “gadgets” if you plug it into another computer. The most popular setting seems to be the virtual network gadget that turns your Zero into a computer on the end of your USB cable. Andrew Mulholland’s guide Raspberry Pi Zero – Programming over USB! (Part 2) (along with his super-short simple guide) seems to be the definitive source on how to set these modes up.

One problem, though, is that the Zero would show up on different network addresses every time it was restarted. The changing addresses made ssh access no fun at all. A suggestion on the Raspberry Pi forum helped me come up with a solution. On the Raspberry Pi Zero, run this command once:

echo 'options g_ether host_addr='$(dmesg | awk '/: HOST MAC/{print $NF}')' dev_addr='$(dmesg | awk '/: MAC/{print $NF}') | sudo tee /etc/modprobe.d/g_ether.conf

This will set the USB port’s hardware addresses to a fixed value, and you should always get a connection on the same IP address if it’s available.

How my Raspberry Pi Zero appears on my Ubuntu machine

Update: For some reason, this seemed to stop working, and I was getting the old random addresses again. I was resisting putting more stuff in /boot/cmdline.txt, but it seems to me it’s more reliable than what I proposed. So if your g_ether.conf looked like:

options g_ether host_addr=66:e0:94:40:44:74 dev_addr=de:82:66:79:e2:66

right at the end of your /boot/cmdline.txt (which is all one line, btw), add

 g_ether.host_addr=66:e0:94:40:44:74 g_ether.dev_addr=de:82:66:79:e2:66

You’ll probably also want to share the IPv4 connection so your Raspberry Pi Zero can use the network of the device it’s attached to:

Emulating a Mac IIx on Raspberry Pi

Yup, I have a failing for 512×384 screens …

Running Mini vMac on a Raspberry Pi is hardly news. But maybe running it as a colour Mac II is. The screen size I’ve chosen is closer to a Color Classic, for no other reason that I like it.

To build a Mac II-capable version of Mini vMac, you’ll need the Alpha source code. You’ll also need a working Mini vMac setup, as it uses a 68k Mac program to set up the source. Pretty much any basic setup and bootable disk will run this okay:

Mini vMac building on an emulated Mac Classic booting from the System 7 Network Access floppy image (no, I couldn’t boot from Classic’s hidden boot ROM disk)

The build options I chose are:

-t larm -ccs -m II -hres 512 -vres 384 -depth 3 -mf 2 -magnify 1 -em-cpu 2 -mem 8M

I’ve chosen to swap the Ctrl key with the Command (⌘) key, as most non-Mac keyboards work better with this.

The build program will export a file out/minivmac-3.5.0-larm.tar that you can unpack into the full source code. It’s a really simple build, and fast, too.

Now you’ll need a Mac IIx ROM image (which I’m not supposed to help you find, but it’s an easy search) and OS image disks from the Mini vMac System Software page. Have fun!

making an hourly chime with cron

I wanted to have a “Hey, be here now!” ping throughout the working day. Something loud enough to hear, but not irritating.

Doing this with cron was harder than you might expect. It seems that sound is typically part of the X11 display infrastructure, so you need to give the command permission to make a noise on this particular machine’s display. Here’s the crontab line I came up with:

# m h    dom mon dow   command
  0 9-17 *   *   1-5   export DISPLAY=:0 && /usr/bin/play -q /home/scruss/sounds/ting/ting.wav

That translates as: at 0 minutes past the hours of 09:00 to 17:00 on any weekday (day of week = 1-5, and we don’t care about day of month or which month it is), execute the command play (part of the sox package) with no text output (-q). cron needs environment variables like DISPLAY set, and prefers full command paths. It may trigger a second or so after the turn of the hour; this is good enough for me.

As for the alert, I wanted something distinctive — percussive, short, bright — but with a tiny bit of modulation to stop it sounding like a bland computer-generated sine wave. This is what I made; click on the image and the sound should play or download:

ting-audacityIt’s essentially a 2093 Hz (C7) sine wave, mixed with itself frequency-modulated at 7 Hz. Why 7 Hz? Apart from sounding about right, 2093 is exactly divisible by 7, 13 & 23, so I used a factor for neatness.

There was some later messing about in Audacity (mostly fades and length edits; I forget exactly what). The two components were generated using sox:

sox -n ting-plain.wav synth 1 sine C7 fade l 0 1 1
 sox -n ting-vibrato.wav synth 1 sin C7 synth 1 sine fmod 7 fade l 0 1 1

Yes, sox does have pretty horrible syntax, doesn’t it?

The frequency-modulated one seems to be pretty close to the final result. It would be less time spent trying to save time …

micro, a nice little text editor


micro – – is a terminal-based text editor. Unlike vi, emacs and nano, it has sensible default command keys: Ctrl+S saves, Ctrl+Q quits, Ctrl+X/C/V cuts/copies/pastes, etc. micro also supports full mouse control (even over ssh), Unicode and colour syntax highlighting.

micro is written in Go – – so is very easy to install:

go get -u

If you don’t already have Go installed, it’s pretty simple, even on a Raspberry Pi:

If your running under Linux, you probably want to have xclip installed for better cut/paste support.

Overall, I really like micro. It’s much easier to use than any of the standard Linux text editors. It uses key commands that most people expect. Creating code should not be made harder than it needs to be.

(I was about to suggest FTE, as it appears to be the closest thing to the old MS-DOS 6 editor that I’ve seen under Linux. While it’s a great plain text editor, its Unicode support isn’t where it needs to be in 2016.
micro suggestion came via MetaFilter’s Ctrl + Q to quit. Need I say more?

Spectrum is Green!

My previous adventures with my Sinclair ZX Spectrum 48K in Canada were not resounding successes. I couldn’t get the display to work, and tapes wouldn’t load well, so I’d been using Fuse while the hardware sulked in a cupboard.

I’d previously got a proper power supply (9 V DC, ≥ 1.4 A, centre negative) and bypassed the PAL UHF modulator to give composite video. No television, monitor or converter box that I had tried seemed to give a useful display.

Back in May, Walter Miraglia brought a tiny 7″ composite colour monitor to TPUG‘s Retrocomputing Night. He let me try it with the Spectrum, and it worked very well. Walter said it was an extension monitor for a car DVD player.

I dug around, and found that local surplus clearout store Tech Source Canada had the Philips 7″ portable DVD Player PD7016/37 for $60. This gives you two identical DVD players with composite input. I think my other one will be destined for a Raspberry Pi project somewhere.

To get these monitors running, you’ll need:

  • a 9–12 V DC power supply able to give ≥ 1 A. I use a regulated supply that gives 9.1 V open circuit and is rated at 2 A. Note that the power connector is slightly smaller than the common 2.1 mm barrel, so you may have to order this one, unless you can solder something up.
  • A cable like this 3.5mm Stereo to Composite Video + Audio Cable (3 RCA). These are sometimes just called camcorder cables. They use a 3½ mm TRRS jack, and can also — if you don’t mind not quite having the connectors in the right order — work with the composite/audio output of more recent Raspberry Pis. Tech Source had these for under $5.

Connect it up , and — success! Well, slightly qualified success. The screens do not have the greatest resolution, so pixels are slightly smeared together. The screens do have a decently fast refresh, and the whole look is just right. With its colour clash and dot crawl, nobody ever expected great video from the Speccy anyway.

Here are some screen shots taken with my phone, and a couple of pixel-sharp screenshots from Fuse to compare:

Moon Cresta - complete with authentic weird language
Moon Cresta – complete with authentic weird language
Moon Cresta — the same screen from Fuse
Moon Cresta — the same screen from Fuse
Moon Cresta - nice loading screen
Moon Cresta – nice loading screen
Manic Miner — a game I am not good at
Manic Miner — a game I am not good at
Manic Miner - perhaps the (deliberately?) worst game music ever
Manic Miner – perhaps the (deliberately?) worst game music ever
3D Death Chase — OH NOES A TREE!!!!1!!
Deathchase — OH NOES A TREE!!!!1!! Looks like the Riders of the Big Bikes just lost another member
Knight Lore
Knight Lore
Chuckie Egg
Chuckie Egg
Chuckie Egg from Fuse. We can't do anything about the attribute clash
Chuckie Egg from Fuse. We can’t do anything about the attribute clash

So I can now definitely view the screens. Huge thanks to Walter for tipping me off to these DVD players.

[Incidentally, the screens are designed for car use, so don’t stand up properly unless you get creative with some supports. I laser-cut these out of 3 mm plywood:

mini screen feet for 3 mm ply
mini screen feet for 3 mm ply. Cutting template PDF is linked underneath this image

Glue the little sticks on to the flat ends, and they’ll fit into the slots in the back of the monitor. Here are the feet with the sticks fitted:

screen feet with sticks glued in place
screen feet with sticks glued in place

There are better-designed feet than these, but they work, mostly.]

I was still having game loading problems. Try as I might, I couldn’t get anything to load reliably. Retrocomputing Stack Exchange came to the rescue, in the shape of mcleod_ideafix’s very helpful answer.  If your audio player is running from batteries and you can use a stereo cable, you can convert the normal mono loading audio into stereo with one channel inverted. This gives you effectively double the volume, and works quite well with my audio player, an old Edirol R-1*.

Inverted stereo loading data, showing 4000/8000 Hz speedload tones
Inverted stereo (or differential) loading data, showing 4000/8000 Hz speed-load tones

This audio will not load into an emulator, or work with a mono cable. Some audio players even render it as silence.

Here’s a script to take monophonic loading data and convert it to this faux-differential stereo format using Sox:

# - convert mono game tape audio to 2× stereo
# usage: infile.wav
#          (creates  infile-differential.wav)
# scruss - 2016-06-07
# method by ‘mcleod_ideafix’; many thanks / greetz
#   —

sox -q --norm=-3 "$1" -b 16 "${base}-n.wav"
sox -q  "${base}-n.wav" "${base}-ni.wav" vol -1.0
sox -q  --norm=-0.1 -M -c 1 "${base}-n.wav" -c 1 "${base}-ni.wav" -c 2 -b 8 "${base}-differential.wav"
rm -f  "${base}-n.wav" "${base}-ni.wav"

If you want to check your audio levels, sox can also create the 800 Hz header tone used by the Spectrum. Run the output of the command below through the script above, load it onto your audio player and fiddle with the volume until the border flickers steadily:

sox -n -b 8 -r 8000 800hz-header.wav synth 30 square 800
Lovely loading bars ...
Lovely loading bars …

I was also looking for the games to load fairly quickly. Tapes used to take over three minutes to load, and while retrogaming all is about the experience, I haven’t got time for that. Fuse has some utility programs which will convert a .Z80 game snapshot into an audio file that loads in about 1¼ minutes.

To convert the snapshot to a speed-load TZX tape image:

snap2tzx -o game.tzx -s 3 game.z80

To convert that virtual tape image into audio:

tape2wav -r 16000 game.tzx game.wav

You can then run that WAV file through the stereo/differential script I listed above. Have fun!

So the Coo~Coo Raspberry Pi Zero case does work with acrylic!

So the Coo~Coo Raspberry Pi Zero case does work with acrylic!

So the Coo~Coo Raspberry Pi Zero case does work with acrylic!

Laser cut template:

Build notes: The “Coo~Coo” Raspberry Pi Zero Case

The “Coo~Coo” Raspberry Pi Zero Case

Coo~Coo Raspberry Pi Zero Case - built
Coo~Coo Raspberry Pi Zero Case

I’d tried making several Raspberry Pi Zero enclosures, but none of them quite worked. My needs are pretty simple, but I do need to be able to fit a full 40 pin strain-relieved (possibly keyed) header into the device while keeping questing fingers and dropped conductors off the circuit board.

Coo~Coo case in fluo acrylic
Coo~Coo case in fluo acrylic

So working from a (scaled) version of the Raspberry Pi Zero Mechanical Drawing, I made a case that meets some very basic requirements:

  1. Conserves material: The Coo~Coo uses just under 80 × 80 mm of 3 mm ply or acrylic, plus four nylon machine screws, nuts and washers.
  2. Takes a full-sized GPIO header with a little headroom.
  3. Provides edge protection for the µSD and connectors.
  4. Has only a single cut layer, with no time-wasting engraved rasters.
  5. Needs only simple tools to make: really only needs diagonal cutters to snip off half of the nylon screw heads. Needle-nose pliers might help too, as there are some fiddly small parts.
  6. Free as in CC0. Yup, since this is derived from the Raspberry Pi Foundation’s copyrighted drawing, my modifications didn’t really add anything of value. Thus I waive all copyright and related or neighbouring rights on my additions:


    To the extent possible under law, Stewart C. Russell has waived all copyright and related or neighbouring rights to the “Coo~Coo” Raspberry Pi Zero Case. This work is published from: Canada.

Why the odd “Coo~Coo” name? Well, look at the pattern of spacer washers and half-spacer washers:

Coo~Coo in the cutter

To save material, I arranged these washers inside the GPIO cutout. I realised that I could spell COO~COO. It’s even clearer on the cutting document:

Coo~Coo — PDF for cutting is linked under the image

Update: here’s a revised path that cut well with acrylic and probably will work slightly better on plywood, too:
(If you do use acrylic, let me introduce you to one of the marvels of backing-paper removal: d-limonene. This fruity solvent — present in products like Goo Gone — causes backing paper to slough off with only a few minutes’ soaking. It washes off to a clean shine with water and dish soap/washing up liquid. I have just saved you fingernails from certain damage!)

The cutting path in the PDF could use a little clean up if you want to try this design in acrylic. The base of the design has been flipped so that any laser flare will be hidden inside the case.

You’ll need four M2.5 or M3 nylon screws of 20 mm length, plus 8 washers and 4 nuts. M3 screws of this length are easier to get, but the mounting holes in the Raspberry Pi Zero are only 2¾ mm in diameter. You can thin the M3 screws down slightly by lightly twisting them inside a piece of folded fine sandpaper. You’ll still have to push them through the Raspberry Pi Zero circuit board with a little force, though.

Cutting & Assembly Instructions

  1. If you have it, place some fine wire mesh or sacrificial heavy card-stock between the laser cutter honeycomb bed and the plywood. The spacer washers are just the right size to fall through the cutter bed and be lost inside the discard hopper.
  2. Cut the piece as normal.
  3. Remove the work from the laser cutter. Masking tape applied over the washers will stop them falling out.
  4. Take the top piece, and thread the other two screws through the holes by the HDMI and PWR labels.
    (It may be easier to do these one at a time)
  5. Place two of the full spacer washers over each screw.
  6. Push the screws through the Raspberry Pi Zero board. M2.5 screws won’t need any force, but M3 will need some coaxing, possibly even cajoling.
  7. Place a nylon washer on each of the two screws under the Raspberry Pi Zero board.
  8. Take the base and flip it horizontally so the screw holes match the top.
  9. Very loosely attach the nuts to each of the screws.
    (You’ll need the slack to fit the top two screws and their C-shaped spacers)
  10. Feed the top two screws through the half-holes by the GPIO cutout in the case and the Raspberry Pi Zero board. Again, coaxing and/or cajoling may be required if you used M3 ones.
  11. Put nylon washers over the screws between the Raspberry Pi Zero board and the base.
  12. Very loosely attach the nuts to the top two screws.
  13. (This is the fiddly bit) Stack two of the half spacers and put them on each screw. You need to get the screws tight enough to just grip the spacers against the case, but not too much or you won’t be able to align them to let the GPIO connector fit in the gap. Tightening the screws at the HDMI and PWR ports can help with this, too.
  14. Nip off half of the heads from two of the nylon screws. This will allow the GPIO connector to fit easily.
  15. Tighten all the screws (finger tight is fine) and make sure the trimmed heads align with the edge of the GPIO cutout.
Raspberry Pi Zero in Coo~Coo case showing GPIO and spacers
Raspberry Pi Zero in Coo~Coo case showing GPIO and spacers

The new Raspberry Pi Zero with camera connector should also fit, but I don’t have one to test it.

Pen plotters: not just output devices …

Pen plotters were pretty expensive and complex pieces of electromechanical equipment. While they often earned their keep in the CAD office, they also had a function that’s almost forgotten: they could be used as input devices, too.

As a kid, we sometimes used to drive past the office of Ferranti-Cetec in Edinburgh. They specialized in digitizers: great big desk or wall mounted devices for capturing points from maps and drawings. Here’s one of their 1973 models:

Ferranti EP210 Freescan Digitiser. Source: Grace's Guide,
Ferranti EP210 Freescan Digitiser. Source: Grace’s Guide,

While the technology and size have changed a bit, these huge bits of engineering kit are the ancestors of today’s track pads and touch screens.

Realizing that their plotters had very precise X-Y indexing and that they had two-way communications to a computer, HP made a drafting sight that fitted in place of a pen on their plotters:

HP drafting sight, part no 09872-60066
HP drafting sight, part no 09872-60066

This is a very pleasing piece of kit, all metal, thick plastic and polished optical glass. They show up on eBay occasionally, and aren’t cheap. With a bit of coercion, it fits into my HP plotter like this:

Drafting sight in HP7470A plotter
Drafting sight in HP7470A plotter

The image is very bright and clear:

Drafting sight near an axis label
Drafting sight near an axis label
Drafting sight over a point
Drafting sight over a point, showing cursor dot

If one has a digitizing sight, one needs to find something to digitize post haste … I’m sure everyone can sense the urgency in that. So I found this, a scan from my undergraduate project writeup (centrifugal pump impeller design ftw, or something), which was probably made on an Amiga or Atari ST:

It's a graph, with pointy bits on it
It’s a graph, with pointy bits on it

I printed this as large as I could on Letter paper, as it’s the only size my HP7470A plotter can take. Now all it needed was a small matter of programming to get the data from the plotter. Here’s a minimally-useful digitizer for HP and compatible serial plotters. Although I ran it on my little HP grit wheel plotter attached to a Raspberry Pi, I developed it with my larger Roland plotter. The only fancy module it needs is pySerial.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# a really crap HP-GL point digitizer
#  scruss - 2016

from time import sleep
from string import strip
import serial

ser = serial.Serial(port='/dev/ttyUSB1', baudrate=9600, timeout=0.5)
lbl = ''
points = []
labels = []
k = 0
retval = 0

ser.write('DP;')                # put in digitizing mode
while lbl != 'quit':
    ret = strip(, chr(13))
    print ('Retval: ', ret)
    if ret != '':
        retval = int(ret)
    if retval & 4:              # bit 2 is set; we have a point!
        print ('Have Point! Retval: ', retval)
        retval = 0
        pt = strip(, chr(13))
        print ('OD point: ', pt)
        lbl = raw_input('Input label [quit to end]: ')
        k = k + 1
        ser.write('DP;')        # put in digitizing mode again

f = open('digit.dat', 'w')
for i in range(k):

In the unlikely event that anyone actually uses this, they’ll need to change the serial port details near the top of the program.

The program works like this:

  1. Move the drafting sight to the point you want to capture using the plotter’s cursor keys, and hit the plotter’s ENTER key
  2. Your computer will prompt you for a label. This can be anything except quit, that ends the program
  3. When you have digitized all the points you want and entered quit as the last label, the program writes the points to the file digit.dat

I didn’t implement any flow control or other buffer management, so it can crash in a variety of hilarious ways. I did manage to get it to work on the lower trace of that graph, and got these data:


The first two columns are X and Y, in HP-GL units — that’s 1/40 mm, or 1/1016 inches. The third column will always be 1 if you have the sight down. The last columns are the label; if you put commas in them, opening the file as CSV will split the label into columns. I used it to fudge axis points. You’ll also note that the last three lines of data are my valiant attempts to quit the program …

Assuming the axes are not skewed (they are, very slightly, but shhh) some simple linear interpolation gives you the results below:

 12.1    0.086
 15.1    0.093
 19.7    0.104
 24.7    0.114
 30.1    0.122
 39.7    0.145
 49.5    0.162
 60.0    0.182
 70.0    0.203
 79.8    0.221
 89.9    0.232
100.0    0.262
120.1    0.293
150.2    0.351
199.7    0.442
248.9    0.516
270.7    0.597

Good enough for a demo.

(For prettier things to do with plotter digitizing commands, Ed Nisley KE4ZNU has made some rather lovely Superformula patterns)

If you don’t have a plotter, or even if you do and you don’t have hours to waste mucking about with Python, obsolete optics and serial connections, Ankit Rohatgi’s excellent WebPlotDigitizer gets numbers out of graphs quickly. It handles all sorts of graphs rather well.

Raspbian: Getting Alt-Tab to work properly in Openbox/LXDE

I’m still happily using a Raspberry Pi 2B 3 as a lightweight desktop machine. It’s not my main computer, but it’s pleasantly capable. Set up with a couple of paged desktops (or virtual desktops, as we used to call ’em), I can get a bunch of things done with it.

One feature that really irked me, though, was the way that window switching worked. Or, for greater clarity, didn’t work. Openbox, the standard window manager in Raspbian, didn’t allow you to switch to windows on another desktop with Alt+Tab. As I have a smallish screen, I typically have very few windows per desktop, so I want that ability to move from task to task.

This, however, can be fixed. In your ~/.config/openbox/lxde-pi-rc.xml file, change the keybinding sections for Alt+Tab and Alt-Shift+Tab from:

    <!-- Keybindings for window switching -->
    <keybind key="A-Tab">
      <action name="NextWindow"/>
    <keybind key="A-S-Tab">
      <action name="PreviousWindow"/>


    <!-- Keybindings for window switching -->
    <keybind key="A-Tab">
      <action name="NextWindow">
    <keybind key="A-S-Tab">
      <action name="PreviousWindow">

Log out, log back in, and Alt+Tab across desktops should Just Work. If you’re not using the default pi user, I suspect you’ll have to edit the ~/.config/openbox/lxde-user-rc.xml file instead.

Credit for this tip: user crunchworksyeay on the CrunchBang Linux Forums.

This has been a Memo To Myself™ production.

Running FreeBASIC on Raspberry Pi

FreeBASIC is a pretty nifty cross-platform BASIC compiler. It uses a Microsoft-like syntax, has an active user and developer base, and is quite fast. Building the latest version on a Raspberry Pi is a bit of a challenge, though.

FreeBASIC 1.01 demo running on a Raspberry Pi
FreeBASIC 1.01 demo running on a Raspberry Pi from Geany

Part of the problem is that FreeBASIC is mostly written in FreeBASIC, so you need a working compiler to bootstrap the latest version.

Update: you’re probably best just downloading the binary install packages from the FreeBASIC site. I’m having difficulty getting recent (late 2016) source packages to build for reasons that would take too long for most people to care about.

The following steps worked for me:

  1. Install some necessary packages:
    sudo apt-get install build-essential libncurses5-dev libffi-dev libgl1-mesa-dev libx11-dev libxext-dev libxrender-dev libxrandr-dev libxpm-dev ncurses-doc libxcb-doc libxext-doc libgpm-dev git libcunit1 libcunit1-dev libcunit1-doc

    (You don’t really have to include the cunit packages; they’re only needed if you run tests before installation.)

  2. Download a nightly binary from Sebastian’s server:  and install it:
    cd fbc_linux_armv6_rpi/
    chmod +x
    sudo ./ -i

    Don’t delete the installation folder just yet.

  3. Grab the latest version of the source from github:
    git clone

    Change directory to the new FreeBASIC source folder (cd fbc), and type make. (or, on a Raspberry Pi 2 or 3, make -j4 to use all the cores …). After a while (in my tests, about 52 minutes on a 512 MB Raspberry Pi, or around 6½ minutes [!] on a Raspberry Pi 2), it should finish. If there’s a bin/fbc file, the compilation worked!

  4. Before you install the new compiler, uninstall the old one: change directory to the fbc_linux_armv6_rpi folder, and type:
    sudo ./ -u
  5. Once that’s done, go back to the new fbc folder, and type:
    sudo make install

And you’re done! You can delete the fbc_linux_armv6_rpi folder now. If you don’t mind it taking up space, keep the fbc folder to allow you a quick rebuild of the latest version of the compiler with:

cd fbc
git pull
sudo make install

Note that this will build a native armv7l compiler on a Raspberry Pi 2, and an armv6l one on a Raspberry Pi. This means you can’t run binaries you built on a Raspberry Pi 2 on a Raspberry Pi (you’ll get an Illegal Instruction error), but you should be able to run ones built on a Raspberry Pi on a Raspberry Pi 2. Binary compatibility is overrated, anyway …