discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] usrp2 receiving errors, seems to be related to "valve


From: Marcus D. Leech
Subject: [Discuss-gnuradio] usrp2 receiving errors, seems to be related to "valve" or "variable sink"
Date: Sat, 31 Jul 2010 14:09:08 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4

I have an application that implements a simple switched radiometer.  I
use a pair of
  "valve" blocks to implement and SPDT switch for the data flow--one
branch terminatesw
  in a variable sink, the other branch terminates in a GUI scope block,
and a file sink.

An external python script, via xmlrpc, operates the "switched" variable
that switches the
  flow between the "reference" branch and the live data branch.
 Switching occurs with a 50%
  duty cycle.

What I discovered is that after only a few seconds of switching, I get
errors from USRP2:

usrp2: channel 0 not receiving
rx_samples() failed



Initially, I thought that perhaps it was XMLRPC interfering somehow, so
I replaced the switching
  control with a manual GUI "check box" control.  Again, after manually
switching after a few seconds,
  I get the above errors.

The bandwidth is quite modest--250KHz, and the variable sink gets a
filtered/decimated version of
  the data flow, so the requisite "python guts" are only being called
occasionally, relative to the
  data rates.

So, I switched (no pun intended, tee hee) to a different approach
entirely, and that is working fine.
  No "valves", and no variable sinks.   Instead, the input stream is
multiplied either by 1 or -1,
  depending on the value of the "switched" variable, and this is then
low-pass filtered via a
  single-pole IIR filter.  That works as you'd expect--the switching
hardware isn't in place yet, so
  it's presenting alternately the "normal" and "negated" versions of the
input data to the IIR filter,
  which is, as you would expect, converged to near zero.

There are a plethora of approaches to this problem (a switched
radiometer), but I was disappointed
  that my first try not only didn't work, but seemed to exercise some
kind of weird bug in Gnu Radio.
  I'm running the "as of late last night (July 30th, 2010)" GIT of Gnu
Radio, if that matters.

I wasn't able to determine whether it was the valves provoking the usrp2
receive errors, or the
  variable sink, and it seems to be related to the branch that
terminates in the variable sink--if I
  never activate the "switch" so that the data always goes down the
"normal" path, the flow-graph
  just runs and runs normally forever.

!Cheers

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]