Forum: GNU Radio Shutting down a usrp_sink_s

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
287db267f16cb26430934ea36168e6b3?d=identicon&s=25 Mattias Kjellsson (Guest)
on 2009-03-16 15:44
(Received via mailing list)
Hi list,

I have a question regarding the shutdown procedures of c++- flow- graphs
(using trunk r10527, ubuntu 8.10). As far as I have understood a flow-
graph will continue until one of the blocks in it either returns -1, or
ctrl+c is pressed.

However, if I connect a gr_file_source(sizeof(short),
"./data_to_usrp.dat", true) with a usrp_sink_s in a gr_top_block and do
top_block->start() the flow- graph exits as if the repeat- flag in
gr_file_source wasn't set to true.

If I on the other hand use (the same configuration) top_block->start()
the flow- graph continues until ctrl+c is pressed, but the destructor of
top-block isn't run, which I verified with a printf in it.
t't
If I install a signal handler which catches ctrl+c and sets a flag, and
then use (still the same configuration) uses something like:

top_block->start();
while(!signaled)
    asm(" nop");
top_block->stop();

The flow- graph is run as long as ctrl+c isn't pressed and the
destructor of top_block is run as well.

Why is the destructor so important? It's important because if I don't
add the two following statements in there:

d_tx0->write_io (d_side, -129, 224);
d_tx0->write_io (d_side, -129, 128);
(where d_tx0 is a usrp_sink_s_sptr)

I end up with a pike in the spectrum at the tuned center frequency.

I have basically worked my way from the c++ dial- tone example, which
imo. is illustrative.

I guess my question is how do I shut down a usrp1 correctly from c++?


Best regards
//Mattias
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-03-16 17:11
(Received via mailing list)
On Mon, Mar 16, 2009 at 7:43 AM, Mattias Kjellsson <mkje@kth.se> wrote:

> If I install a signal handler which catches ctrl+c and sets a flag, and then
> use (still the same configuration) uses something like:
>
> top_block->start();
> while(!signaled)
>   asm(" nop");
> top_block->stop();
>
> The flow- graph is run as long as ctrl+c isn't pressed and the destructor of
> top_block is run as well.

This is the right way.  Unless you call top_block.run(), you are
responsible for your own SIGINT handler.

> Why is the destructor so important? It's important because if I don't add
> the two following statements in there:
>
> d_tx0->write_io (d_side, -129, 224);
> d_tx0->write_io (d_side, -129, 128);
> (where d_tx0 is a usrp_sink_s_sptr)
>
> I end up with a pike in the spectrum at the tuned center frequency.

This is an open bug (ticket #348), not your code.  It's not clear yet
why it happens, but one theory is that we are shutting down the USRP
transmit pipeline before it has a chance to drain, and leaving a DC
value as input to the CORDIC, resulting in a carrier tone.  Your
workaround is appropriate.

Johnathan
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-17 01:43
(Received via mailing list)
On Mon, Mar 16, 2009 at 09:09:57AM -0700, Johnathan Corgan wrote:
> > The flow- graph is run as long as ctrl+c isn't pressed and the destructor of
> > top_block is run as well.
>
> This is the right way.  Unless you call top_block.run(), you are
> responsible for your own SIGINT handler.

Setting up your own signal handler is required, though it would be
better if you used sigwait instead of burning up cycles in your busy
loop.

Eric
This topic is locked and can not be replied to.