Quick Java Setup Tut

Being bred in C/C++, my eventual move to Java wasn't a smooth experience. Setting up the Java environment was something i found difficult to understand initially coming from C++, where essentially there was no such setting up required. The online tutorials I found were either too verbose and I could never find my way through the tones of literature, or they were on the complete opposite end of the spectrum, where I could never understand why I was doing whatever was asked to be done for setup. So here is my quick tut on setting up the Java environment..

1) Install Java SDK for your OS from sun's website
2) Setting the Environment Variables

JAVA_HOME: This is the root directory of the Java installation i.e., something that ends like jdk1.5.0

PATH: This is the list of directories the OS searches for the commands you invoke. If you want to be able to call java from anywhere, you need to make sure the OS can find it.. In other words, the java executable needs to be in the list of directories the OS looks in. The java exectuable and other dev tools are in the JAVA_HOME/bin directory. So edit the PATH variable to include the JAVA_HOME/bin directory

CLASSPATH: This was something i could never digest initially during my move from the C world. Unlike C/C++, you need to tell java where to look for the compiled source files a.k.a classes. And this is exactly what the CLASSPATH variable tells. I think Classpath defaults to current directory and the standard directories (under JAVA_HOME). If your code uses classes from other direcories/.jar files, you will need to include them in the CLASSPATH variable. Note that you need to fully specify the jar files, not just stopping with the containing directory.

Quick Example:

Assume I have installed Java at /home/yoda/jdk1.5.0. And the java source files (.java) I wrote are under /home/yoda/src. Also, my source files import the mysql-java.jar file(located under /home/yoda) and use classes under /home/yoda/ReusableClasses

I will be using bash for the e.g. Use appropriate modifications for setting and exporting environmental variables in your Shell.

vim ~/.bash_profile

JAVA_HOME=/home/yoda/jdk.1.5.0
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=/home/yoda/mysql-java.jar:/home/yoda/ReusableClasses

export JAVA_HOME PATH CLASSPATH

source ~/.bash_profile

Make sure the environment variables are set by echoing e.g. echo $PATH.

Now cd /home/yoda/src
Compiling: javac *.java
Running: java MyMain.java

Sharing internet over the USB on the Nokia N800

Sharing internet over the USB on the Nokia involves two processes

1) Setting up the USB Networking
2) Sharing the internet through the host machine.

Setting up the USB networking

I mostly used stuff from the maemo link


It worked most of the time.. the only event was the usbnet start script couldnt insmod the g_ether.ko module. I did that manually, and ifup usb0 to bring up the interface.

Sharing the internet through the host machine

Use the iptables stuff from here

I havent tried using the N800 native apps on USB networking yet.. I just need to use scp over the USB, and it works fine right now.

MUBICA

I was at MUBICA yesterday and before i forget things, i thought ill write about them. This being the first time of the workshop, there were only around 15-20 people, and there was a workshop on sensor networks happening at the same time, that probably was a bigger crowd puller. Anyways, about the workshop itself..

The keynote talk was about Syd, a middleware for mobile computing over heterogeneous architectures. Essentially what Syd did was making dynamic objects available so that nodes could then find and use them. At the core of Syd is a directory structure which maintains which objects are availabe and where they are. At this time, the directory is on stable store, which i guess needs to be moved into a distributed directory soon if Syd is to really make an impact. The other interesting issue was how Syd tackled disconnection. Essentially, objects are expected to publish proxies on stable store which will perform their functionality when the real objects go offline. I wasnt really satisfied with this solution because this sounds similar to a Coda like architecture.

There were talks on exploiting the grid architecture for pervasive computing and so on.

Also, there are a couple of groups out there working on ubiquitous health care that probably i need to look at as we proceed with CAST.

My presentation went ok with my advisor taking on the more technical and difficult questions. I surely need to practise more before doing presentations.

In summary, most of the MUBICA papers were engineering experiences, more so than scientific discoveries, but being my first workshop presentation, it was quite an experience.

How to do research

This is going to be an eternally updated post as I write my experiences on doing research, things i should have avoided, things i have learnt on my own and from others, and things I hope to remember as I move on..

1) Never give into inaction: Many a times I complain of stagnation.. an inexplicable lack of ideas, and at these times i doze into a state of inaction. Never ever allow this to happen to you. Inaction breeds inaction. Inaction has an extremely high inertia that getting out of it, is by itself becoming a milestone. After giving it some thought, I find that my inaction is fueled not by a lack of ideas, but by a disinterest to do real work. One can always find justifiable reasons not to work (just as I am writing this blog post when i should be doing real work) but the greatness lies in overcoming this overwhelming feeling. When stuck in such a situation, try to work on easy things for as short a duration as you may think comfortable to begin with. As you start working, you will find that you longer need that break , that you were once in desperate need of. This reminds me of a famous saying "We must be taught not to wait for inspiration to start work. Inspiration seldom generates action. Action always generates inspiration". So we must constantly be involved in action.

2) Be receptive to ideas and criticism: In other words, be in constant touch with your advisor. Never feel scared to talk to them because you haven't done anything productive. Probably, they have a different measure of productivity than what you think they use. In any case, the advisor must have an up to date information about your progress. Also, always meet your advisor with an open mind. Never go in with a hard head, as you may lose valuable suggestions then. Its always better to know if your work is reasonable before hand than wasting a lot of time, to find later that it leads no where. This is where the advisor's comments come in handy.

3) Its better to ask for forgiveness than ask for permission: As a student, I think we are more enthusiastic and have a lot more time than our advisors. Make good use of the available time. Experiment with new stuff. Its always better to go to your advisor with some preliminary results than asking him permission for an experiment that you yourself have no idea about the results. Being proactive makes you personally feel good, and portrays a positive image to your advisor, who may now take your work a bit more serious than before.

4) Be happy that you are not walking on unchartered territories: It sometimes feels overwhelming while starting a thesis like project, when you look around and find that most of the ideas you had in mind, have already been beaten to death by others. Do not lose heart. Be happy that there have been many people working in the field since that indicates i) It is a worthwhile field else a vast majority of the people wouldn't have ventured into it in the first place ii) You have a vast amount of literature to build upon. Try to understand others' ideas and compare it with your own or among themselves. Be sure to understand what works when and why. This would be a good start to solidify your thought process.

At the same time never feel scared to venture into unchartered territories. You may become the forefather of a new subarea and many people in the future could potentially benefit from your work.

Dynamic Fine Grained Localisaton in ad hoc sensors

Ranging + Estimation
ToA better than RSSI-- T0A being a difference is more robust, not sure why
Atomic multilateration-- not sure with the exact equations yet.
Collaborative multilateration- when there are not atleast 3 beacons around, use multihop location information.
Statisitical analysis of beacon and node placement

Acousitc Sensor Networks

Water Channel Variability at depths
-mulitpath fading, doppler spread, low bandwidth, high delay varations
Medium access
-no tdma due to timing constraints, cdma looks ok
- no kind of rts/cts since due to high delay variability
Routing
low overhead and low latency, connectivity
Transport
event transport important than actual data transport