Re: [USRP-users] Poor Tx/Rx Isolation on B205

[Tom Bereknyei via USRP-users]

What would the equivalent of this be for the e310?


On Tue, Feb 13, 2018 at 16:23 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/13/2018 03:30 AM, Dominik Eyerly via USRP-users wrote:
>
> Hello,
>
> I've noticed that the isolation between the Tx/Rx and the Rx2 port is
> quite poor at the upper frequencies ~22dB at 5.9GHz. Could you explain if
> this is to be expected? Would it be possible to know which switch you are
> using? Any way to improve the isolation?
>
>
> cheers,
> Dominik
> --
>
>
> The schematics for B20xmini are here:
>
> http://files.ettus.com/schematics/b200mini/
>
> How are you measuring isolation?  Are both ports terminated in 50ohms?
>
> You could remove C23, which would improve isolation a bit further, but
> you'd be stuck with only EVER using RX2 for receive, and this would of
> course
>   void your warranty.
>
>
>
>
> --
>
> i.A. Dominik Eyerly
> Head of RF Software
>
> Tel:  +49 (0) 351 7958019 233
> Fax: +49 (0) 351 7958019 232
> Email:   d.eye...@konrad-technologies.de
> *Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100*supp...@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 
> listUSRP-users@lists.ettus.comhttp://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
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Poor Tx/Rx Isolation on B205

[Marcus D. Leech via USRP-users]

On 02/13/2018 03:30 AM, Dominik Eyerly via USRP-users wrote:


Hello,

I've noticed that the isolation between the Tx/Rx and the Rx2 port is 
quite poor at the upper frequencies ~22dB at 5.9GHz. Could you explain 
if this is to be expected? Would it be possible to know which switch 
you are using? Any way to improve the isolation?



cheers,
Dominik

--



The schematics for B20xmini are here:

http://files.ettus.com/schematics/b200mini/

How are you measuring isolation?  Are both ports terminated in 50ohms?

You could remove C23, which would improve isolation a bit further, but 
you'd be stuck with only EVER using RX2 for receive, and this would of 
course

  void your warranty.




--
i.A. Dominik Eyerly
Head of RF Software

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

*Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzell*
www.konrad-technologies.de  
www.abexstandard.org  

*Support Telefon: +49 (0) 7732 9815 100*
supp...@konrad-technologies.de  
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


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

[USRP-users] Control LO frequency by FPGA

[Xingjian Chen via USRP-users]

Hi,

I am interested in controlling LO frequency using E312 in such a way that timed 
command must be used. However, as far as I know, E312 doesn't support timed 
command for RF front end. So I am thinking if I could write some simple modules 
in Verilog HDL setting up LO frequency. I am wondering if anyone could give me 
a hint how to start. What is the best way to program LO center frequency in 
FPGA for E312? Thank you.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200 USB high CPU usage

[Nate Temple via USRP-users]

Hi Kasper,

There are several caveats/issues/topics to consider with regards to running
at higher sample rates with the B2xx. Generally speaking, Linux will offer
better performance than Windows.

What version of UHD are you using? If you're not using UHD 3.10.3.0, can
you please try upgrading? UHD 3.10.3.0 includes a commit [1] and updated
firmware, which optimizes the FX3 performance.

The i5-3210M may be slightly under-powered for the task, however you can
try all the following performance tuning adjustments, and it may be able to
support 56 MS/s.

It is worth noting that the recent KPTI patches and other related
workarounds [2] for Intel CPUs to protect against Meltdown/Spectre attacks
[3], may cause a considerable overhead. Here [4] are instructions on how to
check to see if KPTI is enabled for Ubuntu. You may want to disable KPTI,
if it is enabled on your system, then test to see how much additional
overhead it creates, running your application.

Adjust your CPU Governor to "performance". This can be done with the
cpu-frequtils utility [5]. ( sudo cpufreq-set -g performance )

Ensure your CPU is not throttling due to overheating ( sudo cat
/var/log/syslog | grep throttled ). This is very common in laptops,
especially older devices where the thermal grease is in need of replacement.

You can test using sc8 and sc12 OTW (over the wire) [6] sample sizes with
the benchmark_rate [7] utility. Using sc12 will not drop any information as
the ADC/DAC on the B2xx is 12bits.

