Forum: GNU Radio gr-lte updated to GNU Radio 3.7 API

5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-15 00:35
(Received via mailing list)
Hello GNU Radio enthusiasts,

some time after the GNU Radio 3.7 release I started to move the code for
'gr-lte' to the new API. Besides moving it to the new API, I wanted to
clean up code and rework a lot of tests. Thus, the whole transition took
a lot of time and work.
Now, all current blocks are moved to the GNU Radio 3.7 API with lots of
enhancements. e.g. I tried to remove all hierarchical python blocks and
created them as GRC hier blocks instead. Or runtime status events, like
cell_id extraction, are all propagated through message ports now.
Also, there is a PyBOMBS recipe now to ease the installation process.

I hope 'gr-lte' can be useful for others.

Source code is available at https://github.com/kit-cel/gr-lte

Happy hacking
Johannes
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2013-12-16 08:33
(Received via mailing list)
Hi Johannes,

I gave this a try today so I thought I'd pass on my results:-

Firstly, I found that I could not 'import lte' as sync_cc.py could not
import 'window' from gnuradio.
I 'fixed' that by changing sync_cc.py as follows:-

self.pfft = fft.fft_vcc(fftl, True, window.rectangular(fftl), False, 1)
to
self.pfft = fft.fft_vcc(fftl, True, fft.window.rectangular(fftl), False,
1)


Now when I run it with my reference waveform I see:-

--------------------------------------------------------------------------------

Press Enter to quit:
pss_calculator_vcm NEW half_frame_start = -13166 N_id_2 = 0 corr_val =
27512.798828


pss_calculator_vcm NEW half_frame_start = -8784 N_id_2 = 2 corr_val =
30075.925781


pss_calculator_vcm NEW half_frame_start = 13187 N_id_2 = 0 corr_val =
33294.562500

sync_frequency_c ASYNC! new offset = 6611 old offset = 0 samp_num = 5910

pss_calculator_vcm NEW half_frame_start = 21971 N_id_2 = 1 corr_val =
35808.539062

sync_frequency_c ASYNC! new offset = 13187 old offset = 6611 samp_num =
5899

pss_calculator_vcm NEW half_frame_start = 43907 N_id_2 = 0 corr_val =
36685.992188

sync_frequency_c ASYNC! new offset = 15 old offset = 13187 samp_num =
15027

pss_calculator_vcm is locked! half_frame_start = 61455 N_id_2 = 0
corr_val
= 36685.992188

sync_frequency_c ASYNC! new offset = 16 old offset = 15 samp_num = 12763

sss_calculator_vcm locked to frame_start = 215056 abs_pos = 1751056
cell_id
= 132

sss_calculator_vcm publish_frame_start 215056
sss_calculator_vcm publish_cell_id 132
<bound method block_gateway_sptr.block__name of <block_gateway>>
received
cell_id = 132
 <bound method block_gateway_sptr.block__name of <block_gateway>>
cell_id
=  cell_id =  132 132  generating RS map!
received cell_id = 132
  generating RS map!

remove_cp_cvc
frame_start = 1751056
mod start   = 215056

Segmentation fault

--------------------------------------------------------------------------------

I'm not certain whether CID 132 is correct for this waveform so it's
hard
to say whether it's working up to the seg fault or not.

Regards,

Mike
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-18 12:52
(Received via mailing list)
Hi,

after opening and generating the hier blocks still the top_level.grc has
missing blocks, at least LTE estimator outputs and unpack MIB inputs are
unconnected, leaving a large white area in between. How should this
flowgraph look like, is there a screenshot available somewhere?

Just wanted to put this all together in my lunch break, but seems too
big for such a short break anyway :)

Ralph.
332b0ca9b755cd32b745eaf01c0c72e0?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-18 18:48
(Received via mailing list)
Hi Ralph,

unfortunately there are no screenshots yet. I guess it is a good idea to
add some. After the estimator, there should be 2 blocks: Decode PBCH and
Decode PCFICH. They take the same stream. and work in parallel. Then
after
Decode PBCH there is supposed to be a 'Decode BCH' block. These blocks
may
need some time to generate because they consist of hier blocks. That's
kind
of the tribute that has to be paid for a clean flowgraph.
If you opened a flowgraph with missing blocks, as far as I know, to make
the missing blocks appear you have to close and reopen at least this
particular flowgraph.

Happy hacking
Johannes


