Getting your location using iPhone with no GPS

One of the main big features in iPhone 3G that was not shipped with its ancestor iPhone 2G is GPS support. You can determine your location using GPS satellites.
It is known that although very accurate, GPS has some drawbacks. It needs a lot of time to connect to the satellites, in the order of tens of seconds. It won't work indoors as well. Moreover, it is banned in Egypt, Syria and North Korea!
Update: It is not banned anymore in Egypt.

So can one determine his location without the aid of GPS technology? The answer is Yes. This can be done by identifying nearby GSM cell towers and query a database that stores their location. So lets divide the rest of this post into 2 parts:


Identifying nearby GSM cell towers

Doing this on the iPhone was a bit tricky. Actually it was a challenge for us at eSpace to get such information. I will list here the challenges we met and how we managed to solve them:

1. There is no official SDK for iPhone OS 1.x. This was the easiest challenge to solve. Everybody uses iphone-dev for building the iPhone toolchain. Most of the header files in the toolchain are generated by class-dump! This is a tool that takes a binary framework (library) as an input and emits some Objective-C code in a header file that represents symbols in the library. Its idea is as simple as using nm to query symbol names and some extra code to wrap this info in Objective-C syntax.
   
2. Even in the non-official toolchain, there is not a word on how to deal with telephony features like calls and text messaging. Thanks to CellStumbler, we used it to get cell information. It is a tool that exploits CoreTelephony framework functionality. CoreTelephony.h is also generated with class-dump.
3. CellStumbler is very fragile, if you do simple edits in it, it may crash! The guys say it is toolchain bugs! Just keep this in mind if you need to modify it. Be aware that server connection callback never get called, so keep on retrieving cell information until you get something useful.
4. Because CellStumbler is that fragile, we left the code untouched in its major parts, we just changed the part that outputs results. We then called the binary from a shell and parsed its output to get useful nearby cell information.
   

Querying a database for cell location

Google used to have a secret API for this. It is called My Location. This is the API it uses in Maps. Unfortunately, at the time of our development, the API was secret, we had to sniff upon packets to/from Google Maps to know what happens under the hood and replays it. Now this API is open to developers, thanks Google.


Read more...

Fortunately, another reason why I use Ubuntu

Since I installed Ubuntu 9.04 on my work machine (and replaced Micro$oft Outlook with Evolution), I always wondered why my download speed became surprisingly a lot faster! My surprises approached a relief today when I came across a local speed test service. I tested the speed on Windows (with no firewalls or anything coming in the middle) and Ubuntu.

The result was Ubuntu achieving DOUBLE speed than Windows! Yes you read it right, DOUBLE speed on the same machine!
I will leave you with the screenshots to witness it yourself.

Windows download speed:


Ubu download speed:

The only explanation I can tell is that the TCP/IP stack default parameters on Windows are not optimally configured, while the defaults in Linux are!
Any other suggestions?


Read more...

Dr Mohamed Slim Alouini farewell at TAMUQ

Today we gathered for the farewell of Dr Alouini at TAMUQ. It has only been one week since I am here at TAMUQ, but Dr Alouini did have an effect on my career! Last October when I came here for an interview, Dr Slim (and Dr Shehab Ahmed) urged me to finish my Masters so that they can apply for my VISA.

After I came back to Egypt, I took an unpaid vacation from my work at eSpace and started the campus of studying! Thanks to Allah, I got the Masters certificate last February. I was always remembering Dr Alouini's words about pushing my career onwards and finishing the Masters as quickly as possible.



From right: Hossam Hammady (me), Dr Wessam Mesbah, Dr Alouini, Dr Ahmed Masoud, Majid Farouqi.

So although we didn't meet much, but thanks Dr. Alouini for pushing me onwards.


Read more...

My new job at Texas A&M University at Qatar

It has been so long since I posted anything here. I am always lazy writing blogs :( Today I thought I should write something. From now on, my blogs should be short so that I don't get lazy writing them!

So, I am writing this to let you know that I have joined Texas A&M University at Qatar as a Teaching Associate. The hiring process took too long since I had to finish my Masters first before I apply for the VISA. Thanks Allah, I finished my Masters last February, but this is another story, I will write about it soon insha2Allah :)

