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: discuss-gnuradio-bounces+address@hidden [discuss-gnuradio-bounces+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
> ---------------------------------------------------------------------------------------
>
>