So, anyway, it wasn't a dark and stormy night but a bright and sunny afternoon a few weeks ago when I ordered a USB charging cable for my cell phone. They're unreasonably expensive in Belgium but I found a great deal on DealExtreme. A Genuine© Immitation™ Nokia®-Like one even.

Today the cable arrived but when I plugged in my phone it refused to charge.
Linux complained too:

[959307.552135] hub 5-0:1.0: over-current change on port 2

Clearly something was wrong with the cable. Two minutes with a multimeter and a working cable for comparison showed that somehow the ground and +5V connections were inverted.
15 minutes with a soldering iron fixed that. All in all I got a great deal: a charging cable, half an hour of entertainment and that lovely feeling of having fixed something for less than a quarter of the price of a genuine Nokia cable.

Beware of geeks with soldering irons.

${Work} has decreed that passwords must be changed regularly and today it was my turn. Fine, despite the usual silliness in reducing the key space (by enforcing certain sets of characters to be present) and a ridiculous maximum length of 8 characters, I can deal with that. pwsafe generates and remembers the password for me. After a while I even manage to remember it myself.

Clearly that's not a good rant. This, however, is worth complaining about:

  dd if=/dev/urandom bs=1k count=10 | md5sum

]]> Tue, 13 Apr 2010 19:19 GMT Lies_Damned_Lies_and_ http://www.sigsegv.be/blog/Lies_Damned_Lies_and_.1024px The build system at work needed a bit of a cleanup. It's a fairly standard autoconf/automake deal which has been extended by people who don't understand those tools. This is understandable. There are after all very few people who truly do. I certainly don't.

Still, seeing HOST be confused with TARGET does indicate there's a problem.

While I don't know much about autotools I do know a thing or two about plain old make. I spent some time setting up a non-recursive build system, borrowing heavily from the Linux kernel build system bag of tricks.
After a little work I got the first few applications building with the new system. Before committing it I wanted some performance numbers. Sure, the new system is (at least in my opinion) much cleaner, simpler, and powerful, but a faster build is something every developer cares about.

Measuring build times can be a little tricky as they could vary significantly due to caching, other processes running on the system, ...
The mathematical tools to deal with this exist, but who wants to spend hours refreshing statistics courses? Fortunately there's a very simple tool to do exactly the kind of statistical calculations benchmarks call for: ministat. All you need to do is hand it two files with the results to compare.
It's a FreeBSD tool, getting it to work on Linux is a (trivial) exercise left for the reader.

Here's the output of 11 test runs of both the old (autotools, recursive make) and the new (plain make, non-recursive) system when running 6 jobs simultaneously.

x old-system.txt
+ new-system.txt
+------------------------------------------------------------------------------+
|+                                                                          x  |
|+                                                                          x  |
|+                                                                          x  |
|++                                                                         x  |
|++                                                                         x  |
|++                                                                         xx |
|++                                                                         xxx|
|A|                                                                         A| |
+------------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x  11        662.44        673.03        663.69     665.20545      3.224591
+  11        324.47        329.55        326.46     326.61364     1.8295151
Difference at 95.0% confidence
  -338.592 +/- 2.3318
  -50.9003% +/- 0.350539%
  (Student's t, pooled s = 2.62156)

The results surprised me a little: because there's so little variation in the results, but mostly because the build time with the new system is so much better. There's little variance in these results so simply comparing the first measurements would have told us the same thing. On the other hand, now we know.

I believe I'll have little trouble convincing my coworkers that the new system is better.

It's got 4 connections marked 'In', 4 marked 'out, two sets of TX/RX, two grounds and one marked 24V. There's also one marked 'K', no idea what that one does. On the inside I found a Morotola G18 GSM module, a Rabbit 2000 microprocessor and tucked away at the top a MAX-232 chip.

It looks like the device has two serial ports so I assume it's basically a serial modem. Getting it to work should be a simple matter of issuing the correct AT commands. Fortunately the Morotola module documentation is easy to find. After soldering together a DB-9 connector and hooking it up at 9600 baud, 8N1 it produces a prompt of sorts:

OK
    

Expected setting or rule
ERROR
    

Inserting a SIM card doesn't help, but it does complain about a bad PIN code. After a few more attempts I give up that approach and start looking for the PUK code to unlock my SIM again.

After some more negotiation with Google the Wayback machine turns up an old copy of the www.neoconnex.com website. It looks like the company disappeared soon after October 2005.
The manual on the website reveals the device can't be used as a modem but can send SMS based on its inputs, or set the outputs when it receives an SMS. These actions can be configured according to rules set through a program called 'Tele-M@te Commander'.
That explains the error message when entering AT commands.

The Wayback Machine doesn't have the program so I'm completely stuck. Copies of 'Tele-M@te Commander' or an ISP for a Rabbit 2000 micro controller can be exchanged for beer.

It still doesn't work, but I did find a bug in the PHY driver which got patched yesterday. I was slightly useful!

The guide was full of stories about people like Tommy Flowers, Harry Hinsley and John Tiltman. I was particularly impressed by the way William Tutte managed to work out the structure of the Lorenz cipher worked and how to attack it based on nothing more than cipher text and the encoding key. He didn't see a real Lorenz machine until the war was over.

The museum doesn't receive any government funding so it depends on gifts and the tickets visitors buy. You should go visit it.

The Cambridge museum of technology didn't disappoint either. It's housed in an old Victorian sewage pumping station. They have two huge steam engines to power the pumps as well as two gas engines and a number of smaller steam engines to run a generator, pull carts up the hill, ...

Best of all: these steam engines still run. I got to watch them work. This museum is also run by volunteers.

If anyone want to come along: I've got three empty spots in my car. I intend to leave early on the 22nd (there's a six o'clock in the morning now?) and return the next day.

While I'm discussing plans: I'm tempted to make a quick trip to the UK the following week. The Museum of Technology in Cambridge is starting its steam engines. While I'm in the neighbourhood I'd also visit another museum that's been on my list for a long time: Bletchley Park.

I left Chur a bit earlier than usual as I had a lot of distance to cover.

The plan was to ride through Davos and the Stelvio pass. Yes, the one you've seen on Top Gear. Unfortunately the GPS got a little confused around Davos and started to send me in circles. I passed through the same 5km tunnel 4 times.

Finally I gave up on the GPS and just followed the signs to the Fuella pass. This didn't quite lead me to Stelvio but it did turn out to be a shorter route to Austria (and then to Munchen).
It turns out I was really, really close to the Stelvio pass too. That should teach me to plan these trips a little better.

Riding though Austria was fairly uneventful though also quite beautiful.
Crossing the border into Germany there was again no customs station. There was a sign even though it wasn't really needed. The Austrian part of that road had no crash barrier, as soon as it became a German road there was a solid, concrete crash barrier. Sort of tells you everything doesn't it?

I'm in Munchen for two days. The plan is to visit the Deutsches museum. According to John Graham-Cumming and his Geek Atlas it's one of the largest and best science museums in the world. Even if it isn't it's bound to be worth a visit.