[srslte-users] Extracting eNodeB and UE OFDM Data
andre.puschmann at softwareradiosystems.com
Wed Jul 26 15:38:02 UTC 2017
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.
> 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:
> 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.
Software Radio Systems (SRS)
PGP/GnuPG key: 6C42AB31
fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31
More information about the srslte-users