[USRP-users] TX Image rejection B210

Ian Buckley ianb at ionconcepts.com
Thu Apr 16 20:10:08 EDT 2015


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 at imst.de> wrote:

> Dear Ian,
> 
>> 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.
> 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. 
>> 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.
> Yes, you are right. By the way I'm on release_003_008_002-40-gf23e7bc.
>> 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. 
> 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 at 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.
> 
> <0001-added-lo_off-parameter-to-tx_waveforms-example.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/6ec1bcee/attachment-0002.html>


More information about the USRP-users mailing list