Re: [Discuss-gnuradio] Σχετ: gr-lte updated t o GNU Radio 3.7 API

[Johannes Demel]

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

Hi Virgilios,

This sounds very close to my setup. I checked everything on my machine
and couldn't find a reason for that to happen.

Your error says that the QPSK soft demod block has 480 float items as
output which corresponds to 1920 bytes. This is exactly as it is
supposed to be. Thus something went wrong with the descrambler. I
suggest you check this hier block for problems. The problem is
somewhere in there. Maybe delete the generated files and regenerate
them. Also make sure that all the values fit.
One other thing about vector lengths. The QPSK soft demod block's
vector length corresponds to its input. So for every complex input
sample 2 float output samples are generated. Thus the vector length of
480 for the descrambler input.

I hope this brings you closer to a solution.

happy hacking
Johannes

On 13.02.2014 19:53, virgil passas wrote:
> Hi Johannes,
> 
> Sorry for not mentioned the versions. GNU Radio 3.7.2.1 gr-lte
> branch-master, latest commit
> 3ded865f40cc43224eca66a6692fa90655a25b62 Ubuntu 13.04 64-bit
> 
> 
> Virgilios
> 
> 
> 
> 
> Στις 8:24 μ.μ. Πέμπτη, 13 Φεβρουαρίου 2014, ο/η Johannes Demel 
> <address@hidden> έγραψε: Hi Virgilios,
> 
> This sounds like an interface mismatch between blocks. To answer
> your question accurately it would be very helpful to know which
> version of GNU Radio and which gr-lte version you use. Branch and
> day of last commit should be sufficient. Also tell us about your
> general setup. Which OS are you using?
> 
> happy hacking Johannes
> 
> On 13.02.2014 18:40, Passas Virgilios wrote:
>> Hello,
> 
>> I ‘m trying to generate the LTE_flowgraph_top_level.grc but the 
>> Decode PBCH block is missing due to an error in
>> decode_pbch_37.grc . The error is the following:
> 
>> Error 0: Connection ( Block - lte_qpsk_soft_demod_vcvf_0 - QPSK 
>> soft demod(lte_qpsk_soft_demod_vcvf) Source - out(0) Block - 
>> lte_pbch_descrambler_vfvf_0 - PBCH 
>> Descrambler(lte_pbch_descrambler_vfvf) Sink - in(0) ): Source IO 
>> size "1920" does not match sink IO size "7680”.
> 
>> Correlating the grc with the images at docs folder, I can see
>> that the input is a vector with length 240 and the input of PBCH 
>> Descrambler is a vector with length 480.
> 
> 
>> Also some tests failed due to this error:
> 
>> import lte_swig as lte ImportError: No module named lte_swig
> 
> 
>> How should I proceed?
> 
>> Virgilios
> 
>> On Jan 7, 2014, at 9:56, Mike Cornelius <address@hidden
> <mailto:address@hidden>
>> <mailto:address@hidden <mailto:address@hidden>>> wrote:
> 
>>> Hi Johannes,
>>> 
>>> I'm back at work after the new year break and have had a
>>> chance to try this again, and I think I have it working !! The
>>> problem was with my test waveform, I've captured a new test
>>> waveform and I can now sync to the DL signal and decode the
>>> MIB.
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> On 21 December 2013 04:26, Johannes Demel 
>>> <address@hidden <mailto:address@hidden>
> <mailto:address@hidden
> <mailto:address@hidden>>>
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> regarding the different parameters. 'tx_diversity' should
>>> always be left as it is. In case of a 1x1 MIMO configuration it
>>> will just have no effect. This parameter reflects the LTE
>>> standard with its two options 'tx_diversity' and
>>> 'spatial_multiplexing'. The latter isn't used for control
>>> channels. In order to specify a certain bandwidth, use the
>>> parameter 'N_rb_dl', which specifies the number of resource
>>> blocks used. This will also set the bandwidth as this is the
>>> unit given by the system to determine the bandwidth. e.g. have
>>> a look at the paper which is included in the project there is a
>>> table which shows the dependencies. 25 RBs --> 25*12 = 300
>>> subcarrier --> 15kHz * 300 + spacing = 5MHz. The FFT length can
>>> be chosen freely as long as it provides sufficient bins to
>>> match the current number of subcarriers. It will be used to
>>> determine the input sample rate. I suggest you stick with power
>>> of 2 values. Those are the only ones I tested and the numbers
>>> the system is designed for. One more thing, a FFT length 
>>> shorter than 256 results in fractional CP lengths, which
>>> should be avoided. LTE's CP use is already quite tricky and
>>> the introduction of fractional CP lengths will not ease the 
>>> situation. PBCH decoding is handled for one and two antenna 
>>> configurations, so you don't have to worry about configuring
>>> the flowgraph there. PCFICH decoding will receive a message on 
>>> runtime which sets the decoded antenna configuration.
>>> 
>>> Happy hacking Johannes
>>> 
>>> 
>>> On Fri, Dec 20, 2013 at 2:39 AM, Baier <address@hidden
> <mailto:address@hidden>
>>> <mailto:address@hidden <mailto:address@hidden>>> wrote:
>>> 
>>> Hi Johannes,
>>> 
>>> thank you very much for updating your gr-lte package. I could 
>>> compiled all .grc files succesfully. Now I would like to test 
>>> your receiver with a LTE signal saved to a file with the 
>>> following settings.( 5 MHz, RB 25, fft 512, occupied carriers 
>>> 300, no tx diversity). So I have started to change the
>>> parameters in your grc files. RB 25 instead 50 fftlen 512
>>> instead 2048(is it right?) occupied carriers 300 instead 600.
>>> So I have realized the files decode_pcfich_37.grc and
>>> decode_pbch_37 .grc are designed for tx_diversity with two
>>> antennas. How can I change it? Removing the blocks for the
>>> second antenna perhaps? Thank you very much. A. Baier
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _________________________________________________ 
>>> Discuss-gnuradio mailing list address@hidden
> <mailto:address@hidden>
>>> <mailto:address@hidden
>>> <mailto:address@hidden>> 
>>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>
>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Discuss-gnuradio mailing list address@hidden
>>> <mailto:address@hidden> 
>>> <mailto:address@hidden
>>> <mailto:address@hidden>> 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> 
>>> 
>>> _______________________________________________
>>> Discuss-gnuradio mailing list address@hidden
>>> <mailto:address@hidden> 
>>> <mailto:address@hidden
>>> <mailto:address@hidden>> 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> <mailto:address@hidden> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTAl1PAAoJEO7fmkDsqywM72IP/1mT7dmvVTQIshuF3/P0TbTU
mf61BavBFc4VSYO/3r+dPFnxV+48xDL+kS4ovtWfqRSax19U70YCEsE50+PDSCGE
W2PfR6b9B038uAm6R+TaGzA0hTiW43JJEaofmZf8kvEKL6YD7doBY2lsTbNS8MKw
vAWtu/S4x4Ql8wbojPPvkzow2bDQKMhDqlazoPjGdyfOkMC3KCrWcjydjQnR8i0T
W4gDCOmt5uGB+c9rnG/TAeqsZ6sGZjuDN2gr7wXlk9YiTjFK6Gc0yOsmDXO6U8AO
S+77s3ljvGyS6LxX/XEqwUOLWte0P9K89ak1Q6J3n7LcsBxL7nFaLxAZiW28nAT8
6+xL/FKQTmH7aUWvKU0jp1BQ7u0pNe/t53sE8OUwkKnwhewtuBxaMrb+dUBuiAgY
5HOwCQqedUVhTi9AvJzxuP4JHCt7GkxV7Z3Rcv2f51zo/Izh1ggq4Emm3DixmkeL
N08hxxxab37AlNem7r+jBvKaG2BK25O1btBNJetzviVHgFib8e0t0wv3qHcySMRP
K0wsDNy9WrYlebWNnk/v5VX8MS/BYfI16uU9w9Bqmp/r7KqyjUgO3Az37PvoDzc5
cokA6wJXQlsSZugXb5pKtTzgFPt+PV/Yw8pnk7VzYlQa0aV/Nmk+pBLzSXbz90dz
65fPjGwKR5MQxWpZXd9T
=4zt1
-----END PGP SIGNATURE-----