On Wed, Dec 18, 2013 at 3:49 AM, Ralph A. Schmid, dk5ras
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 08:28
(Received via mailing list)
Hi everybody,

I added screenshots for all the hierarchical flowgraphs and the top
flowgraph to the docs directory. I hope this helps to build the whole
LTE flowgraph in GRC.
Although, I realized that would be very helpful if the hierarchical
flowgraphs would be compiled with grcc during make and then installed.
Preferably added to a CMakeLists file. I will look into this.

Happy hacking
Johannes
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2013-12-19 08:38
(Received via mailing list)
Hi Ralph,

I had the same problem at first myself, there is no need to reconnect
anything in the top_level.grc block so long as all the hier blocks have
actually been compiled.
In my case the biggest problem was the LTE_estimator_hier block would
not
compile because the 'import lte' failed (see earlier messages in this
thread for details).


Mike
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2013-12-19 08:55
(Received via mailing list)
Hi Johannes,

With regard to my earlier message regarding the crash I'm seeing, I note
that a few tests fail when I run make test, is that to be expected?
Also do you think it would be possible to publish the reference waveform
that you are using ?
That way I could check to see if the crash occurs with your known 'good'
waveform too.

Mike
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2013-12-19 09:01
(Received via mailing list)
Hi Johannes,

Further to my last email I just noticed that the tests that are failing
are
failing because test vectors are not available eg
'/home/johannes/tests/descramble.dat'.

Mike
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 09:01
(Received via mailing list)
Hi Mike,

the reference I use is a rather big file > 1gb. It is hard to share such
a file publicly anywhere. I put a signal generator on the list of needed
features.

All tests are supposed to pass. Which tests fail on your system? Can you
run them with -V and mail the error messages. That could help.

Happy hacking
Johannes
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-19 09:26
(Received via mailing list)
I'd be happy putting it onto my ftp server, if it could be useful to the
public. Only a 10 Mbps uplink, but better than nothing :)

Ralph.

>
> the reference I use is a rather big file > 1gb. It is hard to share such a
file
> publicly anywhere. I put a signal generator on the list of needed
features.
>
> All tests are supposed to pass. Which tests fail on your system? Can you
run
> > Also do you think it would be possible to publish the reference
> >     Hi Ralph,
> >
> >
> >     On 19 December 2013 18:27, Johannes Demel <ufcsy@student.kit.edu
> >     <mailto:ufcsy@student.kit.edu>> wrote:
> >
> >         Hi everybody,
> >
> >         I added screenshots for all the hierarchical flowgraphs and the
top
> >         flowgraph to the docs directory. I hope this helps to build the
> >         whole
> >         LTE flowgraph in GRC.
> >         Although, I realized that would be very helpful if the
hierarchical
> >         > unfortunately there are no screenshots yet. I guess it is a
> >         good idea to
> >         > add some. After the estimator, there should be 2 blocks:
> >         Decode PBCH and
> >         > Decode PCFICH. They take the same stream. and work in
> >         parallel. Then
> >         > after Decode PBCH there is supposed to be a 'Decode BCH'
> >         block. These
> >         > blocks may need some time to generate because they consist of
hier
> >         > blocks. That's kind of the tribute that has to be paid for a
clean
Bf9f933ba2147185954d9766d9f7c72f?d=identicon&s=25 Philip Balister (Guest)
on 2013-12-19 15:49
(Received via mailing list)
On 12/19/2013 03:24 AM, Ralph A. Schmid, dk5ras wrote:
> I'd be happy putting it onto my ftp server, if it could be useful to the
> public. Only a 10 Mbps uplink, but better than nothing :)

Any chance we could setup a torrent tracker for large data sets?

Philip
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 17:07
(Received via mailing list)
That would be cool anyway.
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 17:13
(Received via mailing list)
Hi Mike,

just saw this mail. Basically this means that you're using an old
version. Newer versions don't use these files any more. I recommend
updating your gr-lte version. It runs on GR 3.7 now, so you don't have
to worry about an old version there and I put in all the bugfixes into
the latest master branch.
Besides that, which version do you use exactly?

Happy hacking
Johannes
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-19 17:51
(Received via mailing list)
Hi,



just wanted to let you know that now, after pulling and building latest
gr and gr-lte, it worked. Don't know if from pulling, or if from chosing
F6 instead of F5 within grc.