./benchmark_rate --rx_otw sc12 --rx_rate 40e6
./benchmark_rate --tx_otw sc8 --tx_rate 40e6

Some USB controllers can be problematic. Intel Series 7/8/9 USB controllers
usually offer the best performance.

Using Thinkpads (T430s, T470p) I've found that a recv/send frame size of
8192 tends to work the best at higher sample rates.

As Marcus mentioned, the UHD examples are provided as an API reference and
not tuned for performance. Case in point is rx_samples_to_file being single
threaded. GNU Radio will by default offer a multi-threaded architecture,
which can be useful to test. You may need to adjust the min buffer sizes to
handle the higher sample rates however within the GR Blocks.

I've attached an example of rx_samples_to_file.cpp which is multi-thread
and has additional buffering.

Without a SSD or NVMe hard drive, sustaining a high sample rate to disk can
be difficult. Depending upon your system configuration, you may want to
consider using a ram disk. I would recommend leaving at least 2-8 GB of ram
for your host OS (this is dependent upon your application etc). This will
however limit the length of time you can save to disk (as limited by the
ram in the machine). Below is an example to create a 24GB ramdisk:

mkdir -p ~/ramfs
mount -t tmpfs -o size=24G tmpfs ~/ramfs


[1] -
https://github.com/EttusResearch/uhd/commit/d95613152da3e7c7f41c71acca65101ed0896893
[2] - https://en.wikipedia.org/wiki/Kernel_page-table_isolation
[3] - https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
[4] -
https://askubuntu.com/questions/992137/how-to-check-that-kpti-is-enabled-on-my-ubuntu
[5] - http://www.thinkwiki.org/wiki/How_to_use_cpufrequtils
[6] - https://files.ettus.com/manual/page_stream.html#stream_datatypes_otw
[7] -
https://github.com/EttusResearch/uhd/blob/maint/host/examples/benchmark_rate.cpp

Regards,
Nate Temple

On Tue, Feb 13, 2018 at 11:59 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:
>
>> Hi.
>>
>> We have bought a B200 board and are having issues simply receiving the
>> samples and would like some support in the matter.
>>
>> Running the command
>>./rx_samples_to_file --null --rate 5600
>> on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
>> high CPU usage of ~78%.
>>
>> Is such a high CPU usage expected?
>> Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
>> overflow on the Linux host.
>>
>>
>> There is also a high CPU usage on a Windows 10 machine (ThinkPad,
>> i7-4810MQ).
>> Running
>>./rx_samples_to_file --null --rate 5600
>> results in a infinite stream of overflows.
>>
>> Running
>>./rx_samples_to_file --null --rate 3200
>> utilizes 22% CPU and still overflows once in a while. Moving a
>> calculator window around the screen results in overflows.
>>
>> We have tried increasing buffers using --args="recv_frame_size=X,
>> num_recv_frames=Y"
>> However, we haven't been able to increase X to higher values than ~16000
>> (16384 fails with lots of overflows).
>> The same applies to Y, where 300 fails with an error.
>>
>> The software was compiled in release mode an ran over a USB 3 connection.
>>
>> Thus, for USB transfers using the B200:
>>   - On Vaio: Is ~78% CPU usage expected for 56 Msps ?
>>   - On Win10: Is it not possible to receive 56 Msps?
>>   - On Win10: Is 22% CPU usage expected for 32 Msps?
>>   - Is there some limit to recv_frame_size? A value of 16384 

Re: [USRP-users] B200 USB high CPU usage

[Marcus D. Leech via USRP-users]

On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:

Hi.

We have bought a B200 board and are having issues simply receiving the
samples and would like some support in the matter.

Running the command
   ./rx_samples_to_file --null --rate 5600
on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
high CPU usage of ~78%.

Is such a high CPU usage expected?
Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
overflow on the Linux host.


There is also a high CPU usage on a Windows 10 machine (ThinkPad,
i7-4810MQ).
Running
   ./rx_samples_to_file --null --rate 5600
results in a infinite stream of overflows.

Running
   ./rx_samples_to_file --null --rate 3200
utilizes 22% CPU and still overflows once in a while. Moving a
calculator window around the screen results in overflows.

We have tried increasing buffers using --args="recv_frame_size=X,
num_recv_frames=Y"
However, we haven't been able to increase X to higher values than ~16000
(16384 fails with lots of overflows).
The same applies to Y, where 300 fails with an error.

