Encoder Integration

Hi,

I have implemented a convolutional encoder and a viterbi decoder in
Verilog
and am trying to integrate it with the existing GNU Radio software and
make
it available to everyone, once I integrate it.

My encoder takes in the input binary bits and generates encoded binary
bits,
based on defined parameters.

I am first focusing on integrating the encoder with the GNU Radio
software.
My understanding from the code is that the following steps are performed
while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py,
modulation_utils.py ) :

  1. Generate random bits.
  2. Map bits to symbols (gmsk or any other modulation )
  3. Convolve the symbols with a wave and taking discrete samples
    (Sampling)
  4. Combine the step (3) samples with header information and make a
    packet.
  5. Pass it on to the FPGA.

Generating bits and sending it to FPGA for encoding using my encoder
module
and sending the encoded bits back to follow the above chain will
possibly
not make sense as I am overusing the bus resources, which would defeat
the
purpose of encoding in Verilog/FPGA . (bus usage should decrease by
transmitting raw bits across the bus).

So, should I pass all the above (steps 1 to 5) functionalities into the
FPGA
i.e. generate, “encode”, map, convolve inside the FPGA and then pass it
on
to the existing functionalities in the FPGA ?

Or is there a more optimum way to do this ?

Any inputs on the above would help me. I am stuck with this problem for
quite some time now.

Please correct me if I am going wrong somewhere.

Thanks.

Best Regards,
S. Mande.

S Mande wrote:

My understanding from the code is that the following steps are performed

Or is there a more optimum way to do this ?
Well you could still generate the random bits on the host.
You should however implement the other steps on the FPGA.
There are ways to implement optimized root-raised cosine filters and
(fractional) resampler filters in the FPGA if you do BPSK or QPSK.
(because you only have +1.0 and -1.0 values)
(I have some code for that if you need it)

You said you already had implemented a convolutional encoder and a
viterbi decoder in Verilog.
So it seems like combining all the parts is what has to be done.
Where exactly are you stuck.

Any inputs on the above would help me. I am stuck with this problem for
quite some time now.
Maybe it would help if you published what you got now somewhere, so
people can help by looking at your code.

Thank you Martin for your reply.

I wasent sure if rest of the 4 steps needed to be pushed to the FPGA ?
And
if the current USRP implementation on the FPGA leaves that much room for
expansion? This is where I was stuck, thinking if there was any other
alternate flow / solution ?

So, i guess the flow should be:

  1. Generate the bits on the host. (Then, Pass on those raw bits to the
    FPGA)

Everything after this on the FPGA.

  1. Mapping of the bits to symbols (This should’nt be difficult as this
    can
    be implemented using look up tables in Verilog) – Needs to be
    implemented
    in Verilog
  2. Convolving the symbols with root raised cosine filter (or any other
    wave)
    – Needs to be implemented in Verilog
  3. Sampling the resultant signal. – Needs to be implemented in Verilog

After this, it should be normal flow of the existing GNU Radio FPGA
implementation.

Please correct me if I am going wrong or please reply if I am right (It
is
easy to confuse no response with being right !)

Also, I would be more than happy to use your (Martin) code, as it will
save
my time reimplementing the same logic again.

I think that my code would be more meaningful to others, once I have
atleast
integrated the ‘transmitter’ portion.

Best Regards,
S. Mande.

P.S. Martin: I would be happy to use your code if you could send the
same to
[email protected] (with appropriate rights / notices if you wish) ! It
was
kind of you to suggest the same to me.

Thank you everyone for your inputs.

I knew that integrating the Viterbi algorithm on the receiver side is
going
to take a lot of work. And I had seen gr-trellis folder, which had the
Viterbi decoder implementation, which I was planning to use for the time
being.

I was thinking of atleast integrating the encoder on the transmitting
side
first.

I think that if I replicate the transmitter side steps (steps 2 to 5 in
my
earlier post) in Verilog on the FPGA, then the data packets getting
transmitted from transmitter side would be same as the current
implementation. Then, I can use the existing Achilleas’s Viterbi decoder
on
the receiver side to decode my data for the time being. ~ Any
comments ?
~

I am not sure, but dont see a reason why this should’nt work !

Does anyone has any comments on ~~* if 4 steps (in Verilog) in my
earlier post, would ‘replicate’ the existing transmitting steps or
anything
else needs to be added? ~~*

I plan to finish the transmitter side implementation as soon as possible
and
then moving ahead.

Best Regards,
S. Mande.

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