Image Transmission on Wireless Visual Sensor Networking Devices Imote2 Platform Based on IEEE 802.15.4 ZigBee E...

In recent years, the wireless sensor network (JSN) has provided breakthroughs in the field of monitoring from monitoring rainfall in gardens to monitoring heart rate in the health sector. This technology is known for its very low and simple energy consumption, and is currently being developed so that it can operate without a power source, but instead uses the available ambient energy such as using the energy input of a TV station's electromagnetic waves. JSN initially focused on data that could be sent at a low bit rate channel capacity. In this research, it is more to JSN with a higher bit rate channel capacity in order to transmit multimedia data specifically here is image transmission, so that the term JSN can be reduced to a wireless visual sensor network (JSVN). The platform used is Imote2 with a radio based on IEEE 802.15.4 ZigBee and the main characteristic of this research is implementing an embedded Linux system, which has never been done before. So far, there are no publications that describe the image transmission scheme in Imote2 Linux, in other words there is no information related to image transmission. This research discusses in detail the image transmission scheme between the author's version of Imote2 Linux and the scheme so that it can be used as a testbed, starting from applications written in C, compiling some testbed requirements, to implementing the testbed. The rest of the performance of Imote2 Linux is tested by transmitting the image without compression and with the JPEG2000 standard compression where the compression is carried out on the Imote2 Linux embedded system by the OpenJPEG software. The results show a significant difference between uncompressed and compressed transmission.

Chapter 1 Introduction

1.1 Background

WSN (wireless sensor network) is a wireless network system that uses sensor devices to obtain information. These sensors are distributed in an area that are connected wirelessly (forming a network) to collect information around them as in Figure 1.1. This WSN has been applied in the civil, medical, and other fields (Shwe et al, 2013). There are several types of sensors, including temperature, motion, acidity, sound, and camera sensors. This research uses WVSN (Wireless Visual Sensor Network) which is a camera sensor-based WSN.

Figure 1.1 WSN overview

One example of the application of WSN is the research of Garcia-Sanchez (2010) on monitoring of wild animals on transportation infrastructure in the wild. Things that are monitored are animal interactions such as the frequency and time the animals cross the road or underpass, the length of time the animals have been there, and how the animal's attitude towards the transportation infrastructure. From this monitoring, it can be seen whether the transportation infrastructure is safe, attracts the attention of animals, the overall condition of the transportation infrastructure and the natural conditions around it. Monitoring is carried out by installing camera sensors and motion sensors on the Imote2 platform in the transportation infrastructure area such as the underpass entrance gate, in the underpass, the edge of the highway, above trees, or in ravines as shown in Figure 1.2. Several factors such as no power source (resource), an environment that does not allow the installation of large devices such as ravines, danger zones, uneven terrain, and sensitive environmental conditions (tend to attack the device or avoid the device), or the time factor that requires immediate monitoring so that it is impossible to spend time on large equipment installations, and many other factors, a similar example in the military field to detect the presence of an enemy must use a minimalist and small device so that it is not easily detected, for this matter WSN is an option because it is practical to apply.

Figure 1.2 Example of implementing JSN on a road in the wild (Garcia-Sanches, 2010)

Current WSN research leads to energy savings while maximizing performance in other words, getting as much information as possible with the minimum energy consumption. This is because WSN has limited resources and limited computing capabilities. Imote2 itself uses 4 AAA batteries as a power source, has a processing capability of 13-416 MHz, 32 MB program memory, 256 kB of RAM (Random Access Memory) as a temporary storage place at the processing stage, and a maximum transmission rate of 250 kbps point-to-point. Even though Imote2's specifications are superior to other platforms as shown in Table 1.1, it is still far from being compared to PCs (Private Computers) which now have a minimum specification of over 1 GHz processor, over 1 GB RAM, and over 50 GB hard disk capacity.

Table 1.1 Mote hardware (Akyildiz, 2010)

From these limitations, one of the efforts to save is the determination of the right transmission media. There are many types of standards for wireless transmission media such as WLAN (Wireless Local Area Network), Broadband Wireless, and WPAN (Wireless Personal Area Network). WLAN standardized on IEEE 802.11 has a wide range over 1 km with a max data rate of 54 Mbps on IEEE 802.11g, this standard is more suitable for wireless communication on computers. Broadband Wireless has a wider range with a max data rate of IEEE 802.16m 100 Mbps, better known as WMAN (Wireless Metropolitan Area Network). However, the results of previous research, namely research by Wiasta (2012), Natha (2012), and the author himself Purnama (2013), are not efficient in transmitting binary data using WLAN. The results are far compared to using the WPAN standard, which can be seen in Figure 1.3. For portable devices, the IEEE 802.15 WPAN standard is provided. IEEE 802.15.1 Bluetooth provides a max data rate of 723.2 kbps with a range of 10 meters. It is commonly used for voice and data transmission, applied to cellphones and gadgets. IEEE 802.15.2 regulates communication between WPANs and other wireless networks. IEEE 802.15.3 HR-WPAN (High Data Rate Wireless Personal Area Network) with a data rate of 11-55 Mbps with a range over 70 meters is commonly used for multimedia. Suitable for use on WSN is the IEEE 802.15.4 LR-WPAN (Low Data Rate Wireless Personal Area Network) standard because it is low power consumption and data rates of 20, 40, 250 kbps point-to-point with a range of 10 meters (Ahmad, 2005). IEEE 802.15.4 develops the PHY layer, MAC layer, and NWK layer, while Zigbee develops the full application layer in Chapter 2. The transmission limitation in IEEE 802.15.4 Zigbee is the maximum data rate of 250 Kbps point-to-point with PHY layer, the maximum packet size is 127 bytes minus 89 bytes header. Fragmentation and reassembly are not performed at the NWK layer, therefore the application layer must be developed for fragmentation and reassembly and adapted for image transmission (Pekhteryev, 2005).

   Figure 1.3 Electrical power consumption in WSVN Imote2 binary data transmission (a) Imote2 with WLAN (b) WLAN power supply (c) with LR-WPAN (Natha, 2012, dan Wiasta, 2012)

Another effort is to use a lightweight operating system. Previously Imote2 worked on Intel Platform X. After Imote2 moved to Crossbow, Intel Platform X was no longer being developed because Crossbow released its own operating system. The operating system used is most of the operating systems developed by communities such as SOS (Simple Operating System) but SOS has been discontinued since 2008. Currently, it is TinyOS and most recently Linux. Most publications on the web use TinyOS. Embedded Linux is now being developed due to the limitations of TinyOS such as complex routing. The embedded Linux community thinks the Linux operating system on Imote2 can overcome these limitations. However, embedded Linux on Imote2 is still new and under development (Kasteleiner, 2010). The main reason Linux is used is because it is opensource, which means it is free, open and can be developed by anyone.

This research leads to embedded system Imote2 Linux. Previous work successfully embedded Linux into the Imote2 platform and successfully sent a maximum of 28 bytes of random data. In this work the function will be extended so that Imote2 Linux can transmit images with IEEE 802.15.4 ZigBee-based radios. After being able to transmit, the Imote2 Linux transmission performance will be observed.

1.2 Problem

1. How is the image transmission scheme with wireless media based on IEEE 802.15.4 ZigBee on the Imote2 JSVN platform on embedded Linux?
2. How does the IEEE 802.15.4 Zigbee based WSVN platform perform in image transmission on embedded Linux?

1.3 Research Objective

1. To get an image transmission scheme with wireless media based on IEEE 802.15.4 Zigbee on the Imote2 JSVN platform on embedded Linux.
2. To get a robust image transmission scheme on the Imote2 WSVN platform based on IEEE 802.15.4 Zigbee on embedded Linux.

1.4 Research Benefit

1. Get an image transmission scheme with wireless media based on IEEE 802.15.4 Zigbee on the Imote2 JSVN platform on embedded Linux.
2. Getting the optimal schema for transmitting images on the Imote2 JSVN platform on embedded Linux.
3. Get the performance results of the Imote2 JSVN platform in image transmission implementing IEEE 802.15.4 Zigbee on embedded Linux.

1.5 Scope of Problem

1. Using the Imote2 platform WSVN.
2. Imote2 uses the embedded Linux operating system.
3. Image processing applies the JPEG2000 standard.
4. Transmission system between Imote2 Linux.

Chapter 2 Literature Review

This platform could not handle this much data, therefore this chapter was omitted. Go to the end of this final project and go to other mirrors if you want to read this chapter.

