Description - UniMasr€¦ · Web viewSimulink. Simulink is an environment for multidomain...

Simulink

Simulink is an environment for multidomain simulation and Model-Based Design for dynamic and embedded systems. It provides an interactive graphical environment and a customizable set of block libraries that let you design, simulate, implement, and test a variety of time-varying systems, including communications, controls, signal processing, video processing, and image processing.

With Simulink, you can move beyond idealized linear models to explore more realistic nonlinear models, factoring in friction, air resistance, gear slippage, hard stops, and the other things that describe real-world phenomena. Simulink turns your computer into a laboratory for modeling and analyzing systems that would not be possible or practical otherwise.

Simulink provides you with the tools to model and simulate almost any real-world problem. Simulink also provides demos that model a wide variety of real-world phenomena.

Simulink provides a graphical user interface (GUI) for building models as block diagrams, allowing you to draw models as you would with pencil and paper. Simulink also includes a comprehensive block library of sinks, sources, linear and nonlinear components, and connectors. If these blocks do not meet your needs, however, you can also create your own blocks. The interactive graphical environment simplifies the modeling process, eliminating the need to formulate differential and difference equations in a language or program.

Models are hierarchical, so you can build models using both top-down and bottom-up approaches. You can view the system at a high level, and then double-click blocks to see increasing levels of model detail. This approach provides insight into how a model is organized and how its parts interact.

Model-Based Design is a process that enables faster, more cost-effective development of dynamic systems, including control systems, signal processing, and communications systems. In Model-Based Design, a system model is at the center of the development process, from requirements development, through design, implementation, and testing. The model is an executable specification that is continually refined throughout the development process. After model development, simulation shows whether the model works correctly.

When software and hardware implementation requirements are included, such as fixed-point and timing behavior, you can automatically generate code for embedded deployment and create test benches for system verification, saving time and avoiding the introduction of manually coded errors.

Model-Based Design allows you to improve efficiency by:

Using a common design environment across project teams.

Linking designs directly to requirements.

Integrating testing with design to continuously identify and correct errors.

Refining algorithms through multi-domain simulation.

Automatically generating embedded software code.

Developing and reusing test suites.

Automatically generating documentation.

Reusing designs to deploy systems across multiple processors and hardware targets.

MEX-files

This technical note provides a general overview of MEX-files and a detailed explanation of the external interface functions that allow you to interface C, C++ or FORTRAN subroutines to MATLAB. MEX-files are a way to call your custom C, C++ or FORTRAN routines directly from MATLAB as if they were MATLAB built-in functions.

MEX stands for MATLAB Executable. MEX-files are dynamically linked subroutines produced from C, C++ or FORTRAN source code that, when compiled, can be run from within MATLAB in the same way as MATLAB M-files or built-in functions. The external interface functions provide functionality to transfer data between MEX-files and MATLAB, and the ability to call MATLAB functions from C, C++ or FORTRAN code.

The main reasons to write a MEX-file are:

1. The ability to call large existing C, C++ or FORTRAN routines directly from MATLAB without having to rewrite them as M-files.

2. Speed: you can rewrite bottleneck computations (like for-loops) as a MEX-file for efficiency.

http://www.mathworks.com/access/helpdesk/help/techdoc/apiref/bqoqnz0.html

Simulink-USRP: Universal Software Radio Peripheral (USRP) Blockset

The Simulink-USRP project is an Open Source Software Package that enables owners of an Universal Software Radio Peripheral, also known as USRP, to build models in Simulink that interface with the hardware in realtime. It is thus possible to build a wide variety of signal processing applications and wireless communication devices directly in Simulink while being able to test them on real hardware at the same time.

This software package was developed at the Institut für Nachrichtentechnik at the Universität Karlsruhe (TH), Germany.

It makes use of the library libusrp, which is part of GNU Radio. Currently, it is capable of controlling USRPs Version 1.

Features

The Simulink-USRP package makes a wide variety of functions of the USRP hardware available to Simulink. Some of the features are:

Easy setup and installation. The need for external libraries or programs has been reduced as much as possible.

Native Windows program: no need to install Cygwin or any other Linux emulation.

Supports frame based signals of configurable length. Supports one complex or two real-valued data streams for each

sub-device of a daughterboard. The sample time of blocks by default reflects the real sampling time of

the USRP, taking into account decimation/interpolation. This can be changed to e.g. count the number of samples produced, instead of real time.

Firmware, FPGA Bit stream, USB Block Size and the number of asynchronously read/written blocks can be easily configured.

