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 ,[email protected] > 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 [[email protected]] >> Sent: 02 June 2014 17:16 >> To: David Halls; [email protected] >> 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: [email protected] >>> [[email protected]] on behalf >>> of Marcus Müller [[email protected]] >>> Sent: 02 June 2014 15:50 >>> To: [email protected] >>> 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 >>> [email protected] >>> 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 > --------------------------------------------------------------------------------------- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
