Gr-lte updated to GNU Radio 3.7 API

GNU Radio
#1

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

#2

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

#3

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 :slight_smile:

Ralph.

#4

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

#5

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

#6

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

#7

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

#8

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

#9

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

#10

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 :slight_smile:

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

Philip

#11

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 :slight_smile:

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 D. <[email protected]
<mailto:[email protected]>> 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

#12

That would be cool anyway.

#13

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

#14

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

#15

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 D. [mailto:[email protected]]
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: [email protected]; 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
[email protected] 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 :slight_smile:

Ralph.

#16

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.

#17

On Thu, Dec 19, 2013 at 12:55 PM, Johannes D.
[email protected] 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

#18

OK, I understand. So I need some file J My Intel i5 tablet PC may be too
slow for life decode.

Ralph.

From: Johannes D. [mailto:[email protected]]
Sent: Thursday, 19 December, 2013 18:55
To: Ralph A. Schmid, dk5ras
Cc: [email protected]; 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
[email protected] 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 D. [mailto:[email protected]]
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: [email protected]; 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
[email protected] 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 :slight_smile:

Ralph.

#19

-----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 B. 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
<[email protected] mailto:[email protected]>
hierarchical

a
blocks. That’s kind of the tribute that has to be paid for

unpack MIB

Ralph.

mailto:[email protected]

move the

and created them as GRC hier blocks instead. Or runtime
https://github.com/kit-cel/gr-lte

Discuss-gnuradio mailing list [email protected]

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
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-----

#20

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio