[srslte-users] Extracting eNodeB and UE OFDM Data

[Andre Puschmann]

On 26.07.2017 15:47, Andrew McClelland wrote:
> 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)'.

You could just encode the signal again.

Cheers
Andre

> 
> Thank you
> 
> 
> On Wed, Jul 26, 2017 at 7:51 AM, Andre Puschmann
> <andre.puschmann at softwareradiosystems.com
> <mailto:andre.puschmann at softwareradiosystems.com>> wrote:
> 
>     Hi,
> 
>     On 25.07.2017 21 <tel:25.07.2017%2021>: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
> 
> 


-- 
Andre Puschmann

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

PGP/GnuPG key: 6C42AB31
fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31