Hello all,

My questions concern the B205i. I've uploaded some pictures to simplify the explaining process.

http://imgur.com/a/XMAv6

Basically, I want to transmit and receive a FSK waveform on one board (loopback). This means I've tuned both LOs to the same frequency. I've also inserted a splitter to be able to look at the signal on my VSA.  This has allowed me to identify several problems.

Let's start on the left:
(B205i Receive - no zeros)
Here you see the received power drop from the noise floor to -infinity because the rx_streamer was returning 0's. I've tracked this problem to the creation of a tx_streamer while an acquisition is running. This seems completely unacceptable; that calling a command on a chain (tx) that has nothing to do with rx, has an effect on rx. I could understand that the sample rate performance of rx is affected because they share a communication link, but not to actually alter the data that is returned by the recv call. Is this a known bug? Is there a workaround other than "don't do that"? Is this bug slated for a fix next release?

Next:
Right after all of the 0's, a strong but brief tone is blasted into the tx path. The power of this tone is not affected by the tx gain setting. This is quite a significant problem because we may use this module to test sensitive devices that may not be able to withstand such a transient. Any idea what is causing this? Again, any workarounds or fixes known?

I don't care much for the spur at -83dBm. But it would be interesting to understand it.

Lastly:
The actual waveform is transmitted. Since this is an FSK waveform, I would expect a constant power envelope. Unfortunately, what I capture with the B205i is not even close. I performed the test again, but this time transmitting 200ms of 0s before my actual FSK waveform. You can still see the "warm up" looking behavior, however, by the time the actual waveform hits, the output seems settled. Is that what is happening (warm up)? Preloading every waveform with 200ms of zeroes is extremely undesirable. Is there a way to keep the chip always ready to go from both a Rx and Tx perspective?

Tx only with no zeros:
I performed the no zeros test again, this time without doing an acquisition with the B205i. Now the warm up behavior is completely gone. Why is Rx influencing the Tx RF performance?

Any insight into these issues I am experiencing would be very appreciated.

Best regards,
Dominik

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233
Fax:    +49 (0) 351 7958019 232
Email:  dominik.eyerly@konrad-technologies.de

KONRAD GMBH — FRITZ-REICHLE-RING 12 — D-78315 RADOLFZELL
www.konrad-technologies.de [1]
www.abexstandard.org [2]

SUPPORT TELEFON: +49 (0) 7732 9815 100
support@konrad-technologies.de

Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hello,

Thanks for the reply. I should add I am doing this test at 3.8G.

Response to (A)

Are you saying that regardless of my tx gain setting, I need 40dB of
attenuation? I believe at max tx gain the board outputs around
10-15dBm @3.8G. I currently have a 6dB pad on tx port, cabled to a
splitter which is cabled to the rx port with an inline 10dB pad. The
other splitter port is going directly into my VSA.  Also, my tx gain
is around 50dB. My understanding was that the max input power of the
rx port is -15dBm. With this configuration I should be well under
that, as shown on my VSA capture (~-35dBm).

Response to (B)

According to the rough specifications posted here:
https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications

The IIP3 is -15dBm. As you can see on my VSA capture, it received
-35dBm and that doesn't even include the extra 10dB pad on the ettus
rx port. I should be good on linearity, should I not? The reason the
power capture looks so wavy is probably because I have the LO's tuned
to the same spot. When I move tx off by 100kHz the capture looks
"nicer" but the ramp up behavior is still there. Also, on the link I
posted above, the max input power is called out as 0 dBm... is that
correct?

Could you provide some input on the questions I brought up in my
previous email? Namely:

(1) recv returning 0s when a tx_streamer is created while receiving
continuously.

(2) The ramp up behavior that is only present when transmitting during
an active acquisition.

I also want to mention that the first burst of power in my captures
coincides with changing the frequency of the tx LO. This triggers an
internal calibration of the AD chip which in turn outputs this brief
burst. So at least this mystery is solved. I am curious, however, is
it possible to allow the chip to perform its cal without actually
seeing this signal at the tx port?

Hello,

UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
UHD_3.11.0.git-release, compiled for ARM
B205 running on USB3.

Doesn't matter if the port is terminated or if it has a signal, recv
returns hard 0s, (not 1e-10 or the like) when a tx streamer is
created. I've uploaded a simple bit of code that illustrates the
behavior quite clearly.

https://pastebin.com/ZAccunUe

Please note that this code assumes you have 20dB of attenuation
between rx and tx. However  you can adjust the gain values
appropriately if you do not.

I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
-lboost_system -luhd

But honestly, this issue is not my primary concern. My primary concern
is the ramp behavior. Note that the code I posted also illustrates the
ramping behavior. For this it needs to be in loopback with 20dB
attenuation (or more).  I included a little helper function which
performs a quick dump to a python file. If you have matplotlib for
python you can uncomment the "dump_to_py" line in the rx thread and
then simply run the generated file with python to see a quick plot of
the iq data.

What else could I do to further troubleshoot this?

cheers,
Dominik