Chapter 3 Research Method

3.1 Location and Time of Research

Observation and data collection were carried out at the Communication Systems Laboratory, Department of Electrical Engineering, Faculty, Udayana University, Jimbaran and in the conference room, GDLN, Sudirman Campus, Udayana University. The research schedule plan starts from the end of May 2014 and must be completed before the end of November 2014, more details are in the Appendix.

3.2 Sources and Tjeypes of Research Data

Data sources can be grouped into 2 types:

1. Primary Data: In the form of power consumption values, memory, and time from the Imote2 WSN device.
2. Secondary Data: In the form of research schemes, device specifications, and implementation procedures of IEEE 802.15.4 Zigbee on JSVN Imote2 in image transmission.

The types of data are also grouped into 2 types:

1. Quantitative Data: Is data in the form of numbers, in this study the value of electricity, memory, and time, or the calculation of a value derived from primary data.
2. Qualitative Data: Data that is not in the form of numbers, in this study is a statement of the performance of the WSVN Imote2 device from various conditions applied. In addition, data in the form of graphics, and the implementation of IEEE 802.15.4 Zigbee in image transmission.

3.3 Research Instruments and Materials

The research instrument can be seen in Table 3.1 - Table 3.5. The Imote2 JSVN device can be seen in Figure 2.10.

The research material is an image captured from the camera sensor of the WSVN Imote2 device on May 9, 2014 at the Communication Systems Laboratory, Department of Electrical Engineering, Udayana University with the Portable Pixelmap Graphic (.ppm) format, 480 x 640 pixel resolution in Figure 3.1, with a large file size. 921.6 KB, and IEEE 802.15.4 Zigbee-based transmission media.

Figure 3.1 Research materials

3.4 Research Stages

Overall the research stage consists of 2 stages. The first stage is the procedure for implementing image transmission using IEEE 802.15.4 Zigbee transmission media on the Imote2 WSVN platform with the embedded Linux operating system. The mechanism for transmitting images is explained. The second stage is the testbed to test the performance of WSVN in image transmission. Performance is determined by the power consumption, the time required for transmission, and the amount of memory used. In general, the description of the stages can be seen in Figure 3.2.

Figure 3.2 Schematic of the basis of research

3.4.1 IEEE 802.15.4 Zigbee implementation for image transmission

Radio on Imote2 running Linux OS uses the Tosmac driver. Tosmac provides a script for transmit and receive which will be adjusted for image transmission. It can be seen as follows:

//************************************************************ // // blocking.c // // Gefan Zhang // //************************************************************* #include  #include  #include  #include  #include "tosmac.h" void msg_init(TOS_Msg* pMsg) {    pMsg->length = 0;    pMsg->fcfhi = 0;    pMsg->fcflo = 0;    pMsg->dsn = 0;    pMsg->destpan = 0;    pMsg->addr = 0;    pMsg->type = 0;    pMsg->group = 0;    memset(pMsg->data, 0, TOSH_DATA_LENGTH);    pMsg->strength = 0;    pMsg->lqi = 0;    pMsg->crc = 0;    pMsg->ack = 0;    pMsg->time = 0; } //--------------------- main ------------------------------- int main(int argc, char* argv[]) {   int tosmac_dev;   TOS_Msg recv_pkt;   TOS_Msg send_pkt;   // open as blocking mode   tosmac_dev = open(TOSMAC_DEVICE, O_RDWR);   if (tosmac_dev < 0)   {     fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE);     return 1;   }   msg_init(&send_pkt);   send_pkt.addr = 99; //  memcpy(send_pkt.data, "DATA for test", 14);   memcpy(send_pkt.data, "0000000000000", 14);   send_pkt.length = 14;   printf("User write to driver\n");    write(tosmac_dev, (TOS_Msg*)&send_pkt, sizeof(TOS_Msg));   // close device   close (tosmac_dev);   return 0; }

//************************************************************ // // blocking.c // // Gefan Zhang // //************************************************************* #include  #include  #include  #include  #include "tosmac.h" void msg_init(TOS_Msg* pMsg) {    pMsg->length = 0;    pMsg->fcfhi = 0;    pMsg->fcflo = 0;    pMsg->dsn = 0;    pMsg->destpan = 0;    pMsg->addr = 0;    pMsg->type = 0;    pMsg->group = 0;    memset(pMsg->data, 0, TOSH_DATA_LENGTH);    pMsg->strength = 0;    pMsg->crc = 0;    pMsg->lqi = 0;    pMsg->ack = 0;    pMsg->time = 0; } //--------------------- main -------------------------------  int main(int argc, char* argv[]) {   int tosmac_dev;   TOS_Msg recv_pkt;   TOS_Msg send_pkt;   // open as blocking mode   tosmac_dev = open(TOSMAC_DEVICE, O_RDWR);   if (tosmac_dev < 0)   {     fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE);     return 1;   }   printf("User read from driver:\n");   read(tosmac_dev, &recv_pkt, sizeof(TOS_Msg));// != sizeof(TOS_Msg);   printf("length is %d\n", recv_pkt.length);   printf("data is %s\n", recv_pkt.data);   // close device   close (tosmac_dev);   return 0; } 

3.4.2 Testbed

The testbed uses 2 WSVN Imote2 devices where one functions as a transmitter and the other functions as a receiver. At the transmitter, image capture is carried out with the camera sensor. At the transmitter, the image transmission to the receiver is carried out via wireless media based on IEEE 802.15.4 Zigbee. Image capture has been done in previous studies, therefore only observed in compression and transmission. There are 2 types of transmitted images, namely raw images from the capture of the IMB400 sensor and raw images processed based on the JPEG2000 standard with a ratio of 1, 5, and 10 where the ratio is the limiting of the channel capacity. A ratio of 5 means that the number of bits of the compressed image is limited to a maximum of 1/5 of the original number of bits, and a ratio of 10 means that it is limited to a maximum of 1/10 of the number of original bits.

At the time of transmission, the measurement of power consumption, memory, and time is measured at the transmitter. Measurement of electric power consumption using a multimeter with the object of measurement is the battery on the power supply board (IBB2400). The measurement of electric power is done by measuring the voltage drop and current drop, in other words, the difference in the value of electric power before and after the research. In particular, it measures the consumption of electrical power starting from the command for transmission by the computer until the image is transmitted, as well as the time consumption. The measurement of consumption starts from giving commands by the computer, not from the start of image transmission because it also involves aspects of the operating system used, namely embedded Linux. The measurement result data is from one study. Memory based on the display from the terminal when transmitter access. The transmitted image is measured by PSNR. In general, the testbed can be seen in Figure 3.3, Scenarios will be described in the following sections:

Figure 3.3 Testbed Scheme

1. Scenario 1
   • Insert images based on research materials into Imote2 (pre-store).
   • Imote2 setup.
   • Measurement of battery voltage and current before transmission.
   • Image transmission from the transmitter to the receiver with a distance of 5 meters can be seen in Figure 3.4 and Figure 3.5.
   • Measurement of virtual memory used by the transmission program.
   • Measurement of the length of time it will take for transmission.
   • Measurement of battery voltage and current after transmission.
   • Measurement of the image PSNR value.
   • The research is repeated with a distance of 10, and 15 meters can be seen in Figure 3.6 - Figure 3.9.
2. Scenario 2
   • Imote2 setup.
   • Measurement of battery voltage and current before compression.
   • Image compression is performed on the transmitter with a ratio of 1.
   • Measurement of virtual memory used by compression programs.
   • Measurement of how long it takes to compress.
   • Measurement of battery voltage and current after compression.
   • Measurement of battery voltage and current before transmission.
   • Transmission of the image from the transmitter to the receiver at a distance of 5 meters.
   • Measurement of virtual memory used by the transmission program.
   • Measurement of the length of time it will take for transmission.
   • Measurement of battery voltage and current after transmission.
   • Measurement of the PSNR value.
   • The study was repeated with a compression ratio of 5, and 10.
   • Research is repeated at distances of 10, and 15 meters.

Figure 3.4 Map of the research communication system lab with a distance of 5 meters Figure 3.5 Research communication system laboratory with a distance of 5 meters Figure 3.6 Map of a 10 meter distance research communication system lab Figure 3.7 Research communication system lab 10 meters distance Figure 3.8 Map of the research conference room with a distance of 15 meters Figure 3.9 Research conference room at a distance of 15 meters

