Correct samples for HDL Optimized QPSK Receiver with Captured Data
2 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
Jonathan Lowe
le 8 Mai 2018
Réponse apportée : Jeff Edward
le 18 Fév 2019
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?
0 commentaires
Réponse acceptée
John O'Sullivan
le 14 Mai 2018
Modifié(e) : John O'Sullivan
le 14 Mai 2018
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 commentaire
Plus de réponses (1)
Jeff Edward
le 18 Fév 2019
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.
0 commentaires
Voir également
Catégories
En savoir plus sur QPSK dans Help Center et File Exchange
Produits
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!