I am now in Doha with my little family, my wife and my little 1-year-old kid, Abdullah. My job here includes both teaching tasks and support in IT-related issues for the faculty.

A lot of paper work to do here to finish my residency permit and settle in my new house. I didn't take any task yet, just all about orientation and settlement. I hope work would be fun here as I have always enjoyed my job :)


Read more...

MCabber: a command-line-only multi-protocol IM client

Command-line geeks, its time to stay focused on your terminals and not switch to X back-and-forth when chatting with your buddies.

mcabber is a small Jabber console client.
mcabber includes features such as SSL support, MUC (Multi-User Chat) support, history logging, command completion, OpenPGP encryption, OTR (Off-the-Record Messaging) support and external action triggers.

As you can see MCabber is just a Jabber client. So you can not use it to connect to your favorite IM servers like MSN, Yahoo!, GTalk,...



However, you can use it to connect to these networks with little effort. All you have to do is to install OpenFire (or any Jabber server software) and enable the GatewayIM plugin. From its name, this plugin enables you to connect to other IM networks. Just create an account on your Jabber server through its nice web interface and configure it with other networks login information. Next, let MCabber connect to your server and do everything you love.




To install MCabber on Debian/Ubuntu just type:

sudo apt-get install mcabber


Before you connect with the server, you have to configure MCabber first. The only mandatory configuration is server address, port, username (jid format: username@servername, you can know the servername from OpenFire admin console) and password. You can start with the example configuration file by copying it to your home directory:

cd $HOME
mkdir -p .mcabber/histo
zcat /usr/share/doc/mcabber/examples/mcabberrc.example.gz > .mcabber/mcabberrc

So far, I have been talking about everything old! Anything cool here?

A great functionality of MCabber is that you can write an external script in any language and let it handle IM events like message received, buddy logged in, ...
I have wrote a bash script which plays some nice sounds (got them from Pidgin) on some events, so that you don't have to poll mcabber "window" to watch for new messages! You can download the script from here.

Update: The script now "says" the jid of the buddy logging in/out! However, you need to install festival before you can use this feaute:


sudo apt-get install festival


Don't forget to turn on execution bit or it won't be able to run.

chmod u+x $HOME/.mcabber/event-handler.sh


Don't also forget to edit mcabberrc to tell it to use that script for handling events

set events_command = /your/home/directory/.mcabber/event-handler.sh




Read more...

Building a no-X version of HTK on Linux

The Hidden Markov Model Toolkit (HTK) is a portable toolkit for building and manipulating hidden Markov models. HTK is primarily used for speech recognition research although it has been used for numerous other applications including research into speech synthesis, character recognition and DNA sequencing. HTK is in use at hundreds of sites worldwide.

Quoted from the HTK website.

HTK is a free/open-source piece of software. It builds on Linux, Solaris, IRIX, HPUX, Mac OS/X, Windows NT, 2000, XP and FreeBSD.

The problem:
If you tried to build HTK on a command-line-only Linux machine (no X installed), it will give build errors. You may face this situation if you need to run your experiments on a hosted solution that has no GUI to exploit its CPU/memory power. The problem happens because there is a single tool that requires graphical user interface: HSLab.

HSLab is an interactive label editor for manipulating speech label files. An example of using HSLab would be to load a sampled waveform file, determine the boundaries of the speech units of interest and assign labels to them. HSLab is the only tool in the HTK package which makes use of the graphics library HGraf.

In most cases you will not need this tool in your regular experiments. So if this is your case, you can disable it so that the rest of HTK would build successfully.

The solution:
I assume you are using the latest version of HTK (3.4). Disabling HSLab comes in 2 steps:

1. Remove HSLab target from file HTKTools/Makefile in line 48.
2. Remove HGraph from object dependancy in file HTKLib/Makefile lines 49 and 78.

If you have no idea how to make this, you can download my 2 patches and place them in HTK src directory. Run the following commands to patch the makefiles and make/install HTK:

# change directory to htk src path, then:
./configure
patch HTKLib/Makefile HTKLib.Makefile.patch
patch HTKTools/Makefile HTKTools.Makefile.patch
make
sudo make install