3.5 Analysis Flow

In this section, the research stage will be described in a flowchart diagram in Figure 3.10, Figure 3.11, and Figure 3.12. The overall research is as follows:

1. Specifies the image transmission procedure.
2. Preparing raw image to Imote2 which acts as a transmitter for transmission, compression will be done in Imote2.
3. Conduct research with distances between Imote2 5, 10, and 15 meters for each raw and processed image transmission based on JPEG2000.
4. Finds the power consumption of each stage of image transmission.
5. Get the time taken for each stage and the memory used.
6. From all the data obtained, the optimal scheme is determined.

Figure 3.10 Research flow 1 Figure 3.11 Research Flow 2 Figure 3.12 Research Flow 2

Chapter 4 Discussion

Overall, this chapter discusses the image transmission program, Imote2 Linux as a testbed of the compilation of transmission programs and JPEG2000 compression software to giving commands wirelessly to Imote2 which is the sender, and the final part of this chapter is displayed and analyzed the performance of the Imote2 device. From the research results, it turns out that doing compression before transmission is very helpful to lighten the burden of transmission, and interestingly, the compression process itself does not burden the device too much, so it is highly recommended to use compression.

The point of this research is that Imote2 Linux can be used as a testbed. To summarize again, previous research has succeeded in embedding Linux into the JSVN Imote2 platform and transmitting random data, so in this study it is to transmit image data. The program code in section 3.4.1 is a program for sending character data of up to 28 bytes, then displayed on the screen. To send an image in the form of a file, the code must be modified so that the sender side can read and send the file, and on the receiving side can receive and save the file (not limited to being displayed on the screen), it must also be able to transmit files of more than 28 bytes.

The process for enabling Imote2 Linux to function as a testbed is summarized in Figure 4.1. First, making program code, more fully discussed in section 4.1. Then the program is compiled in section 4.2 and section 4.3, and embeded into Imote2, illustration can be seen in Figure 4.2. Finally, Imote2 is configured to be able to receive commands via radio, in other words, after the transmitter is turned on, ready to receive commands, it can be illustrated in Figure 4.3. Commands can be in the form of compressing, or transmitting images as illustrated in Figure 4.4. This is done because the transmitter is powered by batteries (without cables), so communication is only available via radio.

Figure 4.1 Flow diagram of testbed implementation Figure 4.2 Illustration of compiling and embedding a program   Figure 4.3 Illustration at startup     Figure 4.4 Illustration of the testbed

4.1 Transmission Program

Radio transmission on Imote2. In the previous study described in section 2.1, using the driver from Tosmac to run the radio on Imote2 Linux, here still use the same driver. For transmission, two programs are needed, namely the program for sending and receiving. Both programs are written in C language. Specifically, this research follows the provisions of the tosmac header, namely the maximum data payload sent is 28 bytes. Overall on the sender side reads the image file to be sent, the receiver will create a new file and write the received data to the file. The delivery is done in stages by breaking 28 bytes of each tile (not all at once).

4.2 Sending Program

The following syntax shows a sending program with the file name "send_file_advance.c" which was carried out in this study and is described as follows:

1 //************************************************************ 2 // 3 // blocking.c 4 // 5 // Gefan Zhang 6 // 7 //************************************************************* 8 // Modified by : Fajar Purnama 

Lines 1 - 8 are comments containing information about the programmer and the modifier. Comments can be marked with "//" or begin with "/ *" and end with "* /" (which is not bold). Line 5 is the first author of the program, while line 8 is the name of the author who modified the program.

9 #include  10 #include  11 #include  12 #include  13 #include  

Lines 9 - 13 indicate the header used in this program, the header contains the code definition used. To use the header, you can use the character "#", this character indicates the script required by the program. On line 9 there is “stdio.h” which is the basic header for all C language programs which defines the “printf” command for displaying to the screen, “while” for looping, arithmetic operations, and many others. Line 10 "fcntl.h" defines the command "open" to open a file and "close" to close and "create" to create, line 11 "unistd.h" defines the command "read" to read the file and "write" to write data to file, and line 13 "tosmac.h" sets the variable in the tosmac (radio) driver.

