Re: [Discuss-gnuradio] multiple asynchronous channels in parallel

[Tom Rondeau]

On Wed, Sep 18, 2013 at 3:20 AM, alyafawi <address@hidden> 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