Category Archives: computers suck

The HP48: the best calculator ever

We had an unscheduled overnight stop in East Lansing last week, and I took the chance to visit the MSU Surplus Store.  For $15, they had HP48G calculators, seemingly unused:

hp48gThey still have a bunch of them: HP 48G Graphic Calculator.

They’re maybe not the quickest (the 4 MHz Saturn processor chugs sometimes, and wanders off to clean up memory when it feels like it), the display is downright chunky these days, but they have everything that a scientific calculator should have. The keys have a good action. It just works. Yes, your smartphone has hundreds of times the processing power, but it’s not specialized to the task. The HP48 is.

If you’re feeling really nerdy, you can run an HP48 (a GX, not the G which I have) under Linux using x48. Jeff has some useful tips on installing x48 on newer ubuntu versions (though you don’t have to do the font thing under Ubuntu 13.10).

x48Building it is a small matter of ./autogen.sh ; ./configure ; make ; sudo make install.  To run it, you’ll need to install the GX ROM image to ~/.hp48.  The first time you run it, I’d recommend running it from the terminal with:

x48 -reset -initialize -rom ~/.hp48/rom

as the ROM format has an outdated config file which causes it to complain weakly every time you start the emulator.

Scanned manuals are available from HP here: Manuals for HP 48gx Graphing Calculator.

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

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 \ Processing.org 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 jSSC-2.6.0-Release.zip and extract it:

unzip jSSC-2.6.0-Release.zip

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:

~/processing-2.1/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
println(Serial.list());

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___:

/dev/ttyACM0

(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 processing-arduino.zip from firmata/processing. Extract it into your Processing sketchbook:

unzip processing-arduino.zip -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()
{
  println(Arduino.list());
  arduino = new Arduino(this, Arduino.list()[0], 57600);
  arduino.pinMode(ledPin, Arduino.OUTPUT);
}

void draw()
{
  arduino.digitalWrite(ledPin, Arduino.HIGH);
  delay(1000);
  arduino.digitalWrite(ledPin, Arduino.LOW);
  delay(1000);
}

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.)

Introducing RAFTP — the Really Annoying File Transfer Protocol

I would like to describe a new and highly impractical method of transferring data between computers. Modern networks are getting more efficient every year. This protocol aims to reverse this trend, as RAFTP features:

  1. Slow file transfers
  2. A stubborn lack of error correction
  3. The ability to irritate neighbours while ensuring inaccurate transmission through playing the data over the air using Bell 202 tones.
doge-small-tx
Figure 1

Figure 1 shows a test image before it was converted into PGM format. This was then converted into an audio file using minimodem:

minimodem --tx -v 0.90 -f doge-small-1200.wav 1200 < doge-small-tx.pgm

This file was then transferred to an audio player. To ensure maximal palaver, the audio player was connected to a computer via a USB audio interface and a long, minimally-shielded audio cable. The output was captured as mp3 by Audacity as this file: RAFTP-demo

The mp3 file was then decoded back to an image:

madplay -o wav:- RAFTP-demo.mp3   | minimodem --rx -q -f - 1200 | rawtopgm 90 120 | pnmtopng > doge-small-rx.png

Figure 2 shows the received and decoded file:

Figure 2
Figure 2

My Raspberry Pi talks to my Oscilloscope

… it complains that the oscilloscope is always making waves.

DS1EB134907266_0

Ahem. Anyway. I have a Rigol DS1102E 100 MHz Digital Oscilloscope. For such a cheap device, it’s remarkable that you can control it using USB Test & Measurement Class commands. I’d been wanting to use a Raspberry Pi as a headless data acquisition box with the oscilloscope for a while, but Raspbian doesn’t ship with the usbtmc kernel module. I thought I was stuck.

