Decibel scale

Reference : https://ccrma.stanford.edu/~jos/st/Properties_DB_Scales.html
https://ccrma.stanford.edu/~jos/st/Decibels.html 

A decibel (abbreviated dB) is defined as one tenth of a bel.

The bel is an amplitude unit defined for sound as the log (base 10) of the intensity relative to some reference intensity, i.e., 

     

The choice of reference intensity (or power) defines the particular choice of dB scale. Signal intensity, power, and energy are always proportional to the square of the signal amplitude. Thus, we can always translate these energy-related measures into squared amplitude:

  

Since there are 10 decibels to a bel, we also have 

 

In every kind of dB, a factor of 10 in amplitude increase corresponds to a 20 dB boost (increase by 20 dB):

A function which is proportional to is said to ``fall off'' (or ``roll off'') at the rate of dB per decade. That is, for every factor of in (every ``decade''), the amplitude drops dB.   

Similarly, a factor of 2 in amplitude gain corresponds to a 6 dB boost:

and

   dB 

A function which is proportional to is said to fall off dB per octave. That is, for every factor of in (every ``octave''), the amplitude drops close to dB. Thus, 6 dB per octave is the same thing as 20 dB per decade.  

A doubling of power corresponds to a 3 dB boost:

and 

dB 

dB/Octave & dB/Decade

An Octave is where the frequency halves or doubles (by a factor of 2) i.e. 400Hz to 800 Hz 

A Decade is where the frequency increases or decreases by a factor of 10 i.e. 5 Hz to 50 Hz 

Slopes can be defined as dB/Octave or dB/Decade

20dB/decade ≈ 6.0205999132796 dB/octave 

There are 3.3 octaves in one decade .. in other words 

6dB/octave is equivalent to 20 dB/decade
           

number of decades

Finding maximum possible I/O rate on a disk

You can compute the maximum possible sequential I/O rate.  It's easy:  Look at how many blocks are in one track and how long it takes the disk  to make one revolution (at 7200 RPM) then you will know how many bits  per second fly under the read/write head.  This places an upper bound on the sustained I/O rate.

Generally the XFS file systems gives fastest result.

To make faster read operations, make a separate partition on your drive, possibly at the beginning of the drive (as the beginning of the drive is faster)

Zero copy mechanism

"Zero-copy" describes computer operations in which the CPU does not perform the task of copying data from one memory area to another saving significant processing power and memory. It also saves the time consuming mode switches between user space and kernel space.




Zero-copy protocols are especially important for high-speed networks in which the capacity of a network link approaches or exceeds the CPU's processing capacity. In such a case the CPU spends nearly all of its time copying transferred data, and thus becomes a bottleneck which limits the communication rate to below the link's capacity.

Techniques for creating zero-copy software include the use of DMA-based copying and memory-mapping through an MMU.


Several operating systems support zero-copying of files through specific APIs foe example Windows.
Linux supports zero copy through system calls such as sys/socket.h's sendfile, sendfile64, and splice.

The information above has been taken from Wikipedia.

Pointers in C++

int *p;

p is a pointer to an integer quantity

int *p[10];

p is a 10 elements array of pointers to integer quantities

int (*p)[10];

p is a pointer to a 10 element integer array

int *p(void);

p is a function that returns pointer to an integer quantity and accepts nothing

int p(char *a);

p is function that accepts an argument which is a pointer to a character  and returns an integer quantity

int *p(char *a);

p is a function which accepts an argument which is a pointer to a character and returns a pointer to an integer quantity

int (*p)(char *a);

p is a pointer to a function which accepts an argument as a pointer to a character and returns an integer quantity

int (*p(char *a))[10];

p is function that accepts argument which is pointer to a character and returns a pointer to a 10 element integer array

int p(char (*a)[]);

p is a function which accepts an argument which is a pointer to a character array and returns an integer quantity

int p(char *a[]);

p is a function which accepts an argument which is an array of pointers to characters and returns an integer quantity

int *p(char a[]);

p is a function which accepts a character array as argument and returns a pointer to an integer quantity

int *p(char (*a)[]);

p is function which accepts an argument which is a pointer to an array of characters and it returns a pointer to an integer quantity

int *p(char *a[]);

p is a function which accepts argument as an array of character pointers and returns a pointer to an integer quantity

int (*p)(char (*a)[]);

p is a pointer to a function which takes an argument which is a pointer to character array and  returns an integer quantity

int *(*p)(char (*a)[]);

p is a pointer to a function which takes argument which is pointer to a character array and returns a pointer to an integer quantity

int *(*p)(char *a[]);

p is a pointer to a function which takes argument which is an array of pointers to characters and returns pointer to an integer quantity

int (*p[10])(void);

p is a 10 element array of pointers to functions which does not take anything as argument and each function returns an integer quantity 

int (*p[10])(char a);

p is 10 element array of pointers to functions; each function accepts a character as argument; and each function returns an integer quantity

int *(*p[10])(char a);

p is a 10 element array of pointers to functions; each function takes a character as argument; and each function returns a pointer to an integer quantity

int *(*p[10])(char *a);

p is a 10 element array of pointers to functions; each function takes a character pointer as argument; and each function returns a pointer to an integer quantity

Windows Driver Kit (WDK)/Windows Driver Development Kit(Win DDK)

