Remote surveillance on your mobile phone

I assume that you have read my previous post on 'streaming webcam using VLC' that describes how to use VLC to stream your webcam's video over the network.

This opens up a new and simple means for surveillance. The idea becomes more interesting and useful based on the network that we choose and where the video is viewed from. To me, if I were to view the video from some other comp, the usability decreases a lot -- unless you are streaming video from home and want to have an eye from your office comp over the Internet; yes, but there are cheaper and better ways to do the same.

I was keen in trying to perform surveillance on a mobile phone and was pretty much fascinated when I could do it. It is really awesome to watch a place in real-time from a remote place and that too wirelessly on a mobile. Now that we know how to stream the video over a network, the only missing link is to figure out a way to establish a network between your mobile phone and your comp.

There are multiple ways to do it:

1. Bluetooth PAN (Personal Area Network): This is the simplest, cheapest and comes at no running cost. Modern bluetooth devices provide upto 100m range, but remember you might have to check with your phone's capability also. I would NOT prefer this as this might tend to disconnect and there is no easy way to reconnect remotely. But it works. I sometimes use it to have an eye on my office cube (for no reason :) ) when I'm just around it.

2. Internet: This is cheaper to establish but has a running cost (specially the data charges on the mobile side are usually hefty). Given that we are aiming at transferring video (atleast QVGA), the bandwidth usage will cost a lot of money; the speed of the network might also be an issue (although a high speed EDGE service on the mobile side might be enough). However, this gives the maximum possible range of surveillance. Literally, from anywhere in the world.

3. Wi-fi: This option is similar to option 1, but much more reliable than a bluetooth PAN. Automatic recovery from signal failures is a plus. I prefer this the most, because my office is fully equipped with Wi-fi. In fact, our other offices (including the ones overseas) are all interconnected, so I can really watch my cube (where I broadcast) from my mobile wirelessly from any of my offices. It's really cool (at least for the first few times). Wi-fi drains battery much faster than bluetooth (as of this writing) though -- so may not be suitable for continuous surveillance.

4. Combination: A combination of these options shall also be applied. E.g., I can choose Internet (broadband) on the broadcasting side, and use Wi-fi (maybe in office?) on the mobile side.

How to view on the mobile:

I'm only going to talk about Windows Mobile here (although I believe the same software is available for Symbian phones too). All you need is a video player for streaming video. Based on the platform you have, you can find one. Note that you need to get a player that supports the protocol and codec you used while streaming.

For Windows Mobile, users can choose to use the free TCPMP (The Core Pocket Media Player) or the professional edition of the same called as the CorePlayer. I personally believe that the CorePlayer is the best for playing streaming video.

Streaming webcam using VLC

VLC is definitely more than just a video player. It has lot of interesting features and extensions which are not explored by all. By enabling one of its various input interfaces, it is even possible to program against your VLC player -- I had written a clip-list application quite sometime back that automatically directs vlc player to play only portions of a given video (maybe a post later).

I'm not really interested in streaming my webcam but this was actually useful for me for a different reason. I actually started writing a post on that, and felt that this topic is worth a post by itself -- some people might just want to stream webcam.

It's pretty simple.

1. Start VLC (all my instructions/snapshots will be as of vlc 0.9.6).
2. Before proceeding further, let us open the VLC's console, so we know if there is any error during the process. To open the console, Menu: Tools -> Add Interface -> Console. VLC will throw log messages into this console.
3. Menu: Media->Stream (or ctrl -S)
4. Choose the 'Capture Device' tab (btw, you can stream a video/audio file/DVD using the appropriate tabs)
5. Under the 'Video device name' drop down choose your camera (you can even stream your desktop by choosing it in 'Capture Mode').
6. Click on Stream. A new window pops up. This is where you provide the streaming options.
   
   
   
   
7. A simple method is to stream over HTTP -- this specially helps to get across firewalls/networks without glitch. Provide the IP address of the interface in which you want to stream your video. Eg., if you have a multi-homed computer, you might want to bind it only to your private network and not your internet IP. Choose an appropriate port of your choice. Even 80 would do.
8. Under Profile, choose Windows (wmv/asf) -- If you understand, you can opt to choose the right profile as you see fit.
   
   
   
   
9. Now click on stream and your video should start streaming. If everything was fine, you should see a 'creating httpd' message in the console without any other relevant error messages following it (sometimes you might not have an appropriate encoder or the port binding might fail etc.,). Also the VLC player UI's status pane should show 'Streaming'.