I'm using 1M for both rx and tx. I've seen that example but it does
not have the correct setup to display this behavior. As I mentioned
before, the acquisition has to be running BEFORE transmit begins. In
the example code there is no synchronization between rx start and tx
start so you don't get to see the beginning of the transmit in the
capture. I added a simple atomic bool to the example to ensure rx is
running before tx starts. This is sufficient to display the issue.
Also, the issue of having zeros in rx when creating a streamer will
also not be displayed in this example code because the tx_streamer is
created before the acquisition starts.

Here is a plot of the txrx loopback example with my minor
synchronization addition.

http://imgur.com/a/0FjeI

Would you be able to run the code that I posted in my previous email
to see if you have the same issues on your end?

cheers,
dominik

Hello,

A couple of days has gone by so I wanted to follow up on my questions..

"OK, so, with the zeros, I think I understand what's going on.  When you
create a new streamer, the hardware has to be configured to the new state.

• In the case of the AD9361, this means the data path between the AD9361
  and the FPGA, which unavoidably means that the RX samples are interrupted*
• while the interface is reconfigured.  I believe this is the reason
  for a lump of zeros when you configure for TX--someone in engineering can
  correct*
• my understanding if it's wrong."*

So this is confirmed behavior then? It is inherently due to the AD chip
and not a bug in the code somewhere (host / fpga)?

"In terms of the rather-long transient time--is this only immediately
after configuring the TX streamer, or for any TX burst?  If it's just
immediately

• after configuring a TX streamer, then this may be expected.  If it's
  at the start of every burst, then something is very wrong.  Again, I'm
  awaiting*
• comment from someone in Ettus R&D."*

This is at the start of every burst that is initiated when rx is
running. Even when the tx_streamer is kept alive. Have you had a chance to
run my example program, or modify the existing loopback example in the way
I described in my previous email to reproduce the issue? I don't believe I
am doing something that is incorrect, however, if I am, I would be happy to
have someone point out my mistake.

Best regards,
Dominik

On 04/06/2017 05:51 PM, Marcus D. Leech wrote:

On 04/06/2017 05:07 AM, Dominik Eyerly wrote:

I'm using 1M for both rx and tx. I've seen that example but it does not
have the correct setup to display this behavior. As I mentioned before, the
acquisition has to be running BEFORE transmit begins. In the example code
there is no synchronization between rx start and tx start so you don't get
to see the beginning of the transmit in the capture. I added a simple
atomic bool to the example to ensure rx is running before tx starts. This
is sufficient to display the issue. Also, the issue of having zeros in rx
when creating a streamer will also not be displayed in this example code
because the tx_streamer is created before the acquisition starts.

Here is a plot of the txrx loopback example with my minor synchronization
addition.

http://imgur.com/a/0FjeI

Would you be able to run the code that I posted in my previous email to
see if you have the same issues on your end?

cheers,
dominik

OK, so, with the zeros, I think I understand what's going on.  When you
create a new streamer, the hardware has to be configured to the new state.
In the case of the AD9361, this means the data path between the AD9361
and the FPGA, which unavoidably means that the RX samples are interrupted
while the interface is reconfigured.  I believe this is the reason for
a lump of zeros when you configure for TX--someone in engineering can
correct
my understanding if it's wrong.

In terms of the rather-long transient time--is this only immediately after
configuring the TX streamer, or for any TX burst?  If it's just immediately
after configuring a TX streamer, then this may be expected.  If it's at
the start of every burst, then something is very wrong.  Again, I'm awaiting
comment from someone in Ettus R&D.

On 04/06/2017 04:10 AM, Marcus D. Leech wrote:

On 04/05/2017 10:18 AM, Dominik Eyerly wrote:

Hello,

UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
UHD_3.11.0.git-release, compiled for ARM
B205 running on USB3.

Doesn't matter if the port is terminated or if it has a signal, recv
returns hard 0s, (not 1e-10 or the like) when a tx streamer is created.
I've uploaded a simple bit of code that illustrates the behavior quite
clearly.

https://pastebin.com/ZAccunUe

Please note that this code assumes you have 20dB of attenuation between rx
and tx. However  you can adjust the gain values appropriately if you do
not.

I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
-lboost_system -luhd

But honestly, this issue is not my primary concern. My primary concern is
the ramp behavior. Note that the code I posted also illustrates the ramping
behavior. For this it needs to be in loopback with 20dB attenuation (or
more).  I included a little helper function which performs a quick dump to
a python file. If you have matplotlib for python you can uncomment the
"dump_to_py" line in the rx thread and then simply run the generated file
with python to see a quick plot of the iq data.

What else could I do to further troubleshoot this?

cheers,
Dominik

There is an example program, called txrx_loopback_to_file  that does
something similar to your test.

I wonder if it would be possible to do your tests with that, and see if
there is any change in behavior.

Also, what sample rates are you using?

On 04/05/2017 02:25 PM, Marcus D. Leech wrote:

On 04/05/2017 05:57 AM, Dominik Eyerly wrote:

Hello,

Thanks for the reply. I should add I am doing this test at 3.8G.

Response to (A)

