Correct samples for HDL Optimized QPSK Receiver with Captured Data

1 次查看(过去 30 天)
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?

采纳的回答

John O'Sullivan
John O'Sullivan 2018-5-14
编辑:John O'Sullivan 2018-5-14
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
  1 个评论
Jonathan Lowe
Jonathan Lowe 2018-5-14
编辑:Jonathan Lowe 2018-5-14
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

请先登录,再进行评论。

更多回答(1 个)

Jeff Edward
Jeff Edward 2019-2-18
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.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by