Should it work with life reception, or only from a file? Maybe I'll have
a closer look later, now on board the train I do not want to play with a
blinkenlight piece of naked SDR electronics J



Ralph.



From: Johannes Demel [mailto:johannes.demel@ettus.com]
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: ufcsy@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API



Hi Ralph,

unfortunately there are no screenshots yet. I guess it is a good idea to
add some. After the estimator, there should be 2 blocks: Decode PBCH and
Decode PCFICH. They take the same stream. and work in parallel. Then
after Decode PBCH there is supposed to be a 'Decode BCH' block. These
blocks may need some time to generate because they consist of hier
blocks. That's kind of the tribute that has to be paid for a clean
flowgraph.

If you opened a flowgraph with missing blocks, as far as I know, to make
the missing blocks appear you have to close and reopen at least this
particular flowgraph.

Happy hacking

Johannes



On Wed, Dec 18, 2013 at 3:49 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx> wrote:

Hi,

after opening and generating the hier blocks still the top_level.grc has
missing blocks, at least LTE estimator outputs and unpack MIB inputs are
unconnected, leaving a large white area in between. How should this
flowgraph look like, is there a screenshot available somewhere?

Just wanted to put this all together in my lunch break, but seems too
big for such a short break anyway :)

Ralph.
332b0ca9b755cd32b745eaf01c0c72e0?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 18:56
(Received via mailing list)
Technically it could work with life data. Unfortunately it creates a too
heavy load to be processed in realtime, unless you have the computing
power
or reduce the bandwidth/fft length to a small value. But then you are
probably not able to decode more than the PBCH.


On Thu, Dec 19, 2013 at 8:49 AM, Ralph A. Schmid, dk5ras
Ddb503356cb90b0c95e52700445ef749?d=identicon&s=25 Tom Tsou (Guest)
on 2013-12-19 19:35
(Received via mailing list)
On Thu, Dec 19, 2013 at 12:55 PM, Johannes Demel
<johannes.demel@ettus.com> wrote:
> Technically it could work with life data. Unfortunately it creates a too
> heavy load to be processed in realtime, unless you have the computing power
> or reduce the bandwidth/fft length to a small value. But then you are
> probably not able to decode more than the PBCH.

It's certainly possible, and advisable, to downsample from a full LTE
capturing bandwidth to a more manageable rate of 1.92 Msps or 960
ksps. The latter can be handled very efficiently for initial
acquisition, though the cyclic prefix length becomes fractional, which
is annoying to handle. In either case, the complexity of the
downsampling is mainly dictated by the output rate of the resampler.

Done efficiently, even a small processor can handle PBCH decoding from
a relatively high capture sample rate. Though, this would require a
rather substantial change from the gr-lte synchronization approach and
overall structure.

  -TT
332b0ca9b755cd32b745eaf01c0c72e0?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-19 21:08
(Received via mailing list)
Currently synchronization doesn't support fractional CPs. Besides this,
reducing the sample rate helps a lot to make it run faster. Only thing
to
keep in mind though, having a different number of blocks than used by
the
base station will only allow you to decode PBCH. But for a start. That's
not much of a problem.
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-19 21:18
(Received via mailing list)
OK, I understand. So I need some file J My Intel i5 tablet PC may be too
slow for life decode.



Ralph.



From: Johannes Demel [mailto:johannes.demel@ettus.com]
Sent: Thursday, 19 December, 2013 18:55
To: Ralph A. Schmid, dk5ras
Cc: ufcsy@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API



Technically it could work with life data. Unfortunately it creates a too
heavy load to be processed in realtime, unless you have the computing
power or reduce the bandwidth/fft length to a small value. But then you
are probably not able to decode more than the PBCH.



On Thu, Dec 19, 2013 at 8:49 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx> wrote:

Hi,



just wanted to let you know that now, after pulling and building latest
gr and gr-lte, it worked. Don't know if from pulling, or if from chosing
F6 instead of F5 within grc.



Should it work with life reception, or only from a file? Maybe I'll have
a closer look later, now on board the train I do not want to play with a
blinkenlight piece of naked SDR electronics J



Ralph.



From: Johannes Demel [mailto:johannes.demel@ettus.com]
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: ufcsy@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API



Hi Ralph,

unfortunately there are no screenshots yet. I guess it is a good idea to
add some. After the estimator, there should be 2 blocks: Decode PBCH and
Decode PCFICH. They take the same stream. and work in parallel. Then
after Decode PBCH there is supposed to be a 'Decode BCH' block. These
blocks may need some time to generate because they consist of hier
blocks. That's kind of the tribute that has to be paid for a clean
flowgraph.

