Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[Marcus Müller]

Hi David,

you're right, the scheduler will only call your block when out- or input
buffer situation have changed, and there's no elegant way to coerce that.
However, given a sink that consumes with a constant continous rate, that
will never be a problem for a longer time.

Greetings,
Marcus

On 02.06.2014 18:55, David Halls wrote:
> Hi All, Marcus
>
> I have created a simple block (not yet finished) to create zeros. How do I 
> get this to be scheduled if there are no items at the input? If I connect a 
> source to it, then it works, if I connect my 'sample source b' to it which 
> has no items at time zero, then the block is not scheduled.
>
>     void
>     avoid_block_impl::forecast (int noutput_items, gr_vector_int 
> &ninput_items_required)
>     {
>         ninput_items_required[0] = noutput_items;
>     }
>
>     int
>     avoid_block_impl::general_work (int noutput_items,
>                        gr_vector_int &ninput_items,
>                        gr_vector_const_void_star &input_items,
>                        gr_vector_void_star &output_items)
>     {
>         const gr_complex *in = (const gr_complex *) input_items[0];
>         gr_complex *out = (gr_complex *) output_items[0];
>
>                 for(int idx=0; idx < noutput_items; idx++)
>                 {
>                         out[idx] = 0;
>                 }
>
>         // Tell runtime system how many input items we consumed on
>         // each input stream.
>         consume_each (noutput_items);
>
>         // Tell runtime system how many output items we produced.
>         return noutput_items;
>     }
>
> Regards,
>
> David
> ________________________________________
> From: Marcus Müller address@hidden
> Sent: 02 June 2014 17:16
> To: David Halls; address@hidden
> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 
> transmission
>
> Hi David,
>
> "easiest" way to achieve coherence on both USRP would be a MIMO cable,
> or GPSDO's.
> That being said, depending on your definition of "sync", just setting
> the time at both USRPs would little to some little, yet existent error.
> This error should also occur when using the two USRPs with the same USRP
> Sink, as long as you don't physically synchronize them. You could then
> issue timed commands. The python code would look something like:
>
> zero_time = uhd.time_spec(0.0)
> usrp_sink0.set_time_now(zero_time)
> usrp_sink1.set_time_now(zero_time)
>
> If both can receive the same signal, you could synchronize on a signal
> that both receive; that would of course make your application more
> complex, and also needs to be done periodically, since it's physically
> impossible to keep clocks perfectly aligned over a long time.
>
> Greetings,
> Marcus
>
> On 02.06.2014 17:49, David Halls wrote:
>> Hi Marcus,
>>
>> Yes, your diagram represents what I am trying to achieve.
>>
>> Using two sinks would be really nice! But I have had some problems with 
>> achieving sync using time stamps (where as using one UHD sink is very 
>> straightforward). For example, how do I obtain the current time from the 
>> transmit USRPs, but from another block in the flow graph - in order to 
>> create a tx_time with the right value? Where I have a UHD source its easy as 
>> these output an rx_time tag...
>>
>> I thought that I could use
>>
>> ::uhd::time_spec_t
>>     usrp_sink_impl::get_time_now(size_t mboard)
>>     {
>>       return _dev->get_time_now(mboard);
>>     }
>>
>> but how do I get a pointer to this in other blocks in the flow graph?
>>
>> I like the idea of the block to creates zeros (with rate limiting), unless 
>> there is an input signal. Will this block get scheduled even if there are no 
>> items at its input, though? Isn't that similar to my simple idea of using a 
>> mux between a noise source (with 0 amplitude) with sample source b?
>>
>> I will try to provide some more detail, although the setup is complicated 
>> indeed and might involve explaining a lot of the background...
>>
>> Regards,
>>
>> David
>> ________________________________________
>> From: address@hidden address@hidden on behalf of Marcus Müller address@hidden
>> Sent: 02 June 2014 15:50
>> To: address@hidden
>> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1      
>> transmission
>>
>> Hi David,
>> Generally, this sounds like in principle, your application looks like
>> (nb: not an actual GR flowgraph)
>>
>> +-----------------+             +------+
>> | sample source a |------------>| USRP |---> [USRP1]
>> +-----------------+             |      |
>>                                 | sink |
>> +-----------------+             |      |
>> | sample source b |------------>|      |---> [USRP2]
>> +-----------------+             +------+
>>
>> Let's assume a is continuous and b starts later, or bursts or the like.
>> Can't you just split the flow graph into two independent flowgraphs,
>> syncing the USRPs using time stamps?
>>
>> Alternatively, what about having a block that (rate limitedly) produces
>> zero-samples, unless data comes in on a message port?
>>
>> Generally, using start-of-burst tags, the newly added command time
>> message interface for the uhd blocks, and multiple ways to detangle your
>> sample streams, there are many ways to solve your issues.
>> I think it would be wise if you described your setup in a little more
>> detail.
>>
>> Greetings,
>> Marcus
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ________________________________
>>
>> NOTE: The information in this email and any attachments may be confidential 
>> and/or legally privileged. This message may be read, copied and used only by 
>> the intended recipient. If you are not the intended recipient, please 
>> destroy this message, delete any copies held on your system and notify the 
>> sender immediately.
>>
>> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
>> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 
>> 0GZ, England. Web: www.toshiba.eu/research/trl
>> ---------------------------------------------------------------------------------------
>>  This email has been scanned for email related threats and delivered safely 
>> by Mimecast.
>>  For more information please visit http://www.mimecast.com
>> ---------------------------------------------------------------------------------------
>>
>>
> ________________________________
>
> NOTE: The information in this email and any attachments may be confidential 
> and/or legally privileged. This message may be read, copied and used only by 
> the intended recipient. If you are not the intended recipient, please destroy 
> this message, delete any copies held on your system and notify the sender 
> immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
> England. Web: www.toshiba.eu/research/trl
> ---------------------------------------------------------------------------------------
>  This email has been scanned for email related threats and delivered safely 
> by Mimecast.
>  For more information please visit http://www.mimecast.com
> ---------------------------------------------------------------------------------------
>
>