No worries Ian. š Yeah I have tried different options with tune_request object (including different lo_offsets) but not much luck. There are a few quite strong spurs at 10,20 and some at higher freq but nothing seems to help with reducing the power of those. It looks like we would have to use a filter at the output of the USRP.
If anyone has any other ideas that would be much appreciated. If not we will be putting filters which is a bit of a pain for us but if thats the only option there is nothing we can do. Thanks Milos ________________________________ From: Ian Buckley <i...@ionconcepts.com> Sent: 03 January 2019 15:42 To: Milos Milosavljevic Cc: usrp-users@lists.ettus.com; Marcus D. Leech Subject: Re: [USRP-users] Unexpected spurious from N200 Milos, Early AM for meā¦.disregard what I just saidā¦had a pre-coffee momentā¦LO not present in signal chain at that pointā¦doh! On Jan 3, 2019, at 7:27 AM, Milos Milosavljevic <milos_m...@hotmail.com<mailto:milos_m...@hotmail.com>> wrote: Thank you Ian. Apologies, we are using the SBX not WBX (that was a typo from my side). I believe that SBX also has TX baseband filters. Regardless, sorry, but what did you mean by offsetting the LO spur's into those filters? Via tune_request_t? Thanks Milos ________________________________ From: Ian Buckley <i...@ionconcepts.com<mailto:i...@ionconcepts.com>> Sent: 03 January 2019 15:16 To: Milos Milosavljevic Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>; Marcus D. Leech Subject: Re: [USRP-users] Unexpected spurious from N200 Milos, FWIW WBX includes TX baseband filters of 40MHz bandwidth. LO offsetting your LO spurās into those should suppress this. -Ian On Jan 3, 2019, at 3:48 AM, Milos Milosavljevic via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: Thank you Marcus. Much appreciated. I think I do understand why would I see some sort of phase noise if DUC doesnt work but the only one bit of information that i am missing (i am sure it is a silly question) is why would the offset be ignored if tune_request_t is typcasted to float? Btw, just please note though that if a source is just a constant (so basically there is no modulating signal) the spectrum is much cleaner with float typcasting of tune_request then no typecasting. And lastly, since typecasting to float is no go, do you know how I can reduce the spurs when i just use uhd.tune_request(f,lo_offset) without using external filetring? I tried mode_n=integer but it doesnt help. Those spurs are like 20MHz from the carrier and are destroying our amp (due to reflections). š Thanks Milos ________________________________ From: USRP-users <usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>> on behalf of Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Sent: 03 January 2019 05:36 To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Unexpected spurious from N200 On 01/02/2019 08:06 PM, Milos Milosavljevic via USRP-users wrote: Dear All, I was wondering if somebody could clarify a couple of issues that I have with the UHD and N200 USRP. I am using the latest version of the software. I am generating a single tone to be transmitted with N200 (WBX board) using uhd_siggen as: uhd_siggen -g 15 -s 500000 -m 0.5 -f 402000000 --lo-offset 10000000 -x 50000 --sine 1) I can see quite a strong spurs at 10MHz and 20MHz freq offset from the carrier? (I am not using any external filtering) Define "quite strong". 2) If I modify the siggen to use float((uhd.tune_request(f,lo_offset)) instead of just uhd.tune_request(f,lo_offset) the signal with constant source is much cleaner. However, if I modulate the carrier with a sine source another set of spurs appear very close to the carrier. This is not though the case when float is not used (but spurs at 10 and 20MHz are still present). Why does the float with tune_request make such a big difference? Well, looks like you're casting a tune_request_t to a float, which means that the offset instruction will likely get ignored, which changes whether the DUC comes into play or not. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com<mailto: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
