Re: Spurs in UBX-160 Daughterboard with USRP X310
On 01/03/2023 13:14, Dor Ratz wrote:
Hey Marcus, How are you?
Not sure if you got my email.
Do you know anyway I can change transmitted frequency using PMT
message when doing your solution?
In addition, something that seemed to help me:
I used this:
https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html
In the USRP Sinc block, in center frequency parameter, I've put this:
uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
With this, the transmitted 1003MHz signal is cleaner and the spur is
now further away at 16KHz offset with amplitude of 60dBc below the signal.
This alone cleans the spectrum!
In addition, I type "mode_n=integer" in the
Device Address parameter of the UHD: USRP Sink block, but it doesn't
seem to affect. The tuning without DSP correction in the FPGA seems to
just be sufficient to clean the spectrum.
Why is that? Do you recommend using something else?
Thanks
Dor
Note that only works if the underlying RF PLL has enough "resolution" to
make that work--particularly in integer-N mode.
I'm surprised that the DDC/DUC have such significant "close in"
spurs. I don't know if there's anyone from the R team
on here who can authoritatively comment, but this is a bit of a surprise.
בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת Dor Ratz
<dorrat...@gmail.com>:
Hi Marcus,
Can I pass the desired center frequency with a PMT message?
I want to dynamically change the transmitted center frequency of
UHD: USRP Sink block.
So static frequency in the block is not sufficient.
Thanks
Dor
בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת Marcus Müller
<marcus.muel...@ettus.com>:
Hi Dor,
> 1. How to change the to integer_n tuning? Should I just
type "mode_n=integer" in the
> Device Address parameter of the UHD: USRP Sink block in
the grc?
yes. Or, better, instead of just tuning to the target
frequency, you can pass a
uhd.tune_request_t to
uhd_usrp_{sink,source}.set_center_frequency, like this:
my_uhd_block.set_center_frequency(uhd.tune_request_t(
target_freq = 2.4e9,
args="mode_n=integer"))
(you can also use a uhd.tune_request_t in the RF frequency
fields of the GRC block)
Note that you're probably best off using tune_request_t
anyway, as it allows you to tune
your LO far away from your band of interest, given the analog
bandwidth allows for that,
using `target_freq=` and `rf_freq` or `dsp_freq`.
For more information on tuning, see the UHD manual [1]
> 2. How to know for sure what the mode(integer of
fractional) of the NCO is? Can I print
> its status/get it somehow?
looking at the UHD source code: the routines responsible for
tuning just themselves check
for "mode_n" being set to "integer" in the device or tune
request arguments.
Best regards,
Marcus
[1]
https://files.ettus.com/manual/page_general.html#general_tuning
Re: Galileo Frequency Shifting and Filtering
On 01/03/2023 13:01, Kyeong Su Shin wrote: Hello all: Regarding the signal amplification: * Amplifiers CAN improve the SNR, when used properly. The idea is to minimize the noise figure of the receive chain by putting a good LNA and filters (prevents LNA overload) in front of the chain(Friis law for noise). Since wideband SDRs often do not have great Rx frontend (claimed noise figures are often not met in real-world environments, due to the lack of preselector filtering), these amplifiers in active GNSS antennas do actually improve the signal quality. I'll point out that: (A) Most "active" GPS/GNSS antennas have an LNA, and the antenna structure is a printed-on-high-Er-ceramic patch antenna. Such antennas are quite narrow-band, so, there's already filtering ahead of the pre-amp. Such antennas are also, unfortunately, lossy, even within the pass-band. * That said, the gain level of such amplifiers is not that important (as long as the level is somewhere around 20 - 30 dB). Their noise figure is. Unfortunately, sellers and manufacturers often do not publish the typical noise figure of the circuits. If you care about noise figure, then your receiver noise-figure doesn't really matter as much as the LNA that physics and coaxial cable dictates you have right up at the antenna. Unless your receiver is literally dangling off the antenna outdoors, its noise figure (as long as it isn't totally horrific) doesn't actually matter that much because you'll have an LNA right up at the antenna. Active GPS/GNSS antennas satisfy this requirement already to a great extent. The problem is that in most environments (except perhaps rural and middle-of-nowhere), you *need* some filtering ahead of the LNA, which necessarily eats into the noise figure of the LNA. (See, as you say, Friis noise chain analysis). * Still (as mentioned several times already), you are probably not going to see the real signals on your spectrum plot. Matched filtering is necessary (or maybe cyclostationary detectors?) . Using simulated signals is not a bad idea, I think, since that would make debugging a bit easier. The only situation in which you'd see the signal (as an extended increase in the apparent noise floor) is when your front-end noise figure is really really low, and perhaps you're pointing at only a single GPS satellite. The "trick" in GPS and similar spread-spectrum systems is that if you know the spreading code and offset, you can "despread" the signal, vastly increasing the effective SNR on the underlying BPSK signal and proceed from there. But the signal architecture was *deliberately* designed so that you couldn't "see" it with ordinary equipment if you didn't know the spreading code. * Regards, Kyeong Su Shin *보낸 사람:* It's a cat 대신 discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org *보낸 날짜:* 2023년 3월 1일 수요일 오후 10:55 *받는 사람:* David Dima *참조:* GNURadio Discussion List *제목:* Re: Galileo Frequency Shifting and Filtering Amplifier only increase power (signal plus noise), they can't give you better SNR. Anyway, It's much better to use a CW signal generator to help you debug the frequency converter chain (remember to keep output power low, e.g. -60dBm). You can use freq sink to check every stage of your flowgraph, and use Range / slider widget to control block parameters to search and check. If the signal disappears, or the passband doesn't meet your requirement, the problem can be easily located. David Dima 于2023年3月1日周三 21:50写道： Hi, Sure, but the power of this kind of signals is below noise level. Current antenna amplifies 30dB but it still not enough to see anything in the spectrum (I have checked it alredy). Regards, David El mié., 1 mar. 2023 7:27, It's a cat escribió: If you have a signal generator, GNSS simulator or a high gain antenna, you can verify your settings by adding a spectrum display (Qt Freq Sink) or something like that to your receiver path. Because many things can go wrong in your setup, if you misunderstand something. Just try to verify this directly. If there's a signal you should be able to see it on the spectrum display. David Dima 于2023年2月28日周二 02:00写道： Hi guys, I am trying to simultaneously record Galileo's E5a and E5b signals as follows: imagen.png I have tried to record them separately by tuning the local oscillator in the middle of the signals bandwidths and sampling at 25MHz and it worked. But when I try to shift and filter to get the signals in a different file, it does not work. I have no idea what am i doing wrong. Galileo's Signal Plan is as
Re: Spurs in UBX-160 Daughterboard with USRP X310
Hey Marcus, How are you?
Not sure if you got my email.
Do you know anyway I can change transmitted frequency using PMT message
when doing your solution?
In addition, something that seemed to help me:
I used this:
https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html
In the USRP Sinc block, in center frequency parameter, I've put this:
uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
With this, the transmitted 1003MHz signal is cleaner and the spur is now
further away at 16KHz offset with amplitude of 60dBc below the signal.
This alone cleans the spectrum!
In addition, I type "mode_n=integer" in the
Device Address parameter of the UHD: USRP Sink block, but it doesn't seem
to affect. The tuning without DSP correction in the FPGA seems to just be
sufficient to clean the spectrum.
Why is that? Do you recommend using something else?
Thanks
Dor
בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת Dor Ratz <dorrat...@gmail.com
>:
> Hi Marcus,
>
> Can I pass the desired center frequency with a PMT message?
> I want to dynamically change the transmitted center frequency of UHD: USRP
> Sink block.
>
> So static frequency in the block is not sufficient.
>
> Thanks
> Dor
>
> בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת Marcus Müller <
> marcus.muel...@ettus.com>:
>
>> Hi Dor,
>>
>> > 1. How to change the to integer_n tuning? Should I just type
>> "mode_n=integer" in the
>> > Device Address parameter of the UHD: USRP Sink block in the grc?
>>
>> yes. Or, better, instead of just tuning to the target frequency, you can
>> pass a
>> uhd.tune_request_t to uhd_usrp_{sink,source}.set_center_frequency, like
>> this:
>>
>> my_uhd_block.set_center_frequency(uhd.tune_request_t(
>>target_freq = 2.4e9,
>>args="mode_n=integer"))
>>
>> (you can also use a uhd.tune_request_t in the RF frequency fields of the
>> GRC block)
>>
>> Note that you're probably best off using tune_request_t anyway, as it
>> allows you to tune
>> your LO far away from your band of interest, given the analog bandwidth
>> allows for that,
>> using `target_freq=` and `rf_freq` or `dsp_freq`.
>>
>> For more information on tuning, see the UHD manual [1]
>>
>> > 2. How to know for sure what the mode(integer of fractional) of the
>> NCO is? Can I print
>> > its status/get it somehow?
>>
>> looking at the UHD source code: the routines responsible for tuning just
>> themselves check
>> for "mode_n" being set to "integer" in the device or tune request
>> arguments.
>>
>> Best regards,
>> Marcus
>>
>> [1] https://files.ettus.com/manual/page_general.html#general_tuning
>>
>
Re: Galileo Frequency Shifting and Filtering
On 01/03/2023 08:50, David Dima wrote: Hi, Sure, but the power of this kind of signals is below noise level. Current antenna amplifies 30dB but it still not enough to see anything in the spectrum (I have checked it alredy). Regards, David You generally won't be able to see GPS signals in the spectrum--unless you have a spectacularly good LNA right up at your antenna, and that antenna better not be a dielectric patch antenna (as is typical for GNSS/GPS antennas). El mié., 1 mar. 2023 7:27, It's a cat escribió: If you have a signal generator, GNSS simulator or a high gain antenna, you can verify your settings by adding a spectrum display (Qt Freq Sink) or something like that to your receiver path. Because many things can go wrong in your setup, if you misunderstand something. Just try to verify this directly. If there's a signal you should be able to see it on the spectrum display. David Dima 于2023年2月28日周二 02:00写道： Hi guys, I am trying to simultaneously record Galileo's E5a and E5b signals as follows: imagen.png I have tried to record them separately by tuning the local oscillator in the middle of the signals bandwidths and sampling at 25MHz and it worked. But when I try to shift and filter to get the signals in a different file, it does not work. I have no idea what am i doing wrong. Galileo's Signal Plan is as follows:
Re: Galileo Frequency Shifting and Filtering
Amplifier only increase power (signal plus noise), they can't give you better SNR. Anyway, It's much better to use a CW signal generator to help you debug the frequency converter chain (remember to keep output power low, e.g. -60dBm). You can use freq sink to check every stage of your flowgraph, and use Range / slider widget to control block parameters to search and check. If the signal disappears, or the passband doesn't meet your requirement, the problem can be easily located. David Dima 于2023年3月1日周三 21:50写道： > Hi, > > Sure, but the power of this kind of signals is below noise level. Current > antenna amplifies 30dB but it still not enough to see anything in the > spectrum (I have checked it alredy). > > Regards, > David > > > El mié., 1 mar. 2023 7:27, It's a cat escribió: > >> If you have a signal generator, GNSS simulator or a high gain antenna, >> you can verify your settings by adding a spectrum display (Qt Freq Sink) or >> something like that to your receiver path. >> Because many things can go wrong in your setup, if you misunderstand >> something. Just try to verify this directly. If there's a signal you should >> be able to see it on the spectrum display. >> >> >> David Dima 于2023年2月28日周二 02:00写道： >> >>> Hi guys, >>> I am trying to simultaneously record Galileo's E5a and E5b signals as >>> follows: >>> [image: imagen.png] >>> I have tried to record them separately by tuning the local oscillator in >>> the middle of the signals bandwidths and sampling at 25MHz and it worked. >>> But when I try to shift and filter to get the signals in a different file, >>> it does not work. I have no idea what am i doing wrong. >>> Galileo's Signal Plan is as follows: >>> >>
Re: Galileo Frequency Shifting and Filtering
Hi, Sure, but the power of this kind of signals is below noise level. Current antenna amplifies 30dB but it still not enough to see anything in the spectrum (I have checked it alredy). Regards, David El mié., 1 mar. 2023 7:27, It's a cat escribió: > If you have a signal generator, GNSS simulator or a high gain antenna, you > can verify your settings by adding a spectrum display (Qt Freq Sink) or > something like that to your receiver path. > Because many things can go wrong in your setup, if you misunderstand > something. Just try to verify this directly. If there's a signal you should > be able to see it on the spectrum display. > > > David Dima 于2023年2月28日周二 02:00写道： > >> Hi guys, >> I am trying to simultaneously record Galileo's E5a and E5b signals as >> follows: >> [image: imagen.png] >> I have tried to record them separately by tuning the local oscillator in >> the middle of the signals bandwidths and sampling at 25MHz and it worked. >> But when I try to shift and filter to get the signals in a different file, >> it does not work. I have no idea what am i doing wrong. >> Galileo's Signal Plan is as follows: >> >
Re: Error while loading the FPGA image
Hi Gwenhael, Thank you. Adding the patch solved the issue. Regards, Lakshmi On Wed, Mar 1, 2023 at 6:17 PM Lakshmi Poola wrote: > Hi Gwenhael, > Thank you. Adding the patch solved the issue. > Regards, > Lakshmi > > On Wed, Mar 1, 2023 at 12:52 PM Gwenhael Goavec-Merou < > gw...@trabucayre.com> wrote: > >> Hi, >> According to your screenshot the error isn't at load time but at >> build/setenv >> time. >> >> As mentionned at >> https://files.ettus.com/manual/md_usrp3_build_instructions.html >> Vivado 2021.1 must be patched manually using the zip file available at >> https://support.xilinx.com/s/article/76780?language=en_US >> >> Regards >> Gwenhael >> >> Wed, 1 Mar 2023 12:36:12 +0530 Lakshmi Poola >> wrote: >> >> > Hello, >> > I'm running UHD 4.4 with gnuradio 3.10.5.1 (on Ubuntu 20.4). The Xilinx >> > Vivado required for UHD 4.4 is version 2021.1. I made the installation, >> and >> > it is fine. However, when I tried to load the FPGA image using JTAG, I >> am >> > faced with an error, as seen in the screenshot below. >> > [image: 20230225_132349.jpg] >> > >> > When I looked up this error, I found the suggestion to use the tcl >> command >> > "set_param labtools.override_cs_version_check 1." . I issued this tcl >> > command on vivado, but the error still persists and I am unable to write >> > the FPGA image onto the USRP. >> > >> > Please advise. >> > Thank you, >> > Lakshmi >> >
