Correct samples for HDL Optimized QPSK Receiver with Captured Data

I am experimenting with the HDL Optimized QPSK Receiver design (commqpskrxhdl). I am replacing the captured data input (cdfq) with the IQ output of the TX part of the 'QPSK Transmitter and Receiver' example (commqpsktxrx). The design does not seem to compensate correctly, according to the 'after timing recovery' plot.

Here is the output of the original commqpskrxhdl design

And here is the output using the transmitted data from commqpsktxrx:

What is the reason for this inconsistency? Should I be expecting to see the same output?

Answer 1

[John O'Sullivan]

Hi Jonathan.

I had a look at this, and I think it is to do with a change in the fractional delay in the channel, which the receiver is not handling well. I was able to produce similar results using the commqpskrxhdl with the original captured data by placing a 1 sample delay in between the data source and the receiver. Given that the signal is upsampled by a factor of 4 at this point, this is a fractional delay in the channel from the perspective of the receiver.

If you then change this delay to 2 samples, the constellation in the receiver looks much better again. It appears that this is deficiency in the receiver, and it should be updated to better handle fractional delays.

Best Regards, John

[Jonathan Lowe]

Hi John,

Thanks for the reply. I have been very pleased with this example which handles fractional delays, and may be a useful reference to anyone who comes to this question.

Best regards, Jonathan

Answer 2

[Jeff Edward]

Is there a solution/fix for this issue? Because the sample time at the receiver ADC is arbitrary and there's a 50% probability that it will be an odd numbered delay.

I've had do do a workaround by having a parallel path with 1 sample delay, and then calculating the CRC for both paths and using the correct path depending on the CRC match. Obviously this approach is a brute force method that is computationally inefficient.

Is this a fundamental limitation of the zero crossing TED or an implementation issue or am I missing something here?

The link you gave seems to be incompatible with HDL. Any suggestions?

Thank you,

Jeff.