Re: Mixing two signals for Radar application

Hi Marcus,here is the flow graph and the output signals with movement
across the antennae and without. (GRC
flow) (without
movement) (with movement)Thank
On 26.03.2014 15:28, Marcus M. wrote:> Hi Dimitris,


Hash: SHA1

Hi Dimitris,

I thought you might be supplying us with some background on the flow
graph, hardware, expected Doppler Shift, target range etc.
You’re just posting the effect, without even referring to what you’re


On 27.03.2014 10:11, Dimitris Siafarikas wrote:

Hi list, I am in the process of building an FMCW radar. For

_______________________________________________ Discuss-gnuradio
mailing list [email protected]

Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -


Hi Marcus,
here is the flow graph and the output signals with movement across the antennae
and without. (GRC flow) (without movement) (with movement)
Thank you.
OK, so I looked at the flow-graph you posted. There’s a lot of
confusion in there, it has a lot of “confusion per unit area” of
flow-graph, so there’s
a list:

o You’re mixing sample-rates without doing any interpolation or
decimation. For example, slamming your 100ksps signal source into a
USRP hardware
source that will try to suck samples out at 20Msps.

o You’re trying to mix this 100ksps source with a USRP source running
at 25ksps (which isn’t a valid rate for any USRP that I’m aware of).

o You’re using a throttle block in a chain that includes hardware –
I’m guessing that you thought maybe it would do sample-rate conversion
or something, but it isn’t clear what your intention is here.

o You’re trying to generate a 1MHz signal source with a sample-rate
of only 100ksps. This violates Nyquist rather badly.

I think you need to understand what your bandwidth requirements are, and
let that guide your sample-rate decisions. If this is a CW radar, you
don’t need a lot of bandwidth, and thus, sample-rate.

You don’t mention what USRP hardware you have, but in general, the
sample-rate must be a proper integer fraction of the master-clock rate,
and generally, the resulting decimation can be no higher than 512.
Some USRPs (B100, E1xx, B2xx) have variable master-clocks, so you
can achieve a variety of different rates.

Further, my suspicion from all the above is that your current grasp of
DSP techniques isn’t all that solid–I could be wrong, but it seems
way from the flow-graph. My suggestion would be to step back, trying
to really understand what you want to do, and maybe curl up with
a book on DSP first. While “stumbling around” when you’re just
building RX flow-graphs with real hardware doesn’t do any harm, doing
same with TX flow-graphs can get unwanted visits from the Federal
Authorities in some countries…

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs