[Discuss-gnuradio] Measuring execution rate

2012-11-06 Thread Ben Gear
All, Can anyone tell me if there is a way I can measure the rate at which a flow graph is executing when it contains no rate limited blocks? My motivation for doing this is that I wish to benchmark a signal processing chain so that I can estimate the maximum bandwidth I can expect to process with

Re: [Discuss-gnuradio] M-block integration status

2010-01-15 Thread Ben Gear
Hi Eric, Great to have an update on how the new features are progressing. m-blocks and the replacement features have been mentioned a few times on this mailing list in relation to building TDMA MACs. Having VRT metadata available in gr blocks is going to give access to timestamps for Rx samples;

Re: [Discuss-gnuradio] Block processing order

2009-12-08 Thread Ben Gear
Thanks Eric, My concern was that the scheduler might be creating multiple threads to process the same work method with different blocks of stream samples at different point in time. I haven't managed to locate the multi-threaded scheduler code yet. The fact that there is only one thread per work

[Discuss-gnuradio] Block processing order

2009-12-07 Thread Ben Gear
until the first high bit is received and then the output will remain high until it is reset. If I store the latch state in a member variable is it guaranteed that when the latch is triggered at a given sample number all the output sample before hand will be 0 and all after will be 1? Many thanks,

[Discuss-gnuradio] 'usrp2::tx_raw: FIXME: short packet' from digital/benchmark_tx.py

2009-06-23 Thread Ben Gear
All, I've two USRP2s each with a XCVR2450 and have been attempting to run the digital mod/demod example code, namely benchmark_tx.py and benchmark_rx.py under examples/digital/.I should point out that otherwise the USRP2s seem to be functioning more or less fine: I can run usrp2_fft.py and usr