Initially it was known as Windows Driver Development Kit, now it has been superseded by Windows Driver kit i.e. WDK.
As the name suggests it is a framework to develop drivers on Windows Platform.
You can either instal it directly from internet or you can download the file to install in another system
Here is the link

http://msdn.microsoft.com/en-us/library/windows/hardware/gg487428.aspx

I am installing WDK because I need to work on SORA which is a SDK to develop Software Radio applications. It has been developed by Microsoft Research Asia center.

To install WIN DDK you can follow this link 

http://www.tenouk.com/windowsddk/windowsdriverdevelopmentkit.html

Details are here

http://research.microsoft.com/en-us/projects/sora/

When to use Genetic Algorithms vs. when to use Neural Networks?

A genetic algorithm (GA) is a search technique used in computing to find exact or approximate solutions to optimization and search problems.A genetic algorithm, despite its sexy name, is for most purposes just an optimisation technique. It primarily boils down to you having a number of variables and wanting to find the best combination of values for these variables. It just borrows techniques from natural evolution to get there.

Neural networks are non-linear statistical data modeling tools. They can be used to model complex relationships between inputs and outputs or to find patterns in data.Neural networks are useful for recognising patterns. They follow a simplistic model of the brain, and by changing a number of weights between them, attempt to predict outputs based on inputs.

If you have a problem where you can quantify the worth of a solution, a genetic algorithm can perform a directed search of the solution space. (E.g. find the shortest route between two points)

When you have a number of items in different classes, a neural network can "learn" to classify items it has not "seen" before. (E.g. face recognition, voice recognition)

Execution times must also be considered. A genetic algorithm takes a long time to find an acceptable solution. A neural network takes a long time to "learn", but then it can almost instantly classify new inputs.

UHD

Stands for "Universal Hardware Driver"

Prior to UHD, there were two distinct APIs -- one for USRP1, the other  for USRP2, and the "classic" USRP2 API used raw-ethernet frames for carrying data/control. 

In UHD, all the platforms are supported (USRP1, USRP2, N2XX, and E1XX),  and for ethernet-connected platforms, the protocol is based on VITA-49-over-UDP.

Older example applications, which would have used one or the other of the USRP1 or USRP2 "classic" API, need to be lightly worked-over to be compatible with the UHD API.  

The N2XX platforms are *only* UHD capable, and many of the newer daughtercards are only accessible using the UHD API.

The UHD API also enables some of the fancier synchronization paradigms that weren't available in the "classic" interface, and also allows things like dual-DDC on the USRP2 and N2XXX platforms.

gr.probe_avg_mag_sqrd_cf

gr.probe_avg_mag_sqrd_cf : This function can be used to find the average power on a channel.

Details can be found at /usr/local/include/gnuradio/gr_probe_avg_mag_sqrd_cf.h

http://gnuradio.org/doc/doxygen/gr__probe__avg__mag__sqrd__cf_8h.html

http://gnuradio.org/doc/doxyge/gr__probe__avg__mag__sqrd__cf_8h_source.html

http://gnuradio.org/doc/doxygen/classgr__probe__avg__mag__sqrd__cf.html

The implementation file can be located in :

gnuradio/gnuradio-core/src/lib/general/gr_probe_avg_mag_sqrd_c.cc





Example :

#!/usr/bin/python2.6
#!/usr/bin/env python

from gnuradio import gr
from gnuradio import uhd
import sys, time

class rx_cfile_block1(gr.top_block):
    def __init__(self):
        gr.top_block.__init__(self)

                self.uhd_usrp_source = \
                uhd.usrp_source(device_addr="serial=1R270DU1",stream_args=uhd.stream_args('fc32'))

                self.gr_file_sink = gr.file_sink(gr.sizeof_float ,"/home/sumit/first_app_data1")

                self.uhd_usrp_source.set_subdev_spec("A:0", 0)

                self.uhd_usrp_source.set_antenna("RX2", 0)

                self.uhd_usrp_source.set_samp_rate(1000000)

                self.uhd_usrp_source.set_gain(45)

                treq = uhd.tune_request(2450000000)

                self.uhd_usrp_source.set_center_freq(treq)

                self._head = gr.head(gr.sizeof_float, int(4))
        
                self.c2mag = gr.probe_avg_mag_sqrd_cf(0.01, 0.001)

                self.connect(self.uhd_usrp_source, self.c2mag, self._head, self.gr_file_sink)

def main():
    tb = rx_cfile_block1()   

    while not tb.c2mag.unmuted():

        tb.run()

        print tb.c2mag.unmuted() #show exceed threshold or not
        print tb.c2mag.level()        #show power
        print tb.c2mag.threshold()
        time.sleep(3)
                     


if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        pass

CIC passband compensation

Q: Does the HB filter response compensate for the non-flat passband of the CIC?

A: No [CIC non flat response] compensation filter is available.

Reference : http://gnuradio.4.n7.nabble.com/CIC-passband-compensation-tt15653.html#a15654


Q: Hi Firas,

Thanks for your response. In an earlier thread you had posted a matlab script called usrpddc.m that calculates the overall frequency response of the usrp rx chain and plots it. This would be very useful to me however, when I try to run it I find it is missing mfilt.cicdecim() function. If you still have this and could make it available it will be a great help.

Thanks
Nirali

A: Hi Nirali

The function mfilt.cicdecim() is a standard MATLAB function. Check Filter design tool.

