Also, I would have sent you a sample flow graph.. but the computer I'm in
front of has an embarrassingly old version of GR.
On Wed, Oct 15, 2014 at 12:03 PM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:
> Hmmmm.. I've never done burst transmissions with a 2x MIMO case. That may
> or may not put a minor wrinkle in things. Let's go for the gusto and try
> this anyway...
>
> (or were you not looking for a burst transmission?)
>
> This assumes you're using a relatively recent (past couple months?) build
> of UHD and GR.
>
> 1. Produce some data as a PDU. The quickest is to use a message
> strobe into a random PDU generator. If you want data you control, use a
> message strobe with something like this as the message value:
>
>
>
> pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))
>
> Of course, you'd ultimately replace this fixed or random data with
> your own PDU-producing block. Or maybe use some clever python inside or
> outside the flowgraph.
>
> 2. Use PDU-to-stream block, make sure the length tag name matches
> whatever UHD is using downstream (this is a parameter in the uhd sink now).
>
> 3. Put that stream through your modulator.
>
> 4. I think there's a block that multiplies the value of the length in
> the length tag. set this to the interpolation factor of your modulator and
> put it somewhere in the chain. If this block does not have one, borrow the
> one from gr-mac. "burst_tagger"
> <https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>
>
> In summary:
>
> *Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->
> [see how the constellation works]*
>
> Give it a shot. If it doesnt work, give a brief try with the SISO case.
>
> You'll want to add some leading/trailing samples to flush FIR-filters and
> such for the full frame to get out of the USRP unscathed. We can address
> this next...
> -John
>
> On Wed, Oct 15, 2014 at 11:47 AM, David Halls <
> david.ha...@toshiba-trel.com> wrote:
>
>> Hi John,
>>
>>
>>
>> I have been trying at this all day! Not familiar with the async message
>> stuff, I have tried putting ‘sleep()’ in the source block, I have tried a
>> throttle outside it and even discarding the first X items just before the
>> UHD sink to flush the buffer away.
>>
>>
>>
>> This all causes weird underflows and things at the USRP and results in a
>> horrible looking constellation at the RX (I am transmitting 2x1 MISO which
>> requires perfect TX sync). This is exactly the behaviour, I think, that
>> Matt warned of!!
>>
>>
>>
>> Could you give me a bit more of an idea of how to even do the simpler
>> idea, that I had thought of… I need to basically trigger the source at
>> certain intervals. How does the message queue interact with the block, does
>> the program flow jump to ‘parse_header_data_msg()’ automatically when a
>> message arrives?
>>
>>
>>
>> DH
>>
>>
>>
>> *From:* John Malsbury [mailto:jmalsbury.perso...@gmail.com]
>> *Sent:* 14 October 2014 23:42
>> *To:* David Halls
>> *Cc:* Matt Ettus; GNURadio
>>
>> *Subject:* Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>> In the implementation I have in mind, the upstream logic didn't make
>> decisions on when the data generating block should generate data per se...
>> Instead, the upstream block provided feedback on the number of packets
>> received by the USRP (via the old async message block). With this feedback
>> and knowledge of the interpolation steps between itself and the USRP, the
>> data generating block could throttle its own output to achieve a specified
>> latency [on the order of 10's of ms].
>>
>> I think using a simpler scheme of triggering with an async message would
>> be a more convenient place to start though... What do you think, David?
>>
>>
>> -John
>>
>>
>>
>> On Tue, Oct 14, 2014 at 3:23 PM, David Halls <
>> david.ha...@toshiba-trel.com> wrote:
>>
>> Hi John,
>>
>>
>>
>> Nice to hear from you.
>>
>>
>>
>> Perhaps in a similar fashion to Martin's HPD block; I can pass a message
>> back from later in the flow graph to indicate when to release a packet from
>> the source?
>>
>>
>>
>> David
>>
>>
>>
>> -------- Original message --------
>>
>> From: John Malsbury
>>
>> Date:2014/10/14 23:08 (GMT+00:00)
>>
>> To: David Halls
>>
>> Cc: Matt Ettus ,GNURadio
>>
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>> David,
>>
>> Perhaps you can use an async message to trigger the blocks output?
>>
>> In some applications that require filler between valid data frames, I've
>> seen people throttle based off of the number and size of received messages
>> at the USRP.
>>
>> -John
>>
>>
>>
>>
>>
>> On Tue, Oct 14, 2014 at 3:02 PM, David Halls <
>> david.ha...@toshiba-trel.com> wrote:
>>
>> That sounds promising. The only thing is that the data *is* valid from
>> time zero, but I just want to send the values from my source block, say
>> once per second.
>>
>>
>>
>> What can I use to block in my block, just not produce any items for some
>> period of time or a number of calls? and is there anyway to know when I
>> can stop blocking? What will fill the buffers further down the chain?
>>
>>
>>
>> thanks,
>>
>>
>>
>> David
>>
>>
>>
>> -------- Original message --------
>>
>> From: Matt Ettus
>>
>> Date:2014/10/14 22:56 (GMT+00:00)
>>
>> To: David Halls
>>
>> Cc: Jeff Long ,GNURadio
>>
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>>
>>
>> No, if you don't have anything useful to output in a source block, you
>> can (and should) block while you wait. If you have something useful, but
>> not as much as requested, you can output only what you have. There is no
>> need to generate filler in GNU Radio.
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>> On Tue, Oct 14, 2014 at 2:43 PM, David Halls <
>> david.ha...@toshiba-trel.com> wrote:
>>
>> Matt,
>>
>>
>>
>> In my source block I can limit the calls to the DB ok, but I will still
>> need to output something from the block, won't I? This will then propagate
>> and fill the buffers?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> David
>>
>>
>>
>> -------- Original message --------
>>
>> From: Matt Ettus
>>
>> Date:2014/10/14 19:09 (GMT+00:00)
>>
>> To: Jeff Long
>>
>> Cc: GNURadio
>>
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>>
>>
>> Jeff,
>>
>>
>>
>> If there is a hardware device like a USRP in the chain, then you should
>> not use a throttle block. What you are seeing is the initial startup
>> burst. When everything starts up, all the buffers are empty, and GNU Radio
>> will generate data until something backs up. Once they fill up, you are
>> seeing the rate settle down. This is all normal.
>>
>>
>>
>> If you really need to rate limit what gets requested of the database
>> during the initial transient (which I don't recommend), you should do that
>> within your source block.
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long <willco...@gmail.com> wrote:
>>
>> Should have mentioned ... set the throttle rate just slightly higher than
>> what the chain would consume at steady state when all the buffers are
>> filled and the USRP is transmitting. How well this works depends on what
>> the rest of the chain looks like.
>>
>> - Jeff
>>
>>
>>
>> On 10/14/2014 05:52 PM, Jeff Long wrote:
>>
>> Use a throttle block immediately after your source block, setting the
>> vector size to match your source.
>>
>> - Jeff
>>
>> On 10/14/2014 04:34 PM, David Halls wrote:
>>
>> Dear All,
>>
>> I am wondering how to add some flow control to a source block, so that
>> it doesn’t fire out items so quickly.
>>
>> Later stages of my flow graph are slowed by various bits of processing
>> and combining, before transmission via USRP, with bursts being
>> transmitted every few seconds.
>>
>> What happens is that the block fires out 1,000s of vectors, and then
>> seems to slow down and settle into sync with the rest of the flow graph
>> after a few seconds. As my source block is reading in from a Database, I
>> want to slow this initial rate significantly.
>>
>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>
>> Regards,
>>
>> David
>>
>> ---------------------------------------------------------------
>>
>> David Halls Ph.D.
>>
>> Research Engineer
>>
>> Toshiba Research Europe Limited
>>
>> 32 Queen Square, Bristol, BS1 4ND, UK
>>
>> Tel: +44 (0) 117 906 0790
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> 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
>> ------------------------------
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> 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
>> ------------------------------
>>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
