Re: unexplained received power fluctuations with usrp b210 and gnuradio
On 2022-04-20 08:20, Christophe Marqué wrote:
Hi,
I'm not sure this is the right place to ask this question, but I will try
anyway.
I am using a usrp b210 to simply record the received power at a certain
frequency. The receiver is plugged to a bicone antenna and an amplifier for
testing, but the behaviour I describe below has shown up in more elaborated
setups. I attach the simple flowgraph. The receiver is tuned with a tune
request and an offset equal to half the sample rate.
In short, the power I am recording is not stable and I see large excursions (up
or down) appearing abruptly, even in frequency bands where I expect no signal
(e.g. radio astronomy bands). I know RFI are expected even in quiet bands, but
I would not expect drops in the power levels. I see this at different gain
settings for the receiver, although a higher gain makes things worse. Without
any tune request, it improves a bit but not much.
I have made a similar set of measurements using directly the UHD python API,
and it seems to me that on comparable timescales, no suspicious fluctuations
appear. (see plots, the one of the uhd python api has been integrated by a
factor 1000 to get the same rate as the gnuradio generated ones)
Has this behavior been seen in the past? I'm using fairly recents uhd and
gnuradio libraries (UHD_4.2.0.0, gnuradio 3.10.1), and python 3.8 on a linux
(ubuntu 20.4) pc, but I encountered this with older library versions.
Thanks for any suggestions,
Best regards,
Christophe
###Code for the python uhd-api (derived from online example):
import uhd
import numpy as np
import argparse
def parse_args():
parser = argparse.ArgumentParser()
parser.add_argument("-a", "--args", default="", type=str)
parser.add_argument("-o", "--output-file", type=str, required=True)
parser.add_argument("-f", "--freq", type=float, required=True)
parser.add_argument("-r", "--rate", default=1e6, type=float)
parser.add_argument("-d", "--duration", default=5.0, type=float)
parser.add_argument("-c", "--channels", default=0, nargs="+", type=int)
parser.add_argument("-g", "--gain", type=int, default=10)
return parser.parse_args()
def main():
args = parse_args()
usrp = uhd.usrp.MultiUSRP(args.args)
num_samps = int(np.ceil(args.duration*args.rate))
if not isinstance(args.channels, list):
args.channels = [args.channels]
samps = usrp.recv_num_samps(num_samps, args.freq, args.rate,
args.channels, args.gain)
with open(args.output_file, 'wb') as f:
np.save(f, np.real(samps*np.conj(samps)),
allow_pickle=False, fix_imports=False)
if __name__ == "__main__":
main()
###
Have you repeated your experiments with a terminator on the input of the
receiver? I've been using Gnu Radio for radio astronomy applications
since 2005 or so. The only
anomaly I've found that was GR-related in this regard was that the
single-pole IIR filter has some numerical instability for very small inputs.
Also, for a total-power radiometer, I normally just use
complex-to-mag**2 followed by integration and decimation.
In the analog world, you can often get dips in received power due to
what some call "receiver de-sense" which is caused by a strong
out-of-band signal exceeding the
linearity limits of an early gain stage, but since it's out of band,
you don't see the signal, just the non-linearity effects its causes.
Re: Problems with OOT C++ fft
Hello GNURadio Community,
Please ignore the above problem, I figured it out.
George
On Sun, Apr 17, 2022 at 5:16 PM George Edwards
wrote:
> Dear Gnuradio Community,
>
> I am writing an OOT signal processing algorithm in C++ that requires both
> fft and ifft. I use the Gnuradio C++ library to get the fft and ifft
> functions. To confirm understanding of setting up these functions, I wrote
> C++ OOT blocks for both fft and ifft blocks. I ran a complex sinusoid into
> the fft block and fed its output to the ifft block to reverse the process.
> In the GRC flowgraph, the time and frequency plots seem correct (the output
> of the ifft shows the sinusoidal frequency it recovers is right on mark).
>
> For further validation, I decided to compare Gnuradio C++ fft computation
> to that of Matlab. I created a Python QA file to Debug the fft block and
> examine the fft computation. For the experiment, I fed 8 complex data
> samples into the fft block to see how its fft computation compares to that
> of Matlab. The OOT fft computation was not correct! Here is a snippet of my
> C++ OOT code written to test the fft computation (below "in and out" points
> to the addresses of Gnuradio input/out data variables).
>
> memcpy(d_fft.get_inputbuf(), in, sizerof(gr_complex)*d_fft_size);
> d_fft.execute();
> memcpy(out, d_fft.get_output(), sizerof(gr_complex)*d_fft_size);
> gr_complex c_data[8];
> for(int i = 0; i < 8; i++) {
> c_data[i] = out[i];
> }
> As can be seen in my code, I wrote the fft output into the array variable
> c_data. c_data has 1+1j in c_data[0] and all the other elements of the
> array have values 0+0j. The values are all wrong (not the same as Matlab).
> So I am at a loss!
>
> I appreciate any suggestions?
>
> Thank you!
> George
>
How pass an input vector in an OOT QA test?
Hello GNURadio Community, In an OOT QA testing of a signal processing block designed to accept an input vector of 4 elements, I am having problems passing the QA input as a vector. It sees the input as a stream. I tried passing the data in two ways, but each failed. Here are the two ways I have formated the QA data which I would like to be seen as a vector of 4 elements: data = (1.0, 2.0, 3.0, 4.0) and data = numpy.array([[1.0, 2.0, 3.0, 4.0], [5.0, 6.0, 7.0, 8.0]]) I would appreciate any suggestion. Thank you! George
Meaning of value in noutput_items for an OOT with vector input
Hello GNURadio Community, I have written a C++ OOT "sync" block with vector input and vector output (data type float). I wrote a line in my program to print the value of noutput_items on each GRC flow graph iteration and it alternately prints the values 15 and 16. This is surprising!!! I was expecting this value to be the 512, the number of elements in each input/output vector that I designed the OOT to operate at. In my OOT design, the input/output signatures were set to 512 floating point elements. In the GRC Flow graph my block is fed by a stream to vector block (which brings in vectors of 512 samples) and my block outputs its data to a vector to stream block (which takes a vector of 512 elements and converts to a data stream). I was under the impression that the parameter noutput_items in the work(...) function for an OOT sync block with vector input and output provided the number of elements in each output vector. I will appreciate any insight into this issue. Thanks! George
Re: Meaning of value in noutput_items for an OOT with vector input
The item size is vlen * sizeof (type), so you are seeing 16 * 512 "samples". On Wed, Apr 20, 2022 at 1:44 PM George Edwards wrote: > Hello GNURadio Community, > > I have written a C++ OOT "sync" block with vector input and vector output > (data type float). I wrote a line in my program to print the value of > noutput_items on each GRC flow graph iteration and it alternately prints > the values 15 and 16. This is surprising!!! I was expecting this value to > be the 512, the number of elements in each input/output vector that I > designed the OOT to operate at. In my OOT design, the input/output > signatures were set to 512 floating point elements. In the GRC Flow graph > my block is fed by a stream to vector block (which brings in vectors of > 512 samples) and my block outputs its data to a vector to stream block > (which takes a vector of 512 elements and converts to a data stream). > > I was under the impression that the parameter noutput_items in the > work(...) function for an OOT sync block with vector input and output provided > the number of elements in each output vector. > > I will appreciate any insight into this issue. > > Thanks! > George > > > >