Regards,
Firas

   

Linux or Windows

Reference : http://gnuradio.4.n7.nabble.com/Vista-Xp-or-Linux-tt15028.html#a15029


One advantage of Windows is that you can set the priority of the thread that
processes USRP data to eliminate overruns and data processing hiccups caused
by window management and display events without noticeable impact on GUI
responsiveness.  I think the only option on Linux is to use realtime
priority, which requires root access.

Failed to set TX frequency!!

Reference : http://gnuradio.4.n7.nabble.com/Failed-to-set-TX-frequency-tt13429.html#a13431

Hi Johnathan,

Sorry for not being clear. I was making a new usrp_source.py & usrp_sink.py files (attached below) to be posted to gunradio. Testing the new usrp_source.py code was ok for all frequencies and daughter boards. However, testing usrp_sink.py code, with TX frequencies between 44MHz and 83 MHz gave me the tuning function failing indication which I use it to print the message "Failed to set TX frequency". This is strangely happening to the Basic TX daughter board only in this frequency range.

Firas,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The digital upconverters in the AD9862 don't allow you to set the
frequency to values close to the nyquist frequencies.  Since it samples
at 128 MHz, the prohibited ranges are around multiples of 64 MHz.

Matt 

USRP data rates

Reference : http://gnuradio.4.n7.nabble.com/USRP-data-rates-tt14107.html#a14111

** I have reiterated the things for better remembrance  

The ADCs create 12-bit samples @ 64 Msps and are represented as 16-bit samples with the upper four bits zeroed.

0000xxxxxxxxxxxx


Two independent ADCs coherently sample the down-converted I and Q signals from the daughterboard at this rate and resolution.

** Two ADC because we are doing sampling of I as well as Q

The FPGA decimates and low pass filters these I and Q streams by a minimum factor of 8, resulting in a maximum of 8 Msps on each (alternatively described as 8 Msps complex).

 USRP (64 MSPS) --> decimation factor (minimum = 8) --> Samples to PC (maximum = 8MSPS)

This represents at most 8 MHz of passband (the Nyquist rate for complex sampling = complex sample rate.)

It is possible to retain only the upper eight bits of each sample and  pack these into two bytes such that the USB can carry 16 Msps complex;  this gives you more passband bandwidth at the expense of dynamic range.

** There is a function call pair (make_format, set_format) which tells the USRP to use 8-bit samples.  You can see it's use in some of the example programs.

** USRP can transfer data at maximum of 32MB/s using its USB2. When the data are 16 bit wide (16bit I and 16 bit Q) then maximum complex transfered data will be 8 Msps which gives idealy maximum 8 MHz bandwidth. However, if we use 8 bit data wide ( 8bit I, and 8bit Q), then maximum transfer will be 16 Msps complex data. This means, the USRP can process signals up to 16 MHz.

** Moreover 16MHz or 8MHz is the net bandwidth, one needs to subtract the overhead created by the CIC roll-off.

And a nice suggestion given by Firas A.

"The USRP ADC resolution is 12 Bits. These 12 Bits are converted to 32 bits (16 bits I and 16 Bits Q) after being processed by the FPGA DDC. However, if we reduced the output bit width of the DDC to 12Bit I and 12 Bit Q (or simply rotate right the resultant 16 bits I/Q by 4), then we packed and transfered the resultant 24 bits  into a 3 bytes only (instead of 4 in the case of 16bit complex), then we can have an instantaneous bandwidth of 10.67MHz (32M/3) with 12 bits I/Q which is in my opinion will be optimum in the sense of ADC resolution and the obtained instantenouse bandwidth.
" 

i.e. 8 bits for I & Q each instead of 16 buts for I & Q each


