On Wed, Sep 18, 2013 at 3:20 AM, alyafawi <im_yaf...@yahoo.com> wrote: > for a single channel (quite stable): > > USRP -- LPF -- Module -- > > for multi channel (exit with segfault) > > -- LPF -- Module -- > USRP -- LPF -- Module -- > ................... > -- LPF -- Module -- > > I am using xlating_fir_filter_ccf with the proper frequency offset value. > > > I have attached a draft of my module block, pleased to have a look at it if > I am producing/consuming samples wrongly. > > Yes, I am defining nitems_items_required in the forecast. input/ output size > as follow: > gr_make_io_signature(MIN_IN, MAX_IN, sizeof(gr_complex)), > gr_make_io_signature(MIN_OUT, MAX_OUT, 23)), > whenever I found I message, I convert it to char array, and send it to the > next module. > > I am using gr_block where it accept different ratios of input/output rates. > But with my current implementation, this ratio is not M:N, where M, N are > integers, it can be any ratio (nitems:sample_number as in the attached file) > > From my understanding to the scheduler, the left over samples in the module > (provided = X, consumed = Y, left = X-Y) will be concatenated in the front > of the new stream, regardless how much was left.
Yes, that's correct. > could it be I have to keep the provided:consume ratio as an integers ratio? > then I achieve this using local buffers in the module ? The ratio doesn't need to be an integer. > I checked the timestamp of messages captured by two USRPs running single > channel code in parallel, the resolution was within one symbol duration > (1/R). while the multi channel code, showed a difference of more than one > symbol duration (> 1/R) which I thought its due to samples disorder while > splitting the branches. That lead me to the first question about "faster" Unfortunately, there is only so much I can do to help you with these problems. As I said, you seem to have a good grasp on what's supposed to happen. I have a feeling you're just implementing something wrong. My advice again is to not use a USRP for debugging the block. Create a simulation of 2 channels of data and feed that in and keep track of how many you're consuming, how many you're producing, the message sizes, etc. Often, when it comes to these problems, I find it really helpful to draw out the buffers and the boundaries and walk through it step by step to make sure I'm taking care of all items correctly. -- Tom GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