Alex Forencich turned up in the forum with an all-Python solution: Python USBTMC (source: alexforencich / python-usbtmc). I got this working quite nicely today on both the Raspberry Pi and my Ubuntu laptop. Here’s how I installed it:

  1. Check your device’s USB code with lsusb:
    $ lsusb
    Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
    ….
    Bus 001 Device 004: ID 1ab1:0588 Rigol Technologies DS1000 SERIES
  2. Ensure that libusb-1.0 is installed:
    sudo apt-get install libusb-1.0-0
  3. Create a new group, usbtmc:
    sudo groupadd usbtmc
  4. Add yourself to this group:
    sudo usermod -a -G usbtmc pi
  5. As root, create a file /etc/udev/rules.d/usbtmc.rules. You’ll need to put in your device’s ID values:
    # USBTMC instruments
    # Rigol DS1100 – ID 1ab1:0588 Rigol Technologies DS1000 SERIES
    SUBSYSTEMS==”usb”, ACTION==”add”, ATTRS{idVendor}==”1ab1″, ATTRS{idProduct}==”0588″, GROUP=”usbtmc”, MODE=”0660″
    (all of the SUBSYSTEMS to MODE= should be one one line)
  6. Download and install the latest pyusb (Raspbian version is rather old):
    git clone https://github.com/walac/pyusb.git
    cd pyusb
    python setup.py build
    sudo python setup.py install
  7. Now get python-usbtmc:
    git clone https://github.com/alexforencich/python-usbtmc.git
    cd python-usbtmc
    python setup.py build
    sudo python setup.py install
  8. For this simple demo, you’ll need to convert the USB vendor IDs to decimal:
    0x1ab1 = 6833
    0x0588 = 1416
  9. Now, start python as root (sudo python) then type:
    import usbtmc
    instr =  usbtmc.Instrument(6833, 1416)
    print(instr.ask(“*IDN?”))
  10. This should return something like:
    Rigol Technologies,DS1102E,DS1EB13490xxxx,00.02.06.00.01

If you get the status line, congratulations! You now have a fully working usbtmc link. I haven’t had much time to play with this, but I know I can make really nice screenshots to an attached USB drive using the command: instr.write(“:HARDcopy”). Many more commands can be found in the DS1000D/E Programming Guide, available on Rigol‘s site.

I had a couple of problems, though:

  1. The library seems to need root privileges, despite the udev rule thing. After creating the udev rule, you will need to reboot. This is the simplest way of getting it to work without being root.
  2. Reading from the ‘scope’s memory  chokes on non-UTF8 characters. If I do:
    rawdata = instr.ask(“:WAV:DATA? CHAN1″)[10:]
    I get a lengthy Python error which ends:

    File “/usr/lib/python2.7/encodings/utf_8.py”, line 16, in decode
        return codecs.utf_8_decode(input, errors, True)
    UnicodeDecodeError: ‘utf8′ codec can’t decode byte 0x99 in position 10: invalid start byte
    I have no idea what that means, or how to fix it. Alex suggested using ask_raw instead of ask, and the data comes through with no complaints.

I’ve still got to work my way through the Rigol’s data format, but other people have done that before:

  1. Controlling a Rigol oscilloscope using Linux and Python | C i b o M a h t o . c o m
  2. Ken Shirriff’s blog: Four Rigol oscilloscope hacks with Python

I’ll post any updates here, along with the Raspberry Pi forum topic: USB Test & Measurement class (usbtmc) driver?

Incidentally, if you’re working with WFM data dumps from the Rigol ‘scopes (and you should, because they make storing data to USB drives quick), mabl/pyRigolWFM is basically magic. Not merely can it describe and decode those binary files, it can do pretty graphics with no thought required:

made by pyRigolWFMHat tip for the mention: MP3 Options & Oscilloscope Interfacing For Raspberry Pi @Raspberry_Pi #piday #raspberrypi « adafruit industries blog

Update, 2013-12-20: I’ve successfully managed to run most of Ken’s examples with Alex’s code. The major modification you have to do is use ask_raw instead of ask. Example code shown below:

#!/usr/bin/python
# -*- coding: utf-8 -*-

"""
Download data from a Rigol DS1102E oscilloscope and graph with matplotlib
         using  Alex Forencich's python-usbtmc pure python driver

https://github.com/alexforencich/python-usbtmc

scruss - 2013-12-20

based on
Download data from a Rigol DS1052E oscilloscope and graph with matplotlib.
By Ken Shirriff, http://righto.com/rigol

which in turn was
Based on http://www.cibomahto.com/2010/04/controlling-a-rigol-oscilloscope-using-linux-and-python/
by Cibo Mahto.
"""

import usbtmc
import time
import numpy
import matplotlib.pyplot as plot

# initialise device
instr =  usbtmc.Instrument(0x1ab1, 0x0588) # Rigol DS1102E

# read data
instr.write(":STOP")
instr.write(":WAV:POIN:MODE RAW")
# first ten bytes are header, so skip
rawdata = instr.ask_raw(":WAV:DATA? CHAN1")[10:]
data_size = len(rawdata)

# get metadata
sample_rate = float(instr.ask_raw(':ACQ:SAMP?'))
timescale = float(instr.ask_raw(":TIM:SCAL?"))
timeoffset = float(instr.ask_raw(":TIM:OFFS?"))
voltscale = float(instr.ask_raw(':CHAN1:SCAL?'))
voltoffset = float(instr.ask_raw(":CHAN1:OFFS?"))

# show metadata
print "Data size:      ", data_size
print "Sample rate:    ", sample_rate
print "Time scale:     ", timescale
print "Time offset:    ", timeoffset
print "Voltage offset: ", voltoffset
print "Voltage scale:  ", voltscale

# convert data from (inverted) bytes to an array of scaled floats
# this magic from Matthew Mets
data = numpy.frombuffer(rawdata, 'B')
data = data * -1 + 255
data = (data - 130.0 - voltoffset/voltscale*25) / 25 * voltscale

# creat array of matching timestamps
time = numpy.linspace(timeoffset - 6 * timescale, timeoffset + 6 * timescale,
                      num=len(data))

# scale time series and label accordingly
if (time[-1] < 1e-3):
    time = time * 1e6
    tUnit = "µS"
elif (time[-1] < 1):
    time = time * 1e3
    tUnit = "mS"
else:
    tUnit = "S"

# Plot the data
plot.plot(time, data)
plot.title("Oscilloscope Channel 1")
plot.ylabel("Voltage (V)")
plot.xlabel("Time (" + tUnit + ")")
plot.xlim(time[0], time[-1])
plot.show()

Faster MP3 options for Raspberry Pi

One thing the Raspberry Pi is not good at is encoding MP3s at any great speed. At best (using lame) you might get slightly better than 2× real time playback. If you’re using your Raspberry Pi to transcode to another format, that might be slow enough (with other system overhead) to make the output stutter.

While it would be nice to have the GPU as a general media encoder, we’re not there yet. If you must encode mp3s quickly on a Raspberry Pi, there are a couple of options:

Please note that both of these are based on the old ‘8hz’ mp3 encoder, which was a fairly literal interpretation of the original Fraunhofer code. They only start producing okay sounding files at high bitrates.

If you need to decode mp3s quickly, MAD is pretty good: http://www.underbit.com/products/mad. It’s in the repos as ‘madplay’.

Blueline / Black & Decker Power Monitor RF Packets

Update 2014-10-02: I’ve forked Bryan’s Arduino code and added some instructions: scruss/Powermon433

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 possibly 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.
  • 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.
    powermeter-203453vs203525
  • 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):

MARK
====

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

SPACE
=====

          µS
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 …

We won’t, we won’t Roku …

Roku PSU Output

I’m pretty sure the 9V DC power supply for one of my Roku Soundbridges shouldn’t be doing that ↑↑ . This is the second unit I’ve had to replace, my other Soundbridge blowing its 5 V supply a couple of years back. This one cycles from 9.4 to 4.4 V about 5 times a second. Not very DC, but kind of lethargic for AC.

inside roku psu

It’s hard to tell, but one of the caps inside the rather complex little Unifive wall wart may have blown. I’ve scrapped the PSU and replaced it with a beefier one. It seems that power supplies are a problem (see: 1, 2, 3, 4) on these machines, so I wonder when/if I will need to replace this one.

Serious nostalgia…

Atari_ST-Fast_Basic

Oh man — emulating an Atari ST. It’s 1987, and I’m back in that computer lab on the first floor of the James Weir Building

(Jeremy Ruston went on to write TiddlyWiki, amongst other things.)

Protext lives!

Protext screenshot (dosemu)

Oh man, Protext! For years, it was all I used: every magazine article, every essay at university (all two of them), my undergraduate dissertation (now mercifully lost to time: The Parametric Design of a Medium Specific Speed Pump Impeller, complete with spline-drawing code in HiSoft BASIC for the Amiga, is unlikely to be of value to anyone these days), letters — you name it, I used Protext for it.

I first had it on 16kB EPROM for the Amstrad CPC464; instant access with |P. I then ran it on the Amiga, snagging a cheap copy direct from the authors at a trade show. I think I had it for the PC, but I don’t really remember my DOS days too well.

The freeware version runs quite nicely under dosemu. You can even get it to print directly to PDF:

  1. In your Linux printer admin, set up a CUPS PDF printer. Anything sent to it will appear as a PDF file in the folder ~/PDF.
  2. Add the following lines to your ~/.dosemurc:
    $_lpt1 = “lpr -l -P PDF”
    $_printer_timeout = (20)
  3. In Protext, configure your printer to be a PostScript printer on LPT1:

The results come out not bad at all:

protext output as pdfProtext’s file import and export is a bit dated. You can use the CONVERT utility to create RTF, but it assumes Code page 437, so your accents won’t come out right. Adding \ansicpg437 to the end of the first line should make it read okay.

(engraving of Michel de Montaigne in mad puffy sleeves: public domain from Wikimedia Commons: File:Michel de Montaigne 1.jpg – Wikimedia Commons)

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.

Utility Meter Reader: nice idea, flawed implementation

Utility Meter Reader is a great idea for an app. Using the camera on your smartphone, snap a picture of your utility meter’s analogue dials, and through the power of some clever image processing, the app will return your meter reading. five-dial analogue kWh meter fasciaTraditional meters are a bit hard to read, as the dials rotate in alternate directions. You won’t realize why this is unless you get a chance to peek behind the fascia:

the fiddly gear-train inside a five-dial analogue kWh meterThere’s an incredibly fiddly set of 10:1 reduction gears in there, so each dial registers a tenth of the one next to it. Because it’s a drive-train, adjacent shafts rotate in opposite directions. This serves to keep the cost of the meter down at the expense of having to think a bit about how to read the thing.

We only have one dial meter on the house. It’s a 58 year old gas meter (same age as the house) and it’s certainly been around a bit:

gas meter (but not Scarlett O'Gasmeter)

Here it’s reading 969700 ft³, ignoring the lower dials; the units are hundreds of cubic feet. Let’s see how Utility Meter Reader made out with that:

meter read failed

Not very well, it seems. How about if I carefully process the image, sharpening it up, straightening it, and making it very high-contrast greyscale:

not quite right: gas meter

Hmm, the big figure’s completely wrong, but it got the rest.

Okay, so let’s feed it a nice canned example, like this one (courtesy of Greeneville Light & Power System‘s “How to Read Your Electric Meter” page). Even I can see that this reads 46372:

glps.net-sm46372According to Utility Meter Reader, though:

2013-10-21_16.28.15

The big figure’s off by one again. Very strange, especially since it picked up 4.23 for the first dial. In desperation, I clipped a small part of the GE meter image from my screen, and sent it to the app:

2013-10-21_18.41.11

2558 is the right answer. Phew! But the app only seemed to work on a well-lit, clean meter fascia with no glass in the way and an image taken by a rather nice DSLR. One out of three ain’t quite good enough.

One concern I have about the app is that — while it allows you to e-mail a reading to your utility — it quietly BCCs a copy of that reading (which includes your meter details) to imeterreader [at] the-next-future.com. I didn’t see much of a privacy contract when I downloaded the app onto my Android phone, so I don’t know what they are going to do with my readings or personal data. So if it ever gets to working properly, I won’t use that feature.

The app’s a good idea, but the implementation’s pretty far off where it needs to be. Of course, one could quickly whip up an implementation in OpenCV to identify dial circles and read the pointers. But do all this on your smartphone, however, and you’d fall foul of their US patent application.

Faster Java on Raspberry Pi

With the official announcement of Oracle Java on Raspberry Pi, Java just got usable on the Raspberry Pi. It’s still not super-fast, but I’m seeing ~10× speedup over OpenJDK.

To install it (on Raspbian):

sudo apt-get update && sudo apt-get install oracle-java7-jdk
sudo update-java-alternatives -s jdk-7-oracle-armhf

By way of a baseline, here are SciMark 2.0 results on OpenJDK:

$ java -classpath ./scimark2lib.jar jnt.scimark2.commandline -large

SciMark 2.0a

Composite Score: 2.4987047508570632
FFT (1048576): 1.5550941987343943
SOR (1000x1000):   5.32030759023185
Monte Carlo : 0.6005590152716936
Sparse matmult (N=100000, nz=1000000): 2.3584905938878946
LU (1000x1000): 2.6590723561594847

java.vendor: Sun Microsystems Inc.
java.version: 1.6.0_27
os.arch: arm
os.name: Linux
os.version: 3.6.11+

Here’s what the Oracle JDK cranks out (bigger numbers → better):

$ java -classpath ./scimark2lib.jar jnt.scimark2.commandline -large

SciMark 2.0a

Composite Score: 14.94896390647437
FFT (1048576): 6.953238474333376
SOR (1000x1000):   33.91437255527547
Monte Carlo : 8.869794361002157
Sparse matmult (N=100000, nz=1000000): 9.81896340073432
LU (1000x1000): 15.188450741026523

java.vendor: Oracle Corporation
java.version: 1.7.0_40
os.arch: arm
os.name: Linux
os.version: 3.6.11+

That’s a tidy increase, and might make Processing and Arduino much easier to work with.

(It’s still not tremendously fast, though. My i7 quad-core has a composite score of nearly 1450 …)

BeagleBone Black: slow as a dog

All benchmarks are artificial, but this one had me scratching my head. One hears  that the BeagleBone Black is screamingly fast compared to the Raspberry Pi; faster, newer processor, blahdeblah, mcbtyc, etc. I found the opposite is true.

So I buy one at the exceptionally soggy Toronto Mini Maker Faire. Props to the CircuitCo folks, they are easy to set up: just a mini-USB cable provides power and virtual network shell. And BoneScript — an Arduino-like JavaScript library — is very clever indeed. But I need to see if this thing has any grunt, and so I need a benchmark.

After hearing about the business-card raytracer, I thought it would be perfect. I compiled it on both machines with:

g++  -Ofast   card.cpp   -o card

and then ran it with:

time ./card > /dev/null

The results are … surprising:

  • Raspberry Pi: 4′ 15″
  • BeagleBone Black: 12′ 39″ → 3× slower

(In comparison, my i7 quad-core laptop runs it in 8½ seconds.)

I don’t have any explanation why the BBB is so much slower. It’s almost as if the compiler isn’t fully optimizing under Ångström Linux.

Raspberry Pi: system info

$ uname -a
Linux rpi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux

$ cat /proc/cpuinfo 
Processor    : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : swp half thumb fastmult vfp edsp java tls 
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 000f

BeagleBone Black: system info

# uname -a
Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux
# cat /proc/cpuinfo 
processor    : 0
model name    : ARMv7 Processor rev 2 (v7l)
BogoMIPS    : 297.40
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x3
CPU part    : 0xc08
CPU revision    : 2

Hardware    : Generic AM33XX (Flattened Device Tree)
Revision    : 0000

Both boards are running at stock speed.

Update: I’ve tried with an external power supply, and checked that the processor was running at full speed. It made no difference. I suspect that Raspbian enables armhf floating point by default, while Ångström needs to be told to use it.

Trolling the Bruce Nuclear Cost and Clean Air Calculator for Fun & Profit

Energy_Calculator-Bruce_Power
You might have seen the Bruce Power Cost and Clean Air Calculator. It’s supposed to show that nuclear is both cheap and clean, and using anything else would make your bills and your emissions go through the roof. Well, here are 40+ scenarios that all save money and emissions while using no nuclear and no coal:

  1. 3.9% Solar, 5.7% Wind, 0.2% Gas, 0% Nuclear, 90.2% Hydro and 0% Coal saves $5.09/month and 89.7 t/CO2 annually.
  2. 2.1% Solar, 10.1% Wind, 0.3% Gas, 0% Nuclear, 87.5% Hydro and 0% Coal saves $8.97/month and 89.2 t/CO2 annually.
  3. 0.5% Solar, 23.6% Wind, 0.4% Gas, 0% Nuclear, 75.5% Hydro and 0% Coal saves $2.75/month and 88.7 t/CO2 annually.
  4. 2.1% Solar, 2.5% Wind, 0.8% Gas, 0% Nuclear, 94.6% Hydro and 0% Coal saves $16.32/month and 87.1 t/CO2 annually.
  5. 3.1% Solar, 0.2% Wind, 1.4% Gas, 0% Nuclear, 95.3% Hydro and 0% Coal saves $13.27/month and 84.5 t/CO2 annually.
  6. 0.6% Solar, 5.4% Wind, 1.8% Gas, 0% Nuclear, 92.2% Hydro and 0% Coal saves $19.52/month and 82.7 t/CO2 annually.
  7. 1.9% Solar, 15.8% Wind, 2.5% Gas, 0% Nuclear, 79.8% Hydro and 0% Coal saves $2.48/month and 79.8 t/CO2 annually.
  8. 0.3% Solar, 13.6% Wind, 2.5% Gas, 0% Nuclear, 83.6% Hydro and 0% Coal saves $12.08/month and 79.7 t/CO2 annually.
  9. 3.0% Solar, 11.7% Wind, 2.9% Gas, 0% Nuclear, 82.4% Hydro and 0% Coal saves $1.21/month and 78.0 t/CO2 annually.
  10. 0.1% Solar, 24.8% Wind, 3.1% Gas, 0% Nuclear, 72.0% Hydro and 0% Coal saves $1.35/month and 77.3 t/CO2 annually.
  11. 2.7% Solar, 4.8% Wind, 3.6% Gas, 0% Nuclear, 88.9% Hydro and 0% Coal saves $8.77/month and 75.2 t/CO2 annually.
  12. 4.1% Solar, 1.2% Wind, 3.9% Gas, 0% Nuclear, 90.8% Hydro and 0% Coal saves $5.96/month and 73.6 t/CO2 annually.
  13. 1.3% Solar, 0.3% Wind, 5.6% Gas, 0% Nuclear, 92.8% Hydro and 0% Coal saves $18.44/month and 66.3 t/CO2 annually.
  14. 2.4% Solar, 0.1% Wind, 6.0% Gas, 0% Nuclear, 91.5% Hydro and 0% Coal saves $13.26/month and 64.7 t/CO2 annually.
  15. 3.8% Solar, 4.6% Wind, 6.5% Gas, 0% Nuclear, 85.1% Hydro and 0% Coal saves $1.99/month and 62.2 t/CO2 annually.
  16. 1.4% Solar, 11.8% Wind, 6.8% Gas, 0% Nuclear, 80% Hydro and 0% Coal saves $5.54/month and 61.0 t/CO2 annually.
  17. 2.9% Solar, 5.7% Wind, 7.0% Gas, 0% Nuclear, 84.4% Hydro and 0% Coal saves $4.64/month and 60.1 t/CO2 annually.
  18. 0.6% Solar, 14.4% Wind, 7.6% Gas, 0% Nuclear, 77.4% Hydro and 0% Coal saves $6.09/month and 57.7 t/CO2 annually.
  19. 0.7% Solar, 12.1% Wind, 7.9% Gas, 0% Nuclear, 79.3% Hydro and 0% Coal saves $7.64/month and 56.4 t/CO2 annually.
  20. 2.1% Solar, 2.9% Wind, 8.5% Gas, 0% Nuclear, 86.5% Hydro and 0% Coal saves $104/month and 53.5 t/CO2 annually.
  21. 1.9% Solar, 13.5% Wind, 8.6% Gas, 0% Nuclear, 76.0% Hydro and 0% Coal saves $0.36/month and 53.1 t/CO2 annually.
  22. 2.5% Solar, 3.5% Wind, 8.6% Gas, 0% Nuclear, 85.4% Hydro and 0% Coal saves $7.63/month and 53.1 t/CO2 annually.
  23. 0% Solar, 5.4% Wind, 8.7% Gas, 0% Nuclear, 85.9% Hydro and 0% Coal saves $17.02/month and 52.9 t/CO2 annually.
  24. 0.5% Solar, 0.4% Wind, 8.8% Gas, 0% Nuclear, 90.3% Hydro and 0% Coal saves $19.53/month and 52.4 t/CO2 annually.
  25. 1.6% Solar, 3.9% Wind, 9.7% Gas, 0% Nuclear, 84.8% Hydro and 0% Coal saves $10.31/month and 48.5 t/CO2 annually.
  26. 2.6% Solar, 6.6% Wind, 9.9% Gas, 0% Nuclear, 80.9% Hydro and 0% Coal saves $2.76/month and 47.6 t/CO2 annually.
  27. 0.6% Solar, 9.6% Wind, 10.5% Gas, 0% Nuclear, 79.3% Hydro and 0% Coal saves $8.70/month and 45.2 t/CO2 annually.
  28. 1.4% Solar, 1.0% Wind, 10.5% Gas, 0% Nuclear, 87.1% Hydro and 0% Coal saves $13.58/month and 44.9 t/CO2 annually.
  29. 0.9% Solar, 12.1% Wind, 11.7% Gas, 0% Nuclear, 75.3% Hydro and 0% Coal saves $3.96/month and 39.9 t/CO2 annually.
  30. 0.4% Solar, 13.9% Wind, 12.6% Gas, 0% Nuclear, 73.1% Hydro and 0% Coal saves $3.89/month and 35.7 t/CO2 annually.
  31. 0.3% Solar, 10.7% Wind, 13.3% Gas, 0% Nuclear, 75.7% Hydro and 0% Coal saves $6.89/month and 32.9 t/CO2 annually.
  32. 0.3% Solar, 10.5% Wind, 13.3% Gas, 0% Nuclear, 75.9% Hydro and 0% Coal saves $7.11/month and 32.8 t/CO2 annually.
  33. 0.2% Solar, 17.8% Wind, 13.6% Gas, 0% Nuclear, 68.4% Hydro and 0% Coal saves $0.18/month and 31.8 t/CO2 annually.
  34. 2.3% Solar, 6.9% Wind, 14.0% Gas, 0% Nuclear, 76.8% Hydro and 0% Coal saves $0.96/month and 29.8 t/CO2 annually.
  35. 3.5% Solar, 0.2% Wind, 14.0% Gas, 0% Nuclear, 82.3% Hydro and 0% Coal saves $2.11/month and 29.7 t/CO2 annually.
  36. 0.6% Solar, 15.2% Wind, 14.0% Gas, 0% Nuclear, 70.2% Hydro and 0% Coal saves $0.68/month and 29.6 t/CO2 annually.
  37. 3.1% Solar, 3.4% Wind, 14.9% Gas, 0% Nuclear, 78.6% Hydro and 0% Coal saves $09/month and 26.0 t/CO2 annually.
  38. 2.2% Solar, 3.6% Wind, 16.8% Gas, 0% Nuclear, 77.4% Hydro and 0% Coal saves $2.65/month and 17.8 t/CO2 annually.
  39. 1.4% Solar, 1.3% Wind, 17.1% Gas, 0% Nuclear, 80.2% Hydro and 0% Coal saves $8.29/month and 16.2 t/CO2 annually.
  40. 1.1% Solar, 4.5% Wind, 18.2% Gas, 0% Nuclear, 76.2% Hydro and 0% Coal saves $5.74/month and 11.5 t/CO2 annually.
  41. 0.1% Solar, 13.3% Wind, 19.1% Gas, 0% Nuclear, 67.5% Hydro and 0% Coal saves $0.70/month and 7.9 t/CO2 annually.
  42. 0.1% Solar, 6.4% Wind, 19.8% Gas, 0% Nuclear, 73.7% Hydro and 0% Coal saves $7.47/month and 4.7 t/CO2 annually.
  43. 0.7% Solar, 8.7% Wind, 20.6% Gas, 0% Nuclear, 70% Hydro and 0% Coal saves $1.73/month and 1.2 t/CO2 annually.

Sure, some of these won’t be practical from a dispatch/capacity perspective, but hey, that’s Bruce’s issue to explain away.

I couldn’t have done it without this tiny routine to produce a list of random numbers that all add up to 1. No way was I clicking those sliders 10000+ times. Viewing the source was handy, though.

sub rndnormsum {
    # generate N uniformly distributed random numbers that sum to 1
    # see http://stackoverflow.com/a/2640079/377125
    my $n = shift;        # number of entries to return
    my @arr = ( 0, 1 );
    foreach ( 1 .. ( $n - 1 ) ) {
        push @arr, rand;
    }
    @arr = sort(@arr);
    my @result = ();
    foreach ( 1 .. $n ) {
        push @result, $arr[$_] - $arr[ $_ - 1 ];
    }
    return @result;
}

This is why we still have real calculators…

gnome-calculator fail

So I was checking a simple calculation today, and couldn’t find a proper calculator, so I reached for gnome-calculator on the desktop. That was a mistake.

It seems to think that

8×10¹²÷6×10⁹

comes to

1.333333333×10²¹

which is not correct. It would, if I’d  typed it as:

8×1×10¹²÷6×1×10⁹

You can only get the right answer (1333.333…) if you type

(8×10¹²)÷(6×10⁹)

so it’s clear that gnome-calculator isn’t apply the right exponentiation operator precedence when you hit ‘×10y’. It would have been so much better if gnome-calculator supported ‘E’ scientific notation (1.333E21 for 1.333×10²¹).

A bug is filed, but I don’t think I trust it any more. I’m looking at having a proper calculator again, or maybe invest in one of the delightful tiny HP clones from SwissMicros.com.

HP 49G

Almost forgot that I had a barely-used HP 49G in the cupboard. It was barely used because the thing eats AAA batteries. Who knew that Dollarama would have a pair of NiMH AAAs for only $2?

another partial success…

chuckie_egg-loading

I guess I’ve had some qualified success in getting the ZX Spectrum going. After finding the right (mono) cable, sticking it in the Spectrum’s EAR socket, converting tape images to audio with tape2wav, and getting a PAL/NTSC converter, I can load stuff. Sort of.

chuckie_egg-dotcrawl

The problem is mostly with the video converter; it’s too slow. The screen refreshes a couple of times a second, which is enough to lose many Hen-House Harrys. I know, I should’ve gone for a more expensive one.

I’ve found that the audio files made by tape2wav are very loud; 0 dB, full deflection, distort-o-matic. Dropping the volume to -3 dB made games load better. Adding a couple of seconds of silence at the beginning of the file wouldn’t hurt, either.

A (mostly) colour-managed workflow for Linux for not too many $$$

Colour management is good. It means that what I see on the screen is what you meant it to look like, and anything I make with a colour-managed workflow you’ll see in the colours I meant it to have. (Mostly.) You can spend a lot of money to do this professionally, but you can also get most of the benefits for about $125, if you’re prepared to do some fiddly stuff.

The most important part is calibrating your display. Hughski’s ColorHug (which I’ve mentioned before) is as close to plug-and-play as you’ll get: plug it in, and the colour management software pops up with prompts on what to do next. Attach the ColorHug to the screen (with the newly supplied stretchy band), let it burble away for 10–20 minutes, and the next time you log in, colours will be just right.

Calibrating the scanner on my Epson WorkForce WF-7520 was much more work, and the process could use optimization. To calibrate any scanner, you need a physical colour target to scan and compare against reference data. The cheapest place to get these (unless there was one in the box with your scanner) is Wolf Faust’s Affordable IT 8.7 (ISO 12641) Scanner Colour Calibration Targets. If there are a bunch of likeminded folk in your area, it’s definitely worth clubbing together on a group buy to save on shipping. It’s also less work for Wolf, since he doesn’t have to send out so many little packages.

(I’ve known of Wolf Faust since my Amiga days. He produced the most glorious drivers for Canon printers, and Jeff Walker produced the camera-ready copy for JAM using Wolf’s code. While Macs had the high end DTP sewn up back then, you could do amazing things on a budget with an Amiga.)

colour targetThe target comes packed in a protective sleeve, and along with a CD-R containing the calibration data which matches the print run of the target. Wolf makes a lot of targets for OEMs, and cost savings from his volume clients allow him to sell to individuals cheaply.

Scanning the thing without introducing automatic image corrections was the hard part. I found that my scanner had two drivers (epson2 and epkowa), the latter of which claimed to support 48-bit scanning. Unfortunately, it only supports 24-bit, like the epson2 driver, so whichever I chose was moot. I used the scanimage command line tool to make the scan:

scanimage --mode Color -x 175 -y 125 --format=tiff --resolution 300 > Epson-Workforce_WF-7520-WFaust-R1.tiff

which looks, when reduced down to web resolution, a bit like this:

Epson-Workforce_WF-7520-WFaust-R1It looks a lot darker than the physical target, so it’s clear that the scanner needs calibrating. To do this, you need two tools from the Argyll Colour Management System. The first creates a text representation of the scanned target’s colour patches:

scanin -v Epson-Workforce_WF-7520-WFaust-R1.tiff /usr/share/color/argyll/ref/it8.cht IT87/r130227.txt diag.tiff

The result is a smallish text file Epson-Workforce_WF-7520-WFaust-R1.ti3 which needs one more step to make a standard ICC profile:

colprof -A Epson -M 'Workforce WF-7520' -D 'WFaust R1' -ax -qm Epson-Workforce_WF-7520-WFaust-R1

I didn’t quite need to add that much metadata, but I could, so I did. The resultant ICC file can be used to apply colour calibrations to scanned images. Here’s the target scan, corrected:

Epson-Workforce_WF-7520-WFaust-R1-corrected

(I’ve made this a mouseover with the original image, so you can see the difference. Also, yes, there is a greasy thumb-print on my scanner glass near the bottom right, thank you so much for noticing.)

I used tifficc from the Little CMS package to apply the colour correction:

tifficc -v -i Epson-Workforce_WF-7520-WFaust-R1.icc Epson-Workforce_WF-7520-WFaust-R1.tiff Epson-Workforce_WF-7520-WFaust-R1-corrected.tiff

There are probably many easier, quicker ways of doing this, but this was the first thing I found that worked.

To show you a real example, here’s an un-retouched scan of the cover of Algrove Publishing‘s book “All the Knots You Need”, scanned at 75 dpi. Mouseover to see the corrected version:

all-the-knots-you-need_algrove

(Incidentally, there are two old but well-linked programs that are out there that purport to do scanner calibration: Scarse and LPROF. Don’t use them! They’re really hard to build on modern systems, and the Argyll tools work well.)

The last part of my workflow that remains uncalibrated is my printer. I could make a target with Argyll, print it, scan it, colour correct it, then use that as the input to colprof as above. I’m suspecting the results would be mediocre, as my scanner’s bit depth isn’t great, and I’d have to do this process for every paper and print setting combination. I’d also have to work out what magic CUPS does and compensate. Maybe later, but not yet.