In practice, the FPGA filter roll-off (it's a CIC decimator) is significant in the outer 25% or so of the passband, so depending on how much attenuation your application can withstand, you might only get 6 MHz (with 16 bits samples )or so of usable bandwidth out of it (or 12 MHz using 8-bit samples.)


The data over the USB is always in integer format, normally signed
16-bits each for I and Q.

The usrp.source_c() source block converts
this to a stream of single precision complex floating point samples.

Most of GNU Radio signal processing blocks are designed to work with
floating point and many use highly optimized inner loops that take
advantage of SSE or 3DNow floating point hardware on Intel or AMD
processors.  So this is the natural domain of DSP processing with GNU Radio.


The usrp.source_s() data source provides access to the raw data stream from the USRP (interleaved I and Q), but there aren't many interesting DSP blocks in GNU Radio that can work with this format.  You may, of course, write your own.

Advanced applications of the USRP involve re-synthesizing the FPGA firmware and performing DSP operations directly on the samples coming from the ADCs before handing off the data to the USB.  This theoretically gives you access to the entire 64 MHz receive bandwidth.

However, there isn't a great deal of space on the FPGA for custom code, and the expertise/development time/debugging/pain involved is much higher than just using GNU Radio on the host.  


** 8 Mega complex samples per second -> 8MHz when the real and imaginary
parts of the complex sample are each 16 bits wide. (=32Mbytes/sec)

** 16 Mega complex samples per second -> 16MHz when I/Q are reduced to 8
bits each (=32Mbytes/sec)

** When you use 8 bit data transfer (decimation =4) you will get the 16MHz instantaneous bandwidth. Check the available options of the usrp_fft.py. 


** LOL and another one .. but very clear :
Reference : http://gnuradio.4.n7.nabble.com/Maximal-signal-bandwith-for-the-usrp-tt15432.html#a15433

The USRP can code signals as 32 bits (16 for Q and 16 for I)
In this case the usrp is able to process signals up to 8 MHz.
The USRP can also code signals as 16 bits (8 for Q and 8 for I)
In that case the usrp is able to process signals up to 16 MHz. 

No throttles when using actual hardware sink

Reference : http://gnuradio.4.n7.nabble.com/OFDM-MODULATION-DEMODULATION-PROBLEM-tt38053.html

Remove the throttles, the sample rate is already throttled by the usrp. Otherwise here will be a fight.

Similarly when audio sink is there , no need to use throttle block

We receive 75-80% of the passband only !!

Reference : http://gnuradio.4.n7.nabble.com/8MHz-Tx-Bandwidth-Nightmare-and-Fear-tt14559.html#a14561

No system is capable of using 100% of the nyquist bandwidth, and the USRP is no exception.


On receive, our passband is flat out to about 75 or 80% of nyquist.  

For 8 MS/s complex sampling, that gives more than 6 MHz of flat bandwidth. 

On transmit, there are no halfband filters in there, so you will see more rolloff from the CIC filters.


If this is a problem, you have 3 options:

-  If your generated signal is at less than 8 MS/s complex, then you
should just upsample in software.

-  If your generated signal is at the full 8 MS/s then you can
pre-distort your signal to compensate for the CIC rolloff.

-  Otherwise, I would suggest making a new FPGA image with halfband
filters in the TX side.  You can make room in there by removing one
receive chain (leaving only one).

OFDM : Different modulation schemes on individual subcarriers

Reference : http://gnuradio.4.n7.nabble.com/introducing-different-modulation-schemes-for-each-sub-carrier-in-ofdm-tt31320.html

Look in gr_ofdm_mapper_bcv and gr_ofdm_demapper_vcb.

A chemistry/Biology guy doing GNU Radio stuff !!!

http://www.reynwar.net/ben/docs/fft_dit/

A bit about tunning the daughter boards

Reference : http://gnuradio.4.n7.nabble.com/multi-file-usrp-tuning-options-tt12814.html#a12816

Is there one LO on the USRP which is being switched between these frequencies, or is there more than one LO?

The tuning is split between an LO on the daughterboard and the DDCs in the the FPGA.

In the case of the Basic Rx and LF RX, there is no LO on the daughterboard, so all the tuning is handled by the DDC. 

** Basic Rx and LF RX have LO on the daughterboard,

When using std_4rx_0tx.rbf, there are 4 DDCs available in the FPGA. 


u.tune(...) handles adjusting the LO (if any) and the DDCs transparently for the common case

Can I tune all four subdevices independently, or am I restricted to using the same frequency on a given daughterboard?  

With the Basic and LF Rx everything is independent, since there's no
LO on the daughterboard.

In the case of daughterboards with LO's, life is a bit more complicated and you'll have to explicitly control the LO on the daughterboard, and then explicitly control the 2 DDCs that are being fed from the given daughterboard.

You of course need to ensure that that two frequencies that you want within the IF passband of the daughterboard.  

To see how this is currently handled, take a look at the implementation of "tune" in gr-usrp/src/usrp.py

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meanwhile :

tuning is a two step process. first we ask the front end to tune as close as the desired frequency as it can. then we use the result of that operation and out target frequency to determine the value for the DDC

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A doubt (Now cleared)

If I am sampling at Fs, then the observable b/w is Fs/2

in uhd_fft , when I set sampling freq to X MSPS, I see the b/w is also X MHz wide.

What is the catch here ?

Ans : The catch here is complex sampling . The line which you mentioned above is true for real sampling , but for complex sampling you can observe a b/w of Fs when you are sampling at a rate of Fs.

Got it !!! :)

Important about USRP FPGA images and DDC Filters (CIC + HBF)

USRP-1 has two fpga images :

One with half-band filters and another one without half-and filters.

The fpga file with half-band filter is

usrp1_fpga.rbf located in /usr/local/share/uhd/images

USRP1 cannot achieve decimations below 8 when the half-band filter is present.

This means you cant get samples more than 8 MSPS in the CPU when the half-bad filters are present because actual rate at which CPU receives samples is  adc_rate/decim_rate i.e. 64MSPS/decim_rate , so if decim_rate >=8
this implies samples per sec to CPU <= 8MHz and hence we wont be able to see more than 8MHz

The another image i.e. usrp1_fpga_4rx.rbf file is a special FPGA image without RX half-band filters.
To load this image, set the device address key/value pair: fpga=usrp1_fpga_4rx.rbf


uhd_fft -a "fpga=usrp1_fpga_4rx.rbf"

Even after using this fpga image you wont get samples more than 16MSPS to the CPU

If you try to go above , it will get back to 16MSPS only,

So this means no decimation less than 4 is possible in any of the current FPGA images.

** Keep in mind that if you use this image then there is no low pass filtering by the half-band filter. Low pass filtering is essentially required after decimation. So in this case you have to do low pass filtering in software by yourself. 

** uhd set_samp_rate never fails; always falls back to closest requested