That's it. Now to view the streaming video on any other machine in the network,

1. open VLC on any other machine
2. Menu: open Network (or control - N)
3. Select HTTP in protocol and the IP address of the machine where you are streaming. The port number stays disabled for me (Workaround: change the protocol to RTP, change the port and change the protocol back to HTTP :) )
4. Click on Play.

I wish I were a doctor

I'm an engineer by education and profession; all along I've been happy and so satisfied about it; but not any more.

Engineering explains most of the things that happen around you every day. As I remember

• 'newton's 3rd law' while walking;
• 'doppler's frequency shift' from the horn of a speeding car/bike;
• 'raleigh's scattering' looking at the orange sky;
• 'frequency spectrum' while on a traffic signal pondering about why red is stop and green is go;
• 'acetic acid' when the bearer serves me vinegar for the fried rice;
• 'potential difference' when a crow casually sits on a metallic electric wire;

(and more ...)

....I've always enjoyed my education (as if I were Neo looking at The Matrix :P). No doubt that I still enjoy my education, but there is rather something else that is much more important to understand than all these --- yes, that's our human body.

=== what follows is my own understanding of a disease; do not rely on the information here if you are looking for some critical information on this disease. ===

I was totally devastated when I got to know about this disease (not sure if I can call it a disease) called 'Guillain-Barré Syndrome'; commonly referred as GB syndrome. It is mentioned that this disease is very uncommon and the chances of this disease is just 1 or 2 in 1,00,000. What took me to surprise was the complication of the disease; I never had imagined such a problem was possible. In simple terms, GB-syn is a situation wherein our body's immune system starts destroying our own nerve cells! OMG!!! Apparently there seems to be a generic term for this kind of complication -- autoimmunity. As time proceeds, the disease gets worse, wherein there are too many antibodies generated to act against our own self. A friend of mine is affected by this disease and hence I know about this; the disease progresses at very fast pace -- to given an example, my friend suspected some abnormality on 1st day and went to the doctor; on 2nd day he felt so weak but managed to go the doctor with his friend; on 3rd day he was paralyzed literally and could not move :( The disease is so complicated and the attack is so acute that lack of an immediate medical intervention might even result to death.

In spite of understanding so many things around us, there are things within us which we don't understand and those can put us to stop. To me, if I don't have any idea of how my body works, I don't have to be proud of knowing how a computer works!! after all nothing is more crucial than our lives. Now that it is too late for me to realize or react, I can only wish I were a doctor, to have understood at least a portion of my body!!

One thing is clear that happiness/sadness is subjective and relative. Someone who has GB-syndrome would really not worry about this economic slowdown or losing job or about a huge homeloan on a declining real-estate; there are always worse things in this world; so be happy for what you have and enjoy your days!!

Building a serial port logic convertor

As mentioned in my previous post, it is not possible to directly connect the serial port pins to the uC's pins due to the difference in logic levels. Let me talk about what is the difference and how we can build a serial port logic convertor (note: i'm just posting the summary of all the information I collected, so it is all available in one place for someone else).

Serial port (RS232) logic levels:
In a serial port, a logic level of 1 is denoted by any voltage between -3V to -25V and a logic level of 0 is denoted by any voltage between +3V to +25V. While, for a uC, logic level of 0 is 0V to +0.8V and logic level of 1 is 2.2V to +5V.

Now, there are two problems to be solved:

1. The serial port's have a wide operating voltage -- the worst case being 50V
2. The logic levels are totally different and incompatible with uCs (TTL).