Multiple USRP boards can be used at once. (No MIMO operation until now, though.)

Real Time Workshop builds (including Rapid Accelerator builds) are possible without the need to configure anything for Simulink-USRP.

System Requirements

These are the products required in order to run the Simulink-USRP software:

MATLAB, Simulink, Signal Processing BlocksetObviously, Simulink-USRP won't run without these. Signal Processing Blockset is needed to be able to use framed signals.

Real Time Workshop (optional)The Real Time Workshop can be used to speed up simulations quite a lot.

Microsoft Visual C++If you don't have it already, you may also use the Visual C++ Express Edition which can be downloaded from Microsoft for free (as in beer). The LCC compiler shipping with MATLAB is know NOT to work with Simulink-USRP. Other compilers may work, they have not been tested.

Make sure all requirements are fulfilled before you proceed to the installation instructions.

Installing the USRP USB driver: libusb-win32

The USRP hardware is controlled through the libusb-win32 user-space USB driver. If you have not already installed this driver you will have to download and install it. It is suggested to use the pre-packaged version, including an INF-File for the USRP, which can be found at the download site of the Institute für Nachrichtentechnik (INT). Alternatively, you can download the driver from the libusb-win32's homepage at SourceForge - in this case you need to create the INF-File by yourself. See the weblinks page for download adresses.

After plugging in and powering up your USRP, point Windows to the folder into which you downloaded and extracted the pre-packaged driver. When you start Simulink-USRP for the first time, you might have to repeat this step once. This happens when the USRP's firmware has been loaded into the microcontroller. If everything works, you should see the USRP in the device manager:

If Windows does not ask you for the driver, go to the device manager and delete any previous installations of a USRP driver you might find. If you want to keep an existing driver, this should work fine. However, if you should encounter any segmentation faults, it is recommended to install the pre-packaged driver.

Choosing the Microsoft Visual C++ Compiler under MATLAB

Due to licensing issues, there are no precompiled versions of the Simulink-USRP project. However, compiling the project is as easy as calling one command from the MATLAB command promt. Before doing this, you need to choose the correct compiler, which will be done in this step.

Make sure you have Microsoft Visual C++ installed on your computer, as written in Getting Started. On the MATLAB command promt, type mex -setup and choose the Microsoft Compiler. The output should look similiar to this:

>> mex -setupPlease choose your compiler for building external interface (MEX) files:Would you like mex to locate installed compilers [y]/n? ySelect a compiler:[1] Lcc-win32 C 2.4.1 in D:\PROGRA~1\MATLAB\R2008a\sys\lcc\bin[2] Microsoft Visual C++ 2005 in D:\Programme\Microsoft Visual Studio 8[0] NoneCompiler: 2Please verify your choices:Compiler: Microsoft Visual C++ 2005Location: D:\Programme\Microsoft Visual Studio 8Are these correct [y]/n? yTrying to update options file: [...] mexopts.batFrom template: [...]Done . . .[...]>>

If you are using an older version of MATLAB and the Express-Edition of the Microsoft Visual C++ compiler, please take a look at Microsoft 32/64-bit Visual C++ 2008 Express support files at "MATLAB Central", download the package and follow the readme.txt. Sometimes you have to adapt the path for the MSSdk to the directory where you installed it.

Installing Simulink-USRP into MATLAB

You can place the downloaded Simulink-USRP package whereever you like on your hard drive, it does not need to be underneath your MATLAB root. Installing it into MATLAB means nothing more than adding two folders to your MATLAB path.

To do this, select File > Set Path in the MATLAB desktop. Click Add Folder... and select the folder X:\simulink-usrp\bin\ in a first round, and X:\simulink-usrp\blockset\ in a second round, with X:\ being the location where you unpacked the Simulink-USRP package. After clicking Save and Close, this step is done.

If it ever happens to you that you want to uninstall this package, simple delete the folders from the file system. MATLAB will detect that they are missing the next time it is started, and remove the added paths.

Compiling Simulink-USRP

The final step in setting up this package is to call usrpBuildBinaries on the MATLAB command promt. The output should look like this:

>> usrpBuildBinariesRunning: mex -outdir 'X:\simulink-usrp\bin' -output libusrp LINKER=lib.exe[...]D:\DOKUME~1\[...]\LOKALE~1\Temp\mex_R45T3d emplib.x konnte nicht gefunden werdenRunning: mex -outdir 'X:\simulink-usrp\bin' -output 'simulink-usrp' LINKER=lib.exe [...]D:\DOKUME~1\[...]\LOKALE~1\Temp\mex_e5ubei emplib.x konnte nicht gefunden werdenRunning: mex -outdir 'X:\simulink-usrp\bin' [...]usrp_helper.cpp[...]Running: mex -outdir 'X:\simulink-usrp\bin' [...]usrp_sink.cpp[...]Running: mex -outdir 'X:\simulink-usrp\bin' [...]usrp_source.cpp[...]Running: mex -outdir 'X:\simulink-usrp\bin' [...]stdout2matlab.cpp[...]>>

That's all, now you can start using the Simulink-USRP interface by placing blocks from the USRP library in the Simulink library browser into your models.

Block Reference

The USRP blockset currently consists of these blocks:

USRP_sink:

The usrp_sink block is used to transfer data from a Simulink model to the USRP.

USRP _source : The usrp_source block is used to transfer data from the USRP to a Simulink model.

USRP _helper : The usrp_helper block is used to set properties which are common to a sink and a source on the same USRP board, such as the firmware or USB Block Size.

http://www.cel.kit.edu/block_reference.php#block1069




USRP_sink

Description

This block consumes a certain number of input streams (depending on how many daughterboards on the USRP are enabled) and sends them out to the USRP.

Dialog Box

The usrp_sink block has "per-block" settings, displayed on the USRP tab pane, and "per-daughterboard" settings, displayed on the Side A and Side B tab panes.

USRP Tab Pane

USRP Board Number :

Specify on which USRP board this usrp_sink block acts upon. The first USRP board is numbered 0, the second 1 etc.

Serial Number :

Informational message stating the USB serial number of the specified USRP board. Read only.

Interpolation Factor :

Specifies the interpolation factor which is to be used inside the USRP to bring the baseband sample rate to 128 MSps. Some restrictions apply, depending on the choosen FPGA bitstream. If the interpolation factor could not be set when starting the simulation, check that it is inside the supported range of the FPGA. For some FPGA bitstreams, the interpolation factor must be a multiple of four.

Sample Width

Number of bytes to transfer across the USB bus for one sample. For usrp_sink blocks, 16 bit is the only allowed value.

Effective Sampling Rate and Bandwidth

Displays the effective bandwidth across the USB bus, depending on the number of enabled daughterboards/subdevices and the Sample Width. Read only.

Vector length

Number of samples of one input frame of this block. This number must be calculated in a way such that the block size that goes over the USB bus is a multiple of 512 bytes. That means that the equation

Vector length * 2 * Sample Width/bytes * Number of active channels mod 512 = 0

must be true. The factor 2 comes from complex samples.

Daughterboard Tab Panes ("Side A" and "Side B")

Daughterboard / Subdevice

Displays the type of the daughterboard installed on the USRP. Read only.

Data Type

Enables transmitting with this daughterboard when set to anything different from Disabled. For each daughterboard which is not disabled, one complex-valued input port or two real-valued input ports of the specified data type appear on this Simulink block.

For example, assume that the Data Type of the daughterboard on Side A is set to INT16, and that of Side B is set to SINGLE Complex. This means that input port one of this block expects a stream of real-valued frames, being the in-phase part of the signal going to daughterboard A. Input port two expects the real-valued quadrature part of the same signal. The daughterboard on side B is fed by the complex-valued stream going into port three of this block.

Frequency Range (Hz)

Displays the frequency range that is supported by this daughterboard. Read only.

Frequency (Hz)

Enter the frequency at which the signal entering this block shall be transmitted with the USRP.

Gain Range (dB)

Displays the gain range supported by this dautherboard. Read only.

Gain (dB)

Enter any gain or attenuation within the gain range of the daughterboard.

USRP_source

The usrp_source block is used to transfer data from the USRP to a Simulink model.

Description

This block produces a certain number of output streams (depending on how many sub-devices on the daughter-boards on the USRP are enabled) by reading data from the USRP.

Dialog Box

The usrp_source block has "per-block" settings, displayed on the USRP tab pane, and "per-subdevice" settings, displayed on the Side A - 1 through Side B - 2 tab panes.

USRP Tab Pane

USRP Board Number

Specify on which USRP board this usrp_source block acts upon. The first USRP board is numbered 0, the second 1 etc.

Serial Number


Decimation Factor

Specifies the decimation factor which is to be used inside the USRP to bring the ADC sample rate of 64 MSps to the baseband sample rate. Some restrictions apply, depending on the choosen FPGA bitstream. If the decimation factor could not be set when starting the simulation, check that it is inside the supported range of the FPGA. For some FPGA bitstreams, the decimation factor must be even.