The software was compiled in release mode an ran over a USB 3 connection.

Thus, for USB transfers using the B200:
  - On Vaio: Is ~78% CPU usage expected for 56 Msps ?
  - On Win10: Is it not possible to receive 56 Msps?
  - On Win10: Is 22% CPU usage expected for 32 Msps?
  - Is there some limit to recv_frame_size? A value of 16384 fails with
infinite overflows.
  - Is there some way of tuning the framework for lower CPU?

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

e hope you are able to help!

Let's do some first-order math.

You're bringing in ~5e7 samples/second
If we optimistically assume a mean instructions-per-sample (including 
both kernel and user-space code) of 100 instructions/sample, then we're 
talking a
  requirement for 5e9 instructions/second.  If your CPU is running at 
3e9 Hz, then it'll need to, on average, issue 1.6 instructions/cycle.


You'll generally get more "mileage" out of num_recv_frames than the 
frame size.  On any given system, my understanding is that this is a 
shared resource

  (across a given USB controller, I think, but don't quote me).

Now, the rx_samples_to_file application is single-threaded, so it's 
trying to service the data-stream from the USRP at the same time as it's 
making filesystem
  calls to write the data (even if to /dev/null). That's a tall order 
for a single-threaded application running at 5.6e7sps.   These 
applications, provided with
  UHD, are generally intended as *coding examples*, and no guarantees 
exist with respect to performance on any given system. Furthermore, some
  USB3 controllers are better at handling bulk high-data-rate 
applications than others, and the controller landscape changes so 
quickly that it's next to

  impossible to provide up-to-date recommendations in that department.

If you install Gnu Radio, there's an application called "uhd_rx_cfile" 
that takes advantage of the multi-threaded nature of Gnu Radio, and does 
better.


But keep *firmly in mind* that once you migrate from writing to 
/dev/null to writing to real disk hardware, 5e7 samples/second is going 
to result in
  a LOT of disk I/O--more than most ordinary single-disk, non-RAID disk 
systems can usefully sustain.




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

Re: [USRP-users] X310 underflow in transmit-only configuration

[Steven Knudsen via USRP-users]

Hi all,

I think I may have identified the problem. See what you think.

I added a bit more info output to the tx_timed_loop.cpp test program (see 
attached) and made note of the time a packet is scheduled to go out versus the 
time the send loop completes.

Keeping in mind that the loop runs as fast as it can, that is, it does not 
sleep for 10 ms, wake up, schedule a packet for 10 ms in the future, then sleep 
again, it’s interesting to see how fast it can schedule packets.

If you look at the code in the attached, new version, specifically in the loop 
at the bottom, you can see I output the scheduled packet time at line 152, send 
the packet, then send a zero-length ending packet to signal the end of the 
burst. Then, depending on whether burstACK has been set, I read in the async 
message and process it according to status. Finally, at line 198 I get the 
current USRP time and output it.

The packet is sent with a scheduled time which we assume is after the current 
USRP time. Thus, you’d expect the scheduled packet time to be larger than the 
current USRP time printed at line 198.

For a sample rate of 20 MSps, here are the results

burstACK

device

nsamps

scheduled time - end of loop time (from USRP)

false

B200mini

1

50,000 us (ahead)

false

B200mini

5

8,000 us (ahead)

true

B200mini

1

50,000 us (ahead)

true

B200mini

5

8,000 us (ahead)

false

X310

1

program dies with ’U’s

false

X310

5

program dies with ’U’s

true

X310

1

–800 us (behind)

true

X310

5

–2700 us (behind)


Just to be clear, “ahead” means that the loop finished before the packet’s 
scheduled Tx time.

There are at least two take-aways:

1. The USB interface allows the B200mini to get packet data really quickly 
(5 samples is 2.5 times longer than the longest packet I test with 
normally). Getting the async streamer message back from the B200mini 
effectively takes no time at all. It also appears that you don’t have to read 
the async streamer message for the B200mini to function properly. Compare that 
to what is noted below for the X310.

2. The X310, when the async message is read back (burstACK is true) lags 
badly. Even for 10,000 samples it only finishes the loop after the packet 
starts to go out. 50,000 samples should take 2.5 milliseconds to transmit at 20 
MSps, but the loop only finishes 2.7 ms after transmission starts!

Turning off the burstACK for the X310 just kills it. It never gets going and 
only a handful of packets appear on my scope. I have to assume that the X310 
must need to have the async message read to reset something or other.

Bear in mind all this is done with a normal, not-sync’d-to-gps Linux host, so 
the accuracy of the clock is not the issue. The X310 and B200mini are keeping 
relative time only.

With the above in mind, seemed like a good idea to visit again the 
benchmark_rate example program.

I ran it for the X310 and even with the tx rate set to 20 MSps I got an 
underflow. Bump up to 26 MSps and got several more. Had to drop all the way 
down to 10 MSps before no underflow happened. And this is for tx-only!

The over the wire mode for benchmark_rate is sc16, so 32 bits per sample. So, 
with a 1GigE interface, you’d expect no better than 31.25 MSps. Indeed, 
benchmark_rate receive passes for 28.157 MSps, but not 33 MSps (clock dividers 
forces those two numbers). But like I say above, for Tx it seems there are 
always a couple of underflows just when it starts up. And that’s for continuous 
transmit, not bursts like I need to do.

So, at least for my test setup, it appears that there is a significant 
communications bottleneck for the X310. The NIC appears to be working properly 
so I don’t think that’s the problem (i.e., the benchmark_rate works pretty much 
as expected).

I am starting to wonder if the the X310 via Ethernet is just not able to 
support a burst packet-based system.

 


Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

All the wires are cut, my friends
Live beyond the severed ends.  Louis MacNeice

On February 9, 2018 at 00:56:27, Steven Knudsen (ee.k...@gmail.com) wrote:

Thanks, Ian.

I appreciate the explanation.

Certainly I’ve understood the idea of late as it was inevitable that while 
developing and testing my TDMA MAC I made mistakes and scheduled packets for 
transmission in the past :0)

