Error while building openLTE code on USRP


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


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

Hi Ben,

thank you for your answer.

My previous question was bit strange.

There are to functions of you, once the dl_file_scan and once the only
dl_scan function.

I did undertood that the dl_file_scan function kinda works with USRP,
but I was not sure about the dl_scan function.

I read here that dl_scan does not support USRP:
http://sourceforge.net/p/openlte/mailman/message/30559702/

Is it still valid: Does the dl_scan function still not suppoert USRP?

OR can we by adding the resampler block run it?
When I did run the dl_scan function, it (probably the osmo code)
recognized the USRP2/N-SERIES device and got overflow alerts (“D”).
I don’t undertand, if that means that the dl_scan function works with
the USRP2/N but needs some resampling?

So from your mail, I thought first the addition of the “resampler” is
only valid for the dl_file_scan function, till I managed to run the
dl_scan, thatswhy I am confused.

Lastly, (this is probably my job).
I don’t know if one can create from your source files grc flowcharts. I
looking for that right now. Then, it would be “easy” to add a resampling
block to your code.
If not, could you also please give a hint about how it can be done in
your source code?

Regards, Dincer
Von: Ben W. [mailto:[email protected]]
Gesendet: Dienstag, 1. Oktober 2013 14:47
An: Dincer B.
Cc: [email protected]; [email protected]
Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP

Dincer,
I believe that you will need to add a resampler to the openLTE code in
order to run on a USRP. I don’t have a USRP myself, but I believe that
they only allow sample rates that are integer divisions of 100Msps
(except the USRP B200 series). In order to get a valid LTE sample rate
(30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a
resampling block.
As you mentioned, I am using the gr-osmosdr blocks to interface
currently to rtl-sdr and hackRF. There is support in gr-osmosdr for
USRP, but it will need to be handled in the flowgraph.
Hope this helps,
Ben

On Mon, Sep 30, 2013 at 7:21 AM, Dincer B.
<[email protected]mailto:[email protected]> wrote:
Sorry but I think I mailed to early.

On a normal gnuradio distribution from the build-gnuradio.py -m" code on
Fedora, I did not experience the problems while build and install.
I am checking out the code right now…

Regarding OSMO and RTL-SDR, I did understand it like the libraries can
detect and work with USRP, so that’s probably clear, too.
When using those libraries with USRP, are there any specific changes
that I should make for some blocks etc.?

Regards,
Dincer

Von:
discuss-gnuradio-bounces+dbeken=removed_email_address@domain.invalidmailto:[email protected]
[mailto:discuss-gnuradio-bounces+dbekenmailto:discuss-gnuradio-bounces%2Bdbeken[email protected]mailto:[email protected]]
Im Auftrag von Dincer B.
Gesendet: Montag, 30. September 2013 13:42
An:
[email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]
Betreff: [Discuss-gnuradio] Error while building openLTE code on USRP

Hi all,

I am new to Gnuradio and USRP. I want to try the openLTE Project on my
USRP N210.

During the cmake process I am getting the following errors:

CMake Warning at CMakeLists.txt:92 (find_package): Could not find a
configuration file for package “Gnuradio” that is compatible with
requested version “3.7.0”.

The following configuration files were considered but not accepted:

/usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.git.0

Also since I am not using one of the following devices:
I also get :

– checking for module ‘gnuradio-osmosdr’ – package ‘gnuradio-osmosdr’
not found – Could NOT find GNURADIO_OSMOSDR (missing:
GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) – checking
for module ‘librtlsdr’ – package ‘librtlsdr’ not found – Could NOT
find RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) – checking
for module ‘libhackrf’ – package ‘libhackrf’ not found – Could NOT
find HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS) – checking
for module ‘fftw3f >= 3.0’ – found fftw3f , version 3.3 – Found
FFTW3F: /usr/lib/libfftw3f.so CMake Error at CMakeLists.txt:99
(message): GNURadio required to compile openLTE

After that, I changed in the cmake file the required Gnuradio Version
manually to 3.8. Now I am getting only the OSMO / RTL errors:

  •     -- checking for module 'gnuradio-osmosdr' -- package 
    