I came across a naive seral port logic convertor which just makes use of a voltage regulator (LM7805) to bring down the voltage to required levels -- but I believe the fundamental assumption there is that, the serial ports work on a voltage above 5V, but this isn't necessarily true according to the standards. That said, it seems that most serial ports work off an unwritten standard with a operating voltage of -12V for logic 1 and +12V for logic 0. But devising a circuit on this assumption is probably going to hit us sooner or later.

A common elegant solution is to make use of a MAX232 IC that does the job for us. I got a MAX232 in PDIP 16 pins (8 + 8). The IC can drive 2 serial port I/O and make them available at TTL. The connections are fairly simple. The following is the schematic that I took from their datasheet.



PIN configurations for a standard serial port:

• PIN2 -- output pin of serial port (should go into the input pin of MAX232 -- output should be read),
• PIN3 -- input pin of serial port (should go into the output pin of MAX232 -- input should be sent),
• PIN5 -- ground

I managed to build my own serial port convertor on a general purpose PCB. This is how it looks after it was soldered.



Under the board (the nasty soldering):


Before I integrate this convertor with my uC and fiddle around, I should make sure this works. Otherwise, it might become very difficult to isolate the problem if I made a software error later. The approach is pretty simple, just short-circuit the output and input PINs on the uC side in the convertor, thus creating a loopback serial convertor. Basically, this circuit will just send back whatever comes in -- in software terms, an echo server.

The circuit can be tested by connecting the circuit to the computer's serial port and then using HyperTerminal in windows to connect the COM port in which it is connected. It is important to choose 'Hardware control' as None. Now if everything goes well, just start typing on the hyperterminal and you should see what you are typing. That proves that the serial port logic convertor works fine (by looping back).

Here is the working circuit in action:

Computer and micro-controller communication

After my digital thermometer, I thought it is worthwhile to integrate my micro controller (uC) projects to my computer. There are tonnes of advantages that I see by doing this. While working uCs, specially as being a computer programmer, I found it difficult to achieve a number of stuff. Most basic things like input / output aren't readily available (note that I'm not blaming the uCs here; after all we are not writing software here, but building hardware) -- this makes it very difficult to debug or build prototypes. These days I use LEDs (and different blink rates) to debug various scenarios. But imagine how I would have debugged my first LED blink project :) -- there was simply no way. Not just debugging, allowing uC to talk to the computer (when required) opens up a whole new world of communication. There are so many features that become readily available, like

• keyboard - I can configure my uC parameters at runtime from my keyboard?
• monitor - I can send some debug output or runtime logs to my comp and record it?, you know much work I did to show just 2 digits in hardware.
• processing power - not sure how useful it is but if I need I can make use of the huge processing power a comp has.
• internet - this is very interesting. maybe my uC doesn't need internet but how about controlling my uC from the internet ?? maybe, controlling my room's lights from office ? office -> internet -> webserver on my home comp -> uC -> light; I think this opens up a lot of new opportunities.

Let's see how it evolves :) I have no idea about how I'm going to utilize, but I'm convinced that given my programming knowledge on computers, it is quite a useful thing to have. Technologies becomes more and more powerful only when they interact.

Now that we are convinced that a computer interface is useful, it is time think about the choices. The possible options are serial port, parallel port, USB, bluetooth, infra-red. Bluetooth and infra-red need hardware counterpart on both sides (on the computer and uC hardware), so that isn't practical for me now. USB seems a option, but that also requires a USB protocol handler on the uC side (there are some free open source USB drivers available for AVR uC's but they would occupy considerable code space -- and with just 8KB available for programming, I would rethink). Serial and parallel ports are the simplest options. Over these two I prefer serial port for two reasons.

1. Serial port requires fewer number of lines for transmission/reception (technically only 2 lines for data(tx/rx), but additional lines for vcc,gnd etc., add up to 4-5 lines, still much better than parallel port).
2. ATMega8 has builtin support for handling USART - the standard serial transmission protocol. This makes it handy for us to talk over serial port between the computer and the uC.

So I chose serial port as the preferred communication interface. This does not mean that I can just connect a few wires from serial port of the computer to my uC -- because the logic levels are different between the serial port and the uC. I need a convertor for these logic levels before I can communicate. How? stay tuned.