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 <david.ha...@toshiba-trel.com> 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 Malsbury [mailto:jmalsbury.perso...@gmail.com] > *Sent:* 15 October 2014 20:03 > > *To:* David Halls > *Cc:* Matt Ettus; 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. > > 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 > ------------------------------ > > > > ------------------------------ > > 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
