usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsUSRP's B210 sluggish start of transmission
Hi all,
I'm currently trying to find out how much USRPs B210 are capable of
doing in different tasks.
One of these tasks is transmission of burst with use of UHD's burst api.
To access it I have implemented a GNU Radio app that uses tx_time and
packet_len tags.
Particularly the application was configured to send bursts containing
complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is
2ms, so there should be 0.5us of gap between bursts.
The result of recording of this signal is shown on the attached picture
and it is not what is expected: the gap is about 800us and the length of
pulse is about 1.7ms. About 300us of signal is not transmitted at all.
What it means is that it is problematic to send bursts with use of burst
api. I can attach 300us of signal at the beginning of a burst but what
if there are two bursts in a row that are closer than 300us? One of my
aims is to add ability to transmit gsm bursts to gr-gsm. GSM bursts are
spaced by 8.25us of guard periods... Probably I could find some other
workaround with use of hacks that probably will fail in specific
situations and the whole simplicity provided by burst api will go away
anyway. But I would prefer to not do that if it's possible.
I checked on USRP X310 and everything is fine there - it starts to
transmit almost immediately.
Why does it take so long (and loss of 0.3ms of signal at the beginning)
for USRP B210 to start transmit anything?
Do you know how to make it start transmit faster (100x faster definitely
would make burst api in B210 much more usable).
(UHD used for the test was 3.9.2, carrier frequency of the signal was
940MHz)
--
Best Regards,
Piotr Krysik
Hi Piotr,
Because of the problem you described, and other similar limitations for
stop-and-go usage of the tx_streamer (I'm referring to the C++ UHD API
here), I suggest keeping the tx_streamer always on and just feeding it with
IQ zeros when you don't want to transmit anything. This solution is a
tradeoff: On the pro side the stop-and-go transients will go away, while on
the con side you won't get a perfectly zero RF output when you feed IQ
zeros (e.g., because of carrier leakage and other RF effects).
Best,
Dario
On Sat, Sep 23, 2017 at 4:27 AM, Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hi all,
I'm currently trying to find out how much USRPs B210 are capable of
doing in different tasks.
One of these tasks is transmission of burst with use of UHD's burst api.
To access it I have implemented a GNU Radio app that uses tx_time and
packet_len tags.
Particularly the application was configured to send bursts containing
complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is
2ms, so there should be 0.5us of gap between bursts.
The result of recording of this signal is shown on the attached picture
and it is not what is expected: the gap is about 800us and the length of
pulse is about 1.7ms. About 300us of signal is not transmitted at all.
What it means is that it is problematic to send bursts with use of burst
api. I can attach 300us of signal at the beginning of a burst but what
if there are two bursts in a row that are closer than 300us? One of my
aims is to add ability to transmit gsm bursts to gr-gsm. GSM bursts are
spaced by 8.25us of guard periods... Probably I could find some other
workaround with use of hacks that probably will fail in specific
situations and the whole simplicity provided by burst api will go away
anyway. But I would prefer to not do that if it's possible.
I checked on USRP X310 and everything is fine there - it starts to
transmit almost immediately.
Why does it take so long (and loss of 0.3ms of signal at the beginning)
for USRP B210 to start transmit anything?
Do you know how to make it start transmit faster (100x faster definitely
would make burst api in B210 much more usable).
(UHD used for the test was 3.9.2, carrier frequency of the signal was
940MHz)
--
Best Regards,
Piotr Krysik
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hi Dario,
Of course I can try to use software workarounds duplicating
functionality that doesn't work correctly in B210. But let's at least
try to find an answer what might cause the problem. Then maybe let's try
to estimate how hard it would be to make B210 behave better.
I know that B210 is low cost product (in comparison with other USRPs)
and it's also low on a list of priorities in terms of support. But this
settling time whenever there is start of burst or an underflow seems to
be a symptom of a bigger problem. 300us can't be explained by the time
to turn on amplifier. It might mean for example that every time there is
start of transmission ad9361 chip is restarted. If yes it might be worth
to fix this as UHD's burst mode might not be the only victim of this
approach.
Best Regards,
Piotr Krysik
W dniu 24.09.2017 o 05:56, Dario Fertonani pisze:
Hi Piotr,
Because of the problem you described, and other similar limitations
for stop-and-go usage of the tx_streamer (I'm referring to the C++ UHD
API here), I suggest keeping the tx_streamer always on and just
feeding it with IQ zeros when you don't want to transmit anything.
This solution is a tradeoff: On the pro side the stop-and-go
transients will go away, while on the con side you won't get a
perfectly zero RF output when you feed IQ zeros (e.g., because of
carrier leakage and other RF effects).
Best,
Dario
On Sat, Sep 23, 2017 at 4:27 AM, Piotr Krysik via USRP-users
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
Hi all,
I'm currently trying to find out how much USRPs B210 are capable of
doing in different tasks.
One of these tasks is transmission of burst with use of UHD's
burst api.
To access it I have implemented a GNU Radio app that uses tx_time and
packet_len tags.
Particularly the application was configured to send bursts containing
complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is
2ms, so there should be 0.5us of gap between bursts.
The result of recording of this signal is shown on the attached
picture
and it is not what is expected: the gap is about 800us and the
length of
pulse is about 1.7ms. About 300us of signal is not transmitted at all.
What it means is that it is problematic to send bursts with use of
burst
api. I can attach 300us of signal at the beginning of a burst but what
if there are two bursts in a row that are closer than 300us? One of my
aims is to add ability to transmit gsm bursts to gr-gsm. GSM
bursts are
spaced by 8.25us of guard periods... Probably I could find some other
workaround with use of hacks that probably will fail in specific
situations and the whole simplicity provided by burst api will go away
anyway. But I would prefer to not do that if it's possible.
I checked on USRP X310 and everything is fine there - it starts to
transmit almost immediately.
Why does it take so long (and loss of 0.3ms of signal at the
beginning)
for USRP B210 to start transmit anything?
Do you know how to make it start transmit faster (100x faster
definitely
would make burst api in B210 much more usable).
(UHD used for the test was 3.9.2, carrier frequency of the signal was
940MHz)
--
Best Regards,
Piotr Krysik
Hi all,
For comparison: screenshot of much more "civilized" behavior of USRP
X310 in the same situation.
Best Regards,
Piotr Krysik
Hi all,
An update in my investigation: the problem doesn't appear when
connecting input with output through a cable and an attenuator (VAT-30+
from mini circuits). The problem appears when working on antennas. I've
attached screenshots for situation with a cable and with antennas. What
changes with a cable is that you can see almost whole burst that is
being sent (while for antennas there is the mentioned transition phase).
It might suggest that looking at the electrical schematic of the B210
output and input is what might in the end give answer why B210 has so
long transition phase when starting to transmit. One of the differences
between cable and antennas is that cable+attenuator passes DC.
Best Regards,
Piotr Krysik
