On Fri, Apr 29, 2016 at 10:35 AM, Henning Bredenberg < henning.bredenb...@tuhh.de> wrote:
> Hi Tom, > > That's what i thought the message strobe does. I tried different times but > the time sink output doesn't change and shows a continuous signal flow. I > changed the burst size in the random_pdu_generator but nothing changes. No > matter what options are changed, the time sink shows a continuous stream > with the "packet_lenght" tags from the pdu_to_tagged_stream-block as seen > in the attached file (1k interval in the message strobe block, 256 Bytes > generated). > > So i thought maybe the following blocks, after the generator and before > the time sink, i.e. pdu_to_tagged_stream and the PSK_mod (GRC flow graph > attached in the first post) just consume the items, produce output items > and don't care about the time when a pdu was generated. That leads to the > general question for me: At which rate is the pdu sent? how long is the > transmission time for a fixed size pdu and how can I determine it? > > > Thanks for taking time and have a nice weekend all. > Best regards, > Henning Yes, that's exactly how this should behave. When you "stop" time in a flowgraph, samples don't continuously flow. So even if you send a PDU at time 0, wait a second, and send another, there is no data between the end of the first PDU and the start of the second PDU even though 1 second has elapsed in wall time. One way that I've simulated the effect you're going for is to use a stream mux with a null source as the second input. Have it pass the PDU from the first stream, then calculate the number of samples of 0's you want between PDUs and mux those in as the second stream. Tom > > Quoting Tom Rondeau <t...@trondeau.com>: > > On Fri, Apr 29, 2016 at 5:30 AM, Henning Bredenberg < >> henning.bredenb...@tuhh.de> wrote: >> >> Hi Marcus, >>> >>> Thanks for your response. I realized that I have a more fundamental >>> problem before optimizing this project: >>> Can u give me hints on how I can generate one simple PDU? My flowgraph >>> now >>> keeps generating >>> one PDU after the other and the time sink display is continuously filled >>> with samples. >>> >>> In my understanding the different blocks create output items as long as >>> input items are generated. In this case the flowgraph only stops when >>> closed manuelly. So I would need a generator block who generates one >>> output item, i.e. one PDU, and then stops creating output items. Maybe it >>> is possible to create one PDU following by output items that are just >>> zeros? Is it possible to do that with the random_pdu_generator block or >>> are >>> there any other generation blocks that I should investigate? >>> >>> My goal in general is to generate one simple packet burst that fits into >>> a >>> 20 ms slot. I have issues with this first step, before changing things >>> like >>> adding delays etc. >>> >>> >>> Best regards, >>> Henning >>> >> >> >> >> Henning, >> >> You can use the Random PDU Generator block to send just a single PDU into >> your flowgraph. It has an input message port called "generate" that >> triggers the block to send more PDUs. You can use the Message Strobe block >> to make the Random PDU Generator post a message at given intervals. Or you >> could use the new Edit Box Message (just merged into master yesterday) to >> trigger a new PDU every time to press enter when in that box. >> >> Tom >> >> >> >> >> Quoting Marcus Müller <marcus.muel...@ettus.com>: >>> >>> Hi Henning, >>> >>>> >>>> to only answer the first part of your questions: >>>> On 04/27/2016 03:22 PM, Henning Bredenberg wrote: >>>> >>>> Hi Martin, >>>>> >>>>> the time tag 'tx_time' tells the USRP when to transmit - so far so >>>>> good. So I don't need any delay blocks because the USRP sink realizes >>>>> the delay, right? >>>>> >>>>> Nearly! In fact, the USRP itself realizes that in hardware -- which is >>>> much, much better, because that hardware "knows" and runs at a rate >>>> directly linked to the sampling rate and LO frequencies; if your PC >>>> waited the 240ms of "PC clock time", that might be anything between 238 >>>> and 300ms "USRP time", if we add non-deterministic delay of the USB >>>> transport for commands. So: there's a feature in the FPGA image that >>>> allows you to specify "hey, FPGA, I want you to execute that "start >>>> streaming" command *exactly* at the clock tick nr 12147, and it will do >>>> that. >>>> >>>> Assume i want to add a propagation delay of 240ms: Setting 'tx_time' >>>>> at the begin of the burst to 240ms will realize that? >>>>> >>>>> No, you should first set the device time to something sensible (or just >>>> roll with it being set to zero on device initialization) and use >>>> relative times to that. >>>> Minor caveat: if you're using a device with adjustable master clock rate >>>> (mainly: B2xx and E31x), and you change the MCR after setting the time, >>>> the host won't know when that change of "tick rate" happened, and the >>>> conversion between timestamps and tick numbers will be pretty random. >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>>> >>>>> Do I tag the burst in the code of the PDU-generator using >>>>> add_item_tag() or is there another block who does it after the >>>>> generator (I thought the pdu_to_tagged_stream - block tags the packet)? >>>>> >>>>> The crucial code in the random_pdu_impl.cc is: >>>>> [...] >>>>> // pick a random vector length >>>>> int len = d_rvar(); >>>>> len = std::max(d_length_modulo, len - len%d_length_modulo); >>>>> >>>>> // fill it with random bytes >>>>> std::vector<unsigned char> vec(len); >>>>> for (int i=0; i<len; i++) >>>>> vec[i] = ((unsigned char) d_bvar()) & d_mask; >>>>> >>>>> // send the vector >>>>> pmt::pmt_t vecpmt(pmt::make_blob(&vec[0], len)); >>>>> pmt::pmt_t pdu(pmt::cons(pmt::PMT_NIL, vecpmt)); >>>>> >>>>> message_port_pub(PDU_PORT_ID, pdu); >>>>> [...] >>>>> >>>>> My idea then is to use add_item_tag here with 'tx_time' as key for the >>>>> output vector "PDU_PORT_ID", i.d. "pdus" in GRC. >>>>> >>>>> An additional question: How do I set a data rate that determines how >>>>> long a packet needs to be transmitted? Is that done by USRP as well? >>>>> >>>>> By now the time sink just shows a blue, continuous signal as seen in >>>>> the attached picture. >>>>> >>>>> Best regards, >>>>> Henning >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