If you opened a flowgraph with missing blocks, as far as I know, to make
the missing blocks appear you have to close and reopen at least this
particular flowgraph.

Happy hacking

Johannes



On Wed, Dec 18, 2013 at 3:49 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx> wrote:

Hi,

after opening and generating the hier blocks still the top_level.grc has
missing blocks, at least LTE estimator outputs and unpack MIB inputs are
unconnected, leaving a large white area in between. How should this
flowgraph look like, is there a screenshot available somewhere?

Just wanted to put this all together in my lunch break, but seems too
big for such a short break anyway :)

Ralph.
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-12-19 21:35
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As much as I like the tracker solution, it leads to orphaned torrents
with time passing... There won't be a hundred people willing to seed
this for years.

My suggestion: Does anyone remember sourceforge? It used to be
popular. But then again, many of these young folks don't even remember
slashdot...

ah nevermind:
http://sourceforge.net/apps/trac/sourceforge/ticket/18131
5GB should be fine, and you get free CDN.

Greetings,
Marcus

On 19.12.2013 15:47, Philip Balister wrote:
>>
>>> the reference I use is a rather big file > 1gb. It is hard to
>>>
>>>> 'good' waveform too.
>>>> reconnect anything in the top_level.grc block so long as all
>>>> <ufcsy@student.kit.edu <mailto:ufcsy@student.kit.edu>>
>> hierarchical
>>>>> a
>>>>> blocks. That's kind of the tribute that has to be paid for
>>>>>
>>>> unpack MIB
>>>>> Ralph.
>>>>
>>>>
<mailto:schmid.xxx@gnu.org>
>>>> move the
>>>>>> and created them as GRC hier blocks instead. Or runtime
>>>> https://github.com/kit-cel/gr-lte
>>>>>
>>>> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> _______________________________________________ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSs1gKAAoJEAFxB7BbsDrLWewH/26g/9g98nR7PptwpNYP549k
xNEDtDk4kAGvuYVh+p2NDW/Q2Je9eU3SZCEmZbawDgNuDaLYHaFGvJ4JQVEOGsDl
lj9cxCvcvH0AtYOyepJIt1q2r6Po75mYZzS4ecwP2/O5nhRo1PtOFuWDgYLlt9oB
sPLghCep+UV5c2q6LkUBTnQt3cGGGLcPzJ9maoPi5UijpmMlXYxZsRxxz4W9xgiw
JcHmrFaebmH3i6XarhWWY3aVo6/HY2ySMztEJq4WGBohWXZZB0EgmsBjsJjQAWrJ
2792LANuSiOhioHmxw4MQVz1cXJp492XFdMf8BTN1ELgTIS7HVJn/e0aE+GiNEo=
=i0kj
-----END PGP SIGNATURE-----
D3e3c5e41e9aed486856802be823e181?d=identicon&s=25 Johnathan Corgan (Guest)
on 2013-12-19 22:08
(Received via mailing list)
Attachment: johnathan.vcf (335 Bytes)
Attachment: signature.asc (229 Bytes)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-12-19 22:10
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That'd actually be rather awesome :)

On 19.12.2013 22:07, Johnathan Corgan wrote:
>
> This is how we host the GNU Radio Live DVD image on gnuradio.org.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSs2BUAAoJEAFxB7BbsDrLXvgH/RG3lgU9yGpa1LauvpzrzE2A
rGbDfzleinWVtwnfKaTX+2A3nNOMnANyqIxnxZsllFiwJ0V7seQhheyFwBEYxTZu
XUmxhw9oHyQFuOhxWolovLNUGEGMu2fjnCsR+g2VDKDRbkHNQA+zccvMA/DSDhZR
QMk8eSrcnm18cRA+J4+2ORSCnBWPbmoBohwMvG14V9WjF/gLjDSNPdrK4Q4DHXmx
0aqZphE0vudeBFiHhHomNGv3YgSwfaqkV7ShIoCC/MID39OCGzfYLnH50XKGpDjD
aPIWTq4iswVeaPFcbrfdIMjdF4AzNB+AEGwLnmt4sxn2Ts8vjaiDDHBZpGO6k1E=
=9bBr
-----END PGP SIGNATURE-----
Ddb503356cb90b0c95e52700445ef749?d=identicon&s=25 Tom Tsou (Guest)
on 2013-12-19 22:22
(Received via mailing list)
On Thu, Dec 19, 2013 at 3:07 PM, Johannes Demel
<johannes.demel@ettus.com> wrote:
> Currently synchronization doesn't support fractional CPs. Besides this,
> reducing the sample rate helps a lot to make it run faster. Only thing to
> keep in mind though, having a different number of blocks than used by the
> base station will only allow you to decode PBCH. But for a start. That's not
> much of a problem.

