Friday, 17 September 2010

Another day, another dollar

I spent most of today programming flash chips using DFU (Device Firmware Update) over USB, monitoring the communications using a very expensive Lecroy USB packet analyser. I struck me that packet analysers provide an excellent way of adding many more layers to your stack diagram, especially as this one could be operated over an Ethernet network, or remotely over USB using a DCOM based system.

The analyser worked on a store and dump basis, so you're going to add some pretty bad latency to the system (which is good), grabbing a few bytes at a time and then displaying them on screen.

For maximum wrongness, I think you should connect the computer running the packet analysis tool to something using Composite video out. Perhaps a really old black and white TV display. Which you could then photograph, and send the photograph via fax. And the data retrieved once you had OCR'd the fax of the photo of the screen would in fact be bytes of compressed audio which when converted back to PCM were in fact DTMF tones. Or maybe the output of a Commodore C64. Too much Commodore C64? Tough, I still love them. OK, maybe they are the bytes from a webcam pointed at another monitor. Or bytes from a USB flash drive having data written to it. Too run-of-the-mill? How about bytes of PostScript being sent to a USB printer? Bytes of data from a USB Infrared receiver? Bytes of data sent to a USB LCD?

Sometimes I get worried about how natural this all seems to me.

Friday, 11 June 2010


Using something like this you can move model locomotives around under software control.

If you had a series of optical detectors or perhaps good old fashioned reed switches, you could transmit ones and zeroes by positioning the locomotives. If you had long platforms and short trains you could have perhaps four (2 bits) detectors per platform. If you had locomotives with some kind of detectable unique marking on them and you had the ability to switch trains between platforms (now that would be fun to watch), you could send different values by arranging them. If you had four platforms and three trains there would be 24 combinations. I can't think of a setup that would be a nice power of two, but wouldn't it be more fun to transmit a non-integer number of bits with each arrangement? And think of the fun you'd have working out an algorithm to shuffle the locomotives around, towers-of-hanoi style.

Sunday, 6 June 2010

An itch you just can't scratch.

If you attach a webcam to the carriage of some electromechanical device (I have a Commodore MPS-1230 dot matrix printer) you could wind the carriage backwards and forwards and point the webcam at one of two images (say, a cross and a circle) which you could pick out with some simple image recognition. You'd just have alternately print lines of, say, 20 or 60 characters and let the carriage return at the end of every line using, you know, a carriage return.

The best thing about the MPS-1230 (and I admit, its benefits are few and far between) is it can be operated over the DIN serial port on the back of a Commodore C64. Which has a range of exciting input options, like a set of TTL GPIOs.

Bonus points if it's a Wifi webcam.

IP over Fatness

Something I've seen a little of lately, if you had some Bluetooth or internet-enabled weighing scales, you could exert a force on the scales to transmit a reading. You'd have to check and see what kind of accuracy you can get and how much force you can generate with Meccano. You could place one of two weights on the scales for 0/1, or if you could generate the force mechanically (and accurately enough) you might be able to get 4 or 5 bits per reading. A screw and a spring might work, as long as you can lift it clear of the scales so they can calibrate on power-up.

I like Bluetooth for this application because it adds lots of lovely layers to the stack diagram.

IP over Sonic sonics

I'm sure you could do something with a Sega Megadrive (I happen to have one of those, well an Amstrad Mega-PC, but close enough). If you could find a game where A and B made different noises, you could run the line-out cable to a PC and do a real-time FFT to work out which button was pressed.

Or, you could capture the video output and detect whether Sonic was facing left or right (0 or 1) with 'duck' as a clock pulse.

Wednesday, 12 May 2010

The Idea

I had an idea for a competition, much like a Great Egg race but a bit more technical in nature. I through I'd see if anyone fancied taking part or if it should be restricted to idle musings over the tea table.

The basic idea involves teams, a large room and some very very long tables. Each team has a table and at each end of the table is a RS-232 serial connection. One end has a button. When the button is pressed, a number of bytes are sent out of the serial cable. All of the bytes must be received, in order, by the other serial connection, within a specified time limit.

The most trivial solution is a really long cable. This will score you no points. The more insane the mechanism by which data gets from one end to the other, the better. The winner would be selected by a judge with some notional scoring method, e.g. extra points for every trip up and down the OSI stack.

Teams prepare in advance and bring their own tech on the day. I imagine the event would take most of a day.

Ideas so far include:
  • Operating a keyboard using Lego pneumatics to select checkboxes on a HTML form, the submission of which returns a QR code image which is printed and then read and decoded using a camera and a micro.
  • Using meccano to fire tennis balls into one of two buckets, indicating 1s and 0s - some ball return mechanism obviously required.
  • Creating a custom Quake map where each enemy has some notional 'bit' value and a bot program runs around shooting people in the correct order. A program sits in on the server log and keeps track of the score to generate the bit stream. If the bot involves a camera, some image recognition and a Bluetooth mouse emulator, so much the better.
  • Using an old Commodore 64 to convert between the joystick input (more lego?) and tones over the audio output. Or perhaps you could put a 3.5mm to tape adaptor in a Datasette.
  • All of the above.

Perhaps people could drop me a comment if they'd like to take part or have any suggestions (maybe it's been done before?) and we'll go from there.