Hi Sanjeeb,
it looks like there are some leftover make configuration from an older
bootstrap run on another debian version.
Is there any cause why you need to use a very very very old GNU Radio?
Greetings
Marcus
On 08/21/2013 07:40 AM, sanjeeb wrote:
Hi there,
after ./bootstrap and ./config
Dear All,
I've been trying to investigate how channel estimation works in OFDM based
on the implementation provided in Gnuradio for OFDM transmission. I found
that it was done in the block digital_ofdm_frame_acquisition.cc/h. As I
understand, the digital_ofdm_frame_acquisition::calculate_equalizer
Mohammed,
you should also check the new OFDM implementation (see
examples/ofdm/rx_ofdm.grc and python/digital/ofdm_txrx.py). Much more
modular.
On Wed, Aug 21, 2013 at 11:33:26AM +0200, Mohammed Karmoose wrote:
> However, there are two differences in the implementation in relation to this
> equat
Hi!
I have many sync blocks that work with large fixed size vectors, e.g.
converts one vector of size 12659 to another with size 18353. I have
just multiplied the sizeof(gr_complex) with 12659 and 18353 in the
signature. However, when the flow graph is running, then I get a
warning about paging: t
I am working on a processing multiple signals using a single source block.
The background is below, but I had a couple of high level questions:
- What is the best approach performance wise for selecting multiple ~15khz
channels from a 2mhz+ source block? Is it using a Xlating FIR Filter with a
lo
Hi Luke,
I've found using the FFT blocks are the most cpu efficient way to extract a
channel from the whole 20MHz of the HackRF. Have a look at my latest
Scanoo release built in GRC which uses the 'Keep X in N' block to select
the channel required. There's also a spectrum sense mode which locks
On Wednesday, August 21, 2013, Miklos Maroti wrote:
>
> I have many sync blocks that work with large fixed size vectors, e.g.
> converts one vector of size 12659 to another with size 18353. I have
> just multiplied the sizeof(gr_complex) with 12659 and 18353 in the
> signature. However, when the f
Yes, this is what I am doing, but it is not very nice, and you cannot
easily mix in blocks that want to work at the stream level. What
really bugs me that I think the scheduler could figure all out, and
treat my vectors as a stream, allocate nice buffers (who cares if the
vector fits in the buffer
Yes, this is what I am doing, but it is not very nice, and you cannot
easily mix in blocks that want to work at the stream level. What
really bugs me that I think the scheduler could figure all out, and
treat my vectors as a stream, allocate nice buffers (who cares if the
vector fits in the buffer
On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote:
> So is there a way to work with large odd length vectors which does not
> have this buffer allocation problem, and does not require padding? It
> seems to me that it could be supported: regular streams but the vector
> size would be ve
Evariste,
you can tx anything that's in digital format. Check out some of the
examples in gr-digital.
MB
On Wed, Aug 21, 2013 at 02:18:17PM -0400, Evariste Some wrote:
> Hi all,
>
> Is it possible to send & receive a character via USRPs?
>
> My curiosity brought me to such thing though my DSP
Mike, does this work with the Funcube Dongle Pro+?
On Thu, Aug 22, 2013 at 4:39 AM, Mike Jameson wrote:
> Hi Luke,
>
> I've found using the FFT blocks are the most cpu efficient way to extract
> a channel from the whole 20MHz of the HackRF. Have a look at my latest
> Scanoo release built in
Hi Vanush,
It uses the gr-osmosdr GRC block and the Funcube Dongle Pro+ is second in
the list of compatible devices so yes it will work:
http://sdr.osmocom.org/trac/wiki/GrOsmoSDR
However, In order to work using the 192KHz bandwidth of the Funcube Pro+
you will need to fiddle with the sample rat
Hi Marcus,
Yes, I understand the page size limitation. However, if your vector is
1234 bytes, then you can happily allocate 4096 size buffer, but the
the block you always give out the multiple of 1234 byes (i.e. 1, 2 or
3 vectors). The address space wrapping would work fine, so the start
of the ve
Hi Martin, Yes, I know of stream tags, but it would just make the
blocks complicated: now I can rely on the fact that data is coming in
a multiple of the vector length. For now, padding solves my immediate
needs, but it is not an ideal solution. Miklos
On Wed, Aug 21, 2013 at 11:18 PM, Martin Brau
15 matches
Mail list logo