** If the USRP DDC decimation rate is X. The CIC filter response (decimation =Y ), HBF response (decimation =Z) and cascaded CIC + HBF (total decimation =Y*Z ) i.e. X is actually Y*Z ... Since DDC is implemented with CIC and half-band filters !!

** But for the another image i.e. without half-band filter, the total decimation = Y only

** CIC decimator is a fourth order filter here

Details about CIC decimator can be found in

/fpga/usrp1/sdr_lib/cic_decim.v


** Half-band filter is 31 tap

The coefficients of the Half-band are symmetric, and with the exception of the middle tap, every other coefficient is zero.  The middle section of taps looks like this:

  ..., -1468, 0, 2950, 0, -6158, 0, 20585, 32768, 20585, 0, -6158, 0, 2950, 0, -1468,                                                                   |
                                        middle tap -------+
Details about its implementation can be found in
/fpga/usrp1/sdr_lib/hb/halfband_decim.v



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One interesting discussion :

Reference : http://gnuradio.4.n7.nabble.com/Disabling-the-USRP-FPGA-HBF-tt12603.html

Is there away to disable (or bypass) the USRP FPGA DDC half band filter? I want to get the samples directly from the CIC decimation filter and do the low pass filtering by software. I developed a MATLAB based professional 100KHz bandwidth digital down converter as shown in the attached m file. I want to test this design in USRP. In the mean time, I cannot do this because I don't have access to the CIC output samples because of the HBF.
Waiting for your help, thank you.


Firas.

If receive only is OK, you can use the "fpga=usrp1_fpga_4rx.rbf" configuration

Eric

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A very nice discussion about frequency response of the various filters involved in the DDC stages.

Reference : http://gnuradio.4.n7.nabble.com/wise-big-block-interleaving-in-GNURadio-tt12573.html#a12576

USRP CIC Frequency Response :


USRP CIC Frequency Response Zoomed :


USRP half-band Filter Frequency Response :

Something about Multichannel spectrum sensing

Two interesting spectrum sensing scripts I digged form forum.

http://gnuradio.4.n7.nabble.com/file/n29827/sensing_single_RX_channel.py

http://gnuradio.4.n7.nabble.com/file/n29827/sensing_2_RX_channel.py

Interesting Discussion on Changing Parameters at Runtime

Reference : http://gnuradio.4.n7.nabble.com/how-to-achieve-change-values-of-parameters-at-runtime-tt29993.html#a29995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

tx.ofdm_tx._tx_freq is just a variable holding the frequency, but does
not set it.

You have to re-tune the usrp (tb.set_freq(new_freq)).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Something about Spectral Correlation Function

Reference : http://gnuradio.4.n7.nabble.com/Problem-with-spectrum-sensing-using-cyclostationary-features-tt29836.html

USRP and GSM

Reference : http://gnuradio.4.n7.nabble.com/Is-it-possible-to-make-a-USRP-Tx-and-Rx-at-the-same-time-tt20901.html


GSM is a half-duplex TDMA protocol.  That is, a station is only ever
transmitting or receiving, but not both at the same time. 

The channel is divided into timed frames and slots, and the base
station and mobile units are allocated specific times to transmit.  

The USRP is capable of supporting this. 


There are at least two existing open-source GSM BTS implementations;
OpenBTS is one of them:

http://gnuradio.org/trac/wiki/OpenBTS

This project uses the low-level C++ interface to the USRP1, but not
the GNU Radio framework itself.

Some thing about source and sink connection

When a source src has multiple outputs we can connect as follows


fg.connect((src, 0),.......blocks of fg1)
fg.connect((src, 1),.......blocks of fg2)
fg.connect((src, 3),.......blocks of fg3)

or in other case 

fg.connect((src, 0),.......blocks of fg1)
fg.connect((src, 0),.......blocks of fg2)
fg.connect((src, 0),.......blocks of fg3)


This will connect output 0 to fg1 and output 1 to fg2 and so on

But when it has single output , we connect as 

fg.connect(src, fg1)
fg.connect(src, fg2)  

 

Spectrum Sensing Code Explanation by Firas. A

Reference : http://gnuradio.4.n7.nabble.com/Some-usrp-spectrum-sense-py-code-Explanation-tc26301.html

This program can be used as a basic code for implementing wideband spectrum analyzer. 

The USRP cannot examine more than 8 MHz of RF spectrum due to USB bus limitations. 


So, to scan across a wide RF spectrum band (bigger than 8 MHz) we have to tune USRP RF front end in suitable steps so that we can examine a lot of spectrum, although not all at the same instant. 


The usrp_spectrum_sense shows the way how it can be done.It steps across the spectrum and make the RF measurements. This application can sense a large bandwidth, but not in real time, and it can do the frequency sweep over the required frequency range

Theory: 

To use N points complex FFT X(W) analysis, we have to get N time samples x(t) which are sampled at Fs. 

These N time samples must be time windowed using a known window function to reduce spectral leakage.

Performing N points complex FFT analysis. 

The output of the complex FFT will represent the frequency spectrum contents as follows: 

1. The first value of the FFT output (bin 0 == X[0]) is the passband center frequency. 
 