The fractional CP is a pain to deal with. Performing acquisition at
1.92 Msps, though, is quite reasonable and is appropriate for 1.4 MHz
LTE channels anyways.

UE side LTE decoding is inherently a multirate process. PBCH decoding
should ideally be performed at the reduced sample rate because any
data outside of the inner 6 RBs provides no useful information to the
search and decoding process. The same concept extends to any channel
configurations below the full LTE 30.72 Msps rate. But, since the
channel bandwidth is unknown until PCBH acquisition, the receiver
should, ideally, support all rates and dynamically switch between them
as needed.

Practically speaking, the issue with real-time operation on USRP type
devices is that we can't switch device sample rates without breaking
symbol timing or slot alignment. That means running a fixed device
rate and multiple resampling chains to cover the desired channel
bandwidths.

But yes, sticking with one sample rate avoids all of the above, and is
a much simpler way to start. Perhaps multirate handling is something
to consider for future development. If there were only more hours in a
day...

  -TT
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2013-12-20 02:19
(Received via mailing list)
Hi Johannes and all,

I just pulled a new copy and make test still fails for me with various
missing .dat files.
Can anyone else confirm that make test is working ok for them with the
latest version?

Mike
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-20 08:50
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

it would be really helpful if you posted the error message. If it is
more than a few lines, pastebin'ing would be good. Also can you tell
on which branch you're on? I'm worried about missing '.dat' because
they shouldn't be there. I thought I removed all references to them a
while ago.

Happy hacking
Johannes

On 19.12.2013 17:14, Mike Cornelius wrote:
> On 20 December 2013 03:11, Johannes Demel <ufcsy@student.kit.edu
>
>> Mike
>> note that a few tests fail when I run make test, is that to be
>> <mailto:dr@drelectro.com <mailto:dr@drelectro.com>>> wrote:
>> messages in this thread for details).
>> Hi everybody,
> into this.
>> Decode PBCH and
>>> flowgraph. If you opened a flowgraph with missing blocks, as
>>> On Wed, Dec 18, 2013 at 3:49 AM, Ralph A. Schmid, dk5ras
>>> has missing blocks, at least LTE estimator
>>> Just wanted to put this all together in my lunch
>>> <mailto:schmid.xxx@gnu.org
> <mailto:schmid.xxx@gnu.org>
>>>> Hello GNU Radio enthusiasts,
>>>> Now, all current blocks are moved to the GNU Radio
>> installation process.
> <mailto:Discuss-gnuradio@gnu.org>
>>> _______________________________________________
>>>
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSs/aHAAoJEO7fmkDsqywM6qQP/1RdGsoM8NQZ2BGAsQZ5Ic9z
wd0x5BFKy9fezWMN281ge3A/sV7c0lAKxaw7pjKPkkxANqew8LPrM5DreUTd+S8C
jYccRdsZAdGm0l0Ytf9uaIEGqD3eYSqxbs6lwrezBix+5OEiYHToh3k7RaPaxzga
aLMWDpkK+x7pNmoS3hEdTi5i7LlI+eGCQIJOC6S2vpaj9pgOMm9ZTj8/984+t4Ml
WQW1QP+drrB4uEO8wGhmtR97CMCayj6n5S3e/TnTqQzbL7YxfLTNq4Tgvc1qGrkr
HLhpK71qeiUoR6eJ89zjD8SSPVfBDky+9Lvjn0pOCYBW1rxYCTpZWZiGvO6HZ7tT
4otMvBfWp/wBgfbCf+G8ESZRRC8WW6OldpDSrVfKzaO/EUFBH5wqD3pf/U+lTdXR
4+dTuBdFEzY8DQHDoBGaZ07++RIzSzcca5zYiH3x1GzbLeaLJxfsLyz8FJw3xKQM
6WeypOGc46dqKq7mJhQTk0XUw/0QVkiw9nick7uzoAQhwPCNL7PVTNeL5aDtqO2j
FsEd2Nq0lhcBr3QWIkrmJQEP1uawb1hNL9gHDXGxKn8O3jsh+vg7/6X0dWkUKTiA
RX5TjyZLv+tUt9EGuuf/TV0nN5vDtP4lmpvCRLRgTGNYTAZoaGC+jnbHwJ5PGG6I
6xmZbNnGvUHxR6XW5PWU
=9517
-----END PGP SIGNATURE-----
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-20 10:27
(Received via mailing list)
Do you have the possibility to upload the file to my server? It is on a
VDSL50 line (50Mbps in, 10 Mbps out), so upload from the university
(DFN)
network should be fast enough. Then I could post a link for direct
download
(well, only 10 Mbps) and provide the file via bittorrent...

