How does the gr.enable_realtime_scheduling() affect flow graph? How to avoid receive own data?

Hi all,

I applied Josh’s new block “stream_selector”, it is a great selector
which allow to set dynamic path without stop flow. But I still have some
problem with my flow graph. That is a issue relating to
gr.enable_realtime_scheduling(). I use signal from another process to
control the open and close of my flow based on the new stream_selector.
If the gr.enable_realtime_scheduling() exists the receiving action looks
very slow and the signal handler function reacts wrong sometimes. If
cancers the gr.enable_realtime_scheduling(), all things looks very well
but own data packages transmitted are received sometimes and then the
desired packages can not be received at that moment.
Who knows how the gr.enable_realtime_scheduling() affect flow graph? How
can avoid receive own data when work in duplex mode. I have modified the
configuration in /uhd/host/lib/usrp/dbboard/ to make:

_power_up | ANT_RX2| MIXER_DIS);/

/But it still receives own data sometimes(not always, also dose not
relate to gr.enable_realtime_scheduling()).

/Any suggestion is very appreciated.



On Mon, Feb 13, 2012 at 3:04 PM, Zhonghua [email protected] wrote:

gr.enable_realtime_scheduling(), all things looks very well but own data
relate to gr.enable_realtime_scheduling()).

The enable_realtime_scheduling tells the OS to give this application
priority, which should only improve the performance and reduce any
interruption to the operation of the block. The biggest downside that
observed with using it is that an application can take over the system
be difficult to kill. What you’re describing seems counter-intuitive to
what it’s supposed to do.


If this helps, you can precisely time transmit packets using stream
tags. If you know the time when a transmit occurs, you can intelligently
mute your receiver. See notes in uhd_usrp_sink.h

Also, it has just occurred to me that my stream selector block does not
forward stream tags. - Mental note to myself.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs