Sebastian,

what happens when you turn down the gain (e.g. to 70 dB)?

M

On 29.03.2015 23:50, Sebastian Held via USRP-users wrote:

forgot to include the list.

Dear Martin,

please see attached figure. Reducing the gain acts on both the wanted
and unwanted signal in the same manner.

Sebastian

Am 30.03.2015 um 18:46 schrieb Martin Braun via USRP-users:

--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer

Hi,

Any news on this?
I have the same problem with two B210 units.
Either the error is my misunderstanding of RF performance parameters,
the example file cannot be used for this performance evaluation or the
hardware design does not meet the performance of the AD chip (which is
hard to believe).

Any hint what I'm doing wrong?

Regards,
Sebastian

Am 31.03.2015 um 09:51 schrieb Sebastian Held via USRP-users:

--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer

Hi,

Which spec of the AD9361 did you use to come up with your 45 dB
expected suppression ?

Cheers,

Sylvain

Dear Sylvain,

I'm referring to figure 73 in the datasheet "SSB rejection".

Sebastian

Am 07.04.2015 um 10:08 schrieb Sylvain Munaut:

Update:

I played around with the LO offset feature and got the following result:

The curves were generated by:
blue: ./tx_waveforms --args="master_clock_rate=10e6" --rate 10000000
--freq=5900000000 --gain=50 --wave-type SINE --ref=gpsdo --int-n
--wave-freq=1000000 --lo_off=0
green: ./tx_waveforms --args="master_clock_rate=10e6" --rate 10000000
--freq=5900000000 --gain=50 --wave-type SINE --ref=gpsdo --int-n
--wave-freq=1000000 --lo_off=2000000
red: ./tx_waveforms --args="master_clock_rate=10e6" --rate 10000000
--freq=5900000000 --gain=50 --wave-type SINE --ref=gpsdo --int-n
--wave-freq=1000000 --lo_off=5000000

Clearly visible: The wanted sine (-38.9 dBm) is offset 1 MHz from 5.9
GHz, which is correct.
The LO is the signal at -69.2 dBm; it moves according to the LO offset
parameter.
The to be rejected sideband is at -64.6 dBm.

The specification of the B210
(http://www.ettus.com/content/files/b200-b210_spec_sheet.pdf) states:
SSB/LO Suppression -35/50 dBc

My measurement:
SSB/LO Suppression -25.7/30.3 dBc

This is far off.
Does anyone have similar problems?
Is there anything I can do to improve these figures?

Sebastian

Am 07.04.2015 um 09:47 schrieb Sebastian Held via USRP-users:

--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer

On 04/13/2015 05:50 AM, Sebastian Held via USRP-users wrote:

What version of UHD are you using?

Have you tried specifying a master clock rate that is a multiple of your
(10Msps in your example) sample rate?

I updated my UHD today to the newest maint.

The problem was in fact the master clock rate. I had to change it from
the default, because of the sample rate. After that I forgot about it.
Increasing it to 40 MHz, my OFDM signals now pass the spetrum mask! (I
did not check with the sinusoids again, will do this tomorrow).

One problem remains: how to select the best master clock for a specific
sample rate?

Sebastian

Am 13.04.2015 um 15:24 schrieb Marcus D. Leech via USRP-users:

--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer

On 04/13/2015 09:33 AM, Sebastian Held wrote:

Actually, in the latest UHD, if you don't specify a master clock rate,
UHD will pick an appropriate one.

So this this one has me curious. That image is way too big. I can reproduce it exactly using the same command line.
However when I use one of my standard GRC flow graphs to generate a CW with arbitrary LO/Offset etc the image is far better suppressed.
I see -40dBc vs -25dBc. I also see 10dB more power in the carrier with the same RF gain…that's with a digital CW from GR at 0.95 p-to-p amplitude.

I'm going to suggest that there is something in this UHD example thats less than ideal. I note that the code as supplied by Ettus has no "--lo_off" argument, so perhaps Sebastian has edited this example? Regardless I see the issue in the factory code and I'm going to file a bug.

To the observation that you are seeing improved improved spectral mask conformance with an OFDM signal…I suspect this is mostly because the recent update you did from maint caused you to pick up the new FPGA images that were published last week. These have specific filter changes to improve performance with exactly this kind of wideband signal.

The discussion of what is the ideal master_clock_rate vs what is merely an OK one is a very broad topic and differs between USRP's. If you want to give some specifics of your signal then I can give some suggestions.

On Apr 13, 2015, at 6:49 AM, Marcus D. Leech via USRP-users usrp-users@lists.ettus.com wrote:

Dear Ian,

Yes, I modified the code code to include support for LO offset
modification (changed three lines or so - copied from an other example).
I did this, to nail down the cause of my problem.

Yes, you are right. By the way I'm on release_003_008_002-40-gf23e7bc.

My original problem was the violation of the spectrum mask for 802.11p
signals. I generate the IQ representation with a sample rate of 10 MHz.
Older UHD versions indicated a problem with the sample rate - from that
point on I used a fixed 10 MHz or 20 MHz master clock to further
invetigate the problem.

Back to my testcase: The sinusoids do not change if I modify the master
clock. There is certainly a problem with image suppression.
FYI: I attached the patch with the lo_off parameter. I could also file a
pull request if you wish.

Thanks
Sebastian

--

Sebastian Held (Dipl.-Ing.)
IMST GmbH
Softwareentwickler

Carl-Friedrich-Gauss-Str. 2-4
47475 Kamp-Lintfort
Tel: +49 2842 981-418
Fax: +49 2842 981-199
E-mail: mailto:sebastian.held@imst.de
Internet: http://www.imst.de

http://webshop.imst.de

Geschäftsführer:
Prof. Dr.-Ing. Ingo Wolff
Dr. Peter Waldow
Amtsgericht Kleve HRB 6737
USt.-ID: DE 811348335

Wir weisen darauf hin, dass rechtsverbindliche Erklärungen namens
unseres Hauses grundsätzlich der Unterschriften zweier ausreichend
bevollmächtigter Vertreter unseres Hauses bedürfen. Wir verschicken
daher keine rechtsverbindlichen Erklärungen per E-Mail an Dritte.
Demgemäß nehmen wir per E-Mail auch keine rechtsverbindlichen
Erklärungen oder Aufträge von Dritten entgegen. Diese E-Mail dient
einzig dem unverbindlichen Informationsaustausch zwischen Sender und
Empfänger. Sie entfaltet keine Rechtswirksamkeit.
Diese E-Mail ist vertraulich zu behandeln. Sollten Sie nicht der
vorgesehene Empfänger sein, bitten wir Sie, den Versender zu informieren
und die Nachricht zu löschen. Die Weitergabe sowie Vervielfältigung,
Verwertung und Mitteilung seines Inhalts ist nur mit unserer
ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten,
insbesondere für den Fall der Schutzrechtsanmeldung.
This document has to be treated confidentially. If you are not the
intended recipient, please immediately notify the sender and delete this
message. Its contents are not to be passed on, duplicated, exploited or
disclosed without our expressed permission. All rights reserved,
especially the right to apply for protective rights.

Sebastian,
We have a handle on this bug now, the AD9361's internal IQ Quadrature imbalance routine is not getting run at the correct time. The problem manifests in more than just this application and it will take a little time for us to push a full bug fix to UHD. Meantime if anyone feels this bug is affecting them then a workaround is to add a tune_request immediately before starting streaming to an LO frequency that differs by > 100MHz than the previous tune request, which will force the IQ Quad Cal to re-run. When I try that workaround in tx_waveforms I see the image drop from -25dBc to > -40dBc in your 5.9GHz case, and > -50dBc when run at 4.9GHz.

-Ian

diff --git a/host/examples/tx_waveforms.cpp b/host/examples/tx_waveforms.cpp
index 7e63326..eb64d7b 100644
--- a/host/examples/tx_waveforms.cpp
+++ b/host/examples/tx_waveforms.cpp
@@ -170,11 +170,11 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
}

 for(size_t ch = 0; ch < channel_nums.size(); ch++) {

•    std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6) << std::endl;
  

•    uhd::tune_request_t tune_request(freq);
  

•    if(vm.count("int-n")) tune_request.args = uhd::device_addr_t("mode_n=integer");
  

•    usrp->set_tx_freq(tune_request, channel_nums[ch]);
  

•    std::cout << boost::format("Actual TX Freq: %f MHz...") % (usrp->get_tx_freq(channel_nums[ch])/1e6) << std::endl << std::endl;
  

•  //     std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6) << std::endl;
  

•  //     uhd::tune_request_t tune_request(freq);
  

•  //     if(vm.count("int-n")) tune_request.args = uhd::device_addr_t("mode_n=integer");
  

•  //     usrp->set_tx_freq(tune_request, channel_nums[ch]);
  

•  //     std::cout << boost::format("Actual TX Freq: %f MHz...") % (usrp->get_tx_freq(channel_nums[ch])/1e6) << std::endl << std::endl;
  
     //set the rf gain
     if (vm.count("gain")){
  

@@ -255,6 +255,10 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
UHD_ASSERT_THROW(ref_locked.to_bool());
}

• uhd::tune_request_t tune_request(freq);
• if(vm.count("int-n")) tune_request.args = uhd::device_addr_t("mode_n=integer");
• usrp->set_tx_freq(tune_request, channel_nums[0]);
• std::signal(SIGINT, &sig_int_handler);
  std::cout << "Press Ctrl + C to stop streaming..." << std::endl;

On Apr 13, 2015, at 11:08 PM, Sebastian Held sebastian.held@imst.de wrote: