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.