2. The first half of the FFT (X[1] to X[N/2-1] contains the positive baseband frequencies,which corresponds to the passband spectrum from the center frequency out to the maximum passband frequency (from center frequency to +Fs/2).     

3. The second half of the FFT (X[N/2] to X[N-1]) contains the negative baseband frequencies,which correspond to the lowest passband frequency up to the passband center frequency (from -Fs/2 to center frequency). 

Example :

Let us assume that we have 1024 (I and Q) samples gathered using a tuner centered at 20MHz. And let us assume that the sampling frequency was 8MHz.
Doing 1024 points complex FFT means: 

1. FFT Frequency resolution is : 8MHz / 1024 = 7812.5 KHz 

2. The output of the FFT X[0] represents the spectrum at 20MHz.  

3. The output of the FFT X[1] to X[511] represents the frequencies from 20.0078125 MHz to 23.9921875 MHz (about 4MHz above center frequency). 

4. The output of the FFT X[512] to X[1023] represents the frequencies from 16.0078125 MHz to 19.9921875 MHz (about 4MHz bellow center frequency).
 


RF Frequency Sweeping:

1. Let us suppose that we want to scan RF spectrum band from 10MHz to 52 MHz. 

2. Let us remember that USRP can analyze 8MHz of frequency at a time.  

3. So theoretically we have to step our RF center frequency as follows: 

First step is 14MHz (it will cover frequency band from 10MHz to 18MHz), 
 
Second step is 22MHz (it will cover frequency band from 18MHz to 26MHz), 
 
Third step is 30MHz (it will cover frequency band from 26MHz to 34MHz), 
 
Fourth step is 38MHz (it will cover frequency band from 34MHz to 42MHz), 
 
Fifth step is 46MHz (it will cover frequency band from 42MHz to 50MHz), 
 
and finally the Sixth step is 54MHz (it will cover frequency band from 50MHz to 58MHz). 

Remember that we want the frequencies up to 52MHz only, so we have to discard some FFT points from the Sixth analysis.   

Paralytically we have to use FFT overlapping to reduce the non linearity response of the Digital Down Converter (the DDC frequency response is not Flat from -Fs/2 to + Fs/2) and to fill the frequency holes that will be present at the FFT analysis edges (10MHz, 18MHz, 26MHz, 34MHz, 42MHz, 50 MHz).  


So if we choose to use an overlap of 25%, this means that our step size will be 6MHz (8MHz*(1-.25)), thus practically we have to step our RF center frequency as follows: 


First step is 13MHz (it will cover frequency band from 9MHz to 17MHz), 
 
Second step is 19MHz (it will cover frequency band from 15MHz to 23MHz), 
 
Third step is 25MHz (it will cover frequency band from 21MHz to 29MHz), 
 
Fourth step is 31MHz (it will cover frequency band from 27MHz to 35MHz), 
 
Fifth step is 37MHz (it will cover frequency band from 33MHz to 41MHz), 
 
Sixth step is 43MHz (it will cover frequency band from 39MHz to 47MHz), 
 
and Finally the Seventh step is 49MHz (it will cover frequency band from 45MHz to 53MHz),  

Changing RF center Frequency  

To change USRP RF center frequency we have to send a tunning command to the USRP every time we complete the analysis of the current frequency chunk. 

Before gnuradio revision [10165], all USRP RF daughterboards tunning were done using Python functions and classes. After that revision, tunning the USRP daughterboards from withen C++ code is possible. 

In usrp_spectrum_sense.py, the DSP C++ written code is allowed to transparently invoke Python code USRP tune function. This tunning control is done in gr_bin_statistics_f sink function. 

Tunning Delay Problem:   

When we command the usrp RF daughterboard to change its center frequency, we have to wait until (right) ADC samples arrive to our FFT engine and we have to insure that it belongs to the wanted center frequency. This represents a problem since there are many delays along the digitization path (RF synthesizer settling time, and pipeline propagation delay [FPGA FIFO filling time, USB transferring time...etc]). To overcome this problem we have to use enough tune delay time in order to  be sure that the samples entering our FFT block are belong to the requested center frequency. This is done simply by dropping the incoming received samples over a specified tunning delay time. 

usrp_spectrum_sense Implementation

1. The engine of the usrp_spectrum_sense depends mainly on bin_statistics sink function.  

2. bin_statistics function combines statistics gathering with a state machine for controlling the USRP RF tuning (frequency sweeping). It determines max values (keeps track of the maximum power in each FFT bin) of vectors (with length vlen) over a time period determined by dwell_delay (after converting it to a number of FFT vectors). This operation is performed after discarding tune_delay samples.  

3. After processing N = dwell_delay samples, bin_statistics composes a message and inserts it in a message queue. 

4. Each message from bin_statistics consists of a vector of max values, prefixed by the center frequency corresponding to the associated samples,
i.e., it is the center frequency value of the delivered input samples to bin_statistics. 

Choosing Tune and Dwell delay times  

1) We have to play with the --tune-delay and --dwell-delay command line options to determine appropriate timming values. The most important one is the tune delay time.

2) The choose of tune-delay should include time for the front end PLL to settle, plus time for the new samples to propagate through the pipeline.  The default value is 1ms, which is probably in the ballpark on the RFX** boards.  The TV RX board is much slower.  The tuner data sheets says it could take 100ms to settle.

3) The tune delay timing parameter passed to bin_statistics is calculated in FFT frames which depends on USRP rate and FFT length as in :

tune_delay_passed_to_bin_statistics = int(round(required_tune_delay_in_sec*usrp_rate/fft_size))

