[USRP-users] Configuration Simulink

Mike McLernon Mike.McLernon at mathworks.com
Fri Nov 12 13:00:16 EST 2010


Hi Moises,

Can you send us the model and the exact reproduction steps that triggered the libmwnetworkdevice.so error?

Also, an Interpolation factor of 512 causes Simulink to run about 10 times slower than when it is set to 50.  It's reasonable that the first case runs real-time, and that the second one does not.

Hth,
Mike


From: usrp-users-bounces at lists.ettus.com [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of MOISES NAVARRO
Sent: Thursday, November 11, 2010 1:14 PM
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Configuration Simulink

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/20101112/d753b672/attachment-0002.html>


More information about the USRP-users mailing list