[srslte-users] Extracting eNodeB and UE OFDM Data

Andrew McClelland andrew.m.mcclelland at gmail.com
Wed Jul 26 13:47:50 UTC 2017


Thank you for your response.

> You actually don't need to guess what the supposed constellation point
> was, because if you can decode the signal (even if there were errors)
> you also know what the correct signal is supposed to look like.

What do you mean when you say "you know what the supposed constellation
point was if you can decode the signal"? My understanding is that the
decoded signal will likely never be perfectly ideal, (ie. the decoded point
will likely be slightly different than the ideal, transmitted point (just
due to decoding/transmission errors)). If this is the case, then how do you
ever have a 'baseline ideal constellation point(s)' to compare against the
respective 'RX'd constellation point(s)'.

Thank you


On Wed, Jul 26, 2017 at 7:51 AM, Andre Puschmann <
andre.puschmann at softwareradiosystems.com> wrote:

> Hi,
>
> On 25.07.2017 21:32, Andrew McClelland wrote:
> > Hi Andre,
> >
> > Apologies for responding away from the mailing list. For some reason, I
> > never received an email of your response.
>
> Please still use the list for those kind of questions. Thanks.
>
> >
> > Thank you for your help. When I'm measuring how far away the RX'd
> > constellation points are from ideal (say with QPSK), I use a switch case
> > and guess that the received point (say 0.7072 + 0.7071i) was actually
> > supposed to be 0.707106 + 0.707106i because that's the closest of the 4
> > ideal points to the received point. Is there a better way to do this
> > than using a switch case and guessing which ideal point the received
> > point was supposed to be, and then doing 'distance' on that? Is there an
> > easier way to verify what constellation point was actually supposed to
> > be received?
>
> You actually don't need to guess what the supposed constellation point
> was, because if you can decode the signal (even if there were errors)
> you also know what the correct signal is supposed to look like. How to
> achieve this programmatically is really a matter of taste.
>
> Hope that helps.
>
> Cheers
> Andre
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20170726/0407c792/attachment.html>


More information about the srslte-users mailing list