discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Complex Short/INT16 type


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Complex Short/INT16 type
Date: Tue, 08 Nov 2011 09:13:44 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1


On 11/07/2011 02:15 PM, Nowlan, Sean wrote:
> Hi all -
> 
> I'm getting limited by the slow ARM processor in the E100 and I want
> to modify parts of gr-digital and gnuradio-core to support complex
> short/INT16 types in the modulation schemes. I suspect that it won't
> be as trivial as defining "typedef std::complex<short> gr_complexs;"
> in gnuradio-core/src/lib/runtime/gr_complex.h and doing a
> find-and-replace in the relevant source files. There are probably

It may be that simple for some blocks. Like the symbol table in BPSK.

> issues with dynamic range that I'll have to deal with in addition to
> having to implement filters using fixed-point math.
> 

Often blocks will need to have scale factors. Fortunatly, with a FIR
filter, you get a free scale factor in the "filter taps"

> Questions:
> 
> 1)      Do you think I'd save anything by doing all the modulation &
> filtering in complex float32 and then converting at the very end?

Its good to make the conversion part of an operation that does something
useful rather than doing it for the sake of converting. Like a filter
that takes in floats and spits out shorts.

> This will reduce the bandwidth requirement to the FPGA by two, but
> I'm afraid the float math is the true limitation.
> 

The format going into the FPGA is always integer. If you pass floats
into the UHD, they are copy-converted from host buffer to memory mapped
buffers.

> 2)      Why is there a gr_complex_to_interleaved_short block but not
> a gr_complex_to_complex_short block? Would it be better if I rolled
> my own or just hooked up a gr_complex_to_interleaved_short block and
> then a deinterleave block? Or alternatively, split the complex float
> vector into two streams and feed them to a USRP sink block using
> COMPLEX.INT16?
> 
The interleaved short block is a strange hold-over from ancient times. I
would ignore it. I think a block such as "gr_complex_to_complex_short"
is a good idea.

> 3)      What specific parts of the modulation examples or
> gnuradio-core do you think I need to change to support complex short
> ints?
> 

Probably some new sc16 filter blocks for the matched filters. I have
mentioned the importance of volk before.

The constellation stuff relies on this new constellation library in
gr-digital. Perhaps Ben can lean in here and offer some advice on how to
modify this for alternative data types.

The recovery stuff in the BPSK is using Tom's new gri-control-loop to
simplify writing things like FLLs, PLLs. Thats a place too look, see how
the timing recovery blocks make use of it.

-Josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]