Changes between Version 7 and Version 8 of Software/dOML/CollectingMeasurements


Ignore:
Timestamp:
Nov 26, 2007, 4:21:52 AM (16 years ago)
Author:
thierry
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Software/dOML/CollectingMeasurements

    v7 v8  
    5555}}}
    5656
     57 * The generated ''OML Measurement API'' provides two application-specific methods: ''oml_group1()'' and ''oml_group2()''. The user can then call these methods inside his/her application code to pass on collected data to the client side of the OML Collection framework. In this example, the above XML definition will result in generated application-specific methods which will have the following signatures:
     58{{{
     59     int oml_group1(float rssi, float noise);
     60     int oml_group2(int throughput);
     61}}}
     62 
     63 * The following code sample shows an example of the use of these methods within the user's application:
     64{{{
     65#!c
     66// Application Code Sample
     67//
    5768
    58 Measurement point definitions are saved as an XML-based configuration file as shown above. The  source code for the measurement client is automatically generated by the web-based OML service that accepts the xml file shown above and returns the autogenerated client API. This API contains application-specific methods that handle type-safe data collection. This source code can be compiled and linked with the application as illustrated by a Makefile and sample application code below.
     69// needs to be called only once
     70initialize_oml(&argc, argv, NULL);
    5971
    60 The OML service returns a file called "wrapper" which is a tar+gzipped file containing the src,include and lib directories for the OML client API. The src directory need not be used as we already create a static library for the API (see lib directory). In the Makefile, note that the autogenerated filenames include the application id (foo) from the xml file above. Also note how we use the include and lib directories in CFLAGS and LDFLAGS and then link to the oml_client and the client_api libs in LIBS variable. The oml_client library is installed on the gateway machine and is part of the baseline image.
     72// ...
    6173
    62 '''Makefile and include file for Measurement Points'''
     74// 1st point of Measurement Collection
     75if (r_data->send_option == 1) {
     76  buffer->rssi = recv_packet_params.rssi ;
     77  buffer->noise = recv_packet_params.noise;
     78  oml_group1(buffer->rssi, buffer->noise);
     79} else {
     80  log(LOG_ERR, "Unknown receive option! \n");
     81}
    6382
     83// ...
     84
     85// 2nd point of Measuremenr Collection
     86lost_packets = pck_id.seqnum - old - 1;
     87oml_group2(lost_packets);
     88
     89// ...
     90}}}
     91
     92 * Although the user could execute all the above steps manually, it is more practical to use a custom ''Makefile'' to automatically handle the compilation and linkage of applications. In this case, such a ''Makefile'' can also be used to handle the call to the ORBIT web service which will generate the ''Measurement API''. An example of such ''Makefile'' is given below. A good introduction to Makefile can be found [http://www.gnu.org/software/make/manual/make.html#Introduction here].
    6493{{{
    65 Sample Makefile:
     94#
     95# Makefile example for Interface Application/OML Client via Dynamic Library
     96#
     97# In the Makefile, note that the autogenerated filenames include the application id (foo)
     98# from the xml file above. Also note how we use the include and lib directories in
     99# CFLAGS and LDFLAGS and then link to the oml_client and the client_api libs in LIBS
     100# variable. The oml_client library is installed on the gateway machine and is part of
     101# the baseline image.
     102#
     103
    66104APP = foo
    67105CC  = gcc
    … …  
    77115        wget -q http://oml.orbit-lab.org/generator/wrapper --post-file $< -O -\
    78116        | tar -xzf -
    79 
    80 ---------------- End of Makefile --------------------
    81 
    82 ./include/oml_foo.h:
    83         int oml_group1(float rssi, float noise);
    84         int oml_group2(int throughput);
    85 
    86117}}}
    87118
     119=== More on Interface Application/OML Client using Dynamic Library ===
    88120
    89 '''Application Code Sample'''
    90 {{{
    91 #!c
    92 // needs to be called only once
    93 initialize_oml(&argc, argv, NULL);
    94 
    95 if (r_data->send_option == 1) {
    96   buffer->rssi = recv_packet_params.rssi ;
    97   buffer->noise = recv_packet_params.noise;
    98   oml_group1(buffer->rssi, buffer->noise);
    99 } else {
    100   log(LOG_ERR, "Unknown receive option! \n");
    101 }
    102 lost_packets = pck_id.seqnum - old - 1;
    103 oml_group2(lost_packets);
    104 }}}
    105 
    106 Because not all measurements are needed and not all measurement samples are needed, '''OML''' supports preprocessing or filtering at source to reduce the amount of reported and recorded data.  Filters are defined by experimenter, and experimenter-provided filters are supported.  Figure 1. below illustrates the client-side data flow.  Collection of and access to the recorded data requires the use of a database schema.  '''OML''' automatically generates the appropriate schema as diagrammed in Figure 2 below.
     121 * Sometimes, an experimenter does not require all measurement samples for a given metric, or he/she require some higher level information (e.g. average, min/max, etc...). '''OML''' supports measurement pre-processing or filtering at source to reduce the amount of reported and recorded data.  These filters are specified by experimenter within the ''prototype'' of their application. ''Prototypes'' were first introduced in the [wiki:Tutorial/HelloWorld previous part] of this tutorial, and are detailed further [here]. Figure 3 illustrates the client-side data flow with filters.
    107122
    108123[[Image(clientsidedataflow.PNG)]]
     124Figure 3.  Client-side Data Flow with Filters.
    109125
    110 Figure 1.  Client-side Data Flow.
     126 * On the ''OML Collection Server'' side, the XML definition presented in the first steps above will be used to generate a database schema as illustrated in figure 4 below.
    111127
    112128[[Image(serversideschema.PNG)]]
    113 
    114 Figure 2.  Server-side DB Schema Generation.
     129Figure 4.  Server-side Database Schema Generation.
    115130
    116131