Usrp2 bg_loop() magic?

GNU Radio
1

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.

2

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-tt17353907.html#a17353907

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.

3

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

4

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