In earlier posts of this series I’ve looked at ladder board and Quick2Wire’s boards. This post is about the official expansion project board for the Raspberry Pi, named after its creator Gert van Loo, the Gertboard.
Construction
Like the other boards I’ve looked at Gertboard comes as a kit of parts. The two things that are unlike the other boards are that there are a *lot* of parts in the kit, and some of them are surface mount components.
Soldering SMT
Surface Mount Technology is designed for machines not people, and in most cases kits aimed at hobbyists come with any SMT bits already in place. Not the Gertboard though. It is possible to solder SMT by hand, at least with simple components like resistors and capacitors, it’s just a bit tricky. If you’re thinking of building a Gertboard then I have two pieces of advice for you :
- Don’t work over a carpet.
- Clean the floor before you start, because at some stage you’ll be looking for a capacitor the size of a bread crumb, and you don’t want to be dealing with actual bread crumbs.
My daughter’s young eyes and hands turned out to be very helpful, but even with that assistance we had a few cases of hunt the component after something had pinged out of the needle nose tweezers I was using to hold things in place.
Soldering the rest
The through pin parts of the Gertboard are as easy as any of the other boards I’ve worked with. There’s just a lot of them, so reckon on an entire afternoon to put the whole thing together.
Capabilities
Gertboard does a lot of different things (and has to be configured with various jumpers and jump leads for whatever pieces of functionality you’re after). It has buttons, LEDs, ADCs, DACs, motor controllers and more. It even has its own computer – the same Microcontroller (ATmega328) as used on many Arduino boards.
There’s a lot more functionality than I can really do justice to here, so I’d suggest a read of TechFruits’ ‘Getting to Know Your Gertboard’.
In use
I’ve not really done much with my Gertboard yet past running some rudimentary GPIO examples that use the push buttons and LEDs – stuff that would work just as well on the ladder board. So far its enormous potential has exceeded my ability to think up any cool projects for it. As the motor controller is something that I don’t have with other Raspberry Pi boards (or any of the other dev boards I use) then that’s the most likely area I’ll exploit.
Conclusion
Gertboard is the mother of all project boards for the Raspberry Pi. Just putting it together feels like a major accomplishment. I look forward to having the time and a bright idea for doing something really cool with it.
Filed under: Raspberry Pi, review | Leave a Comment
Tags: ADC, DAC, dev board, Gertboard, GPIO, Raspberry Pi, Raspi, RPi, SMT, soldering, surface mount
End of support, end of the line
I’ve written before about the myth of software support. Software mostly doesn’t work, vendors mostly don’t fix stuff, and the world keeps turning anyway. Everything’s broken and nobody’s upset.
So why do companies stop using perfectly good stuff (hardware and software) simply because they can’t buy support from the original vendor? This position seems nonsensical to me, but I’ve come across two examples in the past week:
IRIS
The Iris Recognition Immigration System (IRIS) was a perfect example of trading privacy for convenience. I let the UK government take pictures of my eyes, and in return they let me get out of passport control quicker by going through an automated gate rather than standing in line. You didn’t have to be a UK Citizen to use it, so it was particularly beneficial to frequent travellers from outside of the EU who might otherwise face a long line at passport control.
One of my friends complained the other day about IRIS not being available, and quickly got an answer from another friend about the reason:
The machines are still there. I’d bet that the machines still work. But somebody is too scared to turn them on in case they break because Microsoft won’t any longer be on the hook to ‘support’ them. I can make two obvious points at this stage:
- The appropriate time to stop using the machines is when they actually stop working.
- If they had stopped working when the ‘support’ was still in place then it would still have taken days (at least) to get a fix.
What is it about software support that causes such insane risk/benefit trade offs?
Part of the problem is of course ‘security’. Microsoft ending support for XP means no more patches for vulnerabilties. This is a problem if you’re an Internet connected PC surfing the web. This shouldn’t be an issue for an applicance with some embedded software.
I’m left wondering how much the UK Borders Agency paid MS for support for IRIS, and how much utility they ever got out of that contract? I expect the answer is something along the lines of too much and not enough.
Before moving on it’s worth noting that IRIS has been partially replaced by new automated gates for those with EU issued RFID enabled passports. This is no good to Kirk, because he has a US passport, and it’s turning out to be no good to me because the regular travelling public has a much higher moron that can’t work things ratio than those that opted into IRIS.
Update (26 Jan 2013) – Kirk tweeted yesterday evening that the IRIS machines are back in action (at least at Heathrow T5). Perhaps somebody saw sense.
Pano Logic
The next example I’ve come across is Pano Logic, who made a thin client device (which they branded ‘Zero Client’). It seems that at least one of their customers has decided to trash over a hundred of the devices as their IT support guy is now looking for creative ways to hack the hardware.
Presumably the day before support ended the devices were working fine, and the day after they were still working fine. The lack of support shouldn’t be an issue until something actually goes wrong. The main causes of going wrong are installation issues (which had already been passed) and age issues (when component failure comes along) – hence the bathtub curve. The age end of the bathtub isn’t all that often an issue in IT because we tend to replace stuff long before it falls apart, though the Pano Logic device might have been an exception – I’d expect that obsolesence would catch up with them due to changes in monitor technology or something like that.
Conclusion
The ability of IT vendors to support things is poor at the best of times. Withdrawal of support shouldn’t be an immidiate trigger to get rid of something – it’s just one of the indicators that it’s time to draw up plan B for when failure actually does occur.
Filed under: could_do_better, technology, travel | 2 Comments
Tags: end of life, IRIS, Pano Logic, support
Return of the Nanode thermometer
It’s almost a year since I built my Nanode thermometer, and it looks like another really cold snap is headed towards the UK – perhaps snow over the weekend.
I’ve not had it set up for a little while, as the TMP36 sensor was reclaimed for a project that put Scratch and an Arduino together to create an on screen fire breathing dragon when hot breath hit the sensor. I’ve also more recently used the sensor with the Quick2Wire Analogue board.
This time I wanted to record data from the Nanode so that I could do some charts later on. I could have done this by modifying the sketch to use MQTT or post data to Pachube Cosm or similar, but I took the path of least resistance and wrote a couple of scripts to scrape from the existing app:
get_temp.sh uses lynx and some sed to strip the temperature reading from the cruft around it:
lynx -nonumbers -dump http://nanode.swos.local | grep Temperature | sed s/'Temperature: '// | sed -e 's/^[ \t]*//'
loop.sh prints a formatted date and time to a (CSV) text file followed by the temperature from get_temp.sh:
#!/bin/bash while : do printf %s "$(date '+%Y%m%d%H%M')" >> temp && echo -n ',' >> temp && ./get_temp.sh >> temp sleep 1800 done
I’m running loop.sh in a screen so that I don’t need a persistent connection to the VM. I’ll update with charts if any of them turn out to be interesting (e.g. a steep overnight drop or something like that).
Filed under: Arduino, code | Leave a Comment
Tags: arduino, bash, csv, date, lynx, Nanode, network, printf, script, sed, sensor, temperature, thermometer
In part 1 of this series I looked at ladder board, and in the next part I plan to review the Gertboard. This post is about Quick2Wire‘s boards, where I’ve been fortunate enough to try out some alpha and beta samples.
Quick2Wire concept
There’s an interface board that connects to the general purpose input output (GPIO) headers on the Raspberry Pi, which can be used on its own as a safer way to break out the GPIO pins (versus something like a Pi Cobbler).
There are also extension boards that plug into the I2C bus (and more planned that will harness SPI). I tried out two of the I2C boards, which can be daisy chained together.
Interface board connected to I2C expander and analogue board
Interface Board
It took my son around an hour to turn this from a kit into a working board, and I didn’t have any faults to resolve. It offers a bunch of different functionality:
- 8 diode protected GPIO ports
- a push button and LED that can optionally be connected to two of the GPIO ports
- a voltage regulator for extra 3.3v
- an FTDI header for serial I/O
- I2C connection
- 2x SPI connectors
My first test for the board was to try out the push button and LED using Gordon Henderson’s Wiring Pi from the command line, and I was quickly able to read whether the switch was pushed and turn the LED on and off.
I returned to the LED later when using Quick2Wire’s Python API. Firstly I installed their GPIO admin command which lets an ordinary user do stuff with GPIO without using sudo. There are a few steps to getting this going:
- Add Quick2Wire as a Raspbian Software Source
- Install with:
sudo apt-get install quick2wire-gpio-admin
- Add your user to the gpio group
sudo adduser $USER gpio
- Log out and back in again so that the group change can take effect
- The gpio-admin command is now ready to use e.g. to allow the LED to flash:
gpio-admin export 12
The Python API is installed from github (I put it into my home directory):
git clone http://github.com/quick2wire/quick2wire-python-api
I created a little environment script (env.sh) to set up PYTHONPATH in accordance with the installation instructions:
export QUICK2WIRE_API_HOME=/home/pi/quick2wire-python-api export PYTHONPATH=$PYTHONPATH:$QUICK2WIRE_API_HOME/src
Then when I wanted to use the Python API I could simply:
. ./env.sh
I then modified one of the Quick2Wire examples a tiny bit to give me an executable script:
#!/usr/bin/env python3
from time import sleep
from quick2wire.gpio import Pin, exported
with exported(Pin(12, Pin.Out)) as pin:
while True:
pin.value = 1 - pin.value
sleep(1)
I2C Extender
The I2C extender board offers a further 16 digitial GPIO pins, and took my daughter about an hour to put together[1]. To use the board requires I2C support to be enabled on the Raspberry Pi (and as previously noted this can interfere with other GPIO stuff that uses the pins that are shared with I2C).
/etc/modprobe.d/raspi-blacklist.conf needs to look like this:
# blacklist spi-bcm2708 # blacklist i2c-bcm2708
and i2c-dev needs to be added to /etc/modules:
# /etc/modules: kernel modules to load at boot time. snd-bcm2835 i2c-dev
If there are other modules there too (such as 8192cu for WiFi) then that’s not a problem.
Just like with GPIO it’s necessary to add the user to the appropriate security group:
sudo adduser $USER i2c
At this stage a reboot is needed (rather than just log off and back on again) so that the kernel module changes can take effect.
Once the RPi is back up and running it’s possible to see the i2c devices with i2cdetect:
i2cdetect 0
WARNING! This program can confuse your I2C bus,
cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
The example above shows that the expander board is connected at address 22 (because I fiddled with the address dip switches) and the analogue board is at 48.
I didn’t really do much with the expander board yet, but I did modify one of the Python examples to prove to myself that it would work:
#!/usr/bin/env python3
import quick2wire.i2c as i2c
address = 0x22
iodir_register = 0x00
gpio_register = 0x09
with i2c.I2CMaster() as bus:
bus.transaction(
i2c.writing_bytes(address, iodir_register, 0xFF))
read_results = bus.transaction(
i2c.writing_bytes(address, gpio_register),
i2c.reading(address, 1))
gpio_state = read_results[0][0]
print("%02x" % gpio_state)
Analogue board
The analogue board is based on the PCF8591 IC, which offers 4 8bit analogue to digital inputs and a single 8bit digital to analogue output. Once again it took about an hour for my daughter to put it together[2].
I tried it out with a TMP36 temperature sensor connected to AIN0 and the following code to read out the temperature in celcius every second:
#!/usr/bin/env python3
from time import sleep
from contextlib import closing
import quick2wire.i2c as i2c
from quick2wire.parts.pcf8591 import PCF8591
with closing(i2c.I2CMaster()) as master:
pcf = PCF8591(master)
pin = pcf.begin_analogue_read(0)
while(True):
print(int(((330*pin.read())/256)-50))
sleep(1)
Conclusion
The Quick2Wire boards bring together a modular and extensible hardware platform with a rich and easy to access software platform. I’m looking forward to getting a better understanding of the Python API so that I can do more with the boards I do have, and there’s plenty of scope for adding more boards later. It will be interesting to see what comes along to use the SPI interfaces.
Notes
1. I had some trouble initially with the expander board not showing up on i2cdetect, which came down to a very hard to spot dry joint on the board.
2. Somehow my daughter managed to get a solder splash on the component side of the board that shorted AGND and VREF. This was a total pain to diagnose and fix as I had to remove the chip holder to resolve the issue.
Filed under: code, howto, Raspberry Pi, review | 2 Comments
Tags: ADC, API, DAC, dev board, github, GPIO, I2C, PCF8591, python, Quick2Wire, Raspberry Pi, Raspi, RPi, soldering, Wiring Pi
One of the things that attracted me to buying a Chromebook was reports I’d read that it would run Ubuntu (and run it fast).
Today my 32GB Transcend Class 10 SDHD card arrived, so I set to work installing ChrUbuntu – Ubuntu 12.04 packaged up for the Chromebook[1]. Like some others I hit an issue with the download of the 11th archive file (ubuntu-1204-arm.binak.bz2), and I needed to repartition the SD card using parted[2]. Once I got past that issue it took a while to install due to my slowish broadband, but it was all very straightforward.
In Use
When I startup my Chromebook I can now choose between booting ChromeOS (in dev mode) by hitting Ctrl-D or Ubuntu by hitting Ctrl-U. Both start up really quickly (around 10s), so there’s no massive penalty to be paid when switching between one and another.
I’m not a great fan of Unity, and I’ve not invested the time yet to find my way around it well, but all of the basic stuff I need is there. My main reason for wanting Ubuntu is to get a full featured set of tools, and I can get that with a terminal window. Having FireFox a click away if I need to look stuff up is also very handy (and it’s working fine now for writing this blog post).
Subjectively things feel fast – particularly on the command line – my comparison point being various VMs and VPSes (and of course my Raspberry Pis). Ubuntu feels a little clunky compared to ChromeOS, but it doesn’t feel slower.
There are still issues with trackpad support and keyboard maps (which may not be helped by the fact I have a UK keyboard), but nothing yet that’s turned into a major trip hazard.
It’s slightly annoying that the SD card pokes out of the machine so far. Hopefully somebody will make a Micro SD to RS-MMC size adaptor (something like the Adafruit Low-profile microSD card adapter for Raspberry Pi, but without the Micro SD bit poking out of the top).
ChromeOS Dev mode
It would be remiss of me not to mention ChromeOS Dev mode, as this is needed for the ChrUbuntu install process.
Firstly going into dev mode wipes locally stored files (such as the SSH keys I’d installed), which is a perfectly sensible security precaution. I’d known this when I got the Chromebook, and considered going straight into dev mode to avoid any wasted effort, but in the end I left things be in order to get a feel for the vanilla experience.
Now that I’ve enabled dev mode I’ll probably not go back, as it provides a much more capable crosh, which has proper shell capabilities. In fact many of the things that I thought I wanted Ubuntu for may turn out to be possible from dev mode.
Conclusion
It was cheap and straightforward to add Ubuntu capabilities to my Chromebook, and I’m sure it’s going to come in handy. Ubuntu works well on the machine, and I probably need to spend more time getting familiar with Unity. Hopefully the hardware support will improve with time (or better still Canonical might do something official). I’m also impressed with the enhanced abilities of crosh when in dev mode.
Notes
1. Be careful to install the ARM version (34v87) rather than the x86 version (tnyga)
2. I had a go first at just reformatting it on a Windows machine, but that didn’t help
Filed under: technology | 4 Comments
Tags: ARM, Chromebook, ChromeOS, Chrubuntu, crosh, dev mode, Linux, parted, SD card, SSH, Ubuntu
The Quick version
- Get OpenELEC Download an SD Card image file from resources.pichimney.com (latest version at the time of writing is RC1 – 2.99.1).
- Install OpenELEC Unzip the image file and burn it onto a (1GB or bigger) SD card using Win32DiskImager (for Windows) or dd (for Mac or Linux).
- Plug Everything in Plug the SD card into the RPi. Plug the RPi into your TV (or AV amp/receiver) using HDMI. (Optionally[1]) plug in a remote control (e.g. a cheap Win MCE remote from eBay or a nice Kogan keymote). Attach the RPi to your network. Finally plug in a suitable 700mA power supply.
- Switch On.
- Enable AirPlay in System > Settings > Services > AirPlay
- Enjoy The OpenELEC device should now show up on the AirPlay menu on any iOS device connected to the same network allowing music, videos, YouTube etc. to be streamed.
A more longwinded explanation
I’ve had a number of people ask me recently whether they could possibly get AirPlay working on the Raspberry Pi, and I’ve even seen some much more involved HowTo type articles. All that effort isn’t really necessary, as XBMC has had AirPlay support for some time, OpenELEC packages XBMC in an easy to use and lightweight container, and OpenELEC is a doddle to install from an SD card image file.
If you don’t have a wired network
Then there’s a bit more setup involved to get things working over WiFi with a suitable USB dongle, but not very much. Go to System > OpenELEC and fill out the Network (or Network 2) section:
Network Technology – WLAN
Network Interface – wlan0
Static IP settings – ignore this unless you’re sure about what you’re doing
WLAN SSID – whatever your WiFi network is called
WLAN Security – select whatever type you use (if any) and fill out the password
I’ve tested this myself with an Edimax EW-7811UN, which is one of the adaptors known to work reliably with the RPi.
Limitations
The only digital audio output from the Raspberry Pi is HDMI. This is fine if you’re AirPlaying video/YouTube, but not so great for music (unless you have an HDMI capable AV amp/receiver or an HDMI/SPDIF splitter). You can of course get audio out of the 3.5mm jack, but whilst AirPlay isn’t audiophile quality anyway the RPi analogue output is likely to disappoint.
Notes
[1] A USB remote isn’t essential, as there are XBMC remote apps for iOS and Android. It’s also possible (but not very living room friendly) to use a regular keyboard and mouse.
Filed under: howto, Raspberry Pi | 2 Comments
Tags: AirPlay, image, iOS, iPad, iphone, ipod, openelec, Raspberry Pi, Raspi, RPi, SD card, wifi, XBMC
This is the first post in what will be (at least) a three part series. I’m also planning to look at the Quick2Wire board(s) and Gertboard.
The ladder board (sold by Tandy for the bargain price of £5.99) is designed for Gordon at Drogon’s ladder game[1], but can be used for various other purposes – basically anything you can think of that employs 10 LEDs and 4 switches.
It took each of my kids around half an hour to turn the kit into a working board, and it’s all very straightforward through pin components.
In use
Gordon supplies a test program for the board, which provides an easy way to confirm that everything is working as expected. With both of the boards I’ve tested I’d note that the switch test didn’t work exactly as expected – the green LEDs would stay on rather than only coming on when the corresponding button was pressed.
Once the board is proven to work OK there are various apps that can then be used to do stuff with it:
- Ladder game – a C programme (that must be run using sudo) where the player has to time button presses to complete a complete set of flashing LEDs. My son and I had originally built this using a homemade Pi Cobbler and breadboard, but it’s much better to have a proper board.
- Simon – a BASIC version of the classic sequence memory game
- Anything you can imagine – with C, Python, BASIC or whatever. I don’t know whether anything has been done yet to bind it to Scratch (like the demos I saw of PiFace at a Raspberry Jam event last week), but I’m sure that will come.
I2C issue
I’d also note that this board doesn’t play nicely with I2C (which I’d enabled for work with the Quick2Wire boards), so I had to go back and disable I2C support. It’s hard to blame the board for this, as the underlying issue is the reuse of various general purpose input/output (GPIO) pins as part of the Raspberry Pi design. This is probably one of those cases where it’s useful to be able to boot the Raspberry Pi from different SD cards (though I can also understand that many people will want to have a single card with all of their stuff on).
Conclusion
The ladder board is cheap, easy to use and a lot of fun. It would definitely be my recommendation for a first project board on the Raspberry Pi – particularly for younger or less experienced makers.
Notes
1. Gordon really has been one of the heroes of the early days of Raspberry Pi. His Wiring Pi library provides a great way to work with GPIO, and he’s done a ton of inspirational projects and guides.
Filed under: Raspberry Pi | 3 Comments
Tags: board, GPIO, Ladder, LED, makers, project, Raspberry Pi, Raspi, review, RPi, switch
OpenELEC 3.0 RC1
The first release candidate for OpenELEC 3.0 (featuring XBMC 12 ‘Frodo’) is now available (official announcement).
If you’d like to download an SD card image to install on a Raspberry Pi then it’s available from the official_images section of the Pi Chimney resources site. RC1 is 2.99.1, and later builds will be available from the same link.
To install the image first unzip it and then use Win32DiskImager (if on Windows) or dd (if on Linux or Mac) to write the image file to your SD card (which needs to be 1GB or larger).
If you’re already running OpenELEC on your Raspberry Pi then just get the release bundle from the OpenELEC.tv download page, extract the files (using 7zip or WinRAR or similar) and follow the Manually Updating OpenELEC guide.
Filed under: howto, Raspberry Pi | Leave a Comment
Tags: 3.0, file, Frodo, howto, image, openelec, Raspberry Pi, Raspi, RC1, release, RPi, SD card, update, upgrade, XBMC
ARM Chromebook – one week on
I got my Chromebook a week ago, so it’s time to reflect on my experiences so far (beyond my initial first impressions).
CC some rights reserved by Cajie
The good parts
Blogging – it’s pretty much a perfect blogging tool, and I’ve managed to get a lot of posts done in the past week. The holiday may have had something to do with that too, but I’ve been able to get more done than during previous weeks that were also holiday.
Battery – the battery life has stood up to expectations, and much like my iPad I don’t find myself worrying too much about where the power cord is.
Flexibility – apart from a session of micro controller hacking, where I needed an Eclipse C/C++ install and a bunch of other PC tools[1], I’ve been able to handle pretty much every task. I was worried for a moment about screen grabs and snips (as I find the Windows 7 snipping tool so handy), but the Chromebook handled itself very well in that area. For many of the things that do need a PC I’ve been using the remote desktop app to one of my Microservers.
The not so good parts
Remote desktop – I’ve had to set the native resolution of the machine I’m connecting to at 1280×720 (it was at 1600×1200, but it’s in my garage so it only gets used at the console when something bad has gone wrong). This results in black bars around it in full screen mode, but a Chromebook native 1366×768 wasn’t on offer. Another slight issue is when logging in dislodges an RDP session from another device, where it connects to log in, disconnects, and has to be connected again (after a little wait) – roll on the day when Chrome RDP works on ARM.
SSH – I’ve still not figured out an easy way to launch multiple SSH sessions from scratch rather than duplicating the first connection.
If I hold it by the left corner then the body flexes so much that the trackpad doesn’t work reliably.
The really annoying thing
It drives me mad when I go back to a browser tab and it refreshes rather than just coming back to where I was.
My iPad does this too (and it’s clearly a big annoyance for many others).
On the iPad I get cross when I’ve clicked on a Hacker News link from Google Reader, and when I go back to Reader it refreshes – so I then can’t see the article I was on because it was marked as read, so it’s a real bother to upvote what I was just reading.
On the Chromebook the issue has been WordPress refreshing[2] after I’ve gone somewhere else to get links to paste in, and then the formatting getting all messed up (e.g. paragraph breaks disappearing). Worse still I’ve had times when content has been lost.
This also seems to be a well documented problem. I’m now starting to keep a close eye on chrome://discards, and like others I suspect a memory leak somewhere as my 2G of RAM seems to get swallowed up with alarming speed whilst not doing much in particular to provoke it. The bottom line here is that if I was just running Chrome on a Windows netbook with 2GB of RAM (which I pretty much did for years) then this wouldn’t happen.
My fingers are crossed that R25 fixes the memory leak as well as bringing me Chrome RDP on ARM, but given how long this issue seems to have been around I’m not holding my breath.
Conclusion
The honeymoon period isn’t over yet, and I’m mostly pretty happy with my Chromebook, but there are some issues to be ironed out.
So far I’ve kept things stock, but after yesterday’s Ubuntu mobile announcement I’m more tempted than ever to try Chrubuntu (as I think the Samsung 303C hardware would make an excellent Ubuntu platform). A 32GB Class 10 card is on its way to me now (as the 16GB one I had spare got pressed into duty for Raspberry Jam and some other Pi stuff).
Notes
[1] Since I was playing with an ARM based STM32F3 dev board it will be interesting to see if/when the day comes where I tinker with it without using a cross compiler.
[2] To be fair it was everything that was refreshing (including gmail, which was loading from scratch – that doesn’t happen on my iPad) not just WordPress, but it’s been WordPress that I was trying to use.
Filed under: review, technology | 3 Comments
Tags: 303C, ARM, Chrome, Chromebook, Chrubuntu, discards, iPad, memory leak, RDP, refresh, remote desktop, Samsung, SSH, tabs, Ubuntu
The perils of modern lego
Update 26 Nov 2014 – I’m very pleased that this post has been referenced by Justin Parkinson’s piece on the BBC News site ‘Has the imagination disappeared from Lego?‘, but I fear he may have misunderstood (or misrepresented) what I say about instructions.
The blogger Chris Swan argues that instructions marked the start of a decline.[1]
Read on for the full skinny…
TL;DR – instructions aren’t the problem, they’re a good and necessary part of all sets beyond basic boxes of bricks, the problem is sets that only make one thing (like a dragon or something licensed from a movie).
Back to the original post…
I must have got my first Lego when I was about 3 or 4. It was pretty basic stuff – mostly 4×2 blocks and a handful of 2×2 blocks. I remember building a house out of it, and being shown by my mum to overlap the bricks to make a strong wall rather than building straight towers that would easily fall.
My Lego house didn’t look this slick. CC licensed by Atsushi Tadokoro
I’ve remained a Lego fan all of my life, buying some of the earliest ‘Technical Lego’ (now Technic) sets, and getting the first Mindstorms set shortly after launch. Even though the Technical sets came with detailed instructions to make various cars and other vehicles the real joy was always in modifying things and creating new stuff from scratch. Bringing multiple sets together meant more variety and bigger projects[2], and when Mindstorms came along I gave myself the challenge of making stuff that could be controlled over the web, blending physical construction with software engineering.
More like Airfix
I also loved making scale models (mostly of planes and warships) when I was a kid. At one stage there was a promotion run by Tudor Crisps (which I think was a local brand in the North East of England) to collect vouchers to send in for Airfix kits – my dad bought them by the box load at the local cash and carry so we could collect all of the sets. Modern Lego is I think more like Airfix for two reasons:
- Each set only makes one thing – whether that’s a spaceship or monster or whatever.
- You don’t break it. I wasn’t the kind of kid who’d destroy their Airfix creations with pellet guns. The finished models were cherished, and I’d get very cross if anybody (usually my brother) damaged them. Some of my models still grace various nooks and crannies of my grandma’s house.
I’ve read criticism elsewhere relating to the single outcome issue – that it harms creativity because kids have to colour in between the lines rather than making their own lines.
I’m just starting to see the damage of the second issue. I passed on my Technical Lego and Mindstorms sets to my son, and also bought an extension kit for the Mindstorms to make fairground rides (which seemed like a good mix of the old and new approaches). The first ride was a big hit with both of my kids, and they enjoyed reprogramming it to spin at different speeds etc. But it hasn’t been taken apart to make one of the other rides. I think it’s now clear to me why nothing much emerged from the Technical sets (the instructions are still intact, but hidden away in the boxes, and all of the parts got mixed up years ago and sorted by size/colour rather than which set they came from).
Why did this happen?
It’s pretty clear that Lego needed to do something about the impending expiry of its key patent around the bricks, and the licensing arrangements for hot properties like Star Wars give it a lot of stickiness with fans young and old. They’ve also had some (mixed) success with their own new brands.
Single purpose sets also drive a lot more purchases than sets that get rebuilt into different configurations. I considered myself quite a Lego fan, but only had one giant box of regular Lego, and three Technical sets. My own kids must have been bought at least an order of magnitude more.
What can be done?
I was chuffed to see some photos of Lego towers built out of some Duplo I got for my Nephew last year, and I think part of the answer is to start out with generic sets so that creativity can develop alongside of construction.
I’m not sure whether this means that generic sets should be preferred over single model sets, but I certainly think time should be dedicated to creative construction (and destruction).
I also suspect that Technic is somewhat overlooked these days, but with sets suitable for 8 year olds it’s probably good to have some alongside the other (sub)brands.
Conclusion
Lego for me was always about creativity, remaking and improving on existing designs. Those things don’t happen with sets that are designed to build a model of a single thing. But that’s not the only problem – Lego taught me the art of creative destruction – the need to break something in order to make something better. Single outcome sets encourage preservation rather than destruction, and sadly that makes them less useful, less educational (and in my opinion less fun). Good old generic Lego (and the more sophisticated Technic sets), with endless possibilities on offer, haven’t gone away, they’ve just been drowned in a sea of marketing for other brands.
Notes
[1] The original text called me a ‘design blogger’.
[2] The same could also be said for Mechano, though that too seems to have gone down the same path of single purpose sets.
Filed under: grumble | 20 Comments
Tags: construction, creativity, design, Lego, Mindstorms, model, Technic, technical
Chris Swan's Weblog 