14 void msg_init(TOS_Msg* pMsg) 15 { 16 pMsg->length = 0; 17 pMsg->fcfhi = 0; 18 pMsg->fcflo = 0; 19 pMsg->dsn = 0; 20 pMsg->destpan = 0; 21 pMsg->addr = 0; 22 pMsg->type = 0; 23 pMsg->group = 0; 24 memset(pMsg->data, 0, TOSH_DATA_LENGTH); // 28 bytes usually 25 pMsg->strength = 0; 26 pMsg->lqi = 0; 27 pMsg->crc = 0; 28 pMsg->ack = 0; 29 pMsg->time = 0; 30 } 

Lines 14 - 30 are written in the form of the function "msg_init" which is a function to initialize the package variables such as address, group, and payload contained in the header "tosmac.h" for transmission.

Inti program “int main” dimulai dari baris 32.

31 //---Main-Program---// 32 int main(int argc, const char *argv[]){ 33 // Check Error 34 if(argv[1]==NULL){ 35 printf("Usage: ./send_file [file], example: ./send_file_advance image.ppm"); 36 return 1; 37 } 38 //sleep(10); //pause for 10 sec (give time for receiver to prepare) cross this out if not needed 39 // Declaration 40 int tosmac_dev, file, file_size, h, i, j, k; 41 //char *packet; 42 TOS_Msg recv_pkt; 43 TOS_Msg send_pkt; 44 // open as blocking mode 45 tosmac_dev = open(TOSMAC_DEVICE, O_RDWR); 46 if (tosmac_dev < 0) 47 { 48 fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE); 49 50 return 1; 51 } 52 // open file to be send 53 file = open(argv[1], O_RDWR); // open file 54 file_size = lseek(file,0,SEEK_END); // calculate filesize by going to final byte of file using lseek function from fcntl.h 55 lseek(file,0,SEEK_SET); // return to start of file 56 msg_init(&send_pkt); 57 send_pkt.addr = 99;  // Address 58 h = file_size/TOSH_DATA_LENGTH; // How much packet or times of transmission should be prepared (using div) 59 i = file_size%TOSH_DATA_LENGTH; // Remainder of "h" (using mod) 60 j = 0; 61 k = 0; 

Lines 33 - 37 contain error checks if the command entered does not match, lines 39 - 43 are part of the variable declaration, lines 44 - 51 open the radio, lines 52 - 55 open the file, and lines 56 - 61 specify packets. On line 32 "int main" there is "int argc, int argv []" so that the program can be executed by selecting the desired file "./send_file_advance argv [1]", as defined on line 53 "file = open (argv [1 ], O_RDWR) ”. If there is no input, it will show how to use the program on line 35, namely "./send_file_advance file" which is set in the statement "if (argv [1] == NULL)" line 34, and line 36 "return 1" to provide an error code on the program if the input matches the statement line 34. Line 45 "tosmac_dev = open (TOSMAC_DEVICE, O_RDWR)" is to open the radio where "TOSMAC_DEVICE" is "/dev/tosmac" as defined in "tosmac.h", "O_RDWR" so that files opened, read & write, can be seen in "fcntl.h". Line 55 "file_size = lseek (file, 0, SEEK_END)" to find the file size by going to the last bit of the file to return it to the initial bit with the code "lseek (file, 0, SEEK_SET)". Defined packets to be sent are "TOS_Msg send_pkt" (line 42) and received "TOS_Msg recv_pkt" (line 43), where "TOS_Msg" is the packet structure defined in "tosmac.h". Line 57 "send_pkt.addr = 99" specifies that the address of the sender is 99. Line 58 "h" is the number of packets by dividing the file size by the maximum data payload "TOSH_DATA_LENGTH", here is 28, while the value "i" (line 59) is the remainder of the division of "h" which is the last byte to be sent.

62 while(j+1>>>> send_pkt.data 75 send_pkt.group = 7; // Group identifier, modify this as wished 76 // writing packet to device 77 printf("User writing %d bytes to driver\n", TOSH_DATA_LENGTH);  78 // verbose  79 write(tosmac_dev, (TOS_Msg*)&send_pkt, sizeof(TOS_Msg));  75 send_pkt.group = 7; // Group identifier, modify this as wished  80 // writing to device, (TOS_Msg*)&send_pkt >>>>> tosmac_dev, & it's a pointer 81 k += TOSH_DATA_LENGTH; // accumulative payload sent 82 printf("%d bytes written\n", k); // verbose 83 // use this function if for some reason need to slow down 84 // usleep(30000); // in micro seconds 85 } 86 // Sending the last bytes 87 read(tosmac_dev, (TOS_Msg*)&recv_pkt, sizeof(TOS_Msg));   88 // Waiting for receiver to send a packet (for ACK), it will wait 89 until receiver is ready 90 read(file,send_pkt.data,i); // i = remainder  91 printf("User writing %d bytes to driver\n", i); // verbose 92 write(tosmac_dev, (TOS_Msg*)&send_pkt, i); // final sending 93 k += i; // accumulative payload sent 94 memcpy(send_pkt.data,"0S0T1O1P0",9); 95 write(tosmac_dev, (TOS_Msg*)&send_pkt, 9); 96 printf("%d bytes written, FINISH!!\n", k); // verbose 

Lines 62 - 85 are the process transmission and lines 85 - 96 are the last transmissions. The transmission process is contained in line 62 of the while loop, where files are sent every 28 bytes. Looping will stop if "j" reaches the value "h" (number of packets). Before transmission awaits information from the receiver containing the number of packets received on line 68 "read (tosmac_dev, (TOS_Msg *) & recv_pkt, sizeof (TOS_Msg))" (this code will read data received by radio "tosmac_dev" of "sizeof (TOS_Msg) "Which is then written to the pointer "&recv_pkt"). The value contained in “recv_pkt” will be entered into “j” (line 70). The arithmetic operation on “k” (line 72) converts the number of packets to the number of bytes received. After that it will go to the next byte which will be sent on line 73 "lseek (file, k, SEEK_SET)". Then On line 75, sizeof (TOS_Msg)) "(this code will write "&send_pkt "of" sizeof (TOS_Msg) "to" tosmac_dev"). After the while loop is sending the last byte "i" which is the remainder of the division of "j", the last one will send the code "0S0T1O1P0" to the receiver to notify that the transmission has ended.

97 //close device   98 close(tosmac_dev); 99 close(file);  100 return 0; 101 } 

Lines 97 - 101 radio and file closings and the end of the program, the code "close" to close the file defined in "fcntl.h".

4.1.2 Receiving Program

The following syntax shows the receiving program with the file name "recv_file_advance.c" which was carried out in the study and overall the receiving program is similar to the sending program, in other words only a slight difference can be explained as follows:

1 //************************************************************ 2 // 3 // blocking.c 4 // 5 // Gefan Zhang 6 // 7 //************************************************************* 8 // Modified by : Fajar Purnama

Lines 1 - 8 are comments containing information about the programmer and the modifier.

9 #include  10 #include  11 #include  12 #include  13 #include  

Lines 9 - 13 indicate the header used in this program, the header contains the code definition used.

14 void msg_init(TOS_Msg* pMsg) 15 { 16 pMsg->length = 0; 17 pMsg->fcfhi = 0; 18 pMsg->fcflo = 0; 19 pMsg->dsn = 0; 20 pMsg->destpan = 0; 21 pMsg->addr = 0; 22 pMsg->type = 0; 23 pMsg->group = 0; 24 memset(pMsg->data, 0, TOSH_DATA_LENGTH); // 28 bytes usually 25 pMsg->strength = 0; 26 pMsg->lqi = 0; 27 pMsg->crc = 0; 28 pMsg->ack = 0; 29 pMsg->time = 0; 30 } 

Lines 14 - 30 are functions for initializing the variables in the packet to be transmitted.

The core of the program starts at line 32.

31 //--------------------- main ------------------------------- 32 int main(int argc, const char *argv[]) { 33 // Check Error 34 if(argv[1]==NULL){ 35 printf("Usage: ./recv_file [file], example: ./recv_file_advance image.ppm"); 36 return 1; 37 } 

Lines 33 - 37 contain error checks if the command entered does not match.

38 // Declaration 39 int tosmac_dev, file, i; 40 TOS_Msg recv_pkt; 41 TOS_Msg send_pkt; 

Lines 38 - 41 are part of the variable declaration.

42 // open as blocking mode 43 tosmac_dev = open(TOSMAC_DEVICE, O_RDWR); // TOSMAC_DEVICE = /dev/tosmac, O_RDWR = Open as Read & Write 44 // Check Error45 if (tosmac_dev < 0) 46 { 47 fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE); 48 49 return 1; 50 51 } 

Lines 42 - 49 open the radio.

50 // file 51 file = open(argv[1], O_RDWR); 52 // Check Error 53 if(file<0){ 54 creat(argv[1], O_RDWR); // create empty file, argv[1] if no file exist: user input (./recv_file argv[1])  55 file = open(argv[1], O_RDWR); // Open created file 56 } 

Lines 50 - 56 open the file in this section if no file is found it will create a new file with the "creat" function line 54.

57 // receving file 58 printf("User read from driver:\n"); 59 // receive 28 bytes of file for infinity     60 while(1){ 61 // Seek to end of file to continue receive (this feature allows continueable download) 62 i = lseek(file,0,SEEK_END); 63 send_pkt.data[1] = (i/TOSH_DATA_LENGTH)-3000; // Since the max value of data type is 3000 we start from -3000, so we could put a number up to 6000, This feature request tells the transmitter how much bytes already received so the transmitter will sinchronize. 64 write(tosmac_dev, (TOS_Msg*)&send_pkt, sizeof(TOS_Msg)); // sending i in send_pkt.data[1] 65 alarm(2); // 2  seconds timeout  66 read(tosmac_dev, (TOS_Msg*)&recv_pkt, sizeof(TOS_Msg)); // Read receive file from Tosmac Device, Pause if device == NULL, !=sizeof(TOS_Msg) 67 // Stop code, break infinite while loop if this code is received, send application should send this string to tell if transmission finish  68 if(strncmp(recv_pkt.data,"0S0T1O1P0",9)==0){  69 break; 70 } 71 // Use group as identifier, so it will not process packet if it is not on this group 72 if(recv_pkt.group!=7){ 73 continue; // it will ignore next code and restart while loop 74 } 75 // Verbose, shows accumulative received number of bytes 76 printf("Receiving %d bytes of data\n", recv_pkt.length); 77 i += recv_pkt.length; // Equal to i = i + recv_pkt.length 78 printf("Received %d bytes\n", i); 79 // Writing received 28 bytes to file that had just been created 80 write(file, recv_pkt.data, recv_pkt.length); // write will automatically go to last byte order of file 81 } 

Lines 60 - 81 represent the transmission process. In the process of transmitting in an infinite while loop, initially read the number of bytes that have been received by the file (file size) on line 62 "lseek (file, 0, SEEK_END)" and at the same time go to the end of the file. On line 63 the file size is entered into "send_pkt.data [1]" and on line 64 it is sent to the transmitter to tell which bytes should be sent. In this program the value starts from -3000 in order to determine a larger value because the maximum value is approximately 3000 while the value that needs to be sent is more than 3000. To do this there needs to be a change to "tosmac.h" in the packet definition section in the section . For this program the data type "data" changes from "s8" to "s16", the change is to increase the number of bits used. If this is set the maximum value in "send_pkt.data [1]" is only below 1000. All this is done so that the transmission can be resumed if it breaks and suppresses errors. This program is filled with "alarm (2)" on line 65, meaning the program will stop (time out) if 1 while loop exceeds 2 seconds. If this occurs the transmission can be resumed by running the program again showing the same file. Another difference is on line 72 "if (send_pkt.group =! 7) {continue;}" which means if the packet received is not a group 7 to ignore and continue to the next loop. In line 68 "if (strncmp (recv_pkt.data," 0S0T1O1P0 ", 9) == 0) {break;}" means if the received string is "0S0T1O1P0" and the number of characters is "9" then break the while loop, it is determined that the string this is a sign that the transmission has ended.

82 printf("FINISH!!"); 83 // closing device and file 84 close (tosmac_dev); 85 close(file); 86 return 0; 87 }

Lines 82 - 87 close radio and file and end of program.

4.2 Openjpeg Compilation

This section contains ways to compile the Openjpeg-1.5.1 software onto Imote2-Linux, in order to make the compression software available on the device. The compiler used is linux-gcc-4.1.2-arm-xscale-linux-gnu-glibc-2.3.3 with dependencies lcms2, libpng, and zlib, for here lcms2-2.6, libpng-1.2.51, and zlib-1.2.8.

The source obtained is compressed in gunzip tape archive format. The following command to extract the compressed file contents:

Lines 60 - 81 represent the transmission process. In the process of transmitting in an infinite while loop, initially read the number of bytes that have been received by the file (file size) on line 62 "lseek (file, 0, SEEK_END)" and at the same time go to the end of the file. On line 63 the file size is entered into "send_pkt.data [1]" and on line 64 it is sent to the transmitter to tell which bytes should be sent. In this program the value starts from -3000 in order to determine a larger value because the maximum value is approximately 3000 while the value that needs to be sent is more than 3000. To do this there needs to be a change to "tosmac.h" in the packet definition section in the section. For this program the data type "data" changes from "s8" to "s16", the change is to increase the number of bits used. If this is set the maximum value in "send_pkt.data [1]" is only below 1000. All this is done so that the transmission can be resumed if it breaks and suppresses errors. This program is filled with "alarm (2)" on line 65, meaning the program will stop (time out) if 1 while loop exceeds 2 seconds. If this occurs the transmission can be resumed by running the program again showing the same file. Another difference is on line 72 "if (send_pkt.group =! 7) {continue;}" which means if the packet received is not a group 7 to ignore and continue to the next loop. In line 68 "if (strncmp (recv_pkt.data," 0S0T1O1P0 ", 9) == 0) {break;}" means if the received string is "0S0T1O1P0" and the number of characters is "9" then break the while loop, it is determined that the string this is a sign that the transmission has ended.

tar xfv linux-gcc-4.1.2-arm-xscale-linux-gnu-glibc-2.3.3.tgz tar xfv openjpeg-1.5.1.tar.gz tar xfv zlib-1.2.8.tar.gz tar xfv lcms2-2.6.tar.gz tar xfv libpng-1.2.51.tar.gz 

The following command adds the location of the compiler executable file:

export PATH=/[lokasi folder]/arm-xscale-Linux-gnu/bin/:$PATH

The first additional dependencies requested are lcms2.

cd /[lokasi folder]/lcms2-2.6 export CROSS-PREFIX=/[lokasi folder]/arm-xscale-linux-gnu/arm-xscale-linux-gnu/ ./configure --prefix=/[lokasi folder]/arm-xscale-Linux-gnu/arm-xscale-Linux-gnu/ --host=arm-xscale-linux-gnu make && make install 

Command "cd" to go to the folder, "export" to assign a value to a variable, here "CROSS-PREFIX" is defined in the "configure" file on zlib, if compiled for cross-compiler it is given the value of the cross-compiler location. In the file "configure" there is a series of configuration, when executed will be created "Makefile" to compile as needed. Command "--prefix" to add the installation location. Command "make" to compile based on files "Makefile" and "make install" to put the compilation into place according to "--prefix". Next compile zlib for the compiler:

cd /[lokasi folder]/zlib-1.2.8 CC=arm-xscale-linux-gnu-gcc prefix=/[lokasi folder]/arm-xscale-Linux-gnu/arm-xscale-Linux-gnu/ CFLAGS=”-04” ./configure --shared make && make install 

In this research, we need the command "--shared" so that it can be detected by "libpng" during configuration. After that compile libpng:

cd /[lokasi folder]/libpng-1.2.51 ./configure --prefix=/[lokasi folder]/arm-xscale-linux-gnu/arm-xscale-linux-gnu/ --host=arm-xscale-linux-gnu make && make install 

Command "cd" to go to the folder, "export" to assign a value to a variable, here "CROSS-PREFIX" is defined in the "configure" file on zlib, if compiled for cross-compiler it is given the value of the cross-compiler location. In the file "configure" there is a series of configuration, when executed will be created "Makefile" to compile as needed. Command "--prefix" to add the installation location. Command "make" to compile based on files "Makefile" and "make install" to put the compilation into place according to "--prefix". Next compile zlib for the compiler:

cd /[lokasi folder]/zlib-1.2.8 CC=arm-xscale-linux-gnu-gcc prefix=/[lokasi folder]/arm-xscale-Linux-gnu/arm-xscale-Linux-gnu/ CFLAGS=”-04” ./configure --shared make && make install 

In this research, we need the command "--shared" so that it can be detected by "libpng" during configuration. After that compile libpng:

cd /[lokasi folder]/libpng-1.2.51 ./configure --prefix=/[lokasi folder]/arm-xscale-linux-gnu/arm-xscale-linux-gnu/ --host=arm-xscale-linux-gnu make && make install 

Based on the file "configure" "--host" determines the type of compilation platform, here is "arm-xscale-linux-gnu", it is necessary to "export" the cross-compiler executable location at the beginning of this section. Lastly is the Openjpeg compilation:

cd openjpeg-1.5.1 ./configure --prefix=/[lokasi folder]/[lokasi folder bebas]/ --host=arm-xscale-Linux-gnu --enable-jpwl --enable-debug --disable-tiff make && make install

4.3 Testbed Implementation

Overall, this section contains the transmission process for this study. Initially including the transmission program and Openjpeg so that in essence the device can transmit on a battery or without being connected to a computer.

4.4 Command Program

Here there are additional programs, apart from using the "recv" program, 2 additional programs are needed, namely a program to send commands and a program to receive commands. The program sending the command "send_command.c" is as follows:

1 //************************************************************ 2 // 3 // blocking.c 4 // 5 // Gefan Zhang 6 // 7 //************************************************************* 8 // Modified by Fajar Purnama 9 /* Only Difference from original send.c is an addition of arguement (argc, argv) we could send any message we want without changing its source code for example sending hello message just type ./send_command hello */ 10 #include  11 #include  12 #include  13 #include  14 #include  15 void msg_init(TOS_Msg* pMsg) { 16 pMsg->length = 0; 17 pMsg->fcfhi = 0; 18 pMsg->fcflo = 0;19 pMsg->dsn = 0; 20 pMsg->destpan = 0; 21 pMsg->addr = 0; 22 pMsg->type = 0; 23 pMsg->group = 0; 24 memset(pMsg->data, 0, TOSH_DATA_LENGTH); 25 pMsg->strength = 0; 26 pMsg->lqi = 0; 27 pMsg->crc = 0; 28 pMsg->ack = 0; 29 pMsg->time = 0; 30 } 31 //--------------------- main ------------------------------- 32 int main(int argc, const char *argv[]) { 33 if(argv[1]==NULL){ 34 printf("Usage: ./send_command [message], example ./send_command reboot, ./send_command hello\n"); 35 return 1; 36 } 37 int tosmac_dev; 38 TOS_Msg recv_pkt; 39 TOS_Msg send_pkt; 40 // open as blocking mode 41 tosmac_dev = open(TOSMAC_DEVICE, O_RDWR); 42 if (tosmac_dev < 0) 43 { 44 fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE); 45 return 1; 46 } 47 msg_init(&send_pkt); 48 send_pkt.addr = 99; 49 memcpy(send_pkt.data, argv[1], TOSH_DATA_LENGTH); 50 send_pkt.length = TOSH_DATA_LENGTH; 51 printf("User write to driver\n");  52 write(tosmac_dev, (TOS_Msg*)&send_pkt, sizeof(TOS_Msg)); 53close(tosmac_dev); 54 return 0; 55 }

The entire description of the command-sending program is the same as that of the transmission program. In particular, what is different in this program is on line 49 where the characters to be written to "send_pkt.data", namely "argv [1]" will be sent. This program is limited to sending characters up to 28 bytes. Here is the program for receiving the command "recv_command.c":

1 //************************************************************ 2 // 3 // blocking.c 4 // 5 // Gefan Zhang 6 // 7 //************************************************************* 8 // Modified by Fajar Purnama 9 /* The only difference is system() function is added from stdlib.h so the message received will be proccess as a command with this code still limited to 28 bytes. Example of message receive is recv_pkt.data = "reboot", it will be system("reboot"), and it will reboot the system */ 10 #include  11 #include  12 #include  13 #include  14 #include  15 #include  16 void msg_init(TOS_Msg* pMsg) 17 { 18 pMsg->length = 0; 19 pMsg->fcfhi = 0; 20 pMsg->fcflo = 0; 21 pMsg->dsn = 0; 22 pMsg->destpan = 0; 23 pMsg->addr = 0; 24 pMsg->type = 0; 25 pMsg->group = 0; 26 memset(pMsg->data, 0, TOSH_DATA_LENGTH); 27 pMsg->strength = 0; 28 pMsg->crc = 0; 29 pMsg->lqi = 0; 30 pMsg->ack = 0; 31 pMsg->time = 0; 32 } 33 //--------------------- main ------------------------------- 34 int main(int argc, char* argv[]) 35 { 36 int tosmac_dev; 37 TOS_Msg recv_pkt; 38 TOS_Msg send_pkt; 39 // open as blocking mode 40 tosmac_dev = open(TOSMAC_DEVICE, O_RDWR); 41 if (tosmac_dev < 0) 42 { 43 fprintf(stderr, "Open error: %s\n", TOSMAC_DEVICE); 44 return 1; 45 } 46 printf("User read from driver:\n");   47 read(tosmac_dev, &recv_pkt, sizeof(TOS_Msg));// != sizeof(TOS_Msg); 48 printf("data is %s\n", recv_pkt.data); 49 system(recv_pkt.data);// Process recv_pkt.data as a command in terminal 50 // close device 51 close (tosmac_dev); 52 return 0; 53 } 

The overall description of the receiving program is the same as the description of the transmission program. In particular, what is different about this program is that on line 49 the received characters contained in "recv_pkt.data" will be treated as commands. This is made possible by the “system” function defined in “stdlib.h”.

4.3.2 Program Placement

After the program code is finished, the code is compiled using “arm-xscale-linux-gnu-gcc”.

export PATH=/[lokasi folder]/arm-xscale-Linux-gnu/bin/:$PATH (jika belum) cd /[lokasi folder program] arm-xscale-linux-gnu-gcc -Wall send.c -o send  arm-xscale-linux-gnu-gcc -Wall recv.c -o recv arm-xscale-linux-gnu-gcc -Wall send_command.c -o send_command  arm-xscale-linux-gnu-gcc -Wall recv_command.c -o recv_command  arm-xscale-linux-gnu-gcc -Wall send_file_advance.c -o  send_file_advance  arm-xscale-linux-gnu-gcc -Wall recv_file_advance.c -o  recv_file_advance  

Then placed in Imote2 in the directory "/root/transmit". The receiver is connected on USB0 with an IP address on the computer 192.168.98.100 and on Imote2 192.168.98.101. The transmitter is connected on USB1 with an IP address on the computer 192.168.99.100 and on Imote2 192.168.99.102. The connection between Imote2 uses SSH (secure shell) which has been prepared in previous studies as described in Chapter 2 section 2.1. Before placing the directory first.

ssh 192.168.98.101 mkdir /root/transmit && mkdir /root/command && mkdir /root/image quit && exit ssh 192.168.99.102 mkdir /root/transmit && mkdir /root/command && mkdir /root/image quit && exit  

Command "mkdir" (make directory) to create a new folder. For this research, the raw image (Figure 3.1) is contained in the directory "/root/image" under the name "1.ppm". When the directory is ready then the program is entered, as well as the compiled Openjpeg.

cd /[lokasi program] scp * [email protected]:transmit/ && scp *  [email protected]:transmit/ cd /[lokasi folder openjpeg] scp -r [folder openjpeg] [email protected]: scp -r [folder openjpeg] [email protected]: 

SCP is a command to copy data via SSH, "*" indicates all files in that folder, "-r" to copy a directory. Next, the compiled Openjpeg will be placed in the appropriate directory.

ssh 192.168.99.102 cd /[lokasi folder openjpeg] cd bin && mv * /bin  cd ../include && mkdir /usr/include && mv * /usr/include cd ../lib && mv * /lib cd ../share && mv man /usr/share && mv /doc/* /usr/share/doc quit && exit ssh 192.168.98.101 cd /[openjpeg folder location] cd bin && mv * /bin  cd ../include && mkdir /usr/include && mv * /usr/include cd ../lib && mv * /lib cd ../share && mv man /usr/share && mv /doc/* /usr/share/doc quit && exit 

To facilitate transmission several commands are prepared in the form of a file as follows:

1. The following contains the command for sending a raw image with the file name "A":

   #!/bin/bash /root/transmit/send_file_advance /root/image/1.ppm

2. The following contains commands for compressing raw images to JPEG2000 format with a ratio of 1 with the file name "B":

   #!/bin/bash image_to_j2k -i /root/image/1.ppm -r 1 -o /root/image/1r1.j2k /root/transmit/send_command Finish!! 

3. The following contains the command for sending a ratio 1 JPEG2000 image with the file name “C”:

   #!/bin/bash /root/transmit/send_file_advance /root/image/1r1.j2k 

4. The following contains commands for compressing raw images to JPEG2000 format with a ratio of 5 with the file name "D":

   #!/bin/bash image_to_j2k -i /root/image/1.ppm -r 5 -o /root/image/1r5.j2k /root/transmit/send_command Finish!! 

5. The following contains the command for sending a 5 ratio JPEG2000 image with the file name “E”:

   #!/bin/bash /root/transmit/send_file_advance /root/image/1r5.j2k 

6. The following contains commands for compressing raw images to JPEG2000 format at a ratio of 10 with the file name "F":

   #!/bin/bash image_to_j2k -i /root/image/1.ppm -r 1 -o /root/image/1r10.j2k /root/transmit/send_command Finish!! 

7. The following contains the command for sending a 10 ratio JPEG2000 image with the file name “G”:

   #!/bin/bash /root/transmit/send_file_advance /root/image/1r10.j2k 

8. For files "B", "D", "F", after compression will send the characters "Finish !!" to notify the receiver that compression is complete.

Files from the table above will be placed in the directory “/root/command”.

cd /[command file location] scp * [email protected]:command/  scp * [email protected]:command/ 

4.3.3 Startup Configuration

The final step for implementing the testbed is for the two Imote2 to be powered on to prepare the Tosmac driver for the radio and the transmitter when turned on is always ready to receive commands from the receiver. This study uses a radio that has been prepared in previous studies. To do this put 2 startup files in "/etc/rc2.d/". File "S12loadtosmac" for radio and file "S14infloop" for receiving commands continuously. Figure 4.1 is an example when sending a "poweroff" command to turn off the device and Figure 4.2 is an example of transmission.

#!/bin/sh insmod /lib/modules/2.6.29.1_r1.1/kernel/arch/arm/mach-pxa/ssp.ko insmod /lib/modules/2.6.29.1_r1.1/kernel/drivers/tosmac/tos_mac.ko mknod /dev/tosmac c 240 0 

while (true) do /root/transmit/recv_command Done 

Figure 4.5 Example of giving the poweroff command Figure 4.6 Example of transmission

4.3.4 Testbed Usage

To perform uncompressed and compressed image transmission as follows:

/root/transmit/send_command /root/command/A (raw image transmission) /root/transmit/recv_file_advance /root/image/[output image name].ppm /root/transmit/send_command /root/command/B (rasio 1 compression) /root/transmit/recv (wait for compression completion notification) /root/transmit/send_command /root/command/C (rasio 1 image transmission) /root/transmit/recv_file_advance /root/image/[output image name].j2k /root/transmit/send_command /root/command/D (kompresi rasio 5) /root/transmit/recv (wait for compression completion notification) /root/transmit/send_command /root/command/E (rasio 5 image transmission) /root/transmit/recv_file_advance /root/image/[output image name].j2k /root/transmit/send_command /root/command/F (rasio 10 image transmission) /root/transmit/recv (wait for compression completion notification) /root/transmit/send_command /root/command/G(transmisi citra rasio 10) /root/transmit/recv_file_advance /root/image/[output image name].j2k

PSNR measurement using ImageMagick software. An image compressed with .j2k format is returned to the .ppm format with the original file size. The commands are as follows:

j2k_to_image -i [image .j2k] -o [image name .ppm] compare -metric PSNR [original image] [compared image] [image output measurement]  

Memory can be seen while the application is running with the command:

ps (can be seen the application process number) cat /proc/[application proccess number]/status  

4.4 Data Analysis

In this section we will analyze the results of research data in the form of consumption of electrical power, memory, and time in each transmission process, and also display the PSNR value of the image that has been sent. If we summarize again, the transmission process includes uncompressed and compressed image transmission based on the JPEG2000 standard with OpenJPEG 1.5.2 software ratios 1, 5, and 10, carried out at a distance of 5m, 10m, and 15m.

4.4.1 Electric Power Consumption

Overall, the results of the research data indicate that compression has a strong effect on transmission. To get the details of the electric power consumption, this study carried out the transmission process at a distance of 5 meters, 10 meters, and 15 meters respectively.

Figure 4.7 Consumption of 5 meter power supply

Figure 4.7 shows the power consumption of the transmission line at a distance of 5 meters. The stress consumption decreases constantly with the applied compression ratio. The difference in power consumption is only transmitted uncompressed images with a more efficient compressed 17 mV for a ratio of 1.37 mV and 44 mV for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference in power consumption as a whole uncompressed and uncompressed image saves 2 mV for a ratio of 1.27 mV and 36 mV for a ratio of 5 and a ratio of 10.

Figure 4.8 Power consumption of 10 meters

Figure 4.8 shows the power consumption of a transmission line at a distance of 10 meters. The stress consumption decreases constantly with the applied compression ratio. The difference in power consumption is only transmitted uncompressed images with a more efficient compressed 18 mV for a ratio of 1, 1.36 mV and 45 mV for a ratio of 5 and a ratio of 10. If compression consumption is involved, consumption while compression is still more efficient. The difference in power consumption as a whole uncompressed and compressed image, saves 2 mV for a ratio of 1.24 mV and 35 mV for a ratio of 5 and a ratio of 10.

Figure 4.9 Power consumption of 15 meters

Figure 4.9 shows the power consumption of a transmission line at a distance of 15 meters. The stress consumption decreases constantly with the applied compression ratio. The difference in power consumption is only transmitted uncompressed images with a more efficient compressed 17 mV for a ratio of 1.35 mV and 45 mV for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference in power consumption as a whole uncompressed and compressed image is the same for the ratio 1, 21 mV and 34 mV for the ratio 5 and the ratio 10.

Figure 4.10 Current consumption of 5 meters

Figure 4.10 shows the current consumption of a transmission power at a distance of 5 meters. The consumption of electric current decreases with the applied compression ratio. The difference in electric current consumption is only transmitted uncompressed images with a more efficient 4.2 mA for a ratio of 1, 4.6 mA and 5.4 mA for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference between the overall consumption of uncompressed and uncompressed images is more efficient 2.8 mA for a ratio of 1, 3.3 mA and 4.3 mA for a ratio of 5 and a ratio of 10.

Figure 4.11 Electric current consumption of 10 meters

Figure 4.11 shows the current consumption of a transmission power at a distance of 10 meters. The consumption of electric current decreases with the applied compression ratio. The difference in electric current consumption is only transmitted uncompressed images with a more efficient 4.7 mA for a ratio of 1, 4.7 mA and 5.8 mA for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference between the overall consumption of uncompressed and compressed images is more efficient 3.2 mA for a ratio of 1, 3.3 mA and 4.6 mA for a ratio of 5 and a ratio of 10.

Figure 4.12 Electric current consumption of 15 meters

Figure 4.12 shows the current consumption of a transmission power at a distance of 15 meters. The consumption of electric current decreases with the applied compression ratio. The difference in electric current consumption between uncompressed and compressed images with a more efficient 4.4 mA for a ratio of 1, 5.2 mA and 6 mA for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference in electric current consumption as a whole uncompressed and compressed images is more efficient 2.7 mA for a ratio of 1, 3.7 mA and 4.6 mA for a ratio of 5 and a ratio of 10.

Figure 4.13 Electric power consumption of 5 meters

Figure 4.13 shows the power consumption of transmission electricity at a distance of 5 meters. The power consumption decreases drastically with respect to the compression ratio applied. The difference in power consumption between uncompressed and compress images are more efficient 268.4 mW for a ratio of 1, 319.6 mW and 341 mW for a ratio of 5 and a ratio of 10. If it is involved consumption while compression is still more efficient. The difference between the overall consumption of uncompressed and compressed images is 161.2 mW for a ratio of 1,265.2 mW and 312.1 mW for a ratio of 5 and a ratio of 10.meter.

Figure 4.14 Power consumption of 10 meters

Figure 4.14 shows the power consumption of a transmission at a distance of 10 meters. The power consumption decreases drastically with respect to the compression ratio applied. The difference in power consumption is more efficient compressed 314 mW for a ratio of 1, 355.4 mW and 390.4 mW for a ratio of 5 and a ratio of 10. If it involves consumption while compression is still more efficient. The difference between the overall consumption of uncompressed and compressed images is 193.2 mW for a ratio of 1, 280.2 mW and 350.8 mW for a ratio of 5 and a ratio of 10.

Figure 4.15 Power consumption of 15 meters

Figure 4.15 shows the power consumption of a transmission at a distance of 15 meters. The power consumption decreases drastically with respect to the compression ratio applied. The difference in power consumption is more efficient compressed 318.4 mW for a ratio of 1, 396 mW and 432 mW for a ratio of 5 and a ratio of 10. If it involves consumption while compression is still more efficient. The difference between the overall consumption of uncompressed and compressed images is 162 mW more efficient for a ratio of 1, 303.9 mW and 378 mW for a ratio of 5 and a ratio of 10.

From Figure 4.7 - Figure 4.15 it can be concluded that in terms of power consumption and compression processing time is very low but it can significantly reduce the transmission load so it is highly recommended to use it. By applying a higher compression ratio, it will reduce the current and voltage consumption when the automatic transmission of the electric power consumed is lower. Also as the compression ratio increases, the current consumption and the power supply voltage decreases so that it is ensured that increasing the compression ratio will lighten the transmission load. The farther the transmission distance, the greater the power consumption, but the difference between the distances of 5 meters, 10 meters and 15 meters is not significant.

4.4.2 Transmission Processing Time

Apart from the consumption of electric power, from a time perspective there is also a drastic effect of compression, but there is almost no visible effect in terms of distances of 5 meters, 10 meters, and 15 meters. Figure 4.16 shows the time required for compression and transmission, while Figure 4.17 represents the overall time required which is a combination of compression and transmission.

Figure 4.16 Time consumption of compression and transmission

Figure 4.16 shows that compression takes a very short time and very lowers the time required for transmission. The greater the compression ratio that is applied, the smaller the transmission time. The compression time will take 25-30 seconds. The transmission time is getting smaller from raw image to compressed image with ratio of 10 with a value of about 10 minutes 30 seconds, 5 minutes, 2 minutes, and 1 minute.

Figure 4.17 Overall time consumption

Overall from a distance perspective it doesn't seem to matter but compression, which plays a role in shortening the transmission time. An image that is compressed with a ratio of 10 takes an overall time of 1 minute 30 seconds, a ratio of 5 2 minutes 30 seconds, a ratio of 1 4 minutes 30 seconds, and 10 minutes for an uncompressed image.

4.4.3 Image Quality

In terms of time, it is also seen in terms of image quality using the PSNR size.

Figure 4.18 PSNR image after transmission process

Figure 4.18 shows the uncompressed PSNR image after transmission at a distance of 5 meters, 10 meters, 15 meters. The ratio of 10 both of 5 meters, 10 meters and 15 meters has the same PSNR of 40.6536, similarly to the ratio of 5 around the value of 43.8. The effect of distance is seen in ratio 1 and without compression, for ratio 1 the PSNR value is around 35 for 5 meters and 10 meters, and drops significantly at 15 meters with a PSNR value of 24.7041. The effect of distance can be seen in the image without compression, for ratios 5 and 10, the effect of distance is not visible. In the image without compression, the PSNR value decreases with the farther distance, 5 meters, 10 meters, and 15 meters, respectively, is 38.8494, 30.4678, 38.3421.

So it can be concluded that ratio 1 has the worst quality after uncompressed image, while ratio 10 has promising quality, and ratio 5 shows the best quality. From the viewpoint, the image with PSNR below 40 dB looks clearly not like the original. The cause is a transmission error.

4.4.4 File Size and Memory

Figure 4.19 Comparison of the maximum use of virtual memory

Figure 4.19 shows the maximum virtual memory used, and the most widely used during compression. For compression using a maximum of 14548 kB of virtual memory and sending using 1256 kB at the transmitter, the receiver uses a maximum of 2336 kB of virtual memory for reception.

Figure 4.20 Image file size

Figure 4.20 shows the uncompressed and uncompressed image file size, the file size decreases by applying a larger ratio. The file size for the uncompressed image is 921.6 kB, the ratio 1 429.9 kB, the ratio 5 184.2 kB, and the ratio 10 91.7 kB. In terms of image quality, the original image and the compressed ratio of 1 have lower PSNR than other images, and it can be seen from the image that there is a transmission error. Then the larger the file size, the more sensitive it is to errors.

Chapter 5 Closing

5.1 Conclusion

From this overall research, it can be concluded as follows:

1. The implementation of the OpenJPEG codec on the Imote2 Linux embedded system is compiled with arm-xscale-linux-gnu, jpwl enabled and tiff disabled, and additional dependencies are required, namely lcms2, zlib, and libpng.
2. Imote2 Linux embedded system image transmission implementation mechanism requires a program written in C language with the required function file delivery features, including "creat", "open", "close", "read", and "write". The solution for a buffer that is finite is a maximum of 28 bytes, so the transmission is incremental so that the looping function is implemented. For the purposes of the testbed, a command-sending and command-receiving program was created, with the sending program as sending characters, and the receiving program as receiving characters, adding the function "system" so that these characters are treated as commands, then activated at startup.
3. This research has succeeded in transmitting images, transmitting images on the Imote2 Linux embedded system where the image is captured without compression resulting in an image file size of 921.615 kB, at a distance of 5 meters to 15 meters consuming electrical power between 350 mW - 450 mW, takes between 10 minutes - 15 minutes, with 2000 kB of memory for each transmission.
4. The application of the JPEG2000 scheme to the image in the transmission process greatly eases the transmission burden in terms of electrical power and transmission time. Image transmission with a distance of 5 meters to 15 meters produces, for a ratio of 1 consumes 191 mW - 294 mW of power with a transmission time of about 5 minutes, a ratio of 5 consumes 87 mW - 152 mW of power with a transmission time of about 2 minutes, and a ratio of 10 consumes power supply 40 mW - 78 mW with a transmission time of 1 minute 30 seconds.
5. In terms of image quality, it shows good performance at a ratio of 5 and a ratio of 10. The main cause is the file size, where the larger the file size the greater the transmission time, thus increasing the chance of bit error transmission.

5.2 Future Work

By successfully transmitting images to Imote2 Linux, this tool can be used for both fieldwork and further research. The following are suggestions for further research:

1. In this study, transmission control is still minimal, so furthermore, a transmission system can be developed that applies error and flow control from the data communication field.
2. The transmission is limited to point-to-point (between devices), so multi-hop transmission should be applied.
3. Technical research for operating Imote2 Linux is still via the command-line, it is recommended to create a graphical user interface (GUI) version of the operation for easy use and research.
4. The transmission distances in this study are 5 meters, 10 meters, and 15 meters, the distance can still be varied according to the datasheet up to a maximum of 100 meters.
5. Image compression can be varied from features of the JPEG2000 to applying other image compression standards, further to video.
6. Multimedia Sensor Board IMB400 also has a sound sensor that has not been touched in this study, when combined with video it can be developed into an audio-video monitoring environment.
7. If multi-hop and audio-video can be applied then it can be continued with the next research, namely distributed audio-video streaming on embedded systems.

Image

Figure 1. Original image Figure 2. Uncompressed image after 5 meter transmission Figure 3. Uncompressed image after 10 meter transmission Figure 4. Uncompressed image after 15 meter transmission Figure 5. Compressed image of 1 ratio after 5 meter transmission Figure 6. Compressed image ratio 1 after 10 meter transmission Figure 7. Compressed image ratio 1 after 15 meter transmission Figure 8. Image compressed ratio of 5 after 5 meter transmission Figure 9. Compressed image of 5 ratio after 10 meter transmission Figure 10. Compressed image of 5 ratio after 15 meter transmission Figure 11. Compressed image ratio of 10 after 5 meter transmission Figure 12. Compressed image ratio of 10 after 10 meter transmission Figure 13. Compressed image ratio of 10 after 15 meter transmission

Bibliography

• Ahmad, A. 2005. Wireless and Mobile Data Networks. New Jersey : John Wiley & Sons Ltd.
• Akyildiz, I, F. Vuran, M, C. 2010. Wireless Sensor Networks. Chichester : John Wiley & Sons Ltd.
• Boliek, M. Christopoulos, C. Majani, Eric. 16 Maret 2000. JPEG 2000 Part I Final Committee Draft Version 1.0. ISO/IEC FCD15444-1 : 2000.
• Daintree Network, Inc. 2006. Understanding the ZigBee Application Framework. Daintree Networks Inc. http://www.daintree.net/downloads/whitepapers/understanding_application_framework_whitepaper.pdf. Diakses: 27 Januari 2014.
• Ergen, S, C. 10 September 2004. ZigBee/IEEE 802.15.4 Summary. http://staff.ustc.edu.cn/~ustcsse/papers/SR10.ZigBee.pdf. Diakses: 27 Januari 2014.
• Garcia-Sanchez, A. Garcia-Sanches, F. Losilla, F. Kulakowski, P. Garcia-Haro, J. Rodriguez, A. Lopez-Bao, J. Palomares, F. 3 Agustus 2010. Wireless Sensor Network Deployment for Monitoring Wildlife Passage. mdpi.com., hal. 7236-7262.
• Irwin, J, D. 1993. Basic Engineering Circuit Analysis Fourth Edition. New York : Macmillan Publishing Company.
• Karthikeyan, A. Shankar, T. Srividhya, V. Sarkar, S. Gupte, A. 20 Januari 2013. Energi Efficient Distributed Image Compression Using JPEG2000 in Wireless Sensor Networks (WSNs). Journal of Theorical and Applied Information Technology, vol. 47, no. 2, hal.860-869. http://www.jatit.org. Diakses: 14 Oktober 2013.
• Kasteleiner, J. 2010. “Principles of applying Embedded Linux on Imote2” (Diploma Thesis). Faculty of Computer Science and Engineering, University of Applied Sciences Frankfurt am Main.
• Mowafi, M. Awad, F. Taqieddin, E. Banimelhem, O. 25-27 April 2011. Experimental Evaluation of Image Compression and Transmission for TinyOS-Based Imote2 Platform. International Conference on Innovations in Information Technology, Abu Dhabi, hal.173-178. http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5893811&url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fstamp.jsp%3Ftp%3D%26arnumber%3D5893811. Diakses: 25 September 2013.
• Mowafi, M. Awad, F. Taqieddin, E. Banimelhem, O. 4 April 2012. A Practical Study of Jointly Exploiting Multiple Image Compression Technique for Wireless Multimedia Sensor Networks. Journal of Communication, vol. 7, no. 4, hal. 309-320. http://www.jocm.us. Diakses: 25 September 2013.
• Nasri, M. Helali, A. Sghaier, H. Maaref, H. 23-25 Maret 2010. Adaptive image transfer for wireless sensor networks (WSNs). 2010 International Conference on Design & Technology of Integrated Systems in Nanoscale Era, Hammamet, hal. 1-7. http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5487597&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5487597. Diakses: 14 Oktober 2013.
• Natha, F, S. 2012. "Performasi Platform Imote2 Menggunakan Standar 802.11 pada Jaringan Sensor Nirkabel" (Tugas Akhir), Denpasar : Jurusan Teknik Elektro., Universitas Udayana.
• Pekhteryev, G. Sahinoglu, Z. Orlik, P. Bhati, G. Mei 2005. Image Transmission over IEEE 802.15.4 and ZigBee Networks. IEEE ISCAS, Kobe. http://www.merl.com/publications/docs/TR2005-030.pdf. Diakses: 27 Maret 2014.
• Purnama, F. Widyantara, I, M, O. Sastar, N, P. 14-15 November 2013. Implementasi Embedded Linux pada Jaringan Sensor Nirkabel Platform Imote2. Prosiding Conference on Smart-Green Technology in Electrical dan Information Systems, Bali, hal. 91-96. http://ojs.unud.ac.id/index.php/prosidingcsgteis2013/article/download/7259/5508.Diakses: 27 Maret 2014.
• Shi, Y. Sun, H. 2007. Image and Video Compression for Multimedia Engineering Second Edition. Broken Sound Parkway NW : Taylor & Francis Group, LLC.
• Shwe, H, Y. Wang, C. Chong, P, H, J. Kumar, A. September 2013. Robust Cubic-Based 3-D Localization for Wireless Sensor Networks. wireless sensor network, vol. 5, no. 9, hal. 169-179. www.scirp.org. Diakses: 12 Oktober 2013
• Wiasta, I, M. 2012. “Performasi Platform Imote2 pada Jaringan Sensor Nirkabel” (Laporan Tugas Akhir). Denpasar : Jurusan Teknik Elektro, Universitas Udayana.