[USRP-users] Configuration Simulink

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


Hi Jorge,

Thanks for the response - more responses below . . .

From: Jorge Miguel [mailto:jmiggal at gmail.com]
Sent: Wednesday, November 10, 2010 4:36 PM
To: Mike McLernon
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Configuration Simulink

Hi Mike,

More feedback about your comments which I find extremely useful, many thanks !
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.

Are the techniques to speed a model you refer to based on the Real Time workshop?
>From your words I understand that the real workshop is not much better compared with the rapid accelerator method since the advantage if of being still in Simulink has to be taken into consideration as well.


On Monday I sent to usrp-users a list of techniques for speeding up Simulink models, particularly in the context of using the USRP.  For convenience, that list is repeated below:


1.       In the Configuration Parameters → Data Import/Export dialog, turn off all logging.

2.       Make sure that the model is single-rate.  If the model requires resampling, then choose rational coefficients that will keep the model single-rate.  For instance, the FM demos in the Communications Blockset use a native frame size of 358, with an initial sample rate of roughly 195 kHz.  The signal is eventually piped to an output audio device, which runs at 48 kHz.  The model then uses a resampling factor of 44/179 to get close to 48 kHz, and results in good quality audio.  (To get to those demos, type ‘demo toolbox commblks’ at the MATLAB command prompt, then navigate in the help browser to Simulink Demos -> SDR Hardware.)

3.       Do not add any Buffer blocks to the model.  Although it's tempting to create friendlier frame lengths than 358, doing so by using a Buffer will severely degrade performance.

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.  (See point 6.)

5.       Try to avoid feedback loops.  Typically, such loops imply scalar processing, which will slow down the model considerably.

6.       Perhaps the most obvious trick of all is not to use scopes unless absolutely necessary.  To visualize your data, send it to a workspace variable and post-process it.

7.       If you are using Accelerator or Rapid Accelerator, set the Configuration Parameters → Optimization → Compiler optimization level to 'Optimizations on (faster runs)'.

8.       If the model has lots of Constant blocks, it could help slightly if Configuration Parameters → Optimization (Signals and Parameters) → Inline parameters is checked on.  This will cause the sample time of those Constant blocks to truly become inf -- Simulink will get the values once and only once during a run.

9.       If the model generates code, the Solver setting should be Fixed-step/discrete.  The tasking mode should be SingleTasking.




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.

As I said in other post, this is what is happening to me. I connect a single tone from a signal generator and no matter the frequency it lands at baseband. (I explain it in the post "Flat response from a signal generator")

However I will focus on the XCVR2450.

As I told you I want to build a pulse radar application. Since the XCVR2450 is not full-duplex I need to switch between TX and RX periodically. that is, transmit a signal (pulse) and switch to RX mode as soon as possible to listen received echoes.

My first thought was to place the USRP2 TX inside one subsystem and the USRP2 RX in another subsystem both with enable inputs controlled by the same pulse which has to be transmitted. Are the transmission/reception from the USRP blocks triggered/stopped just by enabling/disabling this enable input subsystems? I have the impression that when disabled they do not stop the USRP.

That is correct - the USRP hardware is not affected at all by Simulink enable signals.  The USRP Receiver block Data Length output signal turns the downstream processing on or off when it controls the enabled subsystem that contains the processing.  Note that while the USRP hardware is processing data, it may or may not have that data available for Simulink.  When the Data Length output is 0, the hardware doesn’t have any data available for Simulink.  When it is nonzero, the hardware does have data available.


My second thought is about going lower into the code and modify it. Is it feasible to create a new block (that implements both TX and RX code) with an extra input which executes either the TX code or the RX code. Which parts of the code I have to focus into? (the ones that trigger TX and RX)

The 10b version of the USRP I/O blocks do not support a full duplex mode.  We are investing in that capability, but you will need to run two separate models to run both a Tx and an Rx.

Hth,
Mike



How can it be achieved? It is necessary to modify code of the Matlab blocks? Write new code?

Many thanks in advance,
Jorge.



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/2fa36895/attachment-0002.html>


More information about the USRP-users mailing list