[USRP-users] Configuration Simulink

MOISES NAVARRO moises.navarro at campus.uab.es
Thu Nov 11 13:13:39 EST 2010


HI all,
I try to use the Real-Time Workshop.
I build the the code without problem, but when I try to execute the file, I
have the following error:

** starting the model **
Error: Could not open library: libmwnetworkdevice.so
Error: Could not open library: libmwnetworkdevice.so
Error: Could not open library: libmwnetworkdevice.so
ErrorStatus set: "Could not open library: libmwnetworkdevice.so"


I found in google, but I havent anything.
If I build a code witout the USRP2 block I havent that error.

I need some special configuration in the Real-Time Workshp?????

On the other hand,  I use a simple program ( in simulink, without
Real-Time)  only read a variable from workspace and send it through USRP.
And. I cant run this simple probram in real time with the settings that  you
advised me. ( using a Interpolation = 50 with Interpolation = 512 I can do
it in real time)
That is normal??'


Regards.

>Dear Mike,
>
>I am getting started with the USRP2 blocks from Matlab 2010b along with the
USRP2 basic receiver and XCVR2450 transceiver.
>I read your post "Configuration Simulink". I still have some questions:
>
>>>4. You should try to run with Rapid Accelerator instead of Normal mode.
 Be aware that some scopes do not plot data when run in Rapid Accelerator
mode, but scopes >>>inevitably slow down a model in any case.
>
>Question1)Why only try? Is there any case we are not allowed to run in
rapid accelerator mode?
>
>In some cases, scopes do not plot data in Rapid Accelerator (RA) mode.
 That could be a reason to avoid RA.  Also, it's always better to use good
modeling techniques to speed >up your model, and not simply rely on RA.
 That being said, RA is a very useful technique that you should take
advantage of if you can.
>
>
>>>9. If the model generates code, the Solver setting should be
Fixed-step/discrete.  The tasking mode should be SingleTasking.
>
>Q2) What do you mean by "If the model generates code"? I thought that it
has always to be executed in discrete fixed-step. However when executing
variable step I got less lost >packages, how can it be possible?
>
>If you are using RA, you can use a variable step/discrete solver.  If you
are generating a standalone executable, you need to set the solver to
fixed-step/discrete.  Also, for a >multirate model, a variable step solver
polls the Simulink engine less frequently than a fixed step solver, so the
VS solver will run faster.
>
>
>Q3) My goal is to build a radar application within USRP2 and Simulink.
Since I cannot skip any information from the receiver part (in order not to
miss any target) simulink has to >be running in real time, Isn?t it?
>
>Yes.
>
>
>Q4) Does it help to use the real time workshop of simulink? I do not know
how it works....Is this what you mean by "generating code"? Precompile code
and then execute the >pre-compiled code? Does the same workspace have more
performance using this technique? Woull it be interesting for my radar
application?
>
>You can use Real-Time Workshop to generate a standalone executable that
does not require Simulink.  However, when you use Rapid Accelerator, you are
also creating an >executable that eliminates much of the Simulink overhead.
 For your application, since you are receiving data real-time, I believe
that you will want to have Simulink in the loop.
>
>
>Q5) When I recieve data from the USRP2 and I use the Spectrum Scope I
always see a great DC component (frequency 0). I do not understand where
does it come from. Do you >have any idea?
>
>A couple of thoughts:
>
>1.       Are you simply receiving data from the USRP?  Are you processing
it at all?
>
>2.       Store the Spectrum Scope input data into a workspace variable and
do some post-processing in MATLAB.  Try some histogramming to see if the
signal has anything >besides the DC component.
>
>3.       What is your input data?  A sine wave?  If so, it is possible that
the frequency offset of your USRP2 LO is erroneously landing the sine wave
at 0 Hz.  We have seen >phenomena like that before.
>
>Hth,
>Mike



Many thanks in advance,
Jorge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20101111/9d369499/attachment-0002.html>


More information about the USRP-users mailing list