discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Encoder Integration


From: Brian Padalino
Subject: Re: [Discuss-gnuradio] Encoder Integration
Date: Sun, 28 Oct 2007 22:29:54 -0400

Here are some of the thoughts running through my head in no particular order.

You don't have to have the RRC filter for transmit if you don't want
to.  The CIC and the reconstruction filter of the DAC should take care
of filtering out a good portion of the extra spectrum.

To achieve the best performance with the convolutional code, some
interleaving should also be used to utilize time diversity on the
burst transmission.

The modulator LUT should really be an M-QAM LUT that can be configured
to restrict itself to QPSK or BPSK as well.

Another option would be to try to figure out a CPM style mapper that
can be used and/or updated in-band to utilize a different number of
CPM waveforms that require no extra filtering and have the filtering
built into the LUTS.

The Viterbi decoder will probably not be of use while there is no
receiver functionality built into the FPGA as well.  As such, the
testbench for the Viterbi decoder should probably be extremely
extensive and more effort should go into making the decoder extremely
generic (eg: How many ACS units to use in parallel, should traceback
be done in a burst or windowed, programmable constraint length and
generator polynomial, etc).

How hard would it be to change the algorithm to be a soft output
Viterbi algorithm (SOVA) for use with Turbo Codes?  Here is a little
stub:

    http://en.wikipedia.org/wiki/Soft_output_Viterbi_algorithm

Robustness is key to utilizing this code in the fullest extent.

Brian




reply via email to

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