if this calculated value is less than "1", then we should make it at least "1" FFT frame.

For example:

If the :

required_tune_delay_in_sec = 10e-3
and usrp_rate = 8000000 (decimation =8)
and FFT size is 1024


Then :

tune_delay_passed_to_bin_stats = 78   (FFT Frames)

This means we have to skip 78 incoming vectors (FFT frames) before we actually use the acquired samples in our spectrum statistics. 

Beside tunning time depends on the hardware (RF synthesizer speed),one should remember that the time needed to collect 1024 samples
with decimation rate=8 (minimum USRP decimation) is 128 usec, while the time needed to collect 1024 samples with decimation rate=256 (maximum USRP decimation) is 4.096 msec.

This means that the tune delay in the case of decimation rate =256 should be larger than that used for decimation = 8. 

A working tune delay value (which gives accurate results) can be known by experiments (for given decimation rate and FFT length).

Interrupting Output Spectrum  


The actual mapping from the levels at the daughterboard antenna input port to the output analysis values depends on a lot of factors including the used daughterboard RF gain and decimation specific gain in the digital down converter. You'll need to calibrate the system if you need something that maps to dBm.


Currently, the output of usrp_spectrum_sense is the magnitude squared of the FFT output.

That is, for each FFT bin[i], the output is Y[i] = re[X[i]]*re[X[i]] + im[X[i]]*im[X[i]] which  is nothing but power


If we square root the output, and divide it with the fft size, then we will get the voltage magnitude.

Calculating 20 Log10 this value will give us the power.

 
 
    

Something about IIR Filter Co-efficient Normalization

If you're implementing an IIR filter then you are more constrained -- you
are designing a feedback loop, and the gain around the loop determines
the loop performance.  So if you normalize the coefficients to fit (and
you often do) you have to renormalize the result before you use it.  

Further, coefficient precision can have an impact on your filter
performance, as can the precision of the intermediate calculations.

Normalization matters in fixed-point arithmetics, where one wants to avoid underflow and overflow and so on.

You don't need to normalize filter coefficients to 1 under fixed point. 

There are three normalization method typically (cited from MATLAB help):

1. sum of the coefficients means that the sum of the coefficients equals 1

2. filter energy means that the sum of the squares of the coefficients equals 1;

3. peak amplitude means that the maximum coefficient equals 1.

What is the difference between the above three normalizations :

The first (with "magnitude" added) guarantees no internal overflow.

The second defines that the power of the output signal is the same as the power of a broadbanded input.

The third just says that you can represent your coefficients with fixed-point numbers (normally between -1 and +1) and have their relative values (to each other) be correct.

Normalization does not change the shape of the filter

Reference : http://www.hydrogenaudio.org/forums/index.php?showtopic=43195

Rate at which CPU gets the data

USRP ADC sampling rate = 64MSPS

Decimation Rate = x

Actual rate at which CPU gets data = 64/x MSPS

16bit for I and 16bit for Q

64/x MSPS = 64/x I samples + 64/x Q samples

So total bytes per sec = (64/x*16 + 64/x*16)/8

For x = 200

total bytes per sec =(64/200 + 64/200)*16*10^6 = 1.28 MBPS

For x = 100

total bytes per sec = 2.56 MBPS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If the CIC starts linearly from 4 to 128, and followed by decimate by 2 Half Band Filter (HBF) Then [CIC+HBF]  should give us the following range [8,10,12,14,...........,256], and not the range [2,4,6,8,......,256] 


Reference :  http://gnuradio.4.n7.nabble.com/USRP-RX-Decimation Rate-tt11784.html

But Matt said something different

The CIC decimator does 4 through 128, but this is followed by a halfband
decimator which multiplies this by a factor of 2.  Thus, it only does
multiples of 2.  4, 6, 8, 10, 12, 14, 16, 18. 20, etc.   Up to 256 total.

Matt 

Reason of Frequency Spurs in FFT

Reference : http://gnuradio.4.n7.nabble.com/Artefacts-in-usrp-fft-py-tc11359.html

Sometimes we see several unknown frequency components visible in our FFT plot.

These are called "receiver spurs" or "rf spurs" or "a/d spurs"

You can check whether it is because of internal hardware imperfections or some external source. Following is a very simple test to verify it :

Note down the frequency of the spur, now tune the receiver again say by 1KHz and see the frequency of the spur again

If it doesn't move or if it moves in the opposite direction or it moves with an amount other than 1KHz , then it is an internal artifact not external.

** Histogram of a noisy input will be of Gaussian in shape

You can also check the proper functioning of the ADC by observing the  histogram.

Spikes in the histogram may indicate the bits which are stuck

A/D's also have quantization effects that are periodic and show up as spurs


Adding dithering noise helps to break up the periodicity and reduce the spurs.

** Dithering is a process that adds broadband noise to a digital signal. You may wonder why adding noise would make a signal sound better? It is really a trade off. The introduction of noise lessens the audibility of the digital distortion that comes from the quantization errors discussed above. In essence, low-level hiss-like noise is traded for a reduction of digital distortion.Dithering adds amplitude to all the signals in a digital sample. It forces the lower level amplitude values up to the next threshold level.

Reference : http://www.pcrecording.com/dither.htm

Can we detect Bluetooth and 802.11 with USRP-1

A Nice Discussion : 

The answer is no.