The underflow is a little more mysterious. At the request of Nate, a sensible 
person, I’ve created a program to illustrate the problem; see attached.

Running it with the X310 connected to an Octoclock G for 1 PPS and 10 MHz, I 
have it transmit a 2 sample packet every 10 ms at 20 MSps. It manages to do 
that for about 1727 seconds before underflow happens and then it basically 
blocks.

Running it with a B200mini and all the same conditions/parameters, it has been 
going now for more than 8800 seconds.

It is purely speculative on my part, but I have to wonder if somehow 

[USRP-users] B200 USB high CPU usage

[Kasper Føns via USRP-users]

Hi.

We have bought a B200 board and are having issues simply receiving the
samples and would like some support in the matter.

Running the command
  ./rx_samples_to_file --null --rate 5600
on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
high CPU usage of ~78%.

Is such a high CPU usage expected?
Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
overflow on the Linux host.


There is also a high CPU usage on a Windows 10 machine (ThinkPad,
i7-4810MQ).
Running
  ./rx_samples_to_file --null --rate 5600
results in a infinite stream of overflows.

Running
  ./rx_samples_to_file --null --rate 3200
utilizes 22% CPU and still overflows once in a while. Moving a
calculator window around the screen results in overflows.

We have tried increasing buffers using --args="recv_frame_size=X,
num_recv_frames=Y"
However, we haven't been able to increase X to higher values than ~16000
(16384 fails with lots of overflows).
The same applies to Y, where 300 fails with an error.

The software was compiled in release mode an ran over a USB 3 connection.

Thus, for USB transfers using the B200:
 - On Vaio: Is ~78% CPU usage expected for 56 Msps ?
 - On Win10: Is it not possible to receive 56 Msps?
 - On Win10: Is 22% CPU usage expected for 32 Msps?
 - Is there some limit to recv_frame_size? A value of 16384 fails with
infinite overflows.
 - Is there some way of tuning the framework for lower CPU?

We hope you are able to help!


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

Re: [USRP-users] USRP B210 TX-Issues

[Jonathan B via USRP-users]

Hi Derek,

That makes sense, yeah. Thanks!

2018-02-12 23:42 GMT+01:00 Derek Kozel :