Now the whole HTK installs with no problems.
Enjoy :)

Read more...

Writing Large-Scale iPhone Applications using Jiggy

Developing for the iPhone is the hype nowadays. However, one big obstacle that faces anyone who wish to write iPhone applications is learning Objective-C. After all, it is a high-level Object Oriented language. However, in my point of view, and for many people as well, the C family of languages is not suitable for application development. It is perfectly suited for writing system libraries and frameworks. This is because one should always take care of memory management, types and low level system calls.

Thats why we are here, quoted from the Jiggy official website:

What is Jiggy?

Simply put, Jiggy is the easiest way to create applications for the iPhone (or iPod Touch). With just Jiggy and a browser, you'll be able to write an awesome iPhone application in a matter of minutes. JiggyApps run natively on the iPhone, so there is no messing around with HTML and the limitations of Mobile Safari. At the same time, you don't need a compiler or even a Mac, because JiggyApps are written in JavaScript.

When you start writing an application with Jiggy you will find it very simple. However, as your application grows it will be so hard to maintain. Thats why I am writing the following guidelines, which if followed, will help you write large-scale, neat and maintainable Jiggy applications:

1. Don't use the Jiggy IDE, prepare your development environment around ssh.
   If you already installed Jiggy on your iPhone, you will probably have noticed that there are 2 packages your are installing. First one is called Jiggy runtime. This is a set of dynamic-link libraries that encapsulate all native functionality. These are installed in the library path of the system (/usr/lib) and start with the prefix jiggy, as an example: jiggy.UIKit and jiggy.sqlite. The other package is called just Jiggy. This is the Jiggy IDE I am talking about. It is just an application server built on an HTTP server. You run it from SpringBoard, open a browser on your PC and point it to the iPhone IP to get the IDE working inside the browser. This is the simplest way to develop Jiggy applications. You only need a browser. Running into big applications, you will soon find that the browser is never meant to be a reliable IDE. It WILL crash more frequent than you expect. It will leak memory to the ground. It will freeze for seconds as you save and run the application. Moreover, to work on multiple files simultaneously, you have to open several tabs/windows. You can use this IDE as a fast boot but when you eventually develop seriously you need a more reliable environment. Install OpenSSH on the iPhone (but be careful if you need to change the root password). Next, mount the iPhone filesystem using sshfs:
   
sshfs root@IPHONE_IP /mount/point -o allow_other

   You can download sshfs from its official site or if you are using Debian/Ubuntu by:
   
sudo apt-get install sshfs

   or if you are using Gnome use the menu Places/Connect to Server... and select server type as SSH. Write the iPhone IP and root as the username. A shortcut will be placed in Places and on the desktop. Either way, you can browse through /Applicatoins/ and point to your application folder then double click on any Javascript file to edit using your favorite editor. I personally use gedit or vim. Just a note, be sure the iPhone is mounted before editing the files or the editor may get confused and hangs.
   


2. Distribute required runtime libraries along with your applications, don't assume Jiggy runtime.
   These can be found in /usr/lib as discussed earlier. During the installation process, don't copy the libraries in the system /usr/lib in order not to conflict versions. It is safer to leave them in the application directory. By the way, I didn't try leaving them in the application directory yet :) On the contrary, you may prefer to distribute the libraries through Jiggy runtime. However, be very clear in the installation steps.
   


3. For a more stable and collaborative environment, use a code repository and deploy on device as needed.
   When your code-base grows over time, you will discover that it is safer to use a code repostiory (Subversion of CVS). This will also enable you to share the application with other developers. Now you don't have to mount the iPhone filesystem using ssh as you will not be editing files in-place. You will have a working copy on your PC which is linked against some repository. Each time you need to run the application you will have to copy files over the iPhone, you can write a small shell script to do the copy commands. Till the time of writing this line, Jiggy is only available for the iPhone OS 1.x which has no official SDK or emulator from Apple. If Jiggy is ported to iPhone OS 2.x it would be easier to run applications on the emulator without the need of copying files on each run.


