Hi guys ,
I am using DBSRX , now i am trying to trace the data flow in the
usr-gnuradio . I see AD9862 ADC in the usrp and some of the block
diagrams
, and i think that the daughterboard
passes the analog signals to the ADC in the I and Q format . Please
guide me
if this is right or wrong … Thanks .
ton ph wrote in post #994440:
Hi guys ,
I am using DBSRX , now i am trying to trace the data flow in the
usr-gnuradio . I see AD9862 ADC in the usrp and some of the block
diagrams
, and i think that the daughterboard
passes the analog signals to the ADC in the I and Q format . Please
guide me
if this is right or wrong … Thanks .
yes this is true , DBSRX output is basband in the I Q format , i’Ve used
a ocilliscope and got a baseband signal directly from the daughterboard
On 04/22/2011 01:54 AM, ton ph wrote:
Hi guys ,
I am using DBSRX , now i am trying to trace the data flow in the
usr-gnuradio . I see AD9862 ADC in the usrp and some of the block
diagrams , and i think that the daughterboard
passes the analog signals to the ADC in the I and Q format . Please
guide me if this is right or wrong … Thanks .
That is precisely correct, yes. Most daughterboards use an analog
quadrature mixer to produce
a complex (I and Q) baseband signal.
The TV_RX is one that doesn’t – it’s a conventional superheterodyne
receiver, with a final IF
frequency of (as I recall) 5.75MHz, which is passed to a single ADC
channel, and the FPGA
mixes it down to a complex baseband digitally using a digital
quadrature mixer.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 04/25/2011 03:45 AM, ton ph wrote:
The USRP2 and N2XX series sample signals at 100Msps, so the FPGA “sees”
100MHz of incoming
bandwidth. But the absolute most you can send down the 1GiGE
interface to the host is 25Msps.
If you modified the FPGA code to send 8-bit samples to the host, you
might be able to do 50Mhz,
and with 4-bit samples, 100Mhz. At least in theory.
In practice, you’ll have a hard time processing that much bandwidth on
the host computer, unless it’s
a really fast computer, and you’re not doing anything even vaguely
complicated with the signals
on the computer.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Hi marcus
thanks for immediate reply and your guide was very helpful from
my
side … Now the question is ,
suppose, i have 12 bit 200 mhz adc , and i do not want to reduce my
processing bit , as per the instruction from your side it could be
hard to process in my i5 , 4Gb ddr3 configuration computer and also i am
not
aware of the IF bandwidth which might require to make
the bandwidth process instantly ( simultaneously ) . Will gnuradio be
able
to support the instantaneous processing of the 100Mhz bandwidth,
I have a bit doubt as i learnt that gnuradio can support 8Mhz only.
Thanks , and i highly apologize if my post is a bit out of track or may
be
called a bit illogical …
Thanks marcus.
On 25/04/2011 8:34 AM, ton ph wrote:
Thanks , and i highly apologize if my post is a bit out of track or
may be called a bit illogical …Thanks marcus.
I process 25MHz bandwidth from a USRP2 with my Radio Astronomy
applications, on a 6-core AMD Phenom II X6 running at 3.2GHz.
The “8MHz” figure you quote is likely from the original USRP–nothing to
do with Gnu Radio, per se. The USRP1 has a maximum
bandwidth of 8MHz unless you drop down to 8-bit samples.
The computational load of a signal flow-graph is proportional to
bandwidth X complexity.
If you want to process 200Msps, with full 12-bit resolution, you’ll need
to find some other host interface than 1GiGe–you’d likely
need to go to a 10GiGe interface.
And while Gnu Radio “scales” arbitrarily, there are limits to the degree
to which you can optimize a flow-graph for performance.
The “Lego brick” approach to constructing processing graphs isn’t
optimal if really-high performance and low-latency are
important to you. In order to process 200Msps, you’d likely need to
hand-craft your signal processing chain, and carefully
parallelize it in an optimal way. No way are you going to be able to
do this on a single-processor machine.
Further, as you point out, the post-mixer bandwidth of the USRP-family
daughtercards is limited to much less than 50MHz, in order
for there not to be an aliases when sampled at the 100Msps rate of
the ADC on the USRP.
Thank marcus for the information ,
Thou it may be a out of track question , is that possible by using any
of
the daughter board available to process 100 Mhz of bandwidth … more
correctly what can i do, for Exp: if i want to access a bandwidth of
range
105 Mhz … will usrp be able to support, because as i think gnuradio
can
support only 8Mhz bandwidth at a time , will we be able to make changes
in
gnuradio ? … I highly apologize if any of my question is illogical
or
out of track.
Thanks
On 25/04/2011 9:33 AM, ton ph wrote:
to the CPU. But my doubt still exist, processing the 100Mhz bandwidth
using gnuradio wil be possible or not ? … Do we need high IF upto
how much so as it can process 100Mhz … ?
Certainly, if you pre-process your entire bandwidth in the FPGA on your
front-end device, such that only a smaller bandwidth is
required to be processed on the host computer, that will help a lot.
I don’t think there’s a clear answer to “can Gnu Radio do what I want”,
without knowing what you want to do with the data on the
host computer. You might want to put together a few “test”
flow-graphs and see how much CPU resources they consume, and use
that as a model to guide you.
Gnu Radio isn’t inherently limited to any particularly bandwidth–it
doesn’t really know anything about bandwidth. But as a
practical matter, Gnu Radio executes algorithms–collections of
mathematical operations on the data stream from a sample
source. Those mathematical operations have some cost, in terms of
how many millions of them you can execute in any given
length of time on any given CPU configuration.
Since Gnu Radio uses floating-point, it’s quasi-useful to know how many
FLOPS (Floating-point operations/second) your particular
CPU can perform. The Core i7 920, for example, is rated at roughly 70
GFLOPS (7 x 10**10 FLOPS), which means that it can
execute roughly 70 billion floating-point multiply-add pairs per
second (probably using SSE floating-point operations).
So, let’s say we’re processing 100Msps complex samples, that’s
effectively 200Msps (I and Q). Let’s say we’re processing those samples
on the above-stated Core i7 920, and that we’re using a
perfectly-optimal algorithm, with perfectly-optimal compilers, etc,
etc. That
means that our overall processing algorithms can only perform:
7.0e10-FLOPS / 2e8-SAMPLES = 350 OPS/SAMPLE
You won’t be able to perform more than 350 multiply-add equivalent
operations in the very best case, before your CPU isn’t able to
“keep up”. In reality, you’ll run out of performance long before the
theoretical limit has been reached.
I have a question regarding the data processing. Please let me join this
interesting discussion.
I was wondering if we can take the data to an FPGA board like XilinX
FPGA board (V5 or V6) and do the heavy processing there before streaming
it to a PC where we do light processing and display. Is it possible to
route the data processing like this?
Khalid.
Hi marcus ,
As spotted by khaleed i think that could be possible regarding ,let
another
external FPGA does all the heavy works , Now as i have spotted out
before ,
If i just do not let the complete 100Mhz band to be processed in my CPU
and
just choose only some part of the band for exp: 350 * 10 = 3500 Khz , to
let
enter my cpu and process that much bandwidth only. Which will reduce
much of
the overhead calculations in the CPU. I think this could help out. Now,
i
would like to point out what i have in my mind,what I am thinking is
,to
let the 100Mhz bandwidth to be processed by my 12 bit 200MSPS ADC , and
later my 32 bit DDC choose only 350*10 = 3500 Khz bandwidth , and let
the
3500 Khz bandwidth to be processed in my i5 processor ( thou i dont know
how
system performance can be calculated ) and by doing so i can make the
system
be able to do the calculations. Now here my doubt comes that, using the
high
speed ADC , DDC would not gnuradio breaks in some part like processing ,
data transfer etc.
I apologize for any mistaken questions or my innocence with regard to
gnuradio capability, any proper guides will be highly appreciated.
And can you Please suggest me , how much IF i should require to make the
100Mhz bandwidth to be able to process in my 200MSPS ADC,
Sorry for late reply.
Thanks.
Thanks marcus , yes i am referring Software define radio , by jeffrey
and Understanding digital signal processing by Lyon.
One question which i would like to know a thing is regarding the above
discussion on processing 100Mhz bandwidth by my 200MSPS ADC, would not
there be any problem of breakage in the flowgraph in such high speed ,
and thus i can use gnuradio for processing the 100Mhz bandwidth. Can
you please suggest this and i think after that i better start working
on gnuradio what i want it to do.
The preferred topology is to run your ADC at 100Msps, and make it a
dual-channel ADC, and have it process baseband-signals only.
Gnu Radio itself doesn’t have any limitation with respect to incoming
bandwidth, per se. But Gnu Radio executes on a real CPU,
with real limitations. In the end, it comes down to how much $$$
you’re willing to throw at the problem, and how much
hand-tuning you’re willing to do.
Thanks marcus ,
i very much appreciate the info and has cleared many of my wrong
concepts
about usrp and gnuradio. As you have said , processing 100Mhz of
bandwidth
using gnuradio will be a bit Hard unless handcrafting the signal
processing
block by hand , what if I processes the 100Mhz bandwidth by a 200Mhz ,
12
bit ADC and later on i choose only 10 channels out of my 100Mhz full
band
data , by a 32 channel DDC , in which i can access each channel data
from
software. Which might reduce my bandwidth entering the CPU to about for
example: 350 * 10 = 3500 Khz . If i follow this trend, i could reduce
much
of the overhead to the CPU. But my doubt still exist, processing the
100Mhz
bandwidth using gnuradio wil be possible or not ? … Do we need high IF
upto how much so as it can process 100Mhz … ?
Thanks in advance for your genuine and helpful guide , and again i
highly
apologize any illogical post from my side .
Thanks.
On 28/04/2011 5:15 AM, ton ph wrote:
rate will also increase and hence the rest of the chain.
Your geniune advice is very much weighed from my side as well i am
still hoping your geniune suggestions and guide.
Thanks
I don’t have a full picture of your overall architecture, so I’m
unwilling to make a definitive “yes” or “no” statement about what you
will ultimately
be able to make work.
It sounds like you’re contemplating custom hardware, with a DDC
implemented somewhere along the pipeline–in an FPGA?
Anyway, I think I’ve given you all the pointers and hints I really can
at this point, and it’s now up to you to “run with it”.
Thanks marcus ,
That means , if i use i5 processor and make some tweaking in gnuradio
in
right areas , i could be able to process my 100 Mhz bandwidth using my
200
MSPS ADC, 32 channel DDC which will only send data of only 3500Khz
bandwidth
data to the CPU, in spite of inviting a big overhead to the CPU by
letting
in the complete 100Mhz bandwidth baseband data… If i let CPU to
process
only 3500 Khz bandwidth data , i think we will be able to make the
gnuradio
do the processing.What my doubt was that using 200MSPS ADC with gnuradio
could give some trouble or not … as with the increase in the ADC rate
, i
hope the data
rate will also increase and hence the rest of the chain.
Your geniune advice is very much weighed from my side as well i am still
hoping your geniune suggestions and guide.
Thanks