Hi Daniel,
well, when you build gr-lte, it also builds the same "kind" of
documentation, the doxygen API reference.
However, the single blocks aren't necessarily as well-documented. But:
Johannes did a really nice job of commenting his code, so I can only
encourage you to read the source code, an
Cinaed: Update your gr-lte GIT checkout & all of the "make test" errors
should be taken care of.
Johannes: You're welcome & thanks for being so responsive in getting PRs
dealt with. As of this morning (US/EST), gr-lte builds cleanly and
passes "make test" out of the box for me (in MacPorts; probab
Hi all,
in previous versions of 'gr-lte' there were some issues with '*.dat'
files. These were remainders of an internal test. I removed those lines
and the QA tests should work now.
I'd like to say thanks to MLD for issuing PRs to fix some bugs. And
Also, thanks to Marcus for his time to an
On 08/29/2017 08:02 PM, w xd wrote:
> thanks all,
>
> my environment:
>
> gnuradio-config-info --prefix -v
> /opt/local
> 3.7.11
>
> I use the macport to install gnuradio and gr-lte.
>
> 1.
> I try to run "/python hier_block_install_helper.py/" many times, it also
> gives me the error like th
On 08/29/2017 02:42 PM, Michael Dickens wrote:
> In MacPorts, I have the gr-lte port depend on the zeitgeist port for
> testing purposes only. This helps out some with the QA, as does the most
> recent commits that fix some debug log files that couldn't be written
> to.
Thanks!
I'm using the late
thanks all,
my environment:
gnuradio-config-info --prefix -v
/opt/local
3.7.11
I use the macport to install gnuradio and gr-lte.
1.
I try to run "*python hier_block_install_helper.py*" many times, it also
gives me the error like this:
Block key "lte_pcfich_demux_vcvc" not found
Block key "lte_p
In MacPorts, I have the gr-lte port depend on the zeitgeist port for
testing purposes only. This helps out some with the QA, as does the most
recent commits that fix some debug log files that couldn't be written
to.
{{{
The following tests FAILED:
13 - qa_pbch_demux_vcvc (Failed)
On 08/29/2017 02:00 AM, Cinaed Simson wrote:
> Hi - it worked for me.
Opps - I forgot to run make test.
50% of the tests failed. Here's the summary of the report:
The following tests FAILED:
2 - qa_mib_unpack_vbm (Failed)
3 - qa_crc_check_vbvb (Failed)
5 - qa_bch_vi
Hi - it worked for me.
I had to run the
python hier_block_install_helper.py
script 3 times to get all the hier blocks - and in order for to ensure
the script completed without any errors.
Using the latest git commit for gr-lte
commit 28b030dd903c4d107fd51e57a28e4c862417e6d1
and I'm runni
thanks so much, I follow your direction, it's ok now.
Now "make" and "sudo make install " all ok.
But now I run: examples python hier_block_install_helper.py
so many errors:
like this:
Block key "lte_pbch_demux_vcvc" not found
Block key "lte_pbch_demux_vcvc" not found
Block key "lte_pbch_demux_
Thank you so much!
On 08/28/2017 12:50 PM, Michael Dickens wrote:
I've put together a pull request that fixes this issue: <
https://github.com/kit-cel/gr-lte/pull/15 > I'll email a patch to the OP
off-list. Cheers! - MLD
___
Discuss-gnuradio mailing
I've put together a pull request that fixes this issue: <
https://github.com/kit-cel/gr-lte/pull/15 > I'll email a patch to the OP
off-list. Cheers! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/d
So, how did you install GNU Radio, and where? The output of
`gnuradio-config-info --prefix -v` might help us.
Best regards,
Marcus
On 08/28/2017 03:03 AM, w xd wrote:
thanks sir
can you explain it more clearly?sorry for not familiar with it.
I just copy the "volk":(it can not work also)
I
You most prominently need to *link* against libvolk. That requires you
to add an appropriate target_link_libraries entry in lib/CMakeLists.txt
On 08/28/2017 10:10 AM, Johannes Demel wrote:
Hi all,
I'm uncertain how to integrate VOLK into the 'gr-lte' CMakeLists file.
I've just looked at some
I believe you just have to add it to the GR_REQUIRED_COMPONENTS.
Change:
set(GR_REQUIRED_COMPONENTS RUNTIME FILTER)
to:
set(GR_REQUIRED_COMPONENTS RUNTIME FILTER VOLK)
Ron
On 08/28/2017 01:10 AM, Johannes Demel wrote:
Hi all,
I'm uncertain how to integrate VOLK into the 'gr-lte' CMakeLists
Hi all,
I'm uncertain how to integrate VOLK into the 'gr-lte' CMakeLists file.
I've just looked at some other modules. I ended up just adding the line
'find_package(Volk)'. This ends up in a 'works for me'. CMake finds
'VOLK' and I could just compile 'gr-lte' from a new github clone.
Though,
thanks sir
can you explain it more clearly?sorry for not familiar with it.
I just copy the "volk":(it can not work also)
I don't use the MacPorts, just follow the instruction from GitHub.Namely,
build by myself.
# Install a
Oh, I missed that. Not cool, considering I think I've inherently become
one of gr-lte's maintainers :/ Thanks!
Best regards,
Marcus
On 27.08.2017 21:20, Michael Dickens wrote:
> The issue is that gr-lte requires Volk but does not check for it --
> nor use its API / headers correctly nor use its A
The issue is that gr-lte requires Volk but does not check for it -- nor
use its API / headers correctly nor use its ABI / libraries correctly --
in the CMakeLists.txt scripts. This is a simple fix, which you can copy
from other OOT modules.
Related: Are you trying to use MacPorts to do the install?
Dear zs,
that looks most like a broken GNU Radio installation, or rather multiple
conflicting installations. Considering I interpret between the lines
that you're building this on OS X: How did you install GNU Radio? Did
you update any of the dependencies of GNU Radio, but not GNU Radio since
you'
64bit
2017-08-27 15:44 GMT+08:00 Andrew Rich :
> Are you on a 32 bit or 64 bit
>
> Sent from my iPhone
>
> On 27 Aug 2017, at 5:34 pm, w xd wrote:
>
> Environment: Mac os 10.12.6
>
> I want to install gr-lte and learn something about LTE. And I follow the
> instruction from https://github.com/ki
Are you on a 32 bit or 64 bit
Sent from my iPhone
> On 27 Aug 2017, at 5:34 pm, w xd wrote:
>
> Environment: Mac os 10.12.6
>
> I want to install gr-lte and learn something about LTE. And I follow the
> instruction from https://github.com/kit-cel/gr-lte.
>
> when the go to the command "make
Hi Ivan,
there's a problem with this:
> When I am inside Python - import lte retutns no error, so I think
> Python konows about lte package.
Your output says:
ImportError: libgnuradio-lte.so: cannot open shared object file: No such
file or directory
So I guess, you might be one time running Pyt
Hi Marcus
On Thu, Feb 9, 2017 at 3:18 PM, Marcus Müller
wrote:
> Hi Ivan,
>
> is it possible you've installed gr-lte into a place that python doesn't
> look in? You say you installed GNU Radio via an install script; are you
> referring to PyBOMBS, perhaps?
>
For GNU Radio I am using the build-sc
Hi Ivan,
is it possible you've installed gr-lte into a place that python doesn't
look in? You say you installed GNU Radio via an install script; are you
referring to PyBOMBS, perhaps? In that case, make sure your "cmake" call
when build gr-lte has a
"-DCMAKE_INSTALL_PREFIX=/path/to/your/pybombs/pr
----------------------
> Kevin
>
> *发件人：*Marcus Müller
> *发送时间：*2015-12-30 18:46
> *主题：*Re: [Discuss-gnuradio] gr-lte recorded files
> *收件人：*"kevin_L"&l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
the flowgraph expects complex floats. Essentially, other platforms
generate the same values. Cartesian coordinates translate to 'a + jb'.
GR mostly uses float for a and b. Other data types are also possible
and should be easy to convert.
Jo
Hi,johannes,thank you for your reply.Another question bothers me,that is :
what's the type of your input of the "lte_top_block_siso? The recorded
samples from the usrp N210 is the type of complex float 32 with the I/Q
signals placed alternative. But the recorded samples from the matlab tools
is c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
this is only guesswork. Maybe occasional 'O's indicate overruns during
recording. This causes the flowgraph to loose sync. Maybe some
non-linearity causes it. Maybe the SNR is just not good enough. Maybe
frequency sync is off by an integer m
Hi , johannes, thank you for your reply.
I use the recorded samples from the matlab lte system tools. It can decode
the MIB successfully.
But when i use the recorded samples from the usrp N210, ( I set the usrp
N210 with the samp_rate =10M ,and connect to a resampler with the
interpolation of 30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
There's a variable block 'samp_rate'. It calculates the expected input
sample rate for a given FFT size. You need to record your samples at a
rate which the N210 supports. Then a rational resampler does the work.
That's really it. The docs a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
I don't know anything about the source of your samples. So I can't
tell. I guess that's up to you to figure it out. Everything that's
typically causing errors in a radio system may impact the results.
Cheers
Johannes
On 02.12.2015 13:48, k
Hi,Johannes,I ran the "lte_top_block_siso.grc",but I got the message
"INFO: MIB decoding_rate = 0.004"
why the decoding_rate is so low, how to improve the decoding_rate?
best wishes!
--
View this message in context:
http://gnuradio.4.n7.nabble.com/gr-lte-tp57154p57158.html
Sent from the Gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
make sure no overruns happen. It is acceptable to have one or two or
so right at startup. Later overruns will cause synchronization to fail
and the flowgraph won't recover.
I recommend to record samples and then run the flowgraph offline.
C
Hi Johannes, you are exactly right. I made a mistake,I got my input files
from the Uplink.I will try again to use the right input files.
Thank you very much for your reply.
Best wishes!
--
View this message in context:
http://gnuradio.4.n7.nabble.com/gr-lte-tp57123p57125.html
Sent from the GnuR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
the flowgraph is supposed to decode the downlink. Your sample file
name suggests it contains samples encoded for the uplink.
The messages you see should be part of the initial setup. So some of
those parameters may change when the flowgraph
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 foll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ali,
Please don't post so many files on the mailing list. Use a website
which offers free hosting and post the link. Also, please don't send
mails twice.
Actually, I can't spot the issue at the moment. Just to confirm this,
it always detects the c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ali,
I assume you pulled the latest gr-lte Version this week and you're
using the _siso.grc flowgraph.
Does your file source repeat the frames you generated? Maybe the
flowgraph gets stuck before the PBCH path receives any samples.
While PBCH, BC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey Maurizio,
RSRP measurements are not yet implemented in gr-lte. But I assume
others might find it useful too and I'd be happy to receive a pull
request for this feature.
Cheers
Johannes
On 11.09.2015 17:35, Crozzoli Maurizio wrote:
> Are RSRP mea
Hey Doug,
> First one should be pretty easy for you: a couple of the blocks ask
> for input "rxant", and the pre-decoder asks for both rxant and
> N_ant. I scanned the source and looks like "1" will be an okay
> value for both, but just out of curiosity, what is actual different
> between rxant an
: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Johannes Demel [uf...@student.kit.edu]
Sent: Thursday, July 02, 2015 1:22 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-lte chanel estimation
Hey
Hey Doug,
This particular part of the flowgraph deals with reception of a 2
antenna transmitter. That implies that an Alamouti code is applied
before transmission. Thus, for correct reception, it is necessary to
perform the inverse Alamouti code operation. This is generally called
Precoding. For d
On Mon, Jun 29, 2015 at 2:19 PM, Anderson, Douglas J.
wrote:
> https://github.com/kit-cel/gr-lte/blob/master/docs/lte_cp_ffo_sync_hier.grc.png
>
> If I understand that right, it's saying that I actually don't need to retune
> the USRP, it just pumps samples into the input of the FFO Sync hier bloc
Douglas J. [dander...@its.bldrdoc.gov]
Sent: Monday, June 29, 2015 1:04 PM
To: Johannes Demel; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm*
Johannes,
I really appreciate the response, I know you're busy with your SOCIS project.
I'm actu
behalf of
Johannes Demel [uf...@student.kit.edu]
Sent: Thursday, June 25, 2015 9:15 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm*
Hey Doug,
there are a few differences between gr-ofdm and gr-lte. When I started
the project, gr-ofdm wasn't ava
Hey Doug,
there are a few differences between gr-ofdm and gr-lte. When I started
the project, gr-ofdm wasn't available. Later on I tried to use an API
as similar as possible to gr-ofdm. Though, gr-lte is designed for FDD
mode. That being said, it is quite a difference to gr-ofdm which is
primarily
On 24.06.2015 08:48, Anderson, Douglas J. wrote:
> Lately I've been working with gr-lte and trying to use some of those
> blocks in my own application (not grc).
>
> I'm still in the learning phase about ofdm/lte, and I'm struggling with
> the lack of documentation or comments in gr-lte.
>
> I th
Finally, I updated the gnu-radio, and following the instructions for
gr-lte again it worked. I had installed gnu-radio from sources, so I
just updated it with git. Thanks!
Gabriel
El 01/07/14 08:44, Gabriel Tolón escribió:
Hi Marcus, thanks for your answer.
I've uninstalled the gr-lte code a
Hi Marcus, thanks for your answer.
I've uninstalled the gr-lte code and installed it again, with same
results. When the code wasn't installed, I couldn't generate any of the
flow graphs, on the other hand, with the code installed I can generate
all the examples except that mentioned.
In the
Hi!
The errors look like python can't find the LTE module; have you made
sure you've installed that?
With best regards,
Marcus Müller
On 30.06.2014 21:11, Gabriel Tolón wrote:
> Hi,
>
> I downloaded the GNU RADIO LTE receiver code and followed the
> instructions to install it, but unfortunately I
-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. A
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)
Blo
> I remember the mailing list having a discussion on how to exchange these kind
> of files; I think Ralph A. Schmidt offered his FTP server, but I
> don't know how to contact him (aside from this mailing list and maybe @dk5ras
> on twitter).
Just by email, this list, phone, sms, whatever :)
>
> I remember the mailing list having a discussion on how to exchange these kind
> of files; I think Ralph A. Schmidt offered his FTP server, but I
> don't know how to contact him (aside from this mailing list and maybe @dk5ras
> on twitter).
Just by email, this list, phone, sms, whatever :)
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Sorry that it took me so long to respond;
how big is "very big"? Are we talking about a few GBs?
I remember the mailing list having a discussion on how to exchange
these kind of files; I think Ralph A. Schmidt offered his FTP server,
but I don't k
Hi,
Marcus and Martin basically described all I can tell you with the given
info. Many of the given blocks are designed to be verbose about their
setup. This is mainly to see what happens.
The buffer allocator warnings would disappear if you would set N_rb_dl = 6.
But that's just avoiding the unde
Hi,
some info on your output:
On Thu, Jan 16, 2014 at 02:18:18PM +0100, Baier wrote:
> Using Volk machine: avx_64_mmx_orc
This is a GNU Radio init message.
> RS GENERATOR cell_id pilots 0
>
> RS GENERATOR cell_id pilots 1
>
> pre_decoder_vcvcset N_ant to 2
>
> pre_decoder_vcvcset decoding st
Am 16.01.2014 14:29, schrieb Marcus Müller:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Aneta,
though I don't know if everything is going well, the lines you
attached showed no indications of an error. It would be best to
describe your output to help Johannes understand where (and if) hi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Aneta,
though I don't know if everything is going well, the lines you
attached showed no indications of an error. It would be best to
describe your output to help Johannes understand where (and if) his
decoder goes astray.
And: Could you maybe sha
Thanks for the feedback. I'll probably add a warning in the README.
Interesting that this block 'block_tests' shows up. It was never meant to
show up in GRC and I thought I removed it.
During the transition to the GR 3.7 API a lot of code clean up happened as
well. So this should be cleaned up by n
static also not working. Throwing same error.
I downloaded from here
https://github.com/kit-cel/gr-lte/tree/gnuradio-v3.6.5.1
Also one strange thing. When I drag the first block named block_tests
..nothing happens ! ... Just a blank palette of grc comes..
I think I shall grab 3.7
--
View
Hi,
this is a C++11 feature you just "discovered". Older compilers won't allow
you to compile this code like this. Although they usually through a warning
that this is C++11 code. I don't know which commit it was, but I removed
this expression and put in some pre-C++11 code instead.
Also I recomme
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, Joha
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 channel
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 start
.
> -Original Message-
> From: Johannes Demel [mailto:uf...@student.kit.edu]
> Sent: Thursday, December 19, 2013 5:07 PM
> To: Philip Balister; Ralph A. Schmid, dk5ras
> Cc: Demel, Johannes; 'Mike Cornelius'; 'discuss-gnuradio'
> Subject: Re: [Discuss-gnuradi
-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
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
On 20 December 2013 03:11, Johannes Demel wrote:
> Hi Mike,
>
> just saw this mail. Basi
On Thu, Dec 19, 2013 at 3:07 PM, Johannes Demel
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 wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
That'd actually be rather awesome :)
On 19.12.2013 22:07, Johnathan Corgan wrote:
> On 12/19/2013 12:33 PM, Marcus Müller wrote:
>
>> As much as I like the tracker solution, it leads to orphaned
>> torrents with time passing... There won't be a hundr
On 12/19/2013 12:33 PM, Marcus Müller wrote:
> 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.
It is possible to host a data file on a web server, then incorporate a
"web seed" in the to
> -Original Message- From:
>>> discuss-gnuradio-bounces+ralph=schmid@gnu.org
>>> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On
>>> Behalf Of Johannes Demel Sent: Thursday, December 19, 2013 9:00
>>> AM To: Mike Cornelius; Demel
o: Ralph A. Schmid, dk5ras
Cc: uf...@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
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 mu
On Thu, Dec 19, 2013 at 12:55 PM, Johannes Demel
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 ab
18 December, 2013 18:47
> *To:* Ralph A. Schmid, dk5ras
> *Cc:* uf...@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
>
w 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.de...@ettus.com]
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: uf...@student.kit.edu; discuss-gnuradio
Subject: Re: [Discus
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 ma
g] On Behalf Of
>>> Johannes Demel
>>> Sent: Thursday, December 19, 2013 9:00 AM
>>> To: Mike Cornelius; Demel, Johannes
>>> Cc: discuss-gnuradio
>>> Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
>>>
>>> Hi Mike,
&g
ohannes
>> Cc: discuss-gnuradio
>> Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
>>
>> 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
org] On Behalf Of
> Johannes Demel
> Sent: Thursday, December 19, 2013 9:00 AM
> To: Mike Cornelius; Demel, Johannes
> Cc: discuss-gnuradio
> Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
>
> Hi Mike,
>
> the reference I use is a rather big fi
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 he
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
On 19 December 2013 18:54, Mike Cornelius wrote:
> Hi Johannes,
>
> With regard to my earlier message regardin
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
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 ear
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 t
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 blo
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
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,
Hi,
In gr-lte/37grc are all the needed GRC flowgraphs.
LTE_flowgraph_top_level.grc is the one you eventually want to execute.
When you first open 'LTE_flowgraph_top_level.grc' probably most blocks
are missing. This is because all the 'hier blocks' are not compiled yet.
Just open the other flowgr
92 matches
Mail list logo