Ralph.



> > On 12/19/2013 03:24 AM, Ralph A. Schmid, dk5ras wrote:
> >>> -----Original Message-----
> >>>
> >>>
> >>> Happy hacking
> >>> Johannes
> >>>
> >>> On 18.12.2013 23:54, Mike Cornelius wrote:
> >>>> Hi Johannes,
> >>>>
> >>>> With regard to my earlier message regarding the crash I'm seeing, I
> >>>> note that a few tests fail when I run make test, is that to be
expected?
> >>>> Also do you think it would be possible to publish the reference
> >>>> waveform that you are using ?
> >>>> That way I could check to see if the crash occurs with your known
'good'
> >>>>     I had the same problem at first myself, there is no need to
> >>>>     On 19 December 2013 18:27, Johannes Demel
> <ufcsy@student.kit.edu
> >>>>     <mailto:ufcsy@student.kit.edu>> wrote:
> >>>>
> >>>>         Hi everybody,
> >>>>
> >>>>         I added screenshots for all the hierarchical flowgraphs and
> >>>> the
> >> top
> >>>>         flowgraph to the docs directory. I hope this helps to build
the
> >>>>
> >>>>         block. These
> >>>>         least this
> >>>>         >     Hi,
> >>>>         >
> >>>>         >     Just wanted to put this all together in my lunch break,
> >>>>         but seems
> >>>>         >     too big for such a short break anyway :)
> >>>>         >
> >>>>         >     Ralph.
> >>>>         >
> >>>>         >
> >>>>         >     > -----Original Message-----
> >>>>         >     > From:
discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org
> >>>>         <mailto:schmid.xxx@gnu.org>
> >>>>         >     <mailto:schmid.xxx@gnu.org <mailto:schmid.xxx@gnu.org>>
> >>>>         [mailto:discuss-gnuradio-bounces+ralph
> >>>>         <mailto:discuss-gnuradio-bounces%2Bralph>
> >>>>         >     <mailto:discuss-gnuradio-bounces%2Bralph
> >>>>         <mailto:discuss-gnuradio-
> bounces%252Bralph>>=schmid.xxx@gnu.org
> >>>>         <mailto:schmid.xxx@gnu.org>
> >>>>         >     <mailto:schmid.xxx@gnu.org
<mailto:schmid.xxx@gnu.org>>]
> >>>>         On Behalf Of
> >>>>         >     > Johannes Demel
> >>>>         >     > Sent: Sunday, 15 December, 2013 00:34
> >>>>         >     > To: discuss-gnuradio
> >>>>         >     > Subject: [Discuss-gnuradio] gr-lte updated to GNU
Radio
> >>>>         3.7 API
> >>>>         >     >
> >>>>         >     > Hello GNU Radio enthusiasts,
> >>>>         >     >
> >>>>         >     > some time after the GNU Radio 3.7 release I started
to
> >>>>         move the
> >>>>         >     code for 'gr-lte' to the new API. Besides moving it to
the
> >>>>         new API, I
> >>>>         >     > wanted to clean up code and rework a lot of tests.
Thus,
> >>>>         the whole
> >>>>         >     transition took a lot of time and work.
> >>>>         >     > Now, all current blocks are moved to the GNU Radio
3.7
> >>>>         API with
> >>>>         >     lots of enhancements. e.g. I tried to remove all
> >>>>         hierarchical python
> >>>>         >     blocks
> >>>>         >     > and created them as GRC hier blocks instead. Or
runtime
> >>>>         >     > Source code is available at
> >>> gnuradio@gnu.org>>
> >>>>         >     >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>         >
> >>>>         >
> >>>>         >     _______________________________________________
> >>>>         >     Discuss-gnuradio mailing list
> >>>>         >     Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
17a73c1b0a90093d14a6c59db3c613f7?d=identicon&s=25 Baier (Guest)
on 2013-12-20 11:40
(Received via mailing list)
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
332b0ca9b755cd32b745eaf01c0c72e0?d=identicon&s=25 Johannes Demel (Guest)
on 2013-12-20 18:28
(Received via mailing list)
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
7ac6b347cf54e479df06fff52a68ed98?d=identicon&s=25 Mike Cornelius (Guest)
on 2014-01-07 08:57
(Received via mailing list)
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
1459b5a05aaff04c16d5612a78d4ef34?d=identicon&s=25 Passas Virgilios (Guest)
on 2014-02-13 19:03
(Received via mailing list)
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
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2014-02-13 19:24
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
> size "1920" does not match sink IO size "7680.
>
>> to try this again, and I think I have it working !! The problem
>>
>> the bandwidth. e.g. have a look at the paper which is included in
>> situation. PBCH decoding is handled for one and two antenna
>> Hi Johannes,
>> the blocks for the second antenna perhaps? Thank you very much.
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>> _______________________________________________ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> <mailto:Discuss-gnuradio@gnu.org>
>> 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/

