Peterism

“The companies revealed the details Monday at Mobile World Congress in Barcelona. Their system-on-a-chip platform is based on ARM’s Cortex-A9 processor and Globalfoundries’ 28-nanometer manufacturing process. The platform will be used in smartphones, tablets, and smartbooks.”

Full story at News.com.

So it looks like we will have devices that consume less power purely on a per-clock-cycle basis.  I’m guessing the new process won’t trickle down to actual commercial mobile implementation until at least 2013. 

From CNET:

In a speech Wednesday, Microsoft general counsel and senior vice president Brad Smith called on government and business to shore up confidence in cloud computing by tackling issues of privacy and security–two major concerns that have been voiced about the cloud.

Full article.

So Google finally announced its 3G phone for HSPDA back on Jan 5, 2010. Unfortunately, for those of us in the US, the GSM camp does not have a wide enough of 3G data coverage that folks over in Asia and Europe enjoy. I was pretty excited when Google said they would release a version of Nexus One that works on the Verizon network in the Spring of 2010. After all, my contract with Sprint doesn’t expire until May.

Since the GSM Nexus One packs the Qualcomm Snapdragon QSD8250, which according to Qualcomm’s specs only works on the GSM network, I am guessing that the CDMA version would be screaming with Qualcomm’s QSD8650.  According to specs from Qualcomm, the QSD8650 is compatible with both GSM/HSDPA and CDMA/EV-DO, making it a true 3G worldphone (unless you still need iDEN, which I think only Japan and Korea might still be deploying, and Sprint is phasing it out after acquiring it from Nextel).  This would be a very nice phone unlocked, allowing a world traveler to utilize local networks at cheaper rates.

According to a press release from Qualcomm in summer 2009 (will dig up the press release later…), they have managed to clocked QSD8650 at 1.3 GHz, a third faster than QSD8250’s 1GHz.  Since both chipsets are fabricated using the 45nm process, power-saving from lower voltage should be out of the question.  It would be interesting to see how, if at all, Qualcomm can still manage to maintain a comparable running time without sticking a bigger and heavier battery on the back of the phone.

In a way, I am glad that my contract with Sprint isn’t up yet, so I don’t have to rely purely on my (limited) restraint to compulsively buy a GSM-only Nexus One now.

The Italian Supreme Court has issued a decision in a criminal proceeding against www.thepiratebay.org, a P2P website because of the breach of copyright laws through the making available to the public of copyright protected works…

Full story.

December 14, 2009 – At this year’s International Electron Devices Meeting (IEDM), IMEC and partners TNO (a Netherlands-based research group) and the Holst Center (IMEC-TNO joint center set up in 2005), disclosed their latest work in creating a MEMS-based piezoelectric energy harvesting device with record power generation, and a “world-first” organic transponder circuit with bit rate of 50kbits/s, nearing requirements for Electronic Product Coding (EPC) standards.

Full article.

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.

A report from The Register said that hours of unencrypted surveillance video feeds were intercepted by the Iraqi insurgents.  A laptop containing the video feeds were discovered late 2008, but it’s not clear from the report when those feeds were intercepted.

Why were those video feeds unencrypted?  Granted even the strongest encryption scheme to date isn’t unbreakable, given enough technical know-how, processing power, and time.  My guess is that the contractor or subcontractor supplying the camera or the transceiver forgot to turn encryption on, and no one caught the fatal error.

Here’s the full story.

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:

MediaRecorder.AudioSource

One of the values available is:

public static final int VOICE_CALL

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

MediaRecorder.AudioSource = VOICE_CALL;

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 QSD8×50.  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 inQSD8×50 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 is a post forwarded to me by a fellow Linkedin user:

“To those prospective law students applying to law school as a fallback in a bad economy, or because you want three more years to figure out what to do with your life: please save yourself time, money, and a huge amount of stress…” Aaron Street.