Category: computers suck

  • elementary OS: could be worse

    Imagine there’s a really nicely arranged screenshot of elementary OS here. You know, browser arranged just so, dock showing shiny icons, and a coy little dropdown showing that I’m playing music that’s faaaar hipper than you’ll ever be. Got that image? Good. ‘Cos I just spent a ½-hour setting it up, then deleted it in a second of unthought when I cleaned up the elementary OS VM from VirtualBox. Aargh!

    elementary OS is a very pretty Ubuntu/Debian distro. It has a very strong visual identity, and is designed and managed by a very small group. This rigidity may annoy the seasoned Linux user,  but will likely work in a more logical way if you’re used other OSs. You won’t face jarringly mismatched user interface elements, as still happens with Ubunty/Unity. Linux UX allows too much choice, so you’re never sure which options do what at any given time.
    (F’rinstance: Ctrl+Q used to quit programs. Now, Ubuntu wants us to use Ctrl+W, the old close-the-window command. Some programs no longer quit with Ctrl+Q, so you’re left with an awksmash of Ctrl+Q_no-I-meant_W. Don’t make me think!)

    A couple of things put me off elementary OS:

    1. You can’t put files on the desktop. In an effort to be tidy, eOS forbids you putting the stuff you’re working on in the place you’ll see it. This is a major annoyance, but worse things are coming.
    2. It expects you to pay for it. No, really. They want $10 from you, right from the get-go. While you can get around this (click the “Download” button; it only looks like it’s linked to the payment button), they do something far, far worse:
      They use a PayPal popunder.
      Srsly. Gahh. Eww. Pop-unders are the web equivalent of taking a 💩 on an art gallery floor. If they’re low enough to pull that kind of stunt, who knows what leakage lurks under their pretty graphics?
  • Linking ≠ Abuse.

    Got this e-mail today.  Addresses redacted, but otherwise verbatim:


    Subject: Link removal request
    From: Rodger Lodge <entrust_____@gmail.com>
    Date: 14-01-27 08:46 AM
    To: abuse@my hosting company.com, me, hostmaster@my hosting company.com

    Hi,

    We have recently received a notification from Google stating that our website has unnatural links pointing towards it. This has really damaged our rankings on Google and as a result, we’re trying to clear things up.
    Our website url is www.entrust.net.

    We noticed the following links are pointing to our website from your site:
    http://scruss.com/blog/2006/12/
    http://scruss.com/blog/2006/12/14/when-you-really-havent-chosen-not-to-trust-citrix-mac-os-x-and-entrust-certificates/
    http://scruss.com/blog/tag/citrix/

    I appreciate this is inconvenient and isn’t a reflection on your website at all, but if you’re able to remove the links, we would really appreciate it and would be very grateful.

    I look forward to hearing from you.

    Rodger Lodge

    Entrust, Inc.


    So, one of the prime security companies (I’m strongly resisting the urge to link to them here, but I’m above that) is using gmail to send out official notices? Why not a securely signed e-mail from their .net domain? That might be more legit. Also, sending me a copypasta response lifted  from the “Ultimate Guide to Google Penalty Removal” seems a little … gauche.

    If this is for real, then I’m annoyed. I wrote the original article in 2006 in an attempt to help Mac users get work done with a popular remote-access package. I’m not dissing the company in any way: I’m helping people use their products better. Linking is not abuse.

    It’s probably just spam, though.

    Update: Nope, not spam. Got an apology by e-mail from Nate Plaunt of Online Performance Marketing, saying: “This was an automated email generated by this digital agency and your sites were mistakenly targeted”.  Still no apology for the e-mail to abuse@…, tho’. That’s never an acceptable first communication.

  • 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 -connFont -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-16 -smallFont -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-16 -mediumFont -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-16 -largeFont -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-16 -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 and archive.org here: HP 48g User Guide, HP 48g Quick Start Guide.

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

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

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

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

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

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

    Update the system

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

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

    Install Sun Oracle Java

    sudo apt-get install oracle-java7-jdk

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

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

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

    sudo update-alternatives --config java

    Download & Install Processing

    Go to Download \ 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

    Hey! This post is completely ancient. It doesn’t even use Python 3. Advice given here might be well out of date.


    … 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] &amp;lt; 1e-3):
        time = time * 1e6
        tUnit = "µS"
    elif (time[-1] &amp;lt; 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

    Hi there! This post is beyond ancient, and made sense back when the original Raspberry Pi Linux distributions didn’t have floating point support. With the multi-core Raspberry Pi 3, lame now runs at an acceptable rate. You should probably ignore this post unless you’re deliberately trying to recreate that bubbly old MP3 sound.

    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 (though use Bryan’s, srsly)

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

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

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

  • Google Contacts – ISO dates, please

    I’ll just leave this stinker here, shall I?

    google contacts quite failing to understand ISO standard dates

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

  • How come I didn’t know about Quinzee?

    QuinzeeQuinzee is almost the perfect domestic usage dashboard for me. Pretty graphics, clear stats, and easy signup through Toronto Hydro’s TOU portal.

  • 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

    This is about scientific notation, and how Gnome Calculator still doesn’t do it correctly.

    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?

    Update, 2021: Use galculator instead. It does the right thing, and supports RPN like a calculator should. You don’t need to remember any precedence rules when you have The Truth.