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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
