That’s right John, the tx_time tag was required.
This is actually relatively involved to create in a tx flow graph. I
added a UHD source to acquire rx_time which I then pass as a message to
a block just before the twin UHD sink, where I calculate a desired
tx_time.
perhaps someone can chime in as to whether the new message ports that
Martin has added to the UHD blocks allow messages to pass out of the
block or are they for passing info in only? If so this would be an
easier way to do it I guess…
I still get 2 Us (one for each usrp) at the very beginning. Although
this doesn’t seem to damage performance. If I add some padding items to
the beginning before the first burst would this help? and if so what’s
an elegant way to do so?
Interested to hear if anyone can answer John’s question too!
-------- Original message --------
From: John M.
Date:2014/10/16 16:40 (GMT+00:00)
To: David Halls
Cc: Matt E. ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
I’m happy this is working for you, David. So do I understand correctly,
that the adding tx_time finally made the MIMO case work?
I’d never done burst transmission with multiple USRP outputs. I’m not
totally surprised but I wasn’t sure what would happen.
Maybe someone from Ettus can comment on this? Since UHD is trying to do
time alignment in the multi_usrp class, what happens to time alignemt in
the non-continuous-streaming case if you don’t include a tx_time tag?
-John
On Thu, Oct 16, 2014 at 7:23 AM, David Halls
<[email protected]mailto:[email protected]>
wrote:
John thanks for all your help, this works, although it is necessary to
add ‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using
the latest gr-uhd).
If you are using MIMO it is more complicated, as you have to add a
‘tx_time’ tag as well. This is not obvious how to generate in a tx flow
graph.
My solution was to use a UHD source (the same address as the tx USRP),
which generates rx_time, I then created a block which reads in this
rx_time tag and sends it as a message to a block just before my UHD sink
which converts this to a tx_time based on the number of bursts sent, and
the burst interval that I desire.
As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to
use multiple USRPs in the UHD source to produce the rx_time (although
the multiple rx_times will be equal).
From: John M.
[mailto:[email protected]mailto:[email protected]]
Sent: 15 October 2014 20:03
To: David Halls
Cc: Matt E.; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
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.
- 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
<[email protected]mailto:[email protected]>
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 M.
[mailto:[email protected]mailto:[email protected]]
Sent: 14 October 2014 23:42
To: David Halls
Cc: Matt E.; 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
<[email protected]mailto:[email protected]>
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 M.
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt E. ,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
<[email protected]mailto:[email protected]>
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 E.
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff L. ,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
<[email protected]mailto:[email protected]>
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 E.
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff L.
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 L.
<[email protected]mailto:[email protected]> 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.
On 10/14/2014 05:52 PM, Jeff L. wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.
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 0790tel:%2B44%20(0)%20117%20906%200790
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/trlhttp://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]mailto:[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]mailto:[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/trlhttp://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/trlhttp://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]mailto:[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/trlhttp://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/trlhttp://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/trlhttp://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