[USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission
bistromath at gmail.com
Fri Oct 6 11:48:56 EDT 2017
This is especially baffling to me, because I recall that the SKY13335-187LF
switches used in B210 must be isolated from DC on all RF ports. But they
are! The only components connected to the SMA connectors are a series 470pF
Perhaps the problem is exacerbated by poor impedance matching rather than
by lack of a DC path. If reflected power was causing the problem I'd expect
lowering the transmit gain to affect your results. Could you try that for
On Fri, Oct 6, 2017, 1:41 AM Piotr Krysik via USRP-users <
usrp-users at lists.ettus.com> wrote:
> W dniu 27.09.2017 o 07:06, Piotr Krysik via USRP-users pisze:
> > Hi all,
> > I narrowed down when the issue occurs.
> > When using separate sides of B210 for transmitting (i.e. TX/RX port on
> > RF A side) and receiving (i.e. RX2 port on RF B side) everything is fine
> and B210 starts transmitting like i.e. X310.
> > The problem appears when transmitting and receiving on the same side of
> > B210 and it is dependent on what you connect to the TX port. The 300us
> > transition appears if I don't connect anything and measure the TX-RX
> > leakage or when VERT900 antenna from Ettus is connected.
> > I tried also to connect a power splitter to the TX port and an antenna
> > to one of the splitter's ports - with the same result. But as soon as I
> > connected the 30dB attenuator to another port of the splitter, the
> > problem immediately goes away.
> >> The attenuator also has a path (resistive 50 ohms) to ground....an
> >> antenna with a small pad on it (say 1 db) will probably work fine as
> >> Kent Torell
> > So you might be right here Kent that it was the path to the ground in
> the attenuator that
> > changed how the output behaves. It is funny thought that the problem
> > only appears when RX2 port on the same side of B210 is also used :).
> Hi all,
> As for my current application transmitting bursts and receiving
> continuous signal with use of all B210 RF ports is not required, I can
> avoid the problem. So I don't have currently motivation to pursue the
> investigation further.
> The problem isn't solved though. There are of course applications in
> which it is required to use all RX and TX ports and it is convenient to
> transmit burst. If someone needs it I can provide the codes that I used
> for tests (they are not secret, I just don't want to lose time on
> preparing them in case there is no such person). What I have is a GNU
> Radio block that adds tx_time and length tags to a signal, with user
> defined burst length and gap length. From the tagged stream UHD sink is
> able to produce bursts instead of continuous signal. I have also a GRC
> application that presents the problem.
> Best Regards,
> Piotr Krysik
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users