Sample Width

Number of bytes to transfer across the USB bus for one sample. Setting this to 8 Bit yields in a higher maximum sample rate across the USB but decreases the dynamic range of the captured signal.

Effective Sampling Rate and Bandwidth

Displays the effective bandwidth across the USB bus, depending on the number of enabled daughterboards/subdevices and the Sample Width. Read only.

Vector length

Number of samples to put into one output frame of this block. This number must be calculated in a way such that the block size that goes over the USB bus is a multiple of 512 bytes. That means that the equation

Vector length * 2 * Sample Width/bytes * Number of active channels mod 512 = 0

must be true. The factor 2 comes from complex samples.

Sub-device Tab Panes ("Side A - 1" through "Side B - 2")

Daughterboard / Subdevice

Displays the type of the daughterboard installed on the USRP. Read only.

Data Type

Enables receiving with this subdevice when set to anything different from Disabled. For each subdevice which is not disabled, one complex-valued output port or two real-valued output ports of the specified data type appear on this Simulink block.

For example, assume that the Data Type of the daughterboard on Side A - 1 is set to INT16, and that of Side B - 1 is set to SINGLE Complex. This means that output port one of this block produces a stream of real-valued frames, being the in-phase part of the signal from subdevice 1 on daughterboard A. Output port two produces the real-valued quadrature part of the same signal. Subdevice 1 on the daughterboard on side B produces one complex-valued stream on port three of this block.

Frequency Range (Hz)

Displays the frequency range that is supported by this daughterboard. Read only.

Frequency (Hz)

Enter the frequency at which a signal shall be captured.

Gain Range (dB)

Displays the gain range supported by this subdevice. Read only.

Gain (dB)

Enter any gain within the gain range of the daughterboard.

Antenna

Daughterboards with multiple antenna input ports can be configured to use one specified input connnector for the signal. Setting this parameter to a value which is not available on the dautherboard usually produces an error (or has no effect at all, depending on the type of the dautherboard).

The setting I&Q (BasicRX/LFRX only) has a special meaning. The two input connectors on thoses dautherboards are usually mapped to the two subdevices of the dautherboard. If, however, both inputs are fed by the inphase and quadrature parts of the same signal, they both can be combined into one complex signal. In this case, subdevice two can not be used seperately any more. (In fact, this setting chooses subdevice three on those boards.)

The Antenna parameter is only available on the first subdevice of each daughterboard.

USRP_helper

The usrp_helper block is used to set properties which are common to a sink and a source on the same USRP board, such as the firmware or USB Block Size.

Description

This block can be placed anywhere into a Simulink model. Other blocks reference it by searching for blocks of type usrp_helper and comparing the parameter usrp_number against their own usrp_number. Parameters that control the operation of USRP boards are Firmware Filename, FPGA Bitstream Filename, USB Block Size and Number of USB Blocks. If this block is not found in a model the default values will be used for the parameters.

This block is a purely virtual block. If the Block Reduction option is enabled on the Optimization pane of the Configuration Parameters dialog box of a model, this block does not execute during simulation. Furthermore, this block does not add a single line of code to files generated by the Real Time Workshop.

Dialog Box

USRP Board Number

Specify on which USRP board this usrp_helper block acts upon. The first USRP board is numbered 0, the second 1 etc.

Serial Number


RX Daughterboards and TX Daughterboards

Informational messages stating the types of any daughterboards mounted on the USRP.

USB Block Size

Number of bytes that shall be transferred in one read or write operation across the USB bus. This must be a multiple of 512 bytes, since the USRP fragments large transfers in smaller ones of size 512.

The maximum depends on your operating system. To find it, enter inf for this parameter, the allowed maximum will then be displayed when you start the simulation.

A value of zero will make libusrp use its default value.

USB Number of Blocks

Number of asynchronous transfer operations of size USB Block Size that are started simultaneously. This means that a total of USB Number of Blocks times USB Block Size bytes are allocated in kernel space. Increasing this number can lead to less USRP over-/underruns, but at the same time leads to a higher latency.

A value of zero will make libusrp use its default value.

Firmware Filename

Filename of a compiled firmware for the Cypress EZ-USB FX2 USB Microcontroller. This file must stay inside the directory simulink-usrp/firmware/rev4/ in Intel Hex format.

If left empty, the default firmware std.ihx will be used.

FPGA Bitstream Filename