Are you saying that regardless of my tx gain setting, I need 40dB of
attenuation? I believe at max tx gain the board outputs around 10-15dBm
@3.8G. I currently have a 6dB pad on tx port, cabled to a splitter which is
cabled to the rx port with an inline 10dB pad. The other splitter port is
going directly into my VSA.  Also, my tx gain is around 50dB. My
understanding was that the max input power of the rx port is -15dBm. With
this configuration I should be well under that, as shown on my VSA capture
(~-35dBm).

Response to (B)

According to the rough specifications posted here:
https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications

The IIP3 is -15dBm. As you can see on my VSA capture, it received -35dBm
and that doesn't even include the extra 10dB pad on the ettus rx port. I
should be good on linearity, should I not? The reason the power capture
looks so wavy is probably because I have the LO's tuned to the same spot.
When I move tx off by 100kHz the capture looks "nicer" but the ramp up
behavior is still there. Also, on the link I posted above, the max input
power is called out as 0 dBm... is that correct?

Could you provide some input on the questions I brought up in my previous
email? Namely:

(1) recv returning 0s when a tx_streamer is created while receiving
continuously.

Could you try a simple experiment here?  Place a terminator on the input
to the RX side, and see if you get 0s in the recv buffer.  I want to
distinguish
between an analog situation and a digital one.

(2) The ramp up behavior that is only present when transmitting during an
active acquisition.

That's odd.  What version of UHD are you using?

I also want to mention that the first burst of power in my captures
coincides with changing the frequency of the tx LO. This triggers an
internal calibration of the AD chip which in turn outputs this brief burst.
So at least this mystery is solved. I am curious, however, is it possible
to allow the chip to perform its cal without actually seeing this signal at
the tx port?

I'm not certain of exactly how it performs its calibration, but likely
there will always be some leakage when it is doing so.

cheers,
Dominik

On 04/04/2017 04:54 PM, mleech@ripnet.com wrote:

How are you doing the physical loop-back?  If directly-cabled, you'll need
about 40dB of attenuation in-line, to keep the receiver from:

(A) Being damaged

(B) Remaining linear

On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:

Hello all,

My questions concern the B205i. I've uploaded some pictures to simplify
the explaining process.

http://imgur.com/a/XMAv6

Basically, I want to transmit and receive a FSK waveform on one board
(loopback). This means I've tuned both LOs to the same frequency. I've also
inserted a splitter to be able to look at the signal on my VSA.  This has
allowed me to identify several problems.

Let's start on the left:
(B205i Receive - no zeros)
Here you see the received power drop from the noise floor to -infinity
because the rx_streamer was returning 0's. I've tracked this problem to the
creation of a tx_streamer while an acquisition is running. This seems
completely unacceptable; that calling a command on a chain (tx) that has
nothing to do with rx, has an effect on rx. I could understand that the
sample rate performance of rx is affected because they share a
communication link, but not to actually alter the data that is returned by
the recv call. Is this a known bug? Is there a workaround other than "don't
do that"? Is this bug slated for a fix next release?

Next:
Right after all of the 0's, a strong but brief tone is blasted into the tx
path. The power of this tone is not affected by the tx gain setting. This
is quite a significant problem because we may use this module to test
sensitive devices that may not be able to withstand such a transient. Any
idea what is causing this? Again, any workarounds or fixes known?

I don't care much for the spur at -83dBm. But it would be interesting to
understand it.

Lastly:
The actual waveform is transmitted. Since this is an FSK waveform, I would
expect a constant power envelope. Unfortunately, what I capture with the
B205i is not even close. I performed the test again, but this time
transmitting 200ms of 0s before my actual FSK waveform. You can still see
the "warm up" looking behavior, however, by the time the actual waveform
hits, the output seems settled. Is that what is happening (warm up)?
Preloading every waveform with 200ms of zeroes is extremely undesirable. Is
there a way to keep the chip always ready to go from both a Rx and Tx
perspective?

Tx only with no zeros:
I performed the no zeros test again, this time without doing an
acquisition with the B205i. Now the warm up behavior is completely gone.
Why is Rx influencing the Tx RF performance?

Any insight into these issues I am experiencing would be very appreciated.

Best regards,
Dominik

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233 <+49%20351%207958019233>
Fax:    +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email:  dominik.eyerly@konrad-technologies.de
Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[image: sig]
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

_______________________________________________ USRP-users mailing list
USRP-users@lists.ettus.com http://lists.ettus.com/
mailman/listinfo/usrp-users_lists.ettus.com

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233 <+49%20351%207958019233>
Fax:    +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email:  dominik.eyerly@konrad-technologies.de
Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[image: sig]
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233 <+49%20351%207958019233>
Fax:    +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email:  dominik.eyerly@konrad-technologies.de
Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[image: sig]
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233 <+49%20351%207958019233>
Fax:    +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email:  dominik.eyerly@konrad-technologies.de
Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[image: sig]
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

--

--

i.A. Dominik Eyerly
Software

Tel:      +49 (0) 351 7958019 233 <+49%20351%207958019233>
Fax:    +49 (0) 351 7958019 232
Email:  dominik.eyerly@konrad-technologies.de
Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[image: sig]
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur für die adressierte Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com