IMEC sensing engine documentation

To achieve dynamic spectrum access, sensing techniques are crucial. The IMEC Sensing Engine can add sensing capabilities to radio systems and enable the evaluation of cognitive network solutions. Both hardware and firmware are reconfigurable, allowing to support and evaluate a wide range of sensing applications. A CREW application programming interface (API) is implemented as a Linux library, to ease the writing of new applications in a standard way. Currently, eight prototypes are deployed in the CREW w-iLab.t test-bed. These are connected by means of an USB interface to their corresponding Zotac nodes. Figure 1 shows an unpackaged version of the IMEC sensing engine with scaldio frontend.

imecse in wilab2

Figure 1. Unpackaged IMEC sensing engine with a Scaldio-2B wide band front-end.

At present seven units are deployed in the w-iLab.t Zwijnaarde testbed and one is deployed in the w-iLab.t office testbed. An introduction of how to access the IMEC sensing nodes in the CREW w-iLab.t facility is available on following pages:

  • Usage of Imec sensing engine in w-iLab.t Zwijnaarde testbed. Figure 2 gives an overview of available IMEC sensing engine nodes in this testbed.
  • Usage of Imec sensing engine in w-iLab.t office testbed. One unit is available.
  • imecse in wilab2

    Figure 2. Deployment of IMEC sensing engine in the CREW Zwijnaarde w-iLab-t test-bed

    The next sections focus on developing firmware for the IMEC sensing engine. Additional information can be found in following documents:

  • An introduction of the Imec sensing engine: presented on CREW training days, January 2014.
  • The reference manual of the Imec sensing engine.
  • An overview of the Imec sensing engine hardware.
  • AttachmentSize
    SensingPrototypes-20110822.pdf880.07 KB
    SensingEngine_UserManual_CREW.pdf1.43 MB
    SensingEngineScaldio.JPG24.01 KB
    20140114_CREW_training_days_imecse_v1.0.pdf1.01 MB

    Hardware overview

    Different hardware realizations of the IMEC sensing engines exist. This section details the used hardware for IMEC sensing engines, as deployed in the CREW w-iLab-t test-bed.

    The IMEC sensing engine consists out of three main components: a digital processing part, an analog front end and an antenna. The following paragraphs detail these:

    • The SPIDER digital board contains the IMEC DIFFS chip, which is the key component of the sensing real time signal processing (Figure 1.a). This board has two generations: version 1 and 2 respectively. All deployed prototypes for CREW use version 2. Each board has a SPIDER identification number bigger than 128. Specifically this number is derived by adding 128 to the number on the white label of the spider board. These SPIDER identification numbers are available in the test-bed documentation section, eg for the CREW Zwijnaarde w-Ilab-t test bed. An FPGA and on board SRAM allow to reconfigure the SPIDER board. Currently two configurations exist according to the connected front-end type.
    • The analog front end board downconverts the signal band of interest to base-band. Two types of front-end are supported for the SPIDER v2 board (*):
      • The IMEC Scaldio-2B wide band front-end, that supports sensing between 520MHz till 6.32 GHz (Figure 1.b). Note that an appropriate antenna is needed for the selected band.
      • The commercial WARP frontend for the 2.4 GHz and 5.2 GHz ISM bands (Figure 1.c).
      • (*) The SPIDER board needs to be configured properly to support one of these front-end types.

    • To enable correct sensing a suitable antenna is required. For the WARP front end a WiFi antenna is typically used (Figure 2.a). For the Scaldio-2B front end a suitable antenna for the frequency band of interest is recommended. Figure 2.b shows a wide band antenna suited for a frequency range between 800 MHz till 2.5 GHz.

    SPIDER and front-end boards

    Figure 1 : Overview of boards for IMEC sensing engines deployted in CREW (a) SPIDER v2 digital board (b) Imec Scaldio-2B analog front-end (c) WARP analog front-end. A two Euro coin is shown to indicate the size of these boards.

    SPIDER and front-end boards

    Figure 2 : example antenna's (a) Wifi antenna (b) broadband antenna for 800MHz .. 2.5 GHz range

    SE-antennas.jpg32.63 KB

    Software and hardware configuration

    To use the IMEC sensing engine the hardware needs to be configured with the CREW API. The corresponding libraries are typically pre-compiled for the Zotac nodes of thw w-iLab.t test bed. Here we briefly illustrates the main configuration steps, as required when updating or extending nodes with Imec sensing capabilities. We show this for the default organisation of the development files, as illustrated in the user manual

    Software stack of the sensing engine

    Figure 1 : software stack of the IMEC sensing engine

    Software configuration

    A high level overview of the software is shown in Figure 1. The software runs on Linux. The standard (lib)USB development kit implements the low level communication with the USB port on the SPIDER hardware board. An advantage of this approach is that the hardware abstraction layer (HAL), CREW sensing API (application programming interface) and application can be developed in user mode instead of kernel mode. The configuration is done as follows.

    1. Start up a terminal session
    2. Navigate to the top level directory of the development kit. You see two directories : "software" and "spider"
    3. cd spider/software/usb_interface/SensingEngine/ : this is the point where applications can be developed on top of the CREW sensing API
    4. source environment.csh : configure the environment with some additional variables
    5. pushd $USB_DIR : jump to directory with the spider HAL to communicate with the SPIDER board over USB
    6. make clean; make : build the spider API
    7. cd ../../platforms/swi/ : go to directory with the DIFFS HAL
    8. make clean ; make shared : build a shared library of the abstraction layer
    9. popd : jump back to the SensingEngine directory
    10. make clean ; make : build the CREW SensingEngine API


    Hardware configuration

    For CREW, the hardware configuration of the IMEC sensing engine is fixed. Two hardware configurations exist: one for systems equiped with a SCALDIO-2B front end, and another one when a WARP front-end board is present. In the spider/software/usb_interface/SensingEngine/ directory two scripts are available. Execute one of these to properly configure the SPIDER board:

    1. source environment.csh : only needed for a new terminal session
    2. ./ : execute this on nodes equiped with a Scaldio front end
    3. ./ : execute this on nodes equiped with a WARP front end

    With the command lsusb the hardware configuration can be checked. If the unitialised spider board is connected to the Zotac node, a USB device with ID 04b4:8613 of Cypress Semiconducor Corp. is present. After the hardware set-up this device is replaced by a USB device with ID 221a:0100. This signals that the SPIDER board is ready to use.

    SE-software-stack.JPG32.32 KB

    Program examples using the Imec sensing engine API

    The Imec sensing engine is programmed in C, and can be set-up, configured and used with the sensing API. Using a simple example the use of this API is illustrated for the FFT_SWEEP mode. Both a single FFT sweep as multiple FFT sweeps are shown. This is illustrated for an Imec sensing engine equiped with a WARP front-end. A zip archive containing the source code of the examples is included below.

    To conclude we provide an overview of the other modes as supported by the Imec sensing engine.

    FFT_SWEEP example

    The Imec sensing engine supports several modes: for this example uses FFT_SWEEP sensing scheme. This returns 128 points per selected channel. Figure 1 shows the output of one FFT sweep, for channel one to four for WARP, covering center frequencies 2412, 2432, 2452, 2472.

    single FFT sweep result

    Figure 1 Output of one FFT sweep in the ISM band


    The sensing engine is programmed in C. Items (1) .. (8) show the necessary steps to configure the sensing engine, and to produce the data shown in Figure 1. The full source code is available in the zip archive, specifically in the warp_single_FFT_SWEEP.c program file. In (9) we show how the program can be extended to do multiple sweeps.

    The next paragraph discuss the required calls to the sensing API to produce the result.


    Type declarations are highlighted in green, and code snippets in blue. Calls to the sensing engine API are underlined.

    1) Open the sensing engine handler 

       To open an Imec sensing engine board both the spider number and

        front end number need to be used. The output is a software handler 

        that is used for the sensing engine API function calls.


      se_t sensing_engine_handler;

      sensing_engine_handler = se_open(spider, warp); 


    • spider: an integer containing the spider board number. This number is bigger than 128 for spider v2 boards
    • warp:  a constant value 0 to select the WARP front end.


    2) Initialize sensing engine

        After checking the status of the sensing engine,  the se_init function is

         invoked to allocate memory and start adres for the my_se_config struct. 

         With this struct the parameters for the sensing engine will be configured.

         A return value equal to 1 indicates that this step succeeded

        int result = 0;

        struct se_config_s my_se_config;

        if (se_get_status(sensing_engine_handler)) {
          result = se_init(sensing_engine_handler, &my_se_config);
        assert (result==1);
    3) Configure the FFT_SWEEP parameters, and check the configuration   
        The my_se_config senging engine paremeters are configured, 
        and validated with the se_check_config() function. A return value of 1
        indicates that the configuration successfully passed all
        checks of the input parameters for the Imec sensing engine. 
        int start_channel = 1;
        int stop_channel = 4;

       // configure WARP FFT sweep  

        my_se_config.first_channel = start_channel; 
        my_se_config.last_channel = stop_channel; 
        my_se_config.fe_gain = 100; // 100 = max gain
        my_se_config.se_mode = FFT_SWEEP;
        my_se_config.bandwidth = 10450000;
        // check configuration 
        result = se_check_config(sensing_engine_handler, my_se_config);
        assert(result == 1);
    4) Load configuration to sensing engine, and allocate space for the return values
         The verified configuration is now written into the Imec sensing engine for real,
          and returns the number of floating point samples that are returned. 
          This allows to reserve memory space for return values, as illustrated below.
          The configuration can be used once, or applied continously. 
           In this example we opt for one FFT_SWEEP for the configured channels.
        float *fft_result;
        result = se_configure(sensing_engine_handler, my_se_config, 0);
        // 0 for single sweep, 1 for continuous sweeping
        // allocate space for output values
        fft_result = (float *) malloc(result*sizeof(float));
    5) Start measurement
       The sensing is started as follows:
       This procedure is the same for single and continuous sweeping.
       Note however that for the continuous mode only one call to the
       se_start_measurement function is required.
    6)  Read out result of the scan into the fft_result array
        The se_get_ressult() function returns the measument data.
        For this example 4 times 128 values are returned.
        A return value of 1 indicates that the FFT sweep was successful
       result = se_get_result(sensing_engine_handler, fft_result);
       Note that this function can be called only once in this example. 
       If continous mode is selected multiple calls can be done to this functin to 
       get the most recent sensing data.
    7)  Close the spider board
       In this example only one sensing sweep was needed,
       hence the sensing engine can be closed as follows:
    8) Process  results
      In this example the content of the fft_result array is written into a file called
      The result can be inspected with the gnuplot command,
      as shown here.
    9) Extension of the example
    An extention of the single FFT sweep for WARP is provided in the warp_multiple_FFT_SWEEP.c file. The sensing engine is configured in continuous mode, and repeated measurements are colleced, and dumped in a file called warp_multiple_fft_scan.log . The result can be visualized with the warp_meshview.m script, that can be executed in matlab or octave, as illustrated in Figure 2 below. We observe that the highest energy is observed in frequency bands around 2440 and 24480 MHz.
    3D plot of multiple FFT sweeps
    Figure2: Sensing output for multiple FFT sweeps.

    Other sensing modes

    Programming other sensing modes follows the same procedure as shown in the example above. Here we list the supported modes. These are detailed in appendix A of the Sensing engine user manual. Note that Scaldio2B and WARP RF front-ends sweep in other bands, hence channel numbers do not correspond. 
    1. FFT_SWEEP : shown in example above. A 128 point FFT is performed for each configured channel.
    2. WLAN_G: determines the instantaneous power in each selected channel for IEEE802.11g spectrum.
    3. WLAN_A: similar as WLAN_G, for IEEE802.11a spectrum.
    4. BLUETOOTH: determines instantanious power for IEEE802.15.1 spectrum. 
    5. ZIGBEE: similar to BLUETOOTH, for IEEE802.15.4 spectrum
    6. LTE: not implemented.
    7. DVB_T: detection of DVB_T signals. Only applicable for the Scaldio2B front-end.
    8. ISM_POWER_DETECT: determines instantaneous power in the 2.4 GHz ISM band, with a granularity of 1 MHz. 
    9. TRANSMIT: not implemented.
    10. ADC_LOG1: logging of ADC values as retrieved from the front-end. Debug mode for sensing engine equiped with a Scaldio2B front-end.  
    11. ADC_LOG2: logging of ADC values as retrieved from the front-end. Debug mode for sensing engine equiped with a WARP front-end.
    12. STANDBY: not implemented.
    WARPexample.zip5.62 KB
    Imec-sensing-engine-WARP-single-FFT-sweep.png10.84 KB
    Imec-sensing-engine-WARP-multiple-FFT-sweep.png324.93 KB