Filename of a bitstream file for the FPGA on the USRP. This file must reside inside of the directory simulink-usrp/firmware/rev4/.

If left empty, the default bitstream std_2rxhb_2tx.rbf will be used.

Sample Time Factor

Specifies that a sample time different than the "real" sampling time shall be reported to Simulink. By default, the sample time reflects the time between two frames coming out of a usrp_source or running into a usrp_sink. Thus, the absolute time displayed in Simulink during a simulation corresponds to real seconds, and Spectrum Scope blocks display the real bandwidth of a signal.

Changing this factor makes sense if counting samples is more natural to your application than counting time. E.g. specifing a Sample Time Factor of 64e6 makes Simulink display the number of samples calculated in the simulation.

Notes : 1- When you run a simulation you may get "uO" or "uU" messages on the

MATLAB command line where "uO" stands for "USRP overrun" and means that the host PC could not receive data from the USRP as fast as new samples were captured off the air. This message is produced by usrp_source blocks.

"uU" stands for "USRP underrun" and means that the host PC could not produce new samples as fast as the USRP sended them out. This message is produced by usrp_sink blocks.

In both cases, these messages mean that data was lost and discontinuitites were introduced into the signal. The following options reduce the overruns/underruns:

If possible, increase the Decimation Factor and Interpolation Factor of sources and sinks, thus lowering the data rate across the USB and the amount of data to process on the host computer.

Accelerate simulations by using the simulation mode Rapid Accelerator. This will make Simulink compile your model into one executable file, thus reducing overhead of the simulation. Depending on your installed MATLAB products, the Rapid Accelerator mode might not be available to you. (from R2007b)

Reduce the computational complexity of your model. If the USB bus is the bottleneck, set the Sample Width parameter of

usrp_source blocks to 8 Bit. The drawback is that this reduces the dynamic range of the signal.

If the "uO" or "uU" messages appear right away when the simulation is started, but no new overruns occur, it is highly likely that these messages are incorrect and no overrun occured at all. This is a known bug in the USRP.

2- When you open any block from the USRP blockset, something like "usb_control_msg failed: usb_control_msg: sending control message failed [...]" gets displayed on the MATLAB command line. This happens when a USRP board with empty daughterboard slots is connected to the computer. Put a daughterboard into every slot or ignore this message.

3- The Serial Number of the USRP devices sometimes only gets displayed as "S/N: ." This is a know bug, the cause has not been found yet. This seems to happen most often when we are dealing with unconfigured USRPs without firmware/bitstream. Disconnecting and reconnecting the USB cable of the USRP and issuing clear mex; on the MATLAB command promt often helps.

UPDATING THE SIMULINK LIBRARY

Introduction:

In spite of all the features offered by the USRP library, yet we encountered tremendous limitations when trying to use this library to apply the concepts of cognitive radio. This problem can be summarized in the fact that the USRP blocks, once set to a certain frequency at the beginning of the simulation, can’t be tuned to a new frequency except after stopping the whole simulation then re-adjusting the frequency.

A problem that represents the main obstacle in applying the concepts of the Cognitive Radio into the practical use.

This also meant that the idea of even trying to sense the spectrum itself became impossible, which left us no choice except to modify this library and try to add new blocks , to empower the idea of cognitive radio to be feasible by using this new modified library.

The targeted modifications:

Modifying the USRP library blocks in order to allow dynamic frequency tuning –during ongoing simulation.

Adding a new block responsible for determining the new frequencies for the USRP RF front end to tune to, and to sense the spectrum over a certain range and with a specified step according to the required application, restricted with the constraints of the used daughter boards, each with its own category.

All of this should be achieved, taking into consideration constituting a proper interface with the User to manipulate the parameters of the system upon the user's will, to witness the various changes we aimed to highlight through this thesis.

The Modified library:

USRP_source (modified):

To be noticed in the previous figure, we have modified the previous block to have the ability to tune to any desired frequency dynamically once it receives that frequency which is entered by the user.

Also as noticed, we have added two new input ports to import the desired frequencies to be tuned to by the source, where each input port corresponds to a receiver draughter board connected to the USRP device where the max number receiver daughter boards that can be connected is two receiving daughter boards.

usrp_tuner:

Description:

On building this new block, we considered to implement two main objectives:

1-It can tune to any pre-determined single frequency in the spectrum on the condition that it is within the range of the used daughter board.

2-Moreover, we offer the user the option to suggest any range of frequencies to tune over automatically and without any interference from the user.

Parameters description:

Minimum Frequency (Hz):