The bandwidth is too large for the system to currently  handle.

If you tune the GNU Radio to the center frequency of an 802.11  channel, you'll see what looks like a rise in the noise floor (and, under  these conditions, it really is a rise in the noise) when there is a  transmission. 


Bluetooth signals hop from 2.402 - 2.480 MHz

79 1 MHz channels at a rate of  1600 hops per second. 


The GNU Radio cannot look a the entire band all at  once

If you look at a particular slice (~4 MHz) of spectrum, you might  catch a glimpse of a signal every now and then, unless you can plug in the  right frequency hopping sequence

If you have some 1 or 2 Mbps 802.11 devices to use, the BBN guys have done
work on receiving those. Here is the link.

Reference : http://gnuradio.4.n7.nabble.com/802-11-and-Bluetooth tc8615.html#a8618

usrp_spectrum_sense.py application can  sense a large bandwidth, but not in real time! It can do a sweep over  a very large frequency range, but it will very likely not be able to  detect bluetooth (since it is frequency hopping) nor 802.11b/g since this will most likely just look like noise.

Anyway, it is difficult to just detect wi-fi without trying to decode it, since it is not a continuous signal, i.e., packet oriented. Therefore, you won't have a
nice peak in your fft, compared to a radio broadcast channel.

Normally an AP will send beacons at 1 Mbps even if it is a b/g AP. 

Here Eric says :

Actually, I think you should be able to detect Bluetooth without too
much trouble.  If you just stare at a single point in the spectrum you
should be able to reliably detect 7 1 MHz channel's worth of data.

IIRC the hopping sequence is known, and thus you should be able to
determine if what you are seeing is bluetooth or not, even though you
are seeing only 7 out of 79 channels.

Eric 

Bandpass sampling says :

Bluetooth is only about 1 Mb/s data rate, so you should be able to decode it with only a few MSPS of sampling. 

 

Very Important Basics on usrp_oscope.py

usrp_oscope.py -f 103.3M -d 256

The command above, after executed, will plot the received signal in a 250KHz window centred at 103.3MHz

250KHz because the USRP samples at the rate of 64MSPS and decimation is 256, thus 64M/256 = 250e3 = 250KHz

Similarily if the decimation was 512, then we would have observed the received signal in a 125KHz window

This can be more clear if you see the fft of the signal with the same decimation rate.

You can observe that the length of the fft window will go from 0 to fs/2 and 0 to -fs/2 giving a total observable window of length fs Hz

** The Y axis of usrp_oscope does not show the voltage level, its not calibrated for that. The levels depend on gain settings too.

** usrp_oscope shows real and imaginary part of the complex baseband signal coming from the output of Digital down converter of the USRP

** So the usrp_oscope is actually showing the downconverted frequency, not the actual frequency

Something Important about usrp_spectrum_sense.py

gr_bin_statistics_f just keeps track of the maximum power in each FFT bin

--tune-delay  :  should include time for the front end PLL to settle, plus time for the  new samples to propagate through the pipeline.  The default is 1ms,  which is probably in the ballpark on the RFX-* boards.  The TVRX  board is much slower.  The tuner data sheets says it could take 100ms to  settle.

--dwell-delay :  says how long you want to "stare" at any particular window.

m.center_freq is the current tunning/tunned freq

m.data is the mag-squared of the FFT.


Output from m.data is from the center frequency to the maximum frequency and half way it flips to the minimum frequency and increases back to the center frequency.

In other words : 

The first half of the array contains the positive baseband frequencies,  which corresponds to the passband center frequency out to the maximum  passband frequency.

The second half of the array contains the negative baseband frequencies,
which correspond to the lowest passband frequency up to the passband
center frequency.

This format is due to the output format of the underlying fftw library we use to calculate FFTs.

You can rotate the values by swapping the first and second halves of the array and end up with it going from lowest passband frequency to highest passband frequency.

If you have taken 512 point FFT then , for each 512 bins, (m.data[0]) to (m.data[255]) are mag_squared values for (m.center[0]) to (m.center[0] +freq_step/2), and (m.data[256]) to (m.data[511]) are mag_squared values for (m.center[0]-freq_step/2) to (m.center[0]).

USRP is capable to monitor 32MHz theoritically but because of USB it can send only 8MHz of bandwidth to the CPU.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is a line in the usrp_spectrum_sense.py

self.msgq = gr.msg_queue(16) ,

Here 16 means the number of messages in the queue

If you set it to 0 , that means no limit

If the queue is full, an attempt to add a message will block until there's room.

gr_message_sink also has an option that will have it drop messages if the message queue is full

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

log = gr.nlog10_ff(10, self.fft_size, -20*math.log10(self.fft_size)-10*math.log10(power/self.fft_size)). 

** This formula is used to convert the FFT output value to dB. This is relative conversion and the values does not mean actual power because the actuall power value  depends on other factors such as RF gain used. 


** What is meant by relative, is that if the input signal power is (for example) -20dBm and we measured it in this formula as (say) 50dB, then when we change the signal power to -30dBm, we get 40dB from the output of this formula. So, lowering signal power level by 10dBm result a 10dB value reduction from the formula output. 

** So, what is the factors that effect dB conversion?. The first value is the FFT size, so that when we change the FFT size, the formula should compensate for this. Second we should compensate for the taps of the window used for FFT (Hanning, Hamming,...etc).