discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-lte Receiver Framework


From: Johannes Demel
Subject: Re: [Discuss-gnuradio] gr-lte Receiver Framework
Date: Thu, 26 Nov 2015 15:02:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ali,

I'm happy to hear it works now. I've seen this behavior before. But
I'm not sure what exactly causes it. Whenever I can I add more test in
order to track down the problem.
Of course I'm happy to merge any pull request that fixes this issue
and or adds more tests to the blocks.

Cheers
Johannes

On 26.11.2015 12:51, Muhammad Ahsan Ali wrote:
> Thank you johannes for the reply. Somehow I made the receiver work
> by changing the percent_load of my input file to 30 and I got a
> perfect decoding rate. But the problem is that the receiver is
> behaving randomly. For once the receiver worked with this input
> file and when ran again,it is again stuck at received message
> vector. I think there is an issue of synchronization some times it
> works sometimes it doesnt.What are your thoughts on it?
> 
> Regards Ahsan
> 
> On Thu, Nov 26, 2015 at 10:32 AM, Johannes Demel
> <address@hidden> wrote:
> 
> Hi Ali
> 
> 
>>>> 1) it always detects the correct cell_id? Yes
> That's a good sign.
> 
>>>> 
>>>> 2) the OFDM symbols with RS symbols should be recognizable.
>>>> Is this the case? After the decoding of the cell id the LTE
>>>> estimator generates a RS map with # tags followed by ones and
>>>> minus ones. After this I get a message from
>>>> pcfich_lte_descrambler and lte_channel_estimator that PILOT
>>>> MAP RESETTED and received message vector and the decoding
>>>> stops.
> PCFICH does only work for one specific bandwidth because it
> calculates PCFICH positions inaccurately. I suggest you deactivate
> it for now because it also needs information from MIB to work
> correctly.
> 
> A Qt time sink should be able to show you all the tags. If you
> trigger with tags it should show you a pattern with some energy on
> symbols with RS symbols and no energy on most others. That's what I
> would expect. Tags should mark the start of a slot.
> 
>>>> 
>>>> I am testing the other flowgraphs apparently they dont have
>>>> this issue. How long does the flowgraph takes to give the
>>>> final MIB output?
> Once everything is set correctly, it should only take a moment. I
> can just assume that the decoder gets confused by the fact that no
> payload is present and thus most OFDM symbols are zero. This is
> really hard to investigate from a distance. I'm confident that the
> PBCH, BCH, MIB chain works. Also, it has quite extensive tests. The
> synchronization part and partially OFDM demod are more fragile.
> 
>>>> 
>>>> Another quesion would be do you see an error in compilation
>>>> of the program or with my test file? I also have a USRP N210
>>>> with me can I record an LTE signal with it without a
>>>> daughterboard?
> A daughterboard will be necessary.
> 
> - From the given output I can't see any issues.
> 
> Cheers Johannes
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWVxDhAAoJEO7fmkDsqywMCRkP/iOKblcS7dfRjk8mRn9qM6ir
8ktulPviu976uaGN9V+i3jvGO2vUjvkFeyuCnoGDg4Mj+DE0C12mTQggYwU9pCCW
LSGsBT5G8rV5ZzZpZfgIgiME2lP6OK4P0GzsWs9ruDQAb/yD4MUfHqH3Af7PN+mP
q6jan7axvjTgHA+VdC6s3Ge1vllpp+ozIBRWGkiVWVsbWEtdG9aw4Ioa3yVfYVh2
XU/rA5Wubkn9LJnILSPn0b+J3DHYwdzkvYL58Tf69KzvWc6MFUrFmaJoJQmtoacf
PH79cHb/GaclbZCpARuqIqEmbrLelQbY9vQIoXyvOHloZgFnsznRzY2oQ/ZakGSV
IjOyDbjaDCqjhv4xQKuxpNzJybYPhFWAQ4kqn19RSK/hl7WZAvaa4xq5p3jhGdlk
oQGuesi8hZr373gEaX4gCwWMei7Ams7T/1hPy8zgjCnyVJWIRUBzoo9wPzBuDL9j
Pfwl6i2adkOp6SwJAbtpMfFNoIP4VUcITfokR+4fqJCT7sROXh4U91U2rnZPYzJB
YJDvyKtIdixip4lYTxgwvh8qhbPCGB/IInc87ZuxldB7n2Ic3jIVJV5XV+v2ZUfQ
YB/gaF+PZs8YJ/tlPUDAic5cCNCBcYhRNz3nas+cewMRcoiBM/yvaHOM7wexNt0y
pq48NV1/qRWbYeLZdQ50
=wW1M
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]