> Hello Jonathan,
>
> The gain setting in the USRPs are indexed from minimum gain. On most this
> means a gain of 0 is actually an attenuation of the signal. The N210's gain
> range is based on what amplifiers and attenuators are on the daughterboard
> that is installed. The ranges aren't calibrated to be aligned across
> different USRP products so what you are seeing is completely normal.
>
> On Feb 12, 2018 10:21 PM, "Jonathan B via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Marcus,
>
> Thanks! Didn't realise there was a larger range for the B2xx family. At
> 60dB it seems to perform as well as 20dB on the N210. Is that normal?
>
> But either way - something I can work with. Thanks.
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_3513110979629845876_m_-3868461721852336890_m_4051027392395733961_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2018-02-09 20:53 GMT+01:00 Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:
>>
>> Hi Jeff,
>>
>> Thanks for the response.
>>
>> In both cases a gain of 20dB.
>>
>> Best,
>> Jonathan
>>
>> The total gain-control range on the B2xx family is larger (80dB) than on
>> the cards used on X3xxx, N2xx, etc (typically 30.5dB)
>>
>> Try larger gain values on the B210, like 40 or 50dB.
>>
>>
>>
>> On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> What are you using for gain settings?
>>>
>>> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
>>>
 Hi everyone,

 I seem to be having issues with the B210 transmitting at an incredibly
 low power.

 I seem to be getting a 60db difference at the receiver (spectrum
 analyzer) between the B210 and N210 with perfectly identically configured
 transmissions using the simple uhd "tx_waveform" example program.

 Has anyone experienced such an issue. I have two B210s that seem to be
 acting the same way.

 Thanks in advance.

 Best Regards,
 Jonathan

 -

 Probe Output of the B210:

 -- Loading firmware image: C:\Program Files\GNURadio-3.7\share\uhd\i
 mages\usrp_b200_fw.hex...
 -- Detected Device: B210
 -- Loading FPGA image: C:\Program 
 Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin...
 done
 -- Operating over USB 3.
 -- Detecting internal GPSDO No GPSDO found
 -- Initialize CODEC control...
 -- Initialize Radio control...
 -- Performing register loopback test... pass
 -- Performing register loopback test... pass
 -- Performing CODEC loopback test... pass
 -- Performing CODEC loopback test... pass
 -- Setting master clock rate selection to 'automatic'.
 -- Asking for clock rate 16.00 MHz...
 -- Actually got clock rate 16.00 MHz.
 -- Performing timer loopback test... pass
 -- Performing timer loopback test... pass
_
   /
 |   Device: B-Series Device
 | _
 |/
 |   |   Mboard: B210
 |   |   revision: 4
 |   |   product: 2
 |   |   serial: 3113A66
 |   |   name: MyB210
 |   |   FW Version: 8.0
 |   |   FPGA Version: 14.0
 |   |
 |   |   Time sources:  none, internal, external, gpsdo
 |   |   Clock sources: internal, external, gpsdo
 |   |   Sensors: ref_locked
 |   | _
 |   |/
 |   |   |   RX DSP: 0
 |   |   |
 |   |   |   Freq range: -8.000 to 8.000 MHz
 |   | _
 |   |/
 |   |   |   RX DSP: 1
 |   |   |
 |   |   |   Freq range: -8.000 to 8.000 MHz
 |   | _
 |   |/
 |   |   |   RX Dboard: A
 |   |   | _
 |   |   |/
 |   |   |   |   RX Frontend: A
 |   |   |   |   Name: FE-RX2
 |   |   |   |   Antennas: TX/RX, RX2
 |   |   |   |   Sensors: temp, rssi, lo_locked
 |   |   |   |   Freq range: 50.000 to 6000.000 MHz
 |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
 |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
 |   |   |   |   Connection Type: IQ
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Frontend: B
 |   

[USRP-users] Poor Tx/Rx Isolation on B205

[Dominik Eyerly via USRP-users]

Hello,

I've noticed that the isolation between the Tx/Rx and the Rx2 port is
quite poor at the upper frequencies ~22dB at 5.9GHz. Could you explain
if this is to be expected? Would it be possible to know which switch you
are using? Any way to improve the isolation?


cheers,
Dominik

-- 



-- 

i.A. Dominik Eyerly
Head of RF Software

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


*Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzell*
www.konrad-technologies.de 
www.abexstandard.org 

*Support Telefon: +49 (0) 7732 9815 100*
supp...@konrad-technologies.de 
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.



signature.asc
Description: OpenPGP digital signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com