[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission
From: |
Marcus Müller |
Subject: |
Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission |
Date: |
Tue, 03 Jun 2014 08:44:47 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 |
Hi David,
I think you got that right.
Using msg_port_register_in(..) you could set up a message port, define a
message handler, in which you set a class member (eg. d_datatosend) to
the message'd content, and in your work check whether d_datatosend is
empty or not, and in the latter case, emit that.
That's only one way to solve your non-constant streaming issue, and it's
one of the most computationally intensive, so I don't really know if my
advice was good...
Greetings,
Marcus
On 02.06.2014 23:30, David Halls wrote:
> Hi Marcus,
>
> I'm not sure if understand correctly then, how would you suggest it is
> possible to implement your suggestion
>
> 'a block that (rate limitedly) produces zero-samples, unless data comes in on
> a message port?'
>
> ...My new block is connected to the UHD sink - so this should consume the
> output buffer of the block at a constant rate, and so my setup *should* work?
>
> Many thanks,
>
> David
>
>
> -------- Original message --------
> From: Marcus Müller
> Date:02/06/2014 19:56 (GMT+00:00)
> To: David Halls ,address@hidden
> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1
> transmission
>
> 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<http://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<http://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
> ---------------------------------------------------------------------------------------
- Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission, (continued)
Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission, David Halls, 2014/06/02
- Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission,
Marcus Müller <=