Apple has helped usher in a feelgood wave of minimalism. The iPod Shuffle has one sliding, three-position switch (which is hard to use), one big button for the most important feature of the device—play. The four small buttons are for controlling volume (up and down) and track skip (forward and back).

OK.

Let’s play with the concept of minimalism.

I’ve recently spent some time lusting after PDAs. I wanted Bluetooth, first and foremost. However, that’s just play-factor; really, I want something that does two things:

  1. Beeps at me, and
  2. Syncs with my Mac.

That is all I want. Everything else is superfluous in a PDA. So, if that is all I want, I don’t need an interface on my device. It can be, in essence, a battery, some flash, and a small speaker.

Now, to be honest, that’s a bit bare. It does seem like a PDA should allow me to enter new appointments while I’m wandering around away from my Mac. However, I don’t want to care for another mini-computer—how simple can I make the interface?

I think you can build it into an iPod Shuffle.

Shuffle-Pda-Front-Ann

First, I need a way to enter information. However, I don’t want lots of buttons and useless interface elements. So, I’ll take a small microphone. If I’m going to enter information by way of voice, though, I need to be able to hear what I’ve entered. Therefore, I need a small speaker.

Shuffle-Pda-Back-Ann-1

(I’m not much with graphics manipulation; cut me some slack here.)

Now, operation. My iPod Shuffle PDA beeps at me. I slide the two position slider into PDA mode, and can now press Play to listen to the event that just fired. If I have headphones on, it plays through the headphones. Otherwise, it plays quietly through the speaker; I just hold the device up to my ear to listen.

Now, there’s two questions:

  1. How do you enter new events?
  2. How can I listen to events typed into the Mac?

Entering new events is easy; slip into PDA mode (slider), and hold Play (or something) to indicate you want to enter an event. I can imagine this going one of two ways: either you simply speak the event, and it gets recorded, or you speak the date, and then the event, and simple voice recognition is performed when you sync with the PC.

That is, if the first thing you speak is the date, then the corpus of words that must be recognized on the PC is very small. Therefore, you don’t need to “train” your PC on your voice. It should be able to handle “April Seventeenth, six PM” without training.

When I sync, the audio file is brought over, and attached to the correct date in iCal. I can listen to it if I want on the Mac, and possibly transcribe it. However, I’m not too fussed about this; as long as it gets the date, I can deal with the message myself.

Transferring events typed into iCal to the PDA is a piece of cake, fortunately. The Mac can easily render text into speech. Open up your Terminal, for example, and type:

Last login: Sat Apr  9 09:42:40 on ttyp1
Welcome to Darwin!
Lyra:~ mcj4$ say Hi there, everyone!

The ‘say’ command will speak things for you (there you go, Dad, now you know). The Apple can easily render entries in iCal into the spoken word, and sync those to the iPod Shuffle PDA. So, when my ‘Comped book meeting’ alert fires fifteen minutes before my meeting, it beeps at me (perhaps re-beeping every 5 minutes until I acknowledge it), and when I listen, Victoria kindly has her say—speaking whatever I typed into iCal.

Playing back the recordings is easy, because we already have MP3 playback hardware. Now, all we need to do is fit a small speaker and microphone. And, really, you could do away with the speaker, and simply require that we use our headphones to listen to the sound. Now, all the shuffle really needs is a microphone.

What else is the win? Look at this PDA:

Braillenote Pk

That’s the BraileNote PK. I don’t know how much it costs, but it cannot be cheap. Why? Because I don’t know of any cheap assistive devices for the blind. That, and that thing just looks expensive.

However, an iPod Shuffle PDA would be cheap, and is perfect for a blind user, as it has a minimum of interface elements, and lets them record events (while roaming) using their voice, and already have support technology on the computer. OS X 10.4 also has some excellent technologies for the blind built-in, which I think is a good step for Apple to take.

There you go. Steve, drop me a note if you like it. My first name at last name dot com will reach me. I’ll be done with my degree in a few months, and would love to see this come to be.

When I was developing the scripts that drive my research, I was not careful.

That is, I wrote them like throw-away scripts. Many of them are quick hacks, because I was busy exploring the data, not considering how I authored the code. From the start, I was telling myself “Someday I’ll come back and I’ll write these scripts correctly.”

That, of course, was foolish of me.

Here I am now, rewriting code I wrote over a year ago. Why? Because I didn’t even take the time to be clean and consistent in my treatment of all kinds of things. As a result, I have a half-dozen little support libraries haphazardly used throughout many, many scripts. If anyone were to ever do this kind of research again (which I might, even if noone else does), the tools that process the data would be completely useless to them.

Or, for that matter, to me. Last week, I wrestled with trying to reuse the existing code without modification—but it’s a mess. This weekend, I wrestled with a new library and ODBC on my Powerbook and Debian Linux, believing that I might get faster DB interactions that way. In the end, I’m back to my hand-hacked SchemeQL/spgsql library, that gives me a pure-Scheme solution for accessing Postgres.

