WapCamSdkR20
It all started from an idea: “I want look at a remote location using my WAP cell-phone”. I had this idea when I knew about the features of WML (Wireless Markup Language) and WBMP (bitmap for WML). In fact, the actual WAP-phones can display WBMP on their screens. Then I can present an image on the WAP-cell, I can decide the image, and I can decide the time of permanence of the image on the screen. If the time between images is very little, I may have a cinema-effect (in cinema, X fixed-images are projected in one second so that the spectator has the illusion of movement). Following this article, you’ll find that it is true in part.
The application
Briefly, WapCamSdkR20 takes images from a webcam, and after some conversion, creates as output a .wbmp file, under a directory relative to the web-server. That is the simple core of this architecture, for transmitting images on a WAP-phone. Really, there is no transmission to a cell but it is the cell that updates its information. Therefore, we must look at WapCamSdkR20 like an architecture and not like a simple .exe (in its alpha-version, WapCamSdkR20 is a .exe).
The architecture
Let’s take a look at the real architecture of WapCamSdkR20.
We need to take images from a webcam, manipulate these images and obtain a .wbmp. We must repeat this sequence every X milliseconds for refreshing the image on the WAP-phone.
This scope is realized by WapCamSdkR20.exe.
Now we must find the link between WapCamSdkR20.exe, relative to the Microsoft platform, and the WAP-phone: the solution is a synergy between a WAP-Server and Microsoft IIS. If the server-machine, where the software is located, has a modem and a phone-line, we may obtain a self-governing eye on the world.
Windows 2000 or upper OSs are perfects for implementing this type of communication-software (for their API and robustness) and Microsoft Visual Studio (Visual C++ 6.0) is the perfect tool for developing this application (for rapidity of development).
Inside WapCamSdkR20.exe
We have a normal .exe file with SDK technology. WapCamSdkR20 uses Wap.dll, that exports two classes: CWebCam, Cbitmap. The first is responsible for acquiring information from the web-cam, and the second for manipulating and converting the bitmap. At the beginning of WapCamSdkR20.cpp, we have the class CWapPhone that inherits from CWebCam and Cbitmap; the instance of CWapPhone is: “topolino”. All the operations are realized with topolino.
At the beginning of WapCamSdkR20.cpp, we have:
topolino.InitializeCBitmap();
topolino.InitializeCWebCam(WINWIDTH,
WINHEIGHT,
MAIN_WINWIDTH,
MAIN_WINHEIGHT );
These methods initialize the two preceding classes, after we have create the main window and do some operation relative to the window.
topolino.SetCurrentDriverIndex((BYTE)0) gets the first driver of all web-cam drivers and sets its to use with WapCamSdkR20.
topolino.StartCamWindow(CAM_X_ORI,
CAM_Y_ORI,
MAIN_WINWIDTH,
MAIN_WINHEIGHT,
hDaddy )
The above method creates a capture window and links her to hDaddy.
Later we have the creation of the unique thread and the management of message queue for the main window.
In the main window, you can notice two text-boxes. These are responsible for setting of two main parameters necessary for the algorithm of conversion of the bitmap. We will see the parameters later, now we must look at RealThreadProc of the unique thread.
DWORD WINAPI RealThreadProc(void* pv)
{
while(1)
{
SaveOnFile();
Sleep(X_Time);
}
return 0L;
}
SaveOnFile is the only function called again and again, and X_Time is the time that passes between the creation of WBMP.
In the SaveOnFile function, we have FromCamWinToBmp(BitmapFile, COLORONCOLOR) that retrieves images from the web-cam and stores them in one file, Load(BitmapFile) that retrieves the bitmap from the preceding file, Filter_1(Range) that applies a typed algorithm to the bitmap, ColorToBW(Threshold) that converts the color bitmap to BW bitmap, ConvertToWbmp() that converts the BW bitmap to WBMP, and SaveWbmp(WbmpFile) that saves the WBMP to a determinate path.
Notice
You must consider that this application is in alpha release, therefore there are imperfections and abounding of operations.
Important
In the cinema, we have approximately 25 frames per second, but this quality is very difficult to obtain with WAP architecture. Why?
A WAP-phone is a complex micro-device that has one particularity: these devices have a micro browser for the page WML, then we create a low cinema effect refreshing the page-read by device.
But we have the unreliability of GSM communication, a little device with low memory capabilities, and particularly, we must consider the low band of GSM channel. Therefore, when the WAP-phone reads a WML page, this operation is executed slowly and the time interval between two pages can be up to 750 ms.
These technological limitations are probably eliminated with the next generations of the cell-phone.
For all these reasons, we can set X_Time up to 1500 ms; in this way, we take away nothing from WAP performances and we gain precious time for other threads.
Inside Wap.dll
The only image support in the WAP protocol is the WBMP format, this particular format is used only for small and monochromatic images. In the Windows environment, it is very simple to find graphical applications that build or obtain images in BMP format, but this isn’t true for WBMP format. For this reason we have a simple C++ class that converts BMP format to WBMP format.
First, we analyze CBitmap. In this class, you will find two constants that are related to the width and height of a WAP phone (96 x 65). These measures are relative to a common WAP phone, and in the class, are used for all calculations. In the InitializeCBitmap method, there are the allocations for necessary buffers for bitmap and file operations. Load retrieves a bitmap from file and pushes it to the pMem memory buffer. Save stores a bitmap in one file. SaveWbmp stores a Wireless-bitmap in one file.
The class name is CBitmap inside _BartIvan namespace defined in Wap.h. Its constraints are: the size of the source image must be 96x65, and you see this in the Wap.h.
#define WAP_WIDTH 96
#define WAP_HEIGHT 65
For managing the bits in every single byte, we define the following union, myunion, that contains a bitwise structure bits_st.
union myunion {
BYTE byte;
struct bits_st {
unsigned char bit7:1;
unsigned char bit6:1;
unsigned char bit5:1;
unsigned char bit4:1;
unsigned char bit3:1;
unsigned char bit2:1;
unsigned char bit1:1;
unsigned char bit0:1;
} bits;
};
The bits manipulation is implemented in the class method (static) SetBit, and the macro CB is used to simplify this operation.
#define CB(n) case n: \
u.bits.bit##n = val; \
break
static inline void CBitmap::SetBit( BYTE * b, int numbit, int val )
{
myunion u;
u.byte = *b;
switch(numbit){
CB(0);
CB(1);
CB(2);
CB(3);
CB(4);
CB(5);
CB(6);
CB(7);
}
*b = u.byte;
}
Another very important class method is GetBNBitValue that has as input the three bits that define a single pixel of a BMP and a threshold, and returns the equivalent pixel in monochromatic image, that is 0 or 1.
The conversion is done in two steps:
- Conversion from color image to BW image, implemented in the method
ColorToBW.
- Conversion from BW image into WBMP image implemented in the method
ConvertToWbmp.
Moreover, this class supports the serialization of the file of the BW image and the WBMP, through the methods Save (<filename>) and SaveWbmp (<filename>), and it must load the source BMP from file using the method Load (<filename>).
The following picture shows in UML how the conversion is implemented:
Important
Actually, the WAP-phones are devices with monochrome display, therefore, we must convert the color bitmap of AviCapWindow to BlackWhite bitmap, and later, the BW-bitmap to Wireless bitmap.
For all calculations, we used the medium square value of three bytes relative to one color pixel. The method Get3Byte_rms is responsible for this calculation.
Filter_1(short Range) is an imaginable filter that we can apply to the BMP retrieved from the web-cam; particularly, this filter compares the actual BW pixel to preceding, to following, to upper, to lower, and under certain values of Range, you could see the border of shapes instead of filled shapes.
ColorToBW(char Threshold) is the main method for the conversion of bitmap. Changing the Threshold, we must decide when the pixel will be white or black; in fact, this threshold is compared with the medium square value of the generic pixel, and if the condition occurs, the pixel will be set to white. In some cases, we had problems (with particular formats of BMP), and for this reason, you will find the long bnAdjust variable.
ConvertToWbmp() is the last part of the conversion. This method is accurate up to even little values of the width and the height of the image. For more information, you must refer to WAP specifics.
We analyze, now, CwebCam. There is not much to talk about; in the InitializeCWebCam method, we have the initialization phase, StartCamWindow method creates a window of type "AviCap_Basic".
Notice that if the application’s window is hidden, nothing is written in the WBMP file, because the information is retrieved directly from AviCap window.
FromCamWinToBmp is a method that really gets images from AviCap window, and then through the IPicture interface, it saves the information in the .bmp file.
Some resulting .wbmp files are shown:
These pictures are read with Wbmpview.exe, a free application available in the Internet. You must consider that the WAP-phone generally cuts the image to adapt to its display (generally, a display is 96 x 65 pixel).
Inside the WAP system and architecture
Mobile phones have become very popular in recent years. Mobile WAP phones are communication systems that are able to run applications and communicate with other devices and applications over a wireless network (GSM).
Through the technology based on WAP (Wireless Application Protocol), it is possible to interact, directly from WAP mobile phones, with information and the most heterogeneous services on the net, allowing the dialogue between Internet and GSM net, and allowing the development of applications and services that operate on the wireless net.
The WAP has a proper technology. So it is not possible to enter through a WAP mobile phone to the common web sites and applications. WAP uses different languages from those commonly used for web applications. The most important and used language for WAP is WML (Wireless MarkUp Language) fundamentally. But WAP has also its own scripting languages, with own image formats, and it also needs an appropriate browser, called micro-browser, to display the WAP pages. Micro-browsers are available in the WAP mobile phones of the last generation.
WAP Model
The WAP programming model is very similar to the WWW programming model. Wherever possible, the same solutions used for WWW model have been used and adopted as a starting point for WAP technology.
Obviously, WAP model changes some of the WWW standard in order to make them compatible with the characteristics of WAP devices and GSM net.
WAP model assumes the existence of a WAP gateway server which is delegated the functionality of:
- coding and decoding of data transmitted from and towards the client (WAP phone).
- acquiring information.
- compression / decompression of data transmitted on the wireless net.
In the WAP model, WAP mobile phone communicates with the WAP gateway. This gateway translates WAP requests to WWW requests, thereby allowing the WAP client to submit requests to the web server.
The gateway WAP server also encodes the responses from the web server into the compact binary format understood by the client. If the web server provides WAP content (e.g., WML), the WAP gateway retrieves it directly from the web server. However, if the web server provides WWW content (such as HTML), a filter is used to translate the WWW content into WAP content. For example, the HTML filter would translate HTML into WML.
WAP Architecture – layer and protocol
WAP architecture is composed of five layers:
Wireless Application Environment (WAE)
The WAE is an application environment based on a combination of elements and solutions for the World Wide Web with Mobile telephony technology. The main goal for WAE is to establish and to determine an operational environment that allows the operators and the service providers to build applications and services that can satisfy a wide variety of different wireless platform in an efficient manner.
Wireless Session Protocol (WSP)
WSP provides connection services that operate based on the transactions offered from the transaction layer protocol called WTP.
Wireless Transaction Protocol (WTP)
WTP manages the data transport as data packets (datagram). It operates efficiently over secure or non-secure wireless datagram network and provides many features.
Wireless Transport Security Layer (WTLS)
WTLS is a security protocol based on the standard security protocol known as the Secure Socket Layer (SSL). WTLS protocol provides the following functionalities:
- Data integrity
- Client e server authentication
- Privacy
- Denial-of-service protection
Wireless Datagram Protocol (WDP)
WDP operates at the physical device level and it offers services of transparent communication to the upper levels. UDP protocol allows the upper level protocols to be independent from the wireless net.
WAP Solution: Monitoring with a web cam on WAP phone
The image we acquire from a web cam, at regular intervals of time, is translated into a two colors WBMP image. A special software takes care of such image format translation. The image we obtain is stored into a database.
The WAP application, at regular intervals of time, calls the database and makes the refresh of the required WBMP image on the WAP mobile phone user agent. The WAP phone client calls a WML page (menu page) and selects the area which is to be monitored. The WTP request is translated into a HTTP request from the WAP gateway and it is posted to the application web server. The response is passed from the application web server to the WAP gateway. This one, translates the response from HTTP response into a WTP response, and the result is displayed on the WAP mobile phone.
Obviously, we need to configure the IIS web server, adding the following MIME type to the default document root:
.wml text/vnd.wap.wml
.wmls text/vnd.wap.wmlscript
.wbmp image/vnd.wap.wbmp
.wmlc application/vnd.wap.wmlc
.wmlsc application/vnd.wap.wmlscriptc
In this way, for example, the IIS web server knows that a “.wbmp” file is an image for WAP and a “.wml” file is a text file.
Scenario
We could think that a client enters through a WAP cellular phone to a special menu of information and from there makes a request for monitoring a certain area monitored by a television camera (a part of our residence, a part of an inhabited center, and so on).
The request for monitoring arrives to our WAP Gateway and, from there, to our application web server. This one, makes a request for information to a database, withdraws the required image in WBMP format, and keeps the connection open with the WAP mobile phone, making the refresh of the same image at regular intervals of time. The WAP client, is so able to have a full monitoring of the required area on the same device.
Possible Option menu for a WAP client……
…..
<wml>
<card id="Option Menu" title="Option Menu for Monitoring Area">
<p> Menu </p>
<p>
Monitoring for Area Xxxxx
Monitoring for residence area yyyy
……
other option….
</p>
</card>
</wml>
A part of source code for web cam on WAP phone...
…..
<wml>
<card id="Photo_Card">
<onevent type="ontimer">
<refresh/>
</onevent>
<timer value="30"/>
<p>
.... acquire the image from database .....
<img src="Our Image from Data Base.wbmp" alt="monitoring"/>
</p>
</card>
</wml>
WAP Solution Architecture
In the following picture, the architecture of a WAP solution, as regards the WAP request for a monitoring image, is described.
The solution uses a Gateway WAP Server (such as UPLink, Nokia WAP Gateway, WapLite Gateway, and so on...) and an application web server (Microsoft IIS, Apache, ....).
The WAP gateway implements the following functionalities:
- To intercept WML or HTML requests that arrive from a WAP cellular phone.
- To filter and compress such requests, and to translate them into recognizable requests for a web server.
- To distribute such requests to the appropriate web servers.
- To return the requested information to the WAP phone, in a recognizable format.
With regard to the WAP phones, the clients of applications can use any mobile phone which is WAP compliant.
Bibliography
Some articles and/or books used for this article...