iQIcBAEBAgAGBQJS/Q2rAAoJEO7fmkDsqywMBssP/2JxUEthkQMZsiVSQMGVGkbg
CsdjZCzZjFbSjJrmqCPimiJSQqEqxvCjjA9EgPYT6Vx+NDB/k5xcJ3WWIm41S2t+
lzcHvkNNCJjrMZ6sqswKKGMMbGEuOR9WxF/GBG3//qeW0/OJrIEiv4nz4G6AbRsx
S/Z7rcLkc0h78r8J3W6yTQv3qyWoHldlACEiS88lfK2K1YzIvOldXsH/bW/Odgtr
dsgPLVh6arlgeUIkR9zn/P7FPLkgYlgOsTyxCiTh37uFzlMYHH2Dfl5i+9EdlAdb
MP/trQyBnLDJMyZ05qMFH57FYeGrZ5ZAj3LHKFS35nqNDitU8zRMYmTcokhNQWJb
9RzD+TFbkaN4Mlt0qLUdlA29NK1zUM6G6YuH2SesCDcneUwCUmMfiznH4NPBJmgg
E39pj9xP4waHppxuQWmUhCdopW/4M+Vk4CT9r0L1HUSLWQaeUXfwbbbC1CorZG4+
0LVLKWhdjSXnce47+JCfuHZ702TgT2OAjCU9/NzRMAiQTgdEaCWCQX6hgYEbGCZ4
vY3vevrSJP/HQ7NM77rMh3o8eSKrcd+1xOXqtpk4J2jpDW1dz/n48XirEb64yYJ8
+4rpv43MUw35NIw+xEaFBQ31yHTdbgDIXPaGgZ2u7zgQKmD81ZTiU6jrSs294idq
r/ajO6PWQlnKZ+yy5goV
=gx89
-----END PGP SIGNATURE-----
1459b5a05aaff04c16d5612a78d4ef34?d=identicon&s=25 virgil passas (Guest)
on 2014-02-13 19:55
(Received via mailing list)
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
<ufcsy@student.kit.edu> έγραψε:

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

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:
> size "1920" does not match sink IO size "7680”.
>
>> to try this again, and I think I have it working !! The problem
>>
>> the bandwidth. e.g. have a look at the paper which is included in
>> situation. PBCH decoding is handled for one and two antenna
>> Hi Johannes,
>> the blocks for the second antenna perhaps? Thank you very much.
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>> _______________________________________________ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> <mailto:Discuss-gnuradio@gnu.org>
>> 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/