‘gnuradio-osmosdr’ not found – Could NOT find GNURADIO_OSMOSDR
(missing: GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) –
checking for module ‘librtlsdr’ – package ‘librtlsdr’ not found –
Could NOT find RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) –
checking for module ‘libhackrf’ – package ‘libhackrf’ not found –
Could NOT find HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:103 (message): GNURadio Osmosdr required
to compile openLTE (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)

From the discuss Forum of gnuradio, I read that it is possible to run it
with USRP (USRP2)

https://www.ruby-forum.com/topic/4169390#new

How can I ignore those libraries or replace them?
And can I use this code on the USRP?

Regards,
Dincer

Hi Ben,

many thanks for your clarifying answer. I will need to think little bit
about 2).

But I have another Question:

Why did you not use a usual Python flowgraph (like in file scan) but a
C++ flowgraph?
Is there anywhere a python flowgraph for the live scan app?

Thanks again,
Dincer

Von: Ben W. [mailto:[email protected]]
Gesendet: Donnerstag, 3. Oktober 2013 14:40
An: Dincer B.
Cc: [email protected]; [email protected]
Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP

Dincer,
Hopefully this will clarify things a bit:

  1. The dl_scan application will not work with USRP currently due to the
    resampling issue. Since gr-osmosdr will support USRP, the dl_scan
    application should run using a USRP, but the sampling rate will be
    incorrect and it will not decode anything. This is the application that
    will need to have a resampler block added.
  2. The dl_file_scan application is not dependent on any hardware. It
    just uses a recorded baseband I/Q file for its processing. However, the
    file must be recorded at one of the valid LTE sampling rates. So again,
    if you are using the USRP, you will have to resample the data. I have
    found that the octave function resample works great for this task.
    I have not worked with grc in the past, so I can help much with anything
    you do there. However, you can modify LTE_fdd_dl_scan_flowgraph.cc
    directly if you need.
    Hope this helps,
    Ben

On Tue, Oct 1, 2013 at 10:08 AM, Dincer B.
<[email protected]mailto:[email protected]> wrote:
Hi Ben,

thank you for your answer.

My previous question was bit strange.

There are to functions of you, once the dl_file_scan and once the only
dl_scan function.

I did undertood that the dl_file_scan function kinda works with USRP,
but I was not sure about the dl_scan function.

I read here that dl_scan does not support USRP:
http://sourceforge.net/p/openlte/mailman/message/30559702/

Is it still valid: Does the dl_scan function still not suppoert USRP?

OR can we by adding the resampler block run it?
When I did run the dl_scan function, it (probably the osmo code)
recognized the USRP2/N-SERIES device and got overflow alerts (“D”).
I don’t undertand, if that means that the dl_scan function works with
the USRP2/N but needs some resampling?

So from your mail, I thought first the addition of the “resampler” is
only valid for the dl_file_scan function, till I managed to run the
dl_scan, thatswhy I am confused.

Lastly, (this is probably my job).
I don’t know if one can create from your source files grc flowcharts. I
looking for that right now. Then, it would be “easy” to add a resampling
block to your code.
If not, could you also please give a hint about how it can be done in
your source code?

Regards, Dincer
Von: Ben W.
[mailto:[email protected]mailto:[email protected]]
Gesendet: Dienstag, 1. Oktober 2013 14:47
An: Dincer B.
Cc:
[email protected]mailto:[email protected];
[email protected]mailto:[email protected]
Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP

