Posted by & filed under Reviews.

All of the links in this post goes to the relevant Amazon product, in case you want to purchase the same hardware.

Here’s some pictures of my Raspberry Pi enclosure. It is basically a hard drive enclosure which I drilled and filed down. You can get a similar enclosure from Amazon, however that version doesn’t have all of the holes like mine does (which might make it a little harder to drill out).

In the first picture, you can see where I added the WiFi antenna. Basically, I made sure the USB wireless card was flush against the bottom of the enclosure, figured out where the antenna aligned, and drilled it out with a bit slightly larger than the threading. It made for a pretty solid hold.

In the remaining pictures, you can see how I made room for the SHDC card, as well as the USB port for charging the device. Beneath the Raspberry Pi, there is a sheet of acrylic plastic I cutout so that the board wouldn’t short out with the aluminum enclosure. I kinda half assed it so far; it is simply held down with electrical tape. I also put another, smaller, piece of acrylic on the end farthest away form the SD card, so that the board would sit flat (that SD slot is about the same thickness as the acrylic).

Unfortunately, the Raspberry Pi doesn’t have any screw holes, so I can’t securely mount the board. For now it is floating around, and as soon as the USB cord is removed the device starts to bounce around the enclosure. I’m probably going to throw some double sided tape in there to hold it down.

I have two USB male/female cords, and an unpowered USB hub. I’m not sure which combo I’ll end up using quite yet. You can see a USB Bluetooth dongle in the pictures, but it needs to be on the outside of the case for it to function properly. This could be easily done by putting the female end of the cord flush against one of the enclosure holes and plugging it in from the outside. If I end up adding additional devices (like a USB GPS device) I’ll definitely need to use the hub.

Posted by & filed under Reviews.

This is a review of the FM Transmitter (CZH-05B) which I recently purchased from amazon. It had been on the site for about $100 for a while, but a few days ago it dropped to around $60 bucks, so I jumped on it. The device is capable of transmitting at either 0.1 Watts, or 0.5 Watts, where the latter apparently has a range of one mile (I haven’t tested this yet though).

The device itself is pretty fragile. If you plug in a mono-microphone into the mic jack, it will break your device. If you turn it on without an antenna, it will break your device. The antenna on the back does not stay upright, it will fall over on its own. The print on the device looks quite cheap; it’s easy to tell this came from some factory in china.

These setbacks aside, the device seems to run pretty good. The sound quality sounded quite nice.

There are two modes, which are toggled using the power button. The station select mode lets you set a station, and shows an icon of a speaker with a slash through it. During this time the transmitter is not transmitting. Once you set it to transmit mode, you can no longer select a station, but your audio is being transmitted. This is so that you aren’t scrolling through all the stations and destroying all of the signals.

This device lets you transmit on the non standard FM stations (e.g. stations ending in an even decimal number). Some modern radios allow you to pickup these semi-hidden stations. I believe the stations were done like this because signals would bleed out to the neighboring stations, e.g. 100.2 would pick up 100.1 and 100.3.

Warning: Make sure you check with local laws. Depending on how you use it, this thing could be illegal. Make sure you are not broadcasting over top of other stations. If anyone ever complains, stop using the device immediately. Basically; don’t be a dick.

Posted by & filed under Uncategorized.

The Raspberry Pi Arch Linux image runs sshd by default. Assuming you have it plugged into your network with the ethernet jack, you can SSH into it by running (on a remote machine):

$ ssh root@
The authenticity of host ' (' can't be established.
RSA key fingerprint is aa:bb:cc:2d:f3:d7:11:6b:fd:cc:22:72:b2:ac:ee:dd.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
root@'s password: root

[root@alarmpi ~]# cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 0002
Serial : 0000000000000001

That is, if you’re lucky enough that your router reports to you the IP address of the devices on your network. If you aren’t lucky (like me), you’ll need to attach a monitor to your pi, log in with the root:root credentials, and run ifconfig to figure out what the IP address is.

