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.
** 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 comments:
Post a Comment