Dincer,
I believe that you will need to add a resampler to the openLTE code in
order to run on a USRP. I don’t have a USRP myself, but I believe that
they only allow sample rates that are integer divisions of 100Msps
(except the USRP B200 series). In order to get a valid LTE sample rate
(30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a
resampling block.
As you mentioned, I am using the gr-osmosdr blocks to interface
currently to rtl-sdr and hackRF. There is support in gr-osmosdr for
USRP, but it will need to be handled in the flowgraph.
Hope this helps,
Ben

On Mon, Sep 30, 2013 at 7:21 AM, Dincer B.
<[email protected]mailto:[email protected]> wrote:
Sorry but I think I mailed to early.

On a normal gnuradio distribution from the build-gnuradio.py -m" code on
Fedora, I did not experience the problems while build and install.
I am checking out the code right now…

Regarding OSMO and RTL-SDR, I did understand it like the libraries can
detect and work with USRP, so that’s probably clear, too.
When using those libraries with USRP, are there any specific changes
that I should make for some blocks etc.?

Regards,
Dincer

Von:
discuss-gnuradio-bounces+dbeken=removed_email_address@domain.invalidmailto:[email protected]
[mailto:discuss-gnuradio-bounces+dbekenmailto:discuss-gnuradio-bounces%2Bdbeken[email protected]mailto:[email protected]]
Im Auftrag von Dincer B.
Gesendet: Montag, 30. September 2013 13:42
An:
[email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]
Betreff: [Discuss-gnuradio] Error while building openLTE code on USRP

Hi all,

I am new to Gnuradio and USRP. I want to try the openLTE Project on my
USRP N210.

During the cmake process I am getting the following errors:

CMake Warning at CMakeLists.txt:92 (find_package): Could not find a
configuration file for package “Gnuradio” that is compatible with
requested version “3.7.0”.

The following configuration files were considered but not accepted:

/usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.git.0

Also since I am not using one of the following devices:
I also get :

– checking for module ‘gnuradio-osmosdr’ – package ‘gnuradio-osmosdr’
not found – Could NOT find GNURADIO_OSMOSDR (missing:
GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) – checking
for module ‘librtlsdr’ – package ‘librtlsdr’ not found – Could NOT
find RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) – checking
for module ‘libhackrf’ – package ‘libhackrf’ not found – Could NOT
find HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS) – checking
for module ‘fftw3f >= 3.0’ – found fftw3f , version 3.3 – Found
FFTW3F: /usr/lib/libfftw3f.so CMake Error at CMakeLists.txt:99
(message): GNURadio required to compile openLTE

After that, I changed in the cmake file the required Gnuradio Version
manually to 3.8. Now I am getting only the OSMO / RTL errors:

  •     -- checking for module 'gnuradio-osmosdr' -- package 
    

‘gnuradio-osmosdr’ not found – Could NOT find GNURADIO_OSMOSDR
(missing: GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) –
checking for module ‘librtlsdr’ – package ‘librtlsdr’ not found –
Could NOT find RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) –
checking for module ‘libhackrf’ – package ‘libhackrf’ not found –
Could NOT find HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:103 (message): GNURadio Osmosdr required
to compile openLTE (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)

From the discuss Forum of gnuradio, I read that it is possible to run it
with USRP (USRP2)

https://www.ruby-forum.com/topic/4169390#new

How can I ignore those libraries or replace them?
And can I use this code on the USRP?

Regards,
Dincer

Dincer,

Hopefully this will clarify things a bit:

  1. The dl_scan application will not work with USRP currently due to the
    resampling issue. Since gr-osmosdr will support USRP, the dl_scan
    application should run using a USRP, but the sampling rate will be
    incorrect and it will not decode anything. This is the application that
    will need to have a resampler block added.
  2. The dl_file_scan application is not dependent on any hardware. It
    just
    uses a recorded baseband I/Q file for its processing. However, the file
    must be recorded at one of the valid LTE sampling rates. So again, if
    you
    are using the USRP, you will have to resample the data. I have found
    that
    the octave function resample works great for this task.

I have not worked with grc in the past, so I can help much with anything
you do there. However, you can modify LTE_fdd_dl_scan_flowgraph.cc
directly if you need.

Hope this helps,
Ben

Dincer -

Why did you not use a usual Python flowgraph (like in file scan) but a
C++ flowgraph?

Python flowgraphs aren’t any more ‘usual’ than C++ flowgraphs. Python is
perhaps more widely used because that is how GRC generates flowgraphs,
but
many applications, especially those that need low-level control of
memory,
are written in C++.

Both are natively supported by GNURadio - it’s just up to the
application
developer which is more appropriate.

Cheers,
Ben