After giving up on the new backend (which, really, would speed things up tremendously), I sat down, and in a few hours had a completely revised import script. This takes my raw data, and cleanly imports it into a new set of tables in a separate database. This way, my raw data sits in one DB, my clean data in a second, and when I’m done, I’ can export/import that second database easily for moving from machine to machine.

Robin, I still don’t think that code is like data. However, I do believe that it is possible to ignore everything you know is right and set off into the wilds without a care for how you’re going to get back. And that’s where I am now, retracting footsteps and making good on where I’ve been.

When you have a huge bumblebee in your apartment, do not reach for your squash racquet. While you may avoid breaking anything, it will rend the bumblebee into roughly three pieces.

For the last two years, I’ve been doing database work from Scheme using a hybrid set of libraries for PLT Scheme.

I used SchemeQL for my front-end; it’s an excellent set of macros and structures that make it easy to get complex SQL statements right.

Then, I hacked out the existing back-end, and used spgsql as a back-end instead. (Interestingly, when looking for this driver, I found a post of mine on the PLT Scheme list about this very topic. For those interested, the answer is “It’s very doable.”).

Unfortunately, there were several problems about this approach. First, it doesn’t evolve with shifting PLT versions very well (the jump to v300 breaks some things–in the code I hacked, unfortunately). Second, it’s slow: the pure-Scheme driver isn’t so great when it comes to handling many tens of thousands of elements. And, lastly, I didn’t know much about SQL then, and my scripts are ugly… that that has nothing to do with the libraries.

Enter Scheme-PG. These bindings to the Postgres C libraries for PLT Scheme v299/300 are nice. I don’t know about the query mechanism (perhaps I’ll look at hacking this into SchemeQL?), but it sure is quick. And, while it takes time, I might rework the scripts I use for data analysis for my research using this new library. The side effects will be that they’ll run much quicker, and they’ll be much better crafted, having written them once and now understanding the questions and technologies better.

But, you didn’t really care, and I really want to go to bed.

I’ve managed to get Postgres reinstalled on LEGO, despite the efforts of apt-get to bugger everything on the machine to high heaven. Tomorrow, hopefully, I’ll get some productive work migrating databases from my Powerbook to the desktop, and perhaps get some analysis work done.

Or, perhaps I’ll just give up, and continue doing everything on the Powerbook. Although, I’d rather use a machine that’s faster and doesn’t travel so much, so I can let some long-running analyses go overnight.

We’ll see.

I’m about to order the Gumstix for our CSCS work, and I can’t help but wonder if there are other/better small platforms for our project. It’s hard to say: I can’t find a lot on the net about their use, and the Gumstix Wiki is a nightmare to navigate.

That said, it’s clearly an impressive piece of kit. At the end of the day, I guess you just have to toss in your cash and see what happens.

  • Crossbow MICA2
    The MICA2 is a nifty little mote, with great battery, I2C, and wireless communication. Something to look at for the future, I think.
  • Botrics Cerebellum
    The Cerebellum is from the makers of the CMUCam, and is a PIC16-based board. While it has more I/O, it only has 8K of space for code, and is a 14-bit machine. A C-compiler would probably come with a cost as well. That said, it’s also something to look at for the future.
  • CotsBots
    These little bots are all off-the-shelf and under $200. The project merits more investigation and consideration. We did OK in our own exploration of the cheap-and-quick space, but not cheap-and-quick enough, really. Then again, any small robotics platform is probably going to have it’s ups-and-downs. The CotsBots, however, look cool, and are based on the Crossbow line above.
  • Millibots
    This project at CMU looks interesting as well. What cracks me up about them, though, is that they’re like a dump of the Acroname catalog onto a bunch of tiny robot platforms… :)

That said, I think we need:

  1. A Gumstix Connex 200MHz. This is a 200MHz Intel XScale board with 64MB of RAM and 4MB of flash. ($110)
  2. A Waysmall STUART board, that gives me two serial ports ($20)
  3. A cfstix board, that provides a compact flash adapter for the Gumstix; this way, we can use our WiFi or CF cards (that we bought for the PDAs) with the Gumstix. At least, I hope our cards work with the cfstix. ($25)
  4. Two 3′ DB9 to PS2 null modem cables, because we don’t want to futz with moving one cable back-and-forth from a bot to a PC. ($24)

And, niftily enough, I was able to order with PayPal! Which makes it really easy to bury the cost in the UK (£103) instead of in the US ($190). Ah, sometimes a horrible exchange rate is a good thing. But, not usually.

We’ll see how things go. No doubt, we’ll get the Transterpreter up and running on it, and hopefully get the Brainstem slaved to this device.

On the flip side, I’ve discovered that instead of looking at new Palm handhelds, I could look at used handhelds and Bluetooth adapters. In particular, I just ordered a bluetooth adapter for the Palm Vx for 6 GBP. I’ll test it out on someone else’s Palm, and see if it solves my problems.

It’s worth £6 to experiment.