Forum: GNU Radio Usrp2 bg_loop() magic?

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.
Mattias K. (Guest)
on 2008-10-31 11:02
(Received via mailing list)
Hi list,

I have a question regarding bg_loop() for the usrp2. As I have come to
understand it, the function is spawned in a separate thread, which reads
data from the usrp2 every 0.1s and puts it in the eth-buffer associated
with the current usrp2- object. Why was the timeout chosen to this value
(I noted that there is a "fixme, magic timeout" there, but still)? Can I
change this value to any value of my own choice, or are there
limitations that I'm not seeing here?

BR
Mattias K.
Johnathan C. (Guest)
on 2008-10-31 18:08
(Received via mailing list)
On Fri, 2008-10-31 at 09:56 +0100, Mattias K. wrote:

> I have a question regarding bg_loop() for the usrp2. As I have come to
> understand it, the function is spawned in a separate thread, which reads
> data from the usrp2 every 0.1s and puts it in the eth-buffer associated
> with the current usrp2- object. Why was the timeout chosen to this value
> (I noted that there is a "fixme, magic timeout" there, but still)? Can I
> change this value to any value of my own choice, or are there
> limitations that I'm not seeing here?

The background loop's purpose is to handle the Rx side of the GbE
traffic.  But it isn't the case that the it "...reads data from the
usrp2 every 0.1s and puts it in the eth-buffer...".

The call to eth_buf->rx_frames() results in a callback to the usrp2
driver for every packet that is available to be read.  If none are
available, the call will block until the timeout is reached.  The
timeout lets the bg_loop return to the top periodically to check whether
it should keep running.

The comment about "magic" is just that this was a hard-coded constant
rather than a #define somewhere, so it should be fixed in the future.

You can change this if you like.  Making it lower will increase CPU
usage; making it higher will delay application shutdown.  It won't
affect receive performance.

-Johnathan
Paul M. (Guest)
on 2008-10-31 18:30
(Received via mailing list)
I'm working in 915MHz ISM band, using USRP and FLEX900. Stability of
hardware on both xmit and rcv is such that AFC is required, and I'm
struggling with how best to implement it. I examined the archives and
found
threads like this one from May 2008 that refers to work on 'afc.filter':
http://www.nabble.com/atsc_cpll-*almost*-works-tt1...

Can someone comment on the status of this work and suitability for my
purposes and/or refer me to a better starting point for my AFC. Thanks.
Paul M.
Johnathan C. (Guest)
on 2008-10-31 18:32
(Received via mailing list)
On Fri, 2008-10-31 at 09:29 -0700, Paul M. wrote:

> I'm working in 915MHz ISM band, using USRP and FLEX900. Stability of
> hardware on both xmit and rcv is such that AFC is required, and I'm
> struggling with how best to implement it.

What is your modulation type?

-Johnahtan
This topic is locked and can not be replied to.