Hi Joe,
this sounds like you want to use ctrlport performance monitor. This
might show you situations where certain buffers fill up while others are
empty.
Of course, I assume you use a flowgraph with parallel data flows. In
such situations a very slight rate mismatch or bugs that cause lost
ou can find the block I used to calculate and set the tx_time tags in
> flow graph [1].
>
> Cheers,
> Julian
>
> [1] https://github.com/RWTH-iNets/gr-inets/blob/master/grc/inets_tx_phy.grc
>
> On 17.01.19 12:39, Johannes Demel wrote:
>> Hi community,
>>
&
Hi community,
I do have an issue with the 'Burst Shaper' block and I'm uncertain how
to tackle this problem. In this particular case I'm stuck with 3.7 for
now, but as fas as I can tell, the actual implementation did not change
with respect to 3.8.
So, here is the problem:
I have a flowgraph
would appreciate it.
Cheers
Johannes
Von: Müller, Marcus (CEL)
Gesendet: Dienstag, 2. Oktober 2018 18:30:35
An: m...@andrejro.de; Johannes Demel; 246...@gmail.com; phi...@balister.org
Cc: discuss-gnuradio@gnu.org
Betreff: Re: AW: [Discuss-gnuradio] LDPC
is really good. I've not used
it as a library yet. That seems to be a new use case. All in all just a couple
of thoughts on it.
Cheers
Johannes
Von: Müller, Marcus (CEL)
Gesendet: Donnerstag, 20. September 2018 16:17:13
An: m...@andrejro.de; Johannes Demel
Hi all,
would it be an option to add a specialized library to GR for LDPC code?
'aff3ct' [0] would be one library that comes to my mind. Of course, they might
have a different approach to decoders in general. Also, at this point this
might be a "compile your own dependency" library. Anyways,
Hi all,
I just experienced the same error. Since my setup differs (ancient OS),
I thought I'd just share my experience so far.
For low sample rates (3.125MSps) the flowgraph freezes after a while and
an 'O' is printed.
For 6.25MSps:
gr::log :WARN: gr uhd usrp source0 - USRP
Hi Mario,
to sum it up
- your packet duration is:
128bit(in your case also symbols)/50kBaud/s = 2.56ms
- Your "device" sample rate is 50kBaud/s * 20 = 1MSps.
First, do you use any hardware? Or is this just a simulation for now?
If it is a simulation, do you use a throttle block?
In case it is
github.com/harshit4084/MyDoc/blob/master/gsoc2018_Harshit_Gupta.pdf
<https://rb.tc/344QC#https://github.com/harshit4084/MyDoc/blob/master/gsoc2018_Harshit_Gupta.pdf>
Best Regards,
Harshit Gupta
On Fri, Mar 23, 2018 at 10:06 AM, Johannes Demel
<de...@ant.uni-bremen.de <mailto:de...@ant
Hi Harshit,
I read your proposal and I have quite a few suggestions for improvement.
General remarks
Your references must be updated. They do not point to the actual sources
but some general landing page. Also, I found at least one reference that
points to an incorrect source.
Introduction
Hi Gilad,
it is possible to pass references to other blocks to your custom block.
But you should avoid this implementation. First off, another block is
scheduled in another thread. This might cause runtime issues.
If you need status information from another block, add a message port
that
Hi Markus,
the whole gr::random class would be a candidate for a C++11 overhaul.
Though, C++11 is only supported on the next branch aka GR3.8. On GR3.7
C++11 is not supported. To make matters worse, 3.7 requires to work with
a fairly old Boost version. Somewhere in the 1.3x range if I recall
Hi Michael,
is there any specific reason why you want to use wx-scope? WX is
deprecated and the Qt instrumentations should be a full replacement with
additional features at this point. Usually it is quite simple to move
from WX to Qt. Do you have any OOT modules using WX which prevent you
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
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,
files and
they can't find
polar_config
I did a search of the gnuradio tree and my home directory
find . -name polar_config\*
and I couldn't find it either.
-- Cinaed
On 07/14/2017 01:04 AM, Johannes Demel wrote:
Hi,
this is a tricky one. My assumption is, that the configurator block
something does not behave as expected here.
Cheers
Johannes
On 14.07.2017 01:47, Cinaed Simson wrote:
On 07/13/2017 12:03 AM, Johannes Demel wrote:
Hi Alex,
could you be more specific about
'When I drop the POLAR code configurator block on the canvas, the
gnuradio program turns down.'?
Does GRC
Hi Alex,
could you be more specific about
'When I drop the POLAR code configurator block on the canvas, the
gnuradio program turns down.'?
Does GRC quit with an error? Does it turn dark and is unresponsive? Is
there anything printed on the commandline?
Cheers
Johannes
On 12.07.2017 18:04,
Hi everyone,
I've been working with 'blocks::burst_tagger' for a while now and I
wonder why the trigger input expects shorts. The impl only checks if
'trigger[i] > 0'.
I would expect the trigger type to be 'char'. This would fit with the
output of blocks like 'Plateau Detector' or 'Peak
Hi!
as far as I can tell, all tests fail because they fail with
'ImportError: No module named runtime_swig'
This is most probably neither related to GSL nor polar QA tests. Did you
try a minimal example? Did you install some version of GR? Does the
failing line 'from gnuradio import gr,
Hi Fernando,
If you want to use FM modulation, WBFM might still be the block to use.
The const values for the low_pass filter can be changed. You just need
to take care that your sample rates etc. do not cause aliasing.
The two values that need to be reassigned are passband cutoff and
Hi Fred,
this is a warning that you want to execute a 'No GUI' flowgraph without
a terminal.
GRC tries to run your flowgraph by opening a new terminal. All prints
etc. will go into this terminal. But GRC is missing the path to your
terminal application.
How to fix this:
Go to ~/.gnuradio
Hey Hanwen,
in my master thesis [0] I did some benchmarks for polar codes and there
should be one benchmark for LDPC codes. All benchmarks use the GNU Radio
implementation.
[0] https://github.com/jdemel/socis-2015-gr-results
On 07.12.2016 00:52, hanwen wrote:
Dear all,
I just want to know
Hi Junxiao,
so, the tests for polar codes pass? But in GRC the examples won't run?
What does GRC report? I'm referring to the flowgraph error window.
Can you disable some blocks in GRC until it is executable? This might
point us in the correct direction. Also, which example do you try?
Hi JM,
the audio source block has an option 'number of outputs'. I assume you
need to configure your audio source to choose the correct device and the
correct number of output streams. I guess what you want is, you
interpret source0 as I and source1 as Q data. Then use float to complex
to
Hi all,
for clarification. Scipy is an optional dependency. Thus, the tests
might fail.
All polar tests import 'polar.channel_construction', which imports
'polar.channel_construction_awgn', which in turn uses
'scipy.optimize.fsolve' and 'scipy.special.erfc'.
When I wrote this peace of code, I
Hey Ali,
in order to figure out the issue, we'd need a more verbose error message.
Could you run the failing tests with 'ctest -V -R [testname]'? This
might help.
Cheers
Johannes
On 15.08.2016 15:15, Ali The GREAT! wrote:
Hi everyone,
I have installed uhd_3_11_0 and gnuradio_3_7_10_1.
Hey!
As fas as I can tell, you don't check if the output buffer can actually
take that many samples. Thus "you end up in the middle of invalid
memory". At least that's what I guess from the code I can see. You need
to ensure that 'noutput_items' always holds a value greater than your
final
20!
On 15.07.2016 04:54, Henry Barton wrote:
I’m designing a CDMA system with a spreading factor of 20. I recently
wrote an app to go through all the binary permutations up to 2^20 and
report which ones have an equal number of 0’s and 1’s, or at least
differ by only one. It came up with so many
omes out but it
doesn't make any sense since I'm supposed to be printing only '1' and
'0'...There is something i'm missing somewhere.
2016-06-28 13:10 GMT-04:00 Johannes Demel <de...@ant.uni-bremen.de
<mailto:de...@ant.uni-bremen.de>>:
Hi Olivier,
is there a reason, besides
Hi Olivier,
is there a reason, besides you print the values afterwards, that you
copy your input data to your tab array?
Write a test which puts in your frame and checks if the output is
prepended by your sync word. [syncword, payload].
Just write your preamble to the output buffer and then
Hi Olivier,
I guess Nick already pointed out the important bits. Also, the warnings
GRC prints to the shell should help you.
Could you solve your file source issues? Your questions here seem to be
related to a different issue.
Tx flowgraph: get rid of the throttle block. (also see the
ate sample data that
> you know works?
>
> LTE is a lot more complicated than GSM by the looks of it. All I
> need to do is decode the cell ids , lac and mnc... I think your
> MIB/SIB decoder should be able to do this in principle?
>
> Cheers
>
> Balt
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Balthasar,
I know this is a bit tricky. Also I'd like to provide samples but
that's impossible. They are usually just to large.
'hier_block_install_helper.py' started as a little tool to compile all
the hier blocks. You just didn't need to open
-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.
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
Marcus's hint would've been the first thing I'd have mentioned. Also,
your flowgraph expects the samples to be resampled to 30.72Msps. It is
really important that you match the sampling rate the flowgraph expects.
Cheers
Johannes
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
First of all, all those D's indicate that you drop packets. Record
your samples and use a File source in your flowgraph to get rid of this.
The flowgraph should decode 10 CFI's per frame while it decodes one
MIB at most. Deactivate the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi community,
Polar codes are a part of GNU Radio by now. And I'd like to thank
everyone who supported me during SOCIS and beyond.
I wrote my master thesis based on this implementation with simulations
etc. And you can find it here [0]. So everyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
the MIB carries a few parameters. All of them are published. Do you
refer to SIBs? Those aren't implemented. I'd be happy to accept Pull
Requests which add those features.
CFI calculation might need some bugfixing because there position is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
I assume you use a N2x0. UHD tells you that the requested sample rate
is not supported and even exceeds the connection capacity.
Then the resampler does upampling by a large factor which will feed
the flowgraph with the wrong sample rate.
-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,
-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.
-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
> 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
s Ahsan
>
> On Thu, Nov 26, 2015 at 10:32 AM, Johannes Demel
> <uf...@student.kit.edu> wrote:
>
> Hi Ali
>
>
>>>> 1) it always detects the correct cell_id? Yes
> That's a good sign.
>
>>>>
>>>> 2) the OFDM symbols with RS
-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
-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,
he settings.
>
> Any ideas?!!?!?!
>
> Thanks!
>
> DH From:
> discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
> <discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org> on
> behalf of Johannes D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
> 2) Should I set 'Number of Points' to 576?
Yes. The block will take this amount of points and display it. Then
wait a given time and take the next chunk to display it.
As long as the block does not have at least the specified amount of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This happens when too many shared buffers are allocated but not
released. It's an indicator that your flowgraphs are not terminated
correctly. So I suppose the issue is to figure out what 'Ctrl-Z'
really does.
On 12.11.2015 20:03, Richard Bell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Could you extend a test case for this block with Python? This might
reveal issues with the implementation more easily. Also, others might
benefit from it.
For your specific problem, I guess the GR block result is as close as
it gets for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ratnesh,
GR operates on chunks of items. Every block adds some delay. I suggest
you design your system in a way that parallelizes threshold estimation
and the rest of your flowgraph. Or think of a way to pseudo
parallelize them.
happy hacking
ll help me understand the non-GUI related matters better.
>
> Appreciated, Rich
>
> On Fri, Oct 23, 2015 at 2:44 AM, Johannes Demel
> <uf...@student.kit.edu> wrote:
>
> Hi Richard,
>
> I'm currently working on something quite similar. [1] shows an
> example
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Richard,
I'm currently working on something quite similar. [1] shows an example
fur a dummy.
Basically what I do: I wrapped my flowgraph into another Python thread
which runs the flowgraph and generates statistics and everything else
I want for my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniele,
'MIMO TOP FLOW plots.grc' needed an update. I pushed a new version of
this flowgraph which should work now. I had to substitute some blocks.
Cheers
Johannes
On 09.10.2015 10:19, Daniele Disco wrote:
> Johannes Demel student.kit.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniele,
Run this script a few times. Some of those hier blocks are nested. The
script doesn't care about compiling them in correct order. So after 2
- - 3 times it should have everything. Unless something went wrong.
I recommend you open the
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey GNU Radio'ers!
SOCIS project deadline is near. So I'm trying to finish all
outstanding tasks.
Earlier this week I could issue a pull request against VOLK. So my new
kernels are ready for review. Getting them merged into VOLK is a
prerequisite
Hey community!
time for another project update.
I case anyone still wonders, SOCIS is short for ESA Summer of Code in
Space. I just wanted to mention it again.
This week was about VOLKifying things again. Although the math behind
polar codes is pretty clear, there are a lot of implementation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a rule of thumb with expected error rate BERe:
num simulation bits: (1 / BERe) * 100
that's more like a minimum. It's probably better to go for * 1000.
Also if you use BER block, it has a parameter ' BER Min. Errors'. As
long as it didn't count at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Simon,
I recommend using QT GUIs. WX GUI will be removed eventually.
'stream to streams' does not duplicate samples. In your case the first
sample goes to output 0 and the second sample goes to output 1.
repeat pattern
For AWGN you should
Hey community!
Here we go again. Another project update.
I'm working with VOLK and SIMD for two weeks now. I could fix some
hiccups with last weeks pack and unpack kernels. They run just fine
during test now.
Also, I added a 'volk_8u_x3_encodepolar_8u_x2' kernel. It operates on
the the assumption
some python templating that occurs during cmake to set up
the dispatcher and the result is non-intuitive compiler messages
like that.
Nathan
On Tue, Jul 28, 2015 at 11:30 AM, Johannes Demel
uf...@student.kit.edu wrote:
Thanks for the hint Nathan,
I added puppets for both. They both
, West, Nathan wrote:
On Fri, Jul 24, 2015 at 11:44 AM, Johannes Demel
uf...@student.kit.edu wrote:
Hey community,
after last weeks success with channel construction, this week is
calmer. It involves a steep learning curve for SIMD. So I was
able to create my first VOLK kernels [3
Hey community,
after last weeks success with channel construction, this week is
calmer. It involves a steep learning curve for SIMD.
So I was able to create my first VOLK kernels [3]. There are two new
kernels for 8bit packing and unpacking. In case someone wants to pack
8 bytes with the LSB
Hey GNU Radio'ers!
another week has passed. So it's time for a project update.
This week was dedicated to channel construction. Finally, all channel
construction algorithms work. I added a couple of convenience
functions too.
First, there's a command line tool 'polar_channel_construction' which
Hey GNU Radio'ers!
It is time for another project update.
I started the week with a quick test if I could improve successive
cancellation list decoding. Though, I wanted to focus on channel
construction this week. So I did.
For polar codes one might consider different binary discrete memoryless
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 and N_ant?
Hey community!
It's Friday! So it's time for another project update.
This week was all about decoders. After I had finished a successive
cancellation decoder, I started working on a successive cancellation
list decoder. By the end of last week, I was confident, I could finish
it earlier this
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
Hey GNU Radio'ers,
and here we go again. Another week has passed and thus it's time for
my weekly report.
Just like last week, this week has been about implementing an encoder
decoder chain in C++ for FECAPI. After I put a lot of work in a good
encoder implementation, I did so too with the
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
Hey community,
It is time for another project update. So here it is.
This week I dived into C++ and FECAPI. I implemented a polar encoder for
FECAPI. Of course this includes all the necessary tests. I decided to go
with packed bits in the encoder definition. Though I implemented a mode
which
a20761005e60335da2cb78104a6f1c4b576aa3c2 Mon Sep 17 00:00:00 2001
From: Johannes Demel uf...@student.kit.edu
Date: Thu, 18 Jun 2015 20:13:52 +0200
Subject: [PATCH] fec: extended encoder now appends unpack_k_bits(8) block
after encoder to satisfy get_output_conversion() = unpack behaviour
---
gr-fec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey David,
I suggest you read the tutorial [1]. It explains the various parts of
a block in great detail.
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
On 18.06.2015 00:12, dcardona wrote:
Hello Johannes.
Thank you
Hey David,
you should be able to store your bits in a vector.
First of all, unpack_k_bits will yield bytes with the LSB carrying the
actual bit. All the others should be '0'.
Next, the error you get points in another direction. One of the
parameters 'work' gets is a vector with void pointers.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey Bob,
the main idea is to have drop-in blocks for different codes. Have a
look at 'encoder.h' and the '_impl.*' files. They describe the
framework. In 'generic_encoder.h' is a description for all the
required and available functions for all the
Hey GNU Radio'ers!
Another week has passed. Thus, it's time for my next project update.
The week started with a fairly good event. I found a bug in the
decoder which led to incorrect results.
I studied various papers and algorithms for decoding performance
improvements. Especially Successive
Hey GNU Radio community!
Work on POLAR codes for GNU Radio has begun. This week I'm working on
Python implementations for encoders and decoders. So far I have an
encoder working and an Successive Cancellation decoder.
I'm currently working on different algorithms which are supposed to
boost
Hey GNU Radio community!
Thanks for choosing my project for this year's ESA Summer of Code in
Space. I will implement a POLAR code encoder decoder chain as well as
channel construction.
I would like to introduce myself a bit today.
I am a Master degree student at Karlsruhe Institute of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello GNU Radio'ers,
You're probably all well aware that SOCIS is coming up. Although
application deadline is April 30 [1], I want to publish my SOCIS
proposal today. You can find it on github [2]. I hope it is
well-received by the community and I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
GNU Radio has very nice tutorials [1]. Just read them and try them out
for yourself.
happy hacking
Johannes
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials
On 16.02.2015 08:15, Vishwanatha H G wrote:
sir, i dint get the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey list,
I missed an option to rename a block I once created via modtool. Thus
I coded it. You can find it on github [1]. It is supposed to go
through all the created files and change all the old name occurrences
to the new one. Also, it renames the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniel,
OK I have a code, generated with Gnu radio companion that i want
to run over the command line to follow with GDB. I was under the
impression that if I simply got the code generated in the
~/.grc_gnuradio, add the
This folder usually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniele,
_impl classes are not meant to be subclassed usually.
GR distinguishes between interface or public headers, which are
located in the include directory and private headers which are located
in the lib directory.
You can just add new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tiankun,
the recorded files are simply to large to share. ( 1GB)
Also, you probably want to record your own data.
This gets us to the second option. Generated test data. Using the
integrated Python files to generate test data is unfortunately
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Chaitanya,
in GRC there is a category called OFDM with the new style blocks. Also
in [pathtognuradiosource]/gr-digital/examples/ofdm configured
flowgraphs are provided for reference.
Just to make that sure, I'm refering to GNU Radio 3.7.
happy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hey,
I'm not entirely sure if it still holds true, but that might be an
error related to SWIG. For some reason virtual header files don't get
swig'ed again unless explicitly triggered. Just do a 'make clean' and
'make' again. That should rebuild your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
You might have a look at Python with Numpy/Scipy/matplotlib. Processed
data according to your needs may be observed interactively with
matplotlib and numpy/scipy do a good job at offline analysis. You'd
have to process your data again and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sara,
it seems like there is some confusion between time and frequency domain.
In an OFDM system you have subcarriers next to each other in the
frequency domain. You will most likely add new subcarriers by putting
non-zero values on your vector in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Baldo,
there is also gr-lte [1] as another alternative for an LTE receiver in
this case.
happy hacking
Johannes
[1] https://github.com/kit-cel/gr-lte
On 15.05.2014 11:13, Coll Perales, Baldomero wrote:
Hello,
I considering the possibility
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Wafa,
the OFDM Code in GR is a very good start for data transmission. Also
in [1] in the examples folder you can find a
mimo_ofdm_transceiver.grc. It is a transceiver with which it is
possible to establish an IP connection between to computers. It
Hey Siva,
in [1] I parameterized the trellis module for a rate 1/3 code as used in
LTE. Maybe that helps. I put a lot of comments in.
Besides if you tell us what you want to achieve exactly, someone might
give more specific hints.
happy hacking
Johannes
[1]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Amado,
¿What type of samples use?
Mostly people use complex baseband samples. In C++ code in GR their
data type is gr_complex which is a wrapper for std::complexfloat.
¿How obtain the samples of input used in the test of LTE?
To get those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alexander,
I'll try to give you some answers.
1. Are there working examples for producing 3G, UMTS, LTE, WiMAX
signals etc.? Are there implementations including MAC layer
support?
gr-lte might be interesting for you, if a PHY layer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Florian,
the generic implementation serves 2 purposes, at least in my opinion.
Firstly, in case the necessary hardware extension is not available on
the target hardware, there is a backup default.
Secondly, the generic implementation is usually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Winston,
please have a look at the file 'python/bch_viterbi_vfvb.py' and remove
the string parameter from all the blocks [1]. I added an extra feature
to my GR install and it gets you into trouble now.
The idea behind this parameter was to give
passas wrote:
Hi Johannes,
Sorry for not mentioned the versions. GNU Radio 3.7.2.1 gr-lte
branch-master, latest commit
3ded865f40cc43224eca66a6692fa90655a25b62 Ubuntu 13.04 64-bit
Virgilios
Στις 8:24 μ.μ. Πέμπτη, 13 Φεβρουαρίου 2014, ο/η Johannes Demel
uf...@student.kit.edu έγραψε
101 - 200 of 241 matches
Mail list logo
