Hi Jeff,
I use burst mode all the time (mostly on N310 but X310 as well). I
usually prefer a `packet_length` tag instead of SOB --> EOB. As Marcus
mentioned, as soon as the first sample goes into the USRP sink, you
start transmitting and need to sustain your sample rate. To ensure that
you provide enough samples, I'd recommend to start with a vector source
and a defined signal. Or use a PDU with a PDU to tagged block to control
the frequency of your individual packets.
A sine wave with increasing amplitude is probably a very useful signal.
And I assume you're aware that bursts should be preceeded and followed
by some zero values to ensure everything is in a steady state as soon as
your real data is transmitted. The proposed signal would be really
useful to debug these issues.
Cheers
Johannes
On 21.01.21 19:34, Jeff S via USRP-users wrote:
Here's an output of a sine wave which replaced the spikey one:
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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