iQIcBAEBAgAGBQJS/Q2rAAoJEO7fmkDsqywMBssP/2JxUEthkQMZsiVSQMGVGkbg
CsdjZCzZjFbSjJrmqCPimiJSQqEqxvCjjA9EgPYT6Vx+NDB/k5xcJ3WWIm41S2t+
lzcHvkNNCJjrMZ6sqswKKGMMbGEuOR9WxF/GBG3//qeW0/OJrIEiv4nz4G6AbRsx
S/Z7rcLkc0h78r8J3W6yTQv3qyWoHldlACEiS88lfK2K1YzIvOldXsH/bW/Odgtr
dsgPLVh6arlgeUIkR9zn/P7FPLkgYlgOsTyxCiTh37uFzlMYHH2Dfl5i+9EdlAdb
MP/trQyBnLDJMyZ05qMFH57FYeGrZ5ZAj3LHKFS35nqNDitU8zRMYmTcokhNQWJb
9RzD+TFbkaN4Mlt0qLUdlA29NK1zUM6G6YuH2SesCDcneUwCUmMfiznH4NPBJmgg
E39pj9xP4waHppxuQWmUhCdopW/4M+Vk4CT9r0L1HUSLWQaeUXfwbbbC1CorZG4+
0LVLKWhdjSXnce47+JCfuHZ702TgT2OAjCU9/NzRMAiQTgdEaCWCQX6hgYEbGCZ4
vY3vevrSJP/HQ7NM77rMh3o8eSKrcd+1xOXqtpk4J2jpDW1dz/n48XirEb64yYJ8
+4rpv43MUw35NIw+xEaFBQ31yHTdbgDIXPaGgZ2u7zgQKmD81ZTiU6jrSs294idq
r/ajO6PWQlnKZ+yy5goV
=gx89
-----END PGP SIGNATURE-----
5e623cc1b53ddefb15c9bad4245986a1?d=identicon&s=25 Johannes Demel (Guest)
on 2014-02-17 20:06
(Received via mailing list)
-----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:
>
> happy hacking Johannes
>> lte_pbch_descrambler_vfvf_0 - PBCH
>> import lte_swig as lte ImportError: No module named lte_swig
>>> Hi Johannes,
>>>
>>> will just have no effect. This parameter reflects the LTE
>>> match the current number of subcarriers. It will be used to
>>>
>>> compiled all .grc files succesfully. Now I would like to test
>>>
> <https://lists.gnu.org/mailman/__listinfo/discuss-g...
>>>
> _______________________________________________ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> <mailto:Discuss-gnuradio@gnu.org>
> 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-----
1d9f5db45b9560d31c47f362272b2f68?d=identicon&s=25 Charlie Sheen (arvind19)
on 2014-03-25 09:48
I got the LTE flowgraph up Unpack MIB ,but i am not able to see output
since i dont have .dat file.Can someone give link for sample .dat file?
At the end of the unpack MIB what is the expected output?
1d9f5db45b9560d31c47f362272b2f68?d=identicon&s=25 Charlie Sheen (arvind19)
on 2014-03-27 05:21
i have installed gr-lte in gnuradio 3.7.2 .All hier blocks are generated
and flow graph is complete upto unpack MIB.Is that it?.But when i run
this i get following error

Using Volk machine: sse4_2_32
pbch_pre_decoder_vcvc_1  set N_ant to 2
pbch_pre_decoder_vcvc_1  set decoding style to "tx_diversity"
pbch_pre_decoder_vcvc_0  set N_ant to 1
pbch_pre_decoder_vcvc_0  set decoding style to "tx_diversity"
pbch_layer_demapper_vcvc_1  set N_ant to 2
pbch_layer_demapper_vcvc_1  set decoding style to "tx_diversity"
pbch_layer_demapper_vcvc_0  set N_ant to 1
pbch_layer_demapper_vcvc_0  set decoding style to "tx_diversity"
RS GENERATOR cell_id   pilots   1
RS GENERATOR cell_id   pilots   0
Traceback (most recent call last):
  File "/home/cdot/top_block.py", line 218, in <module>
    tb = top_block(N_rb_dl_0=options.N_rb_dl_0)
  File "/home/cdot/top_block.py", line 92, in __init__
    self.decode_bch_hier_gr37_0 = decode_bch_hier_gr37()
  File "/root/.grc_gnuradio/decode_bch_hier_gr37.py", line 46, in
__init__
    self.bch_lte_bch_viterbi_vfvb_0 = lte.bch_viterbi_vfvb()
  File "/usr/local/lib/python2.7/dist-packages/lte/bch_viterbi_vfvb.py",
line 42, in __init__
    self.vtss = blocks.vector_to_streams(1* gr.sizeof_float, 120,
"bch_viterbi_vector_to_streams_0")
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig1.py",
line 369, in make
    return _blocks_swig1.vector_to_streams_make(*args, **kwargs)
TypeError: vector_to_streams_make() takes at most 2 arguments (3 given)
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.