4. Avoid using off-the-shelf libraries (prototype for example), you don't need larger useless interpretation times.
   Usually you won't need fancy mechanisms or drag-and-drop and alike functionality. If you need to use AJAX, write your own prototype-alike around the XMLHttpRequest object. If you are too lazy to write it, see mine.
   


5. Don't start the application from SpringBoard (if you don't have to). Start it from an ssh terminal instead.
   Some functionality won't work if you don't start the application from SpringBoard (like the accelerometer). If you don' have to, ssh to your iPhone and change to the applications directory then launch the jiggy binary:
   
ssh root@IPHONE_IP
cd /Applications/MyApp.app
./jiggy

   This is a must if you need to see useful log messages from Jiggy native implementation. You can also write your own logs straight from Javascript using the global function log(). See my other post for a discussion on logging in Javascript platforms.
   


6. Optionally generate a public/private ssh key-pair so that you don't have to enter ssh password every time you login to your iPhone.
   See the OpenSSH page or this good tutorial.


7. Keep your main.js as small as 10 lines or less.
   This is always a rule-of-thumb for all programming paradigms. The general flow of the program should be readable by anybody. Throw away your implementations inside classes and throw these classes inside files other than your main.js. Even more, I do NOT write any flow in my main, its just a logic switch, or program selector:


// main.js
try {
//include("test1.js")
//include("test2.js")
include("myprog1.js")
}
catch(e) {
log(e)
terminate()
}

Whenever I need to test any code or run any sample code, I just throw it in a file and switch to it in my main. When I am finished I uncomment back the original program.
The try/catch is there to bust silly alerts that appears on-screen which if not dismissed normally by user, will freeze the SpringBoard.


8. Create a test-harness because you will need to try various things first.
   You may create a new application for the sole purpose of testing code. Create any testing code in new files and switch between them in main.js. This way you don't need new applications each time you try any code. See the code of main.js in previous point as an example.
   


9. Make your files self-contained, don't assume any implicit dependency.
   In Jiggy, there are 2 types of code dependency. First is Plugin dependency where you depend on a native plugin (Jigglin). Second type is Javascript dependency where you depend on other Javascript files. As an example for the first type, if you use the package Images don't assume that the UIKit plugin is loaded. In the beginning of the file check if it is not loaded and load it accordingly:
   
if (typeof Images == 'undefined')
Plugins.load('UIKit')

   Current Jiggy implementation does not check for loading same plugins more than once, and hence the check above.
   As an example for the second dependency type consider this:
   
include('another.js')

   And in another.js put the inclusion guard which I borrow from C/C++!
   
if (typeof __ANOTHER_JS == 'undefined') {
__ANOTHER_JS = 0
// write all your Javascript code here
...
}

   
This inclusion guard is recommended although not mandatory because re-interpretation of code may cause undesired logical errors.


10. Use a central include path because you are going to make/use reusable components.
    Sticking to the Object Oriented design will render many parts of your code reusable. The straightforward way to reuse the components is to copy them over through different applications. However, you will be changing them frequently and you need a central place for them. You may place them in a separate directory and create symbolic links inside your application folder. I wish I could have time to patch Jiggy source so that it looks in a central include path if it does not find the file in the application directory. Did I hear someone offering help?
    


11. Always remember the restricted memory resources, cache on disk if necessary.
    Don't write code that aggressively allocates memory. Don't let your arrays grow indefinitely. If you need large data-structures let them write their data on disk if they exceeded some limit, using sqlite if needed. If it is all about memory cache, let older values drop altogether.


12. Don't forget your friend, the garbage collector (GC), you may know when to call it better than the engine does.
    Let the code be smart and invoke it in places where you are sure many objects have been released. Each time you release an object, or return from a function, increment released objects count and invoke the GC if it reached some limit. The AutoReleaseCache and ImageLoader are perfect examples for restricted memory management and garbage collection. There should be a global GC function when using them. Here it is:
    
var GC_TRIGGER = 40
var releasedObjectsCount = 0
GC = function(force)
{
if (force || releasedObjectsCount++ > GC_TRIGGER) {
releasedObjectsCount = 0
log("-----------------------------------------------")
log("running gc")
log("-----------------------------------------------")
gc(1)
}
}

    

Read more...