>When using the single-threaded-scheduler, if the flow graph consists >of more
>than 1 distinct subgraph, each subgraph will get its own >thread. (Most often
>you'll see this with a transceiver, where the Tx >and Rx are implemented by
>separate hier blocks that are contained by >the single top_b
Hi, all
I met a problem when I tried to read data from USRP. I hope someone can help
me. Thanks.
Here is my flow graph:
source_c --> keep_one_in_n --> g.head --> gr.complex_to_mag -->
gr.vector_sink_f
if __name__ == '__main__':
tb = top_block()
try:
tb.start()
what do you mean updated? Where and when do you print the data?
If you print it after the block stops, the data will not change anyway.
--
Yang
Sent with Sparrow
On 2011年5月22日星期日 at 下午10:13, lishan_wh wrote:
> Hi, all
> I met a problem when I tried to read data from USRP. I hope someone can hel
I mean data should be different at different time. I print data after it is
assigned
def main(tb):
while(True):
time.sleep(1)
data = tb.dst.data()
print data
At 2011-05-22 23:14:11��Yang wrote:
what do you mean updated? Where and when do you print the data?
If you print it after the block stops
Hello list!
I've updated (or at least tried updating) two of UCLA ZIGBEE PHY project's
examples to work with UHD - cc2420_txtest.py and cc2420_rxtest.py. I think the
tx one works fine (spectrum analyzer says that we truly are transmitting at the
given frequency), however the rx example isn't r
I'm looking for a way to create a block that can find the USRP source
and/or sync in the flowgraph and be able to get to the dboard iface for
doing write_aux_dac and write_io. Bottom line I'd like to write an AGC
block that can manipulate a custom card. Is there a facility for finding
other block i
Follow up to self here- can anyone confirm whether I'm understanding
this right?
Looks like gr_edge_vector_t is a shared/static vector with all the edges
Say I take this guy from gr_hier_block2_detail and modify it:
gr_edge_vector_t edges, tmp = d_fg->edges();
gr_edge_vector_t::iterator p;
On Sun, May 22, 2011 at 11:37 PM, Brett L. Trotter wrote:
> Follow up to self here- can anyone confirm whether I'm understanding
> this right?
>
> Looks like gr_edge_vector_t is a shared/static vector with all the edges
>
> Say I take this guy from gr_hier_block2_detail and modify it:
>
> gr_edge
> Blocked waiting for GDB attach (pid = 5466)
> Press Enter to continue:
> cordic_freq = 2.45G
Not sure whats wrong, but, cordic_freq should be the error in tuning the
RF center freq, so only a few kHz really. That may be a good place to
start looking.
-josh
___
