Re: puncturing pattern used

[U L]

The delay before the decoder might be throwing off the alignment at the output. Might consider setting to 0 or removing.

Generally If you use a test input vector like the block of 0xff and 0x00 I mentioned before, you should be able to look at the relative delay between input and output by putting the source output and decoder output into a time sink and measuring the delay between the source signal being non 0 and the decoder output being non 0.

Jared.

On Wed, Aug 23, 2023, 4:58 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I am getting constant BER through our the SNR ranges

On Tue, Aug 22, 2023, 7:15 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Ok, I will check. 

I was confused with this stack input (https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio)

I will try with 1011 and delay blocks and will update you.

On Tue, Aug 22, 2023, 7:12 PM U L <jareddpub@gmail.com> wrote:

The extended en/decoder does puncturing and zero stuffing internally so you don't need an extra puncturing block. Like I mentioned, the puncturing string can only have 0s and 1s so 13 is invalid. I'd try '1011' instead. 

Finally I think you still need some delay between your source and the ber block to align your input bytes with those from your output. The output does not start with the first decoded bit, but some number of 0s. In one of your prior flowgraphs you did have a delay. What happened to it?

Jared.

On Tue, Aug 22, 2023, 4:13 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Hi Jared,

     Completed the flowgraph based on the inputs from you like i have taken code rate :2/3 and pattern 1101(0xD)-puncture size-4 as reference from (https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio) bt still i am facing the issue.Always i am getting 10^-0.3 BER FROM 0 to 15 dB.