With my particular setup, the HDMI doesn’t seem to want to work properly, so I have to use the RCA jack for now. Luckily me I don’t plan on using a display with it so it’s not the end of the world.

Raspberry Pi Running (and hating my HDMI)

Posted by & filed under Linux.

So… You got Arch Linux installed on your Raspberry Pi. And, you want to update all of the packages so that you can start installing stuff. Well, not so fast. Arch Linux has this little “feature”, where you can’t really install packages without generating a key.

Generate Pacman Key

To generate a key, folks will tell you that it is as easy as running:

pacman-key --init

And those folks are total liars. When running that command, you will get the output, “Generating pacman keychain master key…”, and it will just sit there doing nothing. Forever. In actuality, you are supposed to open another virtual console (Alt + F3 or Alt + F4), and do a bunch of random shit that causes drive reads and writes.

Perhaps, to do those writes, you would run a command such as:

ls -R /

But, that isn’t nearly enough stuff on the tiny Raspberry Pi Arch image to generate enough IO. Still others will tell you to run:


But, of course, that command does not exist on a newly installed system. To get that command available and then run it, you need to actually run:

pacman -S mlocate

Once you’ve done that and made a lot of hard drive writes, you can switch back to the key init app by hitting Alt+F1. But, you’ll notice that it STILL isn’t done. At this point, get angry, go back to your terminals, and mash your keyboard with the recursive ls and the updatedb commands, and run the top command in another terminal. After several minutes of frustration and anger, your pacman-key –init command will finally be done.

Update Pacman

Now, you need to update the package manager itself. Run the command:

pacman -S pacman

And you should have the latest version.


Now, try running

pacman -Syyuf

Replace libusb with core/libusbx? Y
… procps? Y
… udev? Y
Proceed? Y

By the time it is done (about 15 minutes of installing), you’ll have all sorts of new packages on your system. Most importantly, you’ll have the latest firmware.

The udev, libusb, procps stuff is kinda goofy because Arch recently made a big change to their system, and since it’s a rolling release, those three packages seem to complain a little about being replaced.

Posted by & filed under Linux.

We all know the humble ping command. Check out its nice, human-readable output:

$ ping -c 4
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=63 time=26.6 ms
64 bytes from ( icmp_req=2 ttl=63 time=27.4 ms
64 bytes from ( icmp_req=3 ttl=63 time=25.7 ms
64 bytes from ( icmp_req=4 ttl=63 time=26.8 ms

--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 25.723/26.686/27.481/0.641 ms

Now, imagine you want to parse this data so that your application can read it. Here’s a regular expression I nabbed from a Stack Overflow answer which grabs information about the individual ping responses:

^(?<Size>\d+) bytes from (?<DestinationHost>[^\s]+)
 \((?<DestinationIP>.+?)\): icmp_seq=(?<ICMPSequence>\d+)
 ttl=(?<TTL>\d+) time=(?<Time>.+)$

On the surface it seems like a perfectly acceptable solution. Until, that is, the maintainer of the app changes the formatting/wording of the output. Not to mention the slight overhead of running a regex, or even the effort it takes for the app to take this output, make it pretty for a human, just to have us convert it back into a format for machine consumption. But really, the biggest overhead IMO is the time it takes to build a script, regex, or grep command to parse such output.

JSON Output

Now, imagine a world where a large subset of Linux command line utilities have a magical –json (or –xml, –yaml) option, which takes that normally human-readable output displayed via stdout and instead renders it as the specified data transmission language. Here’s an example of our previous ping command converted to JSON:

$ ping -c 4 --json
    "target": "",
    "target_ip": "",
    "bytes_of_data": 56,
    "statistics": {
        "packets": 4,
        "received": 4,
        "packet_loss": 0.0,
        "time": 3006,
        "min": 25.723,
        "avg": 26.686,
        "max": 27.481,
        "mdev": 0.641
    "transmissions": [
            "size": 64,
            "hostname": "",
            "address": "",
            "icmp_req": 1,
            "ttl": 63,
            "time": 26.2
            "size": 64,
            "hostname": "",
            "address": "",
            "icmp_req": 2,
            "ttl": 63,
            "time": 27.4
            "size": 64,
            "hostname": "",
            "address": "",
            "icmp_req": 3,
            "ttl": 63,
            "time": 25.7
            "size": 64,
            "hostname": "",
            "address": "",
            "icmp_req": 4,
            "ttl": 63,
            "time": 26.8

Suddenly, we have an amazingly simple output format for parsing! Simply fire up your language of choice’s JSON library and parse that output. We could even possibly take the contents of stderr and display it in the same output, but in an error node.


I’m not sure of a good solution for handling ‘streaming’ output, e.g. a ping command without the -c option. Perhaps we could actually display several complete JSON documents, maybe requiring a delimiter of some sort , but at this point we are no longer dealing with pure clean JSON and are instead starting to develop a JSON superset.

This also wouldn’t make a lot of sense to be used with interactive commands, or really anything that needs a Ctrl+C when complete. So, for this reason, it would probably mean that –json is limited to being used in conjunction with other arguments, and that it cannot be used with all CLI apps.

Arguments Against

What if the author of the app changes the structure of the JSON document? The applications digesting the output of the app would still need to be re-written, but grabbing a different data node is usually easier than getting familiar with the new output and writing a different parser.

Why use JSON? Well, JSON is a pretty commonly used data format (at least on the web, it isn’t too popular among Linux utilities). Importantly, JSON can be easily converted into different formats such as XML or YAML. One could write a utility and pipe the output through it, such as “ping -c 4 –json | json2xml”. Or, even better, the author of the app could provide switches for the different types of data.

What about the Linux philosophy of having simple, human readable output? We would still keep the default, human readable output. The –json flag would simply be an option that the maintainer of the app would add as an enhancement.

My app already has a –json switch for doing something else. The –json flag is just an example, really. There doesn’t need to be a universal switch for enabling this output (although it would be nice). The overall goal of these switches would be to make parsing of the output of the command built into the actual app instead of being external.


Of course, I wasn’t inspired by the ping command to write this (with its simple output), but instead the output of the command iwlist wlan0 scan. I’ve been writing a parser using node.js, and the code is a bit scary looking (as I feel most parsers must be). Here’s an example of the output being parsed (the Cell’s repeat once for each network):

wlan0     Scan completed :
          Cell 01 - Address: 40:F4:EC:7F:A1:52
                    Frequency:2.462 GHz (Channel 11)
                    Quality=70/70  Signal level=-31 dBm
                    Encryption key:on
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
                    Extra: Last beacon: 13986ms ago
                    IE: Unknown: 000C43544C5F576972656C657373
                    IE: Unknown: 2D1A2C181BFFFF000000000000000000000000000000000000000000
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 3D160B000700000000000000000000000000000000000000
                    IE: Unknown: 9606004096001400
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : TKIP CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: DD180050F2020101800003A4000027A4000042435E0062322F00
                    IE: Unknown: DD1D0040960C032A6F6EFA818036010000130604000000FDB8F23A2A1


Thanks for giving this a read! If you know of any possible solutions to the ‘streaming’ output, if you can think of a better output format, if you know of a similar initiative, or even if you think I’m an idiot, please let me know in the comments below.


Thanks for all of the great feedback on Reddit (and even a little bit on Hacker News). It is interesting to see how much of a controversial subject this is. One one side, there are the *nix purists who have been writing programs for years, and have always understood the plain-text Unix philosophy. On the other hand, there are the (probably younger) half who love the thought of being able to easily read the output of commands without the need for complex parsing instructions.

I think the biggest issue is the purists hating the thought of JSON; the new-comer / web-centric data format I mentioned in the title and ping output example. Again, that was just an example language. Most of us just want a standardized method for parsing command output, and surprisingly, we really don’t care what that format is, as long as it is easy to work with.

The best example someone had of this type of thing already being in the wild is the emacs formatted output for the ls command, as pointed out by ISV_Damocles on Reddit. If there is an output format for the most commonly used Unix command just to be consumed by one program, why not have a standardized output option easily digested by any program?