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 model in each block of the signal processing pipeline.
ninput_items_required[i] = noutput_items + history(); On Thu, Aug 22, 2013 at 9:29 AM, Tom Rondeau <[email protected]> wrote: > On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang <[email protected]> > 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 --> to_complex --> tx > > > > I'm always using the STS scheduler because that's the default > configuration > > to run Buettner's program. Before running the program, we specify > > GR_SCHEDULER=STS. Are there drawbacks of using STS scheduler? > > Yes. If you have more than 1 core, the thread-per-block scheduler will > distribute your blocks over multiple thread units. Also, the TPB > scheduler allows the use of stream tags and async message passing, but > this program doesn't use those. > > > If the amount of data that goes into the tag_decoder module is smaller > than > > 1000 bits, the whole program runs correctly because tag_decoder module is > > scheduled several times to process all the incoming data. If the amount > of > > data is over 1000 bits, the tag_decoder module is scheduled several > times to > > process the first 1000 bits. However, the tag_decoder module never gets a > > chance to be scheduled to process the rest of incoming data. Instead of > > tag_decoder module, only self.reader module is always scheduled at that > > point. > > This sounds like a different problem then what you posted originally. > What does this have to do with launching multiple threads? > > This sounds like a problem in some of the custom blocks from that > project that aren't handing the consume/produce model correctly. > > -- > Tom > Visit us at GRCon13 Oct. 1 - 4 > http://www.trondeau.com/grcon13 > > > > On Tue, Aug 20, 2013 at 11:05 AM, Tom Rondeau <[email protected]> wrote: > >> > >> On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang <[email protected]> > >> 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 number, the decoder thread is scheduled to run for a while, > >> > decodes > >> > the initial part of the incoming data, and is not scheduled anymore > >> > before > >> > it finishes processing the rest of the incoming data. > >> > > >> > I'm a bit surprised to observe that one thread is not always scheduled > >> > by > >> > the scheduler. Does anyone have some ideas on how to tackle this > >> > problem? > >> > Thanks. > >> > > >> > Pengyu > >> > >> > >> I don't follow. How many threads are run? You said 'not always' but > >> that doesn't make any sense. Are you sure it's not consistent between > >> runs? Are you sure you are always using the STS scheduler (and if so, > >> why?)? > >> > >> -- > >> Tom > >> Visit us at GRCon13 Oct. 1 - 4 > >> http://www.trondeau.com/grcon13 >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