Indicates the starting centre frequency from which covering the required band to be inspected begins and it is also restricted to the range of frequencies supported by the connected daughter boards to the USRP

Step(Hz) :

Specifies the step by which the centre frequency is incremented by in order to cover the whole frequency range specified by the user (it should be set to zero in case of single frequency tuning i.e.: no automatic dynamic spectrum sensing)

Maximum frequency(Hz):

Indicates the final centre frequency for the band required to be inspected and it is also restricted to the range of the frequencies supported by the connected daughter boards to the USRP.

Tutorial examples:

Spectrum sensing example:

Here, we want to highlight the idea of spectrum sensing concept by illustrating how we retain the previously mentioned objectives.

First we will simulate the model to operate as a single frequency tuner by setting the step of the "usrp_tuner" to zero.

The first attempt represents the spectrum sensing concept in case of fixed bandwidth around the desired carrier –which is predetermined by the decimation.

Secondly we will simulate the same model but we will re-adjust the step to 1MHz until we cover the whole desired frequency spectrum then it is re-tuned to the starting frequency then the whole procedures is repeated automatically all over again,

The second attempt represents the spectrum sensing concept in case of overlapping bandwidths around each carrier –which is determined by the decimation- with each other.

Thirdly, we will repeat the 2nd attempt but we will replace the step with a 3MHz step and then observe the change in the output response.

The fourth attempt represents the spectrum sensing concept in case of non -overlapping bandwidths around each carrier –which is determined by the decimation- with each other.

Response Analysis:

Pre-settings:

- we will use the daughter boards: "TVRX" daughter board.

-The gain of the "TVRX" is set to 50 dB.

-Having a certain signal at frequency 64 MHz which is characterized with a strong ampliyude which made it suitable for our illustration.

-For the "usrp_source" block:

-Where the USRP Board Number is "0" as we have only 1 connected USRP

-The Decimation factor was taken to be 8 (minimum decimation factor )so that we would be able to display the maximum possible effective sampling rate which is 8 Mhz.

-The vector length was set to 1024 (1024 sample per output frame)

-The common model used in the three experiments:

1st experiment: single frequency tuning:

We will set the minimum/starting frequency to 63MHz and the maximum/final frequency also to 63 MHz with zero frequency step as to achieve a single frequency tuning and observe the surrounding bandwidth as shown in the next GUI and its enhanced figure:

-The concluded results will be displayed on the figure from the FFT block.

Brief explanation:

Here the RF front end will be tuned to the desired center frequency entered in the dialogue box ( 63 MHz) , then this signal frequency and its accompanied bandwidth will brought to the baseband, and since the test signal is at 64 MHz it will appear at the 1 MHz in the base band window as shown in the previous figure.

2 nd experiment:

Here we will sense a spectrum of width 16MHz, starting from 57 MHz till 73 MHz, with step 1Mhz and overlap of 7 MHz .This means that the carrier frequencies selected to cover the whole frequency range will thus be:

- 61 MHz to cover the range from 57 MHz till 65MHz









So the "usrp_tuner" settings will thus be as follows:

After executing the simulation, we obtained the following results, showing how the centre frequency (61MHz, 62 MHz …) of the spectral window hops with uniform step (1 MHz) in order to cover the whole required frequency range (16 MHz) defined earlier by the parameters in the tuner dialogue box.

Experiment three:

Here we will sense a spectrum of width 14 MHz, starting from 57 MHz till 71 MHz, with step 3 MHz and overlap of 5 MHz .This means that the carrier frequencies selected to cover the whole frequency range will thus be:





After executing the simulation, we obtained the following results, showing how the centre frequency (61MHz, 64 MHz…) of the spectral window hops with uniform step (3MHz) in order to cover the whole required frequency range (14 MHz) defined earlier by the parameters in the tuner dialogue box.

Experiment Four:

Here we will sense a spectrum of width 16 MHz, starting from 57 MHz till 73 MHz, with step 8 MHz but non-overlapping .This means that the carrier frequencies selected to cover the whole frequency range will thus be:




After executing the simulation, we obtained the following results, showing how the centre frequency (61 MHz, 69 MHz) of the spectral window hops with uniform step (8 MHz) in order to cover the whole required frequency range (16 MHz) defined earlier by the parameters in the tuner dialogue box.

Description - UniMasr€¦ · Web viewSimulink. Simulink is an environment for multidomain...

Documents

Transcript of Description - UniMasr€¦ · Web viewSimulink. Simulink is an environment for multidomain...