Here's an output of a sine wave which replaced the spikey one: [cid:8d38035e-60ec-4052-99cd-9185c4bb5015]
I think that shows what I believe you were explaining, that the SOB/EOB doesn't work like I thought. I was using them as packet identifiers and assumed the USRP would wait for the whole packet to begin transmission, but your description seems to indicate that tx_sob turns the radio on and tx_eob turns the radio off (maybe a simplification?) and just streams whatever it sees during that time. And during that time, the buffer may be empty because data isn't produced fast enough. The time between the segments of the sine wave show the delay from one call of the work function to the next. There is a delay within the source that slows the output of the data, and since I thought the SOB/EOB combination would only transmit after the EOB was received, I did not think it would be a problem. It obviously is. I now have to think of a way to do that with random length data. Maybe add a tx_time to provide some delay before transmission? Jeff ________________________________ From: Marcus Müller <marcus.muel...@ettus.com> Sent: Thursday, January 21, 2021 10:29 AM To: Jeff S <e070...@hotmail.com>; usrp-users <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal Hi Jeff, thanks for clarifying! Yes, that should work. Also, your GR version definitely has support for SOB/EOB. Generally, I'd expect this to work; only misconception I see is that the Sink doesn't start sending when it sees the EOB; it starts sending at SOB, and stops expecting and sending samples to the USRP at EOB. Could you try replacing your very "spikey" signal with something like a sine, so to see whether we might be seeing turn of/off behaviour? Best regards, Marcus On 21.01.21 16:34, Jeff S wrote: > Thanks, Marcus. > > Of course, I forgot the important version information. I'm currently using > v3.7.13.5. We > are also doing some RFNoC work, which we had some issues upgrading a while > back, so we > were holding off until it matured more. I'll ask our team if they want to > try and upgrade > to 3.8 again. > > I'm sure my description wasn't clear, so I'll try and clarify a little better > based on > your feedback. > > I created the Random Source, and it is sending approximately 10,000 samples > to the UHD > USRP Sink as one message, with a tx_sob at the start and a tx_eob at the end. > My thought > was that the sink would not transmit anything until the EOB was received. > The way > GNURadio seems to be running, I'm getting [noutput_items == 4096], so it > takes three calls > to the work function to deliver all 10K samples of one message to the Sink. > I only want > one burst from the sink of those 10K samples. What I am receiving seems to > be three > transmissions that make up the one sample. The length of the three > transmissions seem to > correspond to the value of noutput_items I was seeing. > > The mention of 100 ms between bursts was only indicating how fast the > modulator was being > requested to transmit a single message. So if I only requested one message, > there would > have been one group of three signals seen in the Rx signal. > > Hope that clarified what I was trying to convey a little better. > > Regards, > Jeff > > > > ------------------------------------------------------------------------------------------ > *From:* Marcus Müller <marcus.muel...@ettus.com> > *Sent:* Thursday, January 21, 2021 9:06 AM > *To:* Jeff S <e070...@hotmail.com>; usrp-users <usrp-users@lists.ettus.com> > *Subject:* Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal > > Hi Jeff, > > which version of GNU Radio are you using? Judging by the looks of your flow > graph it's the > (now legacy) 3.7, but *if* I remember correctly (it's really been a while), > the SOB/EOB > functionality appeared *somewhen* in 3.7.x; it might be worth trying your > exact same > application in GNU Radio 3.8 (or 3.9). > > Conceptually, it's important to note that after tx_sob you need to supply the > full burst > of samples: I think you're doing that, but then again, you say you get three > data bursts > 100 ms apart, so I'm not sure about that, to be honest. The USRP sink can't > guess that you > want three bursts of samples to be sent as one; it starts streaming as fast > as you supply > it data after the SOB, and will tell you you're late or too slow at supplying > data (tG/U > printed to your console) if you don't give it 10 million samples a second, > until it gets > an SOB. > > Best regards, > Marcus > > > On 21.01.21 15:53, Jeff S via USRP-users wrote: >> I am attempting to use burst mode on an X310. I'm generating a random >> signal from one >> X310 and receiving it on another. My simple flowgraph is: >> >> I can see the tx_sob and tx_eob tags, set to true, from the time sink: >> >> >> where I verify that I can see the EOB, followed by a new SOB in the next >> message (both set >> to true, according to >> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html > <https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html> >> <https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html > <https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html>>). > But when I am >> receiving the signal, the message seems to be broken up into three different >> transmissions >> instead of one burst: >> >> >> >> I'm transmitting a message every 100 ms, which seems to correspond to the >> start of the >> three messages. >> >> Analyzing the modulator in a debugger indicates that there are three times >> that the work >> function is called to build the message, which may correspond to the three >> messages seen >> in the signal, but I'm not sure why the tx_sob and tx_eob tags are not being >> followed. >> Maybe I may just have a major misunderstanding of how burst mode works. >> >> Any ideas on what I may be doing wrong? >> >> Thanks, >> Jeff >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
