Re: [Discuss-gnuradio] one thread is not always scheduled

2013-08-22 Thread Pengyu Zhang
Hi Tom, Do you have some suggestions about how to debug the consume/produce model? For example, how could I verify that the amount of the data produced meets the requirement of the consumer. Thanks. Pengyu On Thu, Aug 22, 2013 at 10:47 AM, Pengyu Zhang wrote: > So you suggested that tag_decod

Re: [Discuss-gnuradio] one thread is not always scheduled

2013-08-22 Thread Pengyu Zhang
So you suggested that tag_decoder module stops after 1000 bit transfer because of the incorrect consume/produce model used by the custom block rather than the STS scheduler. The consume/produce model used by the tag_decoder module is shown below. I will take a close look at the consume/produce mode

Re: [Discuss-gnuradio] one thread is not always scheduled

2013-08-22 Thread Tom Rondeau
On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang wrote: > I'm running Michael Buettner's RFID program. > > https://www.cgran.org/wiki/Gen2 > > This program has many blocks: > > rx --> matched_filt --> command_gate --> agc --> to_mag --> to_mag, center > --> mm --> tag_decoder --> self.reader --> amp

Re: [Discuss-gnuradio] one thread is not always scheduled

2013-08-20 Thread Pengyu Zhang
I'm running Michael Buettner's RFID program. https://www.cgran.org/wiki/Gen2 This program has many blocks: rx --> matched_filt --> command_gate --> agc --> to_mag --> to_mag, center --> mm --> tag_decoder --> self.reader --> amp --> to_complex --> tx I'm always using the STS scheduler because t

Re: [Discuss-gnuradio] one thread is not always scheduled

2013-08-20 Thread Tom Rondeau
On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang wrote: > Hi, > > I build a signal processing pipeline on USRP: RX --> decoder --> protocol > --> TX. I used STS scheduler to schedule those signal processing blocks. > When the amount of data that goes into the decoder module is larger than a > fixed