Peterism

Note:  I don’t have time to complete this posting right now, so it’s in a draft format.  I just wanted to briefly document my findings before I forget.  Back to studying for the Patent Bar…

I finally pony up the Benjamins and got myself an Android handset, wait for it – the Sprint HTC EVO 4G!

You may not share my enthusiasm, but finally ditching my HTC Mogul (running WinMo 6.1) and moving into an even more open platform opens up a lot of possibilities for me.  I’ve always been more comfortable developing on the *nix realm, and although I don’t have anything against the iPhone, Apple’s tight control on the iPhone OS just doesn’t sound that appealing to me.  At this point in the mobile platform ecosystem, iPhone enjoys a  almost 4-to-1 margin in the number of developers probably due to its two year head start in reaching the mainstream market, but the fact that Google opens up the entire Android platform, allowing me to develop apps that interface the hardware in a low-level way is much more appealing.  I hope for a day when the mobile platform mimics the general purpose computers that makes it possible to run almost any OS on the same hardware.

A bunch of people have been having problem building a true phone recorder on the Android.   Almost all smartphones these days come with an application processor (AP) and a baseband processor (BP).  The BP is responsible for handling the radio, and voice encoding -decoding, among other related tasks.  While the AP is used to run the OS and applications.  The fact that despite having an API that supports recording voice call (both uplink and downlink), none have been able to successfully implement the feature suggests to me that there’s more than meet the eye.  Upon further digging through the Android platform source and documentation, I found an interesting project within the platform that seems to be responsible for implementing what I want…, the Radio Interface Layer (RIL).

More to come…

German researcher Karsten Nohl has cracked the encryption used for GSM.  His team has made information and tools needed to replicate the attack with a somewhat modest set up.    The A5/1′s 64-bit encryption key used in GSM is simply too short for the kind of computing power widely available today.  Considering that the technology is over 20 years old, however, it’s robustness is still remarkable.

Here’s the A5/1 Cracking Project’s website.

An interesting report by CNET News.  How do you define evil?  I suppose one way to not do evil is to write the code so that it consumes less resources, either in terms of CPU cycles or memory (or both if you can!), thus reducing the power dissipated in millions or billions of CMOS Flip-Flops.  Just think about the implications of wasted charges/discharges and unnecessarily-spent batteries.  Wait, maybe I’m getting off topic…

So I’ve been wanting to get my hands dirty at cooking up an Android app, and have had dreamed up a few ideas. Some of these ideas have since been implemented by others (barcode scanner with camera that searches for products and prices online, music “recognizer” like Shazam, etc). The latest idea that I have is a mobile app that records live phone conversation on demand.

Quick searches for existing solutions suggest that there are no apps of this kind for the Andoird and the iPhone, but a few good candidates may be available for the Symbian as well as for Windows Mobile.  I’m not certain about the WebOS that newer Palm devices run on.
The idea seems simple enough, but the actual implementation seems to have been curbed by limitations of the baseband processor in most smartphones.  From what I have gathered, most smartphones incorporates two major processors.  One of them is the “general purpose” processor, or that application processor that runs the OS and applications.  The other is a “special purpose” DSP  or sometimes referred to as the baseband processor that handles real-time voice encoding and decoding.   While it’s fairly straight-forward to record and encode local voice using the application processor, capturing the output of the baseband processor, or the remote voice, seems to have caused issues with most developers.

In my quest to write a conversation recorder app for the Android, I came across this class:
[java]MediaRecorder.AudioSource[/java]
One of the values available is:
[java]public static final int VOICE_CALL[/java]
Voice call uplink + downlink audio source
Constant Value: 4 (0×00000004)

This is available since API Level 4, which corresponds to Android 1.6.  It then appears deceptively simple to just set
[java]MediaRecorder.AudioSource = VOICE_CALL;[/java]
to record both the uplink (local) and downlink (remote) audio feeds.  I don’t actually have an Android phone to test on, but if you do, and have the means to load your code onto your Android phone, please let me know if you get 2-way voice recording going.  As I’ve said, it may depend on the capabilities of the baseband processor you have.

I’m eyeing on the HTC Passion/Google Nexus One, which is rumored to be based on Qualcomm’s Snapdragon QSD8x50.  The QSD8650 is especially interesting, with some reports having said that it may be clocked at 1.3GHz, with the capabilities to run on both the CDMA and GSM families of 3G data networks, making it a powerful world phone.  Detailed specs are especially hard to find, but I’m hoping the baseband processor inQSD8x50 will expose the downlink audio to the application processor, by perhaps providing some sort of DMA to the cache that the baseband processor uses.

I’ll report my findings as more details are available in the coming days, I hope, as the Passion/Nexus One is supposed to be coming out in as early as January 2010!

This course will introduce basic concepts needed to understand, design, and implement wireless distributed embedded systems. Topics include: a) design implications of energy, and otherwise resource-constrained nodes; b) network self-configuration and adaptation; c) data routing and transport; c) applications; and e) software design issues. The course will be heavily project based. Working knowledge of C programming in the UNIX environment (particularly GNU/Linux) is assumed.

The Department of Defense CIO office has released a new guideline which is aimed at easing open source software adoption.

Department of Defense CIO David Wennergren’s revised guidance (PDF)