Little 418

The resulting entity body MAY be short and stout

A faster way to copy your Raspberry Pi SD cards on OS X

The Raspberry Pi is awesome. One of the reasons that it’s awesome is because it’s so newbie friendly, and has great docs. For example, it has a great guide on creating an SD card image from OS X.

But, that guide does have one problem. The way they tell you to use the dd tool results in a very slow copy.

Default Instructions

Here’s what happened when I followed the instructions to install Raspbian on a cheap SD 16 GB SD card.

mimming@femputer:~$  sudo dd bs=1m if=2015-05-05-raspbian-wheezy.img of=/dev/disk2
Password: correcthorsebatterystaple

3125+0 records in
3125+0 records out
3276800000 bytes transferred in 2903.165983 secs (1128698 bytes/sec)

2903 seconds? That’s like 48 minutes. That’s almost an hour! But, but, but I want to be hacking sooner than that.

Targeting rdisk

Luckily there’s another way! OS X provides /dev/rdisk#. The r stands for raw and provides a more direct interface with the SD card. In this case, more direct = more faster.

mimming@femputer:~$ sudo dd bs=1m if=2015-05-05-raspbian-wheezy.img of=/dev/rdisk2
Password: correcthorsebatterystaple

3125+0 records in
3125+0 records out
3276800000 bytes transferred in 652.856126 secs (5019176 bytes/sec)

The same copy took just over 10 minutes. Not too shabby.

Bigger Chunks

Some Stack Overflow answers indicated that using bigger chunks might speed things up even more. I gave it a try.

mimming@femputer:~$  sudo dd bs=10m if=2015-05-05-raspbian-wheezy.img of=/dev/disk2
Password: correcthorsebatterystaple

312+1 records in
312+1 records out
3276800000 bytes transferred in 653.281030 secs (5015912 bytes/sec)

The result is almost exactly the same. It seems that block size does not matter too much.

A tip about dd progress

While dd is a neat tool, it’s hardly verbose. Sometimes it’s hard to tell if it’s working hard, or if the process is hung (which can happen if your computer goes to sleep).

You can query it for a status update by pressing CTRL + T.

Thanks to that goes to this superuser answer.

A Twiddler 3 review


The Twiddler 3 is the most flexible single-handed wireless input device that I have ever used. It has some rough edges, and it requires significant time investment to learn, but it’s worth it.

What’s a Twiddler 3?

It’s a handheld chorded keyboard. Instead of pressing down on a single key to make a letter, on a Twiddler you lift multiple keys to make a letter (or sequence of letters).

The Twiddler 3 works as a USB or Bluetooth keyboard. It’s targeted at use for mobile devices and wearables.

Unboxing and first moments

The box contains the Twiddler 3 keyboard, a velcro strap, and a MicroUSB cable. I didn’t take any photos, but there are already unboxing videos on YouTube.

After flipping that little switch to power it up, mine started looking for a device to pair with. I was mashing the keys and typing gibberish into my laptop within a minute of opening the box. The unboxing experience is great.

This is where the polish starts to end, and the mildly rough road begins.

Pairing with other stuff

The next thing I wanted to do was verify that the Twiddler could pair with all of my tiny computers. You know, the mobile phone kind. This was when I realized that the box didn’t contain any printed instructions. A quick web search turned up the official docs. They’re a bit disorganized and hard to read, but after a few minutes of clicking around I learned that I could clear the paired state with the special chord N+S R000.

It paired easily with my Moto X, 2013 Nexus 7, and iPhone 6+. It did not pair as easily with
Google Glass, but that’s a story for another day. (Literally another day: I’m drafting a follow up blog post about using the Twiddler 3 with Glass right now.)

Holding it correctly

This may seem like a no-brainer, but my instincts lead me astray here. Initially I grabbed it with my right hand and tightened the velcro band. The docs have detailed guidance about how to hold the Twiddler. The tl;dr: is to hold it with your non-dominant hand, and leave the velcro band pretty loose.

The recommended grip wasn’t very comfortable for me, so I swapped out the velcro for a strip of elastic and gripped it with my thumb.

how Jenny holds her Twiddler

Hacking Layouts

Twiddler Tuner

One of the coolest things about the Twiddler 3 is how configurable it is. The layout is easily programmable with the tuner web app.

Don’t be afraid to experiment with your layout right away. Your layout is a very personal choice. Lots of people like the default one, espiecally those who type with their left hand, but I found it difficult to learn and uncomfortable.

Try these popular layouts.

If none of those work for you, write your own. I did.

Actually using it to type stuff

Expect to invest a lot of time in being productive. Research indicates that you’ll probably get pretty fast, but expect to practice, a lot.

There’s a tutor web app. It works OK, but I gave up on it for a few reasons.

  • Your progress is only saved in a cookie, which is easily lost. You can export your progress, but oddly, you can’t import it.
  • It only supports the default layout.
  • It does not work on mobile.

Instead, I learned from lots of short practice sessions:

After a couple weeks, I got up to about 20 wpm.

Most important

I know what you’re really wondering, can it type emoji? Can I use a single chord to (╯°□°)╯︵ ┻━┻?

Well, no. The tuner does not approve of table flipping. It gets all scrambled when you save it.

(╯°□°)╯︵ ┻━┻

And it might be moot, because I’ve been told that the Twiddler itself may have trouble flipping tables… something to do with the HID spec. Anyway, if I figure out a way to hack around it, I’ll post a follow up.

In conclusion

Becoming awesome with it is hard, but it’s worth it.

Oh, and if you get lonely, drop by the Google+ Wearable Computing community. It seems to be the best place to talk about general purpose werable computing, and input devices like the Twiddler.

SaferRoads @ the AT&T Mobile Hackathon

I love hackathons. I like running them. I like volunteering at them. I also love hacking at them. There’s nothing quite like spending a weekend hacking out some code with new friends.

This past weekend I attended a hackathon hosted by AT&T at their office in Palo Alto. This was the third AT&T Palo Alto hackathon that I’ve attended. They’re great events.

  • They hit the sweet spot on size: 100 to 200 hackers
  • Great diversity in turn out: people of all experience levels and backgrounds.
  • I can always find a great, friendly pick up group.
  • The Foundry space has a great mix of small rooms, couches, and standing desks to work on.
  • The wifi works the whole time.
  • The organizers are a pleasure to hack with.

As a side note, despite attending three of their hackathons, I don’t really understand the AT&T developer program. Most of their APIs require a paid premium developer account, and they don’t have a feature set that that’s very hackable anyway. Yet, this mystery does not detract from their events.


Somehow I convinced a group of 6 awesome people that it was a good idea to work on the project at the top of my to do list: A way to tattle on Uber drivers illegally parking in my bike lane. We named it SaferRoads.

After a day of hacking with the Myo, the YouTube Data APIs, and Android, we got something working:

interface for next version

No, that’s not really it. That’s a mock of the UI that we didn’t have time to implement. The real app has an engineering interface that does not look nearly as nice. But, we achieved a lot.

  • It is indeed possible to write an Android app overnight, but only barely.
  • The YouTube Data APIs are kind of tricky to use from Android.
  • The Myo is really fussy, to the point of being useless beyond technical demos.
  • I registered my first alternative TLD domain name!

We also made a couple shameful achievements

  • We checked a hard-coded OAuth refresh token into a public GitHub Repo (yes, it’s already disabled)
  • We used an InVision mock as part of our demo

You can read more on the marketing website or see the shameful code on the GitHub repo.

Until next time, happy hacking everyone :)