The USRP E100

I thought that I would take a moment to plug a product that I think has great potential for anyone working, experimenting, or interested in learning about digital wireless communication - the USRP E100. This device, jointly developed by Ettus Research and OpenSDR, was announced just a few months ago. It's a tightly-integrated embedded Linux solution for research into digital baseband signal processing for wireless systems.

I've worked with previous products from Ettus, like the USRP2, and have had 99% good experiences. The entire USRP product family is supported with GNURadio, which greatly facilitates signal visualization, processing, and software interfacing. The one down-side of using the USRP2 was that the only way to connect with it was by using a Gb ethernet cable (which is not a standard feature on laptop / desktop computers). The Gb ethernet port did not make the USRP2 'networkable' since it was only used for data transfer using raw ethernet packets.

The main differentiator of the E100 is that this device ships with a modular ARM board from GumStix. The stock GumStix board is powered by an OMAP3 (Cortex-A8) chip from Texas Instruments. The modular design makes repairs and upgrades easy (any COM can be used with conformant electrical and mechanical specifications). The OMAP3 has appeared in several mobile phones, but (more importantly) has also been the driving force behind a tidal wave of low-cost and powerful embedded Linux developer boards such as the BeagleBoard and BeagleBoard xM. Texas Instruments really has made a great contribution back to the developer community just by making these developer boards available. The OMAP3 processor is capable of running just about every operating system in existence, ranging from Windows Mobile to Ubuntu or Android (all flavours of Linux, and FreeBSD too). The E100 (probably) ships with Ångström by default. As for interfacing, the E100 even exposes HDMI, ethernet, and USB ports so this SDR box can literally be it's own work-station. I really wish this was available back when I was working on the USRP2!

So - that's great - an SDR device that eliminates the need for an external laptop or desktop computer so the entire system consumes much less power in total.

There's just one more thing...

The way that the OMAP3 interfaces with the radio hardware is super-efficient. The TX and RX buffers are mapped directly in to the OMAP3's MMU. To the layman, this means that the Linux kernel can easily expose the radio as a regular device to userspace using Phil Ballister's driver, which is on its way upstream. Furthermore, users of TI's Code Composer Studio (or developers who choose to use CGT directly) can write DSP firmware for OMAP3's integrated C64x+ DSP. Thus, keen developers can run code on the DSP to control the baseband radio and process baseband signals directly (the way nature intended). Naturally, only one processor on the chip can 'own' the radio buffers at one time (without proper synchronization).

To summarize: the USRP2 E100 is the ideal product for most engineers researching embedded RF systems and digital baseband processing.

PS: Nice work Phil! (he was my co-mentor for GSOC2010). I would love to use the E100 for some of my more recent work with ahumanright.org to engineer a low-cost / low-power satellite modem...

GSOC 2011: I Recommend Mono.SIMD

If anyone is looking for a good GSOC 2011 project, I would suggest Mono.SIMD. If you don't already know what SIMD is, then this project probably isn't for you, but you might find it interesting nonetheless. Although the Microsoft .NET version of C# does not explicitly support SIMD, once Mono has it for x86, ARM, and others, Microsoft likely will want it as well. The ARM port is just as important (if not more) important than the x86 port, so please don't ignore it. Buy a BeagleBoard or a PandaBoard to tackle NEON SIMD, (or even buy a Plug Computer or Verdex Pro for iwMMXt) . Although some people may think that iwMMXt is old news, it still lives on with Marvell's Sheeva and ARMADA product lines. You can still do blazingly fast multimedia with iwMMXt (h264, for example) but its limited to integer operations rather than floating-point (which is more efficient for multimedia in any case). 

Chances are you already have a PC with several flavours of SSE, so you should be all set to do add x86 SIMD and at least one flavour of ARM SIMD to the Mono JIT. Read this article to see why it makes sense.

PS: Good luck to all volunteering organizations and students this year!

Death, Taxes, & Voting

Considering that less than 50% of Canadians of the age of majority actually vote, why don't we make it mandatory to vote every time an individual files their taxes?

PS: I am intentionally leaving a lot of editorial commentary out of this post.

AMD Open-Sources Video API

This is quite a leap forward for free and open-source software users everywhere.

Nvidia ARMs Themselves for a Shot at the Desktop Market

X86 chip manufacturers should probably be a little bit worried at this point, considering that Microsoft has also decided to do a full windows port to ARM. Of course, Linux has been running beautifully on ARM for almost two decades already.

Don't be fooled, Nvidia's ARM team is not only aiming at the netbook / laptop market - they're setting their crosshairs on the desktop market as well, as indicated by their roadmap.



PS: If you are reading this, and you were present at a certain meeting with me not too long ago where we were talking about buying an ARM architecture license, then I hope you are hearing this message loud and clear. My honest opinion is that you need to act now or suffer tremendously in sales.

Ahem... Picasa?

Dear Google,

Don't you think it's about time to make functional Picasa clients for Linux and Android?

Currently, I am relying on a random 3rd-party app maker to upload video from my Google Nexus S to my Google / Picasa Web account - it's a little discomforting.

Also, video transcoding for Picasa Web albums is really straight forward to do using ffmpeg from the command-line, and it will even do VP8 :) ... but still, I can only upload videos from Picasa using Windows or Mac. If you're worried about software patents, then just use a plug-in architecture with dlopen(). That way, users can supply "their own" versions of popular multimedia encoders / decoders. For closed-source platforms, just write a plug-in that uses the codecs available on that system (e.g. windows, os x).

OMAP4-powered Blackberry Playbook runs QNX

Congrats for TI, RIM, and QNX on being a choice pick of CES.

Make

Having a modern (i.e. multi-core) workstation makes such an unbelievable difference. I can't even begin to describe how much my life has been made easier by "make -j9".

U-Boot on the TS7260

Click here for the original image

The Future of Android and the Chrome OS

Apparently I'm not the only one to have some innovating thoughts about Android and the Chrome OS. Slashdot has a story that mentions how the two should be merged in the near future. Furthermore, Paul Buchheit, the creator of Gmail, also seems to agree. I'm still a little bit hesitant to disclose all of the technical details publicly, but it would seem that Google is starting to take some steps in the right direction. My plan essentially boils down to taking the Android userspace back to the desktop and incorporating an Android App Screen, much like what Apple showcased at their Back to the Mac event, but also modifying apps so that they are literally write-once, run-anywhere - on any architecture. Incidentally, it would also enable users to run any of the tens of thousands of amazing open-source applications already available, and potentially tie in a revenue system for open-source projects via the Android app store.

Perhaps it was slightly selfish to come up with these ideas - I really just wanted to beautify Linux in both software and hardware, and make the user experience just as enjoyable as it is on a Mac (minus the annoying hard-coded settings). Could 2011 finally be the Year of the Linux Desktop?