Forum: GNU Radio Resource busy error:

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.
39d2ede00600359591ee3db54733147f?d=identicon&s=25 kollimarla bhargav (Guest)
on 2009-04-23 00:42
(Received via mailing list)
Hi all,
         We are trying to run a simple receiver program using
benchmark_rx.py. The problem we are facing is when we try to run another
receiver program like usrp_spectrum_sense.py inside the benchmark_rx.py
using os.system() command , the error is " Device or Resource busy". We
get
a feeling that the thread from benchmark_rx.py is still running. We even
used thread.stop before calling usrp_spectrum_sense.py, but this did not
work, the same error message popped up. Is there any other way of
exclusively kill the thread and call another receiver program.???
We are able to call a benchmark_tx.py transmitter code in
benchmark_rx.py
receiver code, but the combination of calling any program with a
reciever
block from benchmark_rx.py  was not successful and we got a error
message
"Resource busy ". Is this a thread issue??
Appreciate any help!!

Thanking you
bhargav
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin DvH (Guest)
on 2009-04-23 00:55
(Received via mailing list)
On Wed, 2009-04-22 at 17:41 -0500, kollimarla bhargav wrote:
> We are able to call a benchmark_tx.py transmitter code in
> benchmark_rx.py receiver code,
This is logical.
The TX part of the USRP can be used seperately from the RX part.
The RX part is still in use so it can't be used for a new receiver.
>  but the combination of calling any program with a reciever block from
> benchmark_rx.py  was not successful and we got a error message
> "Resource busy ". Is this a thread issue??
> Appreciate any help!!
>
Your receiver chain still exists, even if it is not running.
This keeps the RX part of the USRP in use.

Did you instruct the topblock to stop and wait for it to finish.

If you did, you could try after stopping the topblock.

tb.rxpath=None

or even
tb = None

This throws away the reference to the receive_path (which keeps the RX
part of the USRP in use and thus 'Resource Busy'.)

Martin
39d2ede00600359591ee3db54733147f?d=identicon&s=25 kollimarla bhargav (Guest)
on 2009-04-23 01:48
(Received via mailing list)
Thanks a lot Martin, that solved our problem, now we are able to call
another reciever code in benchmark_rx.py .One last question we tried to
call
benchmark_rx.py from usrp_spectrum_sense.py, but still we get the same
error
"Resource busy"
It seems that another top block other than tb is running in
usrp_spectrum_sense.py

thanks
bhargav
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin DvH (Guest)
on 2009-04-23 02:55
(Received via mailing list)
On Wed, 2009-04-22 at 18:47 -0500, kollimarla bhargav wrote:
>
> Thanks a lot Martin, that solved our problem, now we are able to call
> another reciever code in benchmark_rx.py .One last question we tried
> to call benchmark_rx.py from usrp_spectrum_sense.py, but still we get
> the same error "Resource busy"
> It seems that another top block other than tb is running in
> usrp_spectrum_sense.py
This might have to do with:

self._tune_callback = tune(self)        # hang on to this to keep it
from being GC'd

GCing (Garbage collecting) is exactly what we want here.
There is a kind of circular reference here so the tb keeps existing

I would try:
tb._tune_callback.tb=None
tb._tune_callback=None
tb.u=None
tb=None

Good luck,
Martin
This topic is locked and can not be replied to.