Re: [Discuss-gnuradio] Inquiry about USRP GNU Radio

[George Nychis]

If there was a MIMO project on CGRAN you can find it archived still:
https://web.archive.org/web/20140822005337/https://www.cgran.org/

I need to just link to this on the explanation...
On Oct 28, 2014 9:19 PM, "이재훈"  wrote:

> Dear
>
>
>
>
>
> Hi, my name is jaehoon Lee and a graduate student at Seoul National
> University in South Korea.
>
>
>
> Recently, I heard that CGRAN site is closed. I was so surprised because it
> is so famous GNU RADIO site.
>
>
>
> I want to experiment using USRP N210 with XCVR240 dautherboard. Could you
> give me some example code or project about MIMO transmission?
>
>
>
> By using 4 USRPs, 2 USRPs will be transmitter and 2 USRP will be
> receivers.
>
>
>
> Thanks for reading my request.
>
>
>
> Best regards
>
>
>
>
>
> Jaehoon Lee
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] installing gnuradio and additional projects

[Rachel Citchlow]

Hello all,
I have installed gnuradio using build-gnuradio. How do I go about gr-drm or
another project that is not there by detault?
If i use pybombs, it brings in source code for all the dependencies. Is
this the right way to bring in gr-drm?
thanks
Rachel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] serial port source/sink

[Marcus Müller]

Agreed, but as soon as device setup is through with your device (thus
the "properly configured character device") and your reading program
behaves nicely (which I'd expect GR's file_sink to do), just reading
from a character device should work, if I'm not mistaken.

However, this brings us to a new question: "serial" doesn't really say
what kind of interface we're talking about; there's a whole lot of bytes
that you can not send over a 1980's style UART as used for the RS-232
peripheral on PCs, and thus the data that comes in over that has to be
decoded first; you could write a block that converts these bytes to
bytes, or, and this is more likely, you already have software that does
that, and writes the result to a file, or prints it on standard output.
You could then connect the output of that to GNU Radio, e.g. using a
named pipe.

On 29.10.2014 00:21, Marcus D. Leech wrote:
> On 10/28/2014 06:34 PM, Marcus Müller wrote:
>> Hi Julian,
>> this really depends on how your serial data gets into your PC, but
>> assuming you're on linux and have the data coming in over a properly
>> configured character device (ie. something that appears as /dev/ttyS*
>> or the like), you could just use the file source and open that device.
>>
>> Greetings,
>> Marcus
> TTY I/O on Unix is a bit weird.  You'd have to open it, and configure
> it (into RAW mode for one).
>
>
>> On 28.10.2014 19:35, Julián Andrés Quenardelle wrote:
>>> Hey there! i'm working on a proyect of comunications and i need to
>>> get my
>>> serial data stream into gnuradio companion, so i'm looking for a
>>> block (2
>>> actually) that can make this work, i tried to install pyserial and
>>> gr-pyserial but repository is down, so i'm looking for alternatives,
>>> that
>>> make me skip programming it myself (becoues of my low programing
>>> skills ),
>>> so i though serial port is pretty comun, some one else had to build it
>>> before, if you know some blocks which could help me i would be very
>>> thankfull
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] serial port source/sink

[Marcus D. Leech]

On 10/28/2014 06:34 PM, Marcus Müller wrote:

Hi Julian,
this really depends on how your serial data gets into your PC, but 
assuming you're on linux and have the data coming in over a properly 
configured character device (ie. something that appears as /dev/ttyS* 
or the like), you could just use the file source and open that device.


Greetings,
Marcus
TTY I/O on Unix is a bit weird.  You'd have to open it, and configure it 
(into RAW mode for one).




On 28.10.2014 19:35, Julián Andrés Quenardelle wrote:

Hey there! i'm working on a proyect of comunications and i need to get my
serial data stream into gnuradio companion, so i'm looking for a block (2
actually) that can make this work, i tried to install pyserial and
gr-pyserial but repository is down, so i'm looking for alternatives, that
make me skip programming it myself (becoues of my low programing skills ),
so i though serial port is pretty comun, some one else had to build it
before, if you know some blocks which could help me i would be very
thankfull



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] serial port source/sink

[Marcus Müller]

Hi Julian,
this really depends on how your serial data gets into your PC, but
assuming you're on linux and have the data coming in over a properly
configured character device (ie. something that appears as /dev/ttyS* or
the like), you could just use the file source and open that device.

Greetings,
Marcus
On 28.10.2014 19:35, Julián Andrés Quenardelle wrote:
> Hey there! i'm working on a proyect of comunications and i need to get my
> serial data stream into gnuradio companion, so i'm looking for a block (2
> actually) that can make this work, i tried to install pyserial and
> gr-pyserial but repository is down, so i'm looking for alternatives, that
> make me skip programming it myself (becoues of my low programing skills ),
> so i though serial port is pretty comun, some one else had to build it
> before, if you know some blocks which could help me i would be very
> thankfull
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: QTGui Number Sink, Demodulation Problems

[Jason Noble]

Tom,

Thanks for the quick bug fix Re: the number sinks. In the interim I've been
troubleshooting by dumping output to a binary file and discovered other
mistakes on my part. But once again I'm at an impasse. I captured some data
which I view in the terminal using xxd -b filename.

The interesting thing is that the first portion of the file is all 1's
"  ", which is the correct output that I'm looking for.
However, it transitions to outputting "0101 0101 0101" and stays with that
output apparently indefinitely. Could this in some way be caused by the
Polyphase Clock Sync?

Thanks,
-Jason


On Fri, Oct 17, 2014 at 1:56 AM, Tom Rondeau  wrote:

> On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble 
> wrote:
>
>>
>> The purpose of my current experiments is to create a 16QAM transmitter
>> and receiver, with UDP sources/sinks, and using bladeRFx40's to
>> transmit/receive.
>>
>> I'm using Number sinks to check values at various points of my flowgraph.
>> If I use a constant source value of 1, a float input type to a Number sink
>> displays a "1", but a byte input type displays a "0". This is problematic
>> because I'm trying to troubleshoot the QAM demodulator which has an output
>> type of byte.
>>
>> I've got Number sinks throughout the flowgraph. The source, modulator,
>> and polyphase clock all output correct values for samples/symbols of ""
>> but the demodulator is giving outputs of "0".
>>
>> Are these bugs, or am I doing something wrong?
>> Also, I tried replacing the QAM mod/demod blocks with 8PSK blocks and
>> still have the save problem.
>>
>> Thanks in advance for any assistance.
>>
>
> Yeah, this was a bug. Looks like a very stupid mistake on my part.
>
> I've pushed a fix that mostly works, but we can't really fix it without
> breaking the api. It should work fine now for char, short, and float
> inputs. There's a note in the block's documentation about this.
>
> Tom
>
>


qam16_txrx_polyphase_debug.grc
Description: application/gnuradio-grc


sample-16qamdump.bin
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] skiphead block with reset

[Anderson, Douglas J.]

Thanks for this, your git-fu is much stronger than mine!

I wonder why the mutator func for d_nitems didn't make it into the current 
version. At least for me, it's really useful to have.

Anyway, looks like it won't be too bad to graft in. Thanks again.

-Doug

From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
Michael Berman [mrberma...@gmail.com]
Sent: Tuesday, October 28, 2014 12:12 PM
To: Martin Braun
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] skiphead block with reset

Taking a quick look at a branch of that hash tag, the Reset function simply 
sets d_nitems = 0.  There are 4 helper functions within the Skip Head block of 
old that are not in the current one; namely setting the number of items to 
skip, checking how many items are to be skipped, checking how many items have 
currently been skipped, and resetting the block.  The code below is from the 
hash tag given, and should be trivial to implement into the current block (the 
variable names are even still the same).

void
gr_skiphead::set_nitems_to_skip(uint64_t nitems_to_skip)
{
  d_nitems_to_skip = nitems_to_skip;
  reset();
}

uint64_t
gr_skiphead::nitems_to_skip() const
{
  return d_nitems_to_skip;
}

uint64_t
gr_skiphead::nitems_skiped() const
{
  return d_nitems;
}

void
gr_skiphead::reset()
{
  d_nitems = 0;
}

Michael Berman

On Tue, Oct 28, 2014 at 10:59 AM, Martin Braun 
mailto:martin.br...@ettus.com>> wrote:
Doug,

that commit is in master. Note that it's old, and committed *before* the
3.7 API change, so the changes are moved to the corresponding new block
in gr-blocks.

M

On 10/28/2014 06:54 PM, Anderson, Douglas J. wrote:
> Hi all,
>
> I was looking into the possibility of adding a reset ability (ala the
> head block) to skiphead.
>
> In my search to find out if it had already been done, I came up with
> this commit message:
>
> commit 9aabbe0601919c9fecd46e4e418e5c94183fca45
> Author: Tom Rondeau mailto:trond...@vt.edu>>
> Date:   Thu Jul 5 22:01:45 2012 -0400
>
> core: adding ability to change and reset skiphead parameters.
>
> But I couldn't find that capability or commit in the current github code.
>
> Does anyone have a hint at where I could find that modification or,
> barring that, any hints on how to accomplish it myself? I'm hoping it
> will be as straightforward as pull the reset bits from the head block.
>
> -Doug
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hierarchical Block in c++ not working, linker or swig problem

[Julius Durst]

Hi list.

I am trying to write a hierarchical block in c++ in an OOT module.
I create the block with the gr_modtool and try to make a very simple 
hier block. The only relevant changes to the template are:


in the ...impl.cc:

#include 
...
testhier::make()... unchanged
...
gr::blocks::copy::sptr copy(gr::blocks::copy::make(sizeof(gr_complex)));
connect(self(), 0, copy, 0);
connect(copy, 0, self(), 0);

testhier_impl::testhier_impl()
  : gr::hier_block2("testhier",
  gr::io_signature::make(1, 1, sizeof(gr_complex)),
  gr::io_signature::make(1, 1, sizeof(gr_complex)))
  {
gr::blocks::copy::sptr 
copy(gr::blocks::copy::make(sizeof(gr_complex)));

connect(self(), 0, copy, 0);
connect(copy, 0, self(), 0);
  }

So this should be the quite simplest form of a hier block. However, the 
following wierdnesses occur:


On Ubuntu:
make is successful
If I import the module in python, I get a segmentation fault. As far as 
I got with gdb, the error may be somewhere in swig.
However, if I first do "from gnuradio import blocks", the import is 
successful, but the module only contains the python blocks, all c++ 
blocks are missing.
When I only use a block from the same OOT module in the hier block, the 
import also is successful, but again the c++ blocks are missing.


On arch linux:
make fails with a linker error:
undefined reference to `gr::blocks::copy::make(unsigned long)'
However if I only use a block from the same OOT module in the hier 
block, the whole thing seems to work.



What am I doing wrong? Did I forget to include something? Can it be that 
hard to make a c++ hier block?


Thanks for your help

Julius

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] serial port source/sink

[John Malsbury]

Also, I just checked. The repo works fine through https but not ssh...
:shrugs:



On Tue, Oct 28, 2014 at 11:41 AM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:

> I can look into my repos.  Those blocks were meant for a customer who
> specifically had to interact with a GR app through serial, due to legacy
> interfaces/software.  This allow them the interface to a GNU Radio app
> through virtual serial connections (ie. SOCAT), just as if they were
> connected to an 90's vintage radio.
>
> Is there a specific reason you want to do this through serial?  Can you
> explain your architecture?
>
> -John
>
>
>
> On Tue, Oct 28, 2014 at 11:35 AM, Julián Andrés Quenardelle <
> julian.quenarde...@gmail.com> wrote:
>
>> Hey there! i'm working on a proyect of comunications and i need to get my
>> serial data stream into gnuradio companion, so i'm looking for a block (2
>> actually) that can make this work, i tried to install pyserial and
>> gr-pyserial but repository is down, so i'm looking for alternatives, that
>> make me skip programming it myself (becoues of my low programing skills ),
>> so i though serial port is pretty comun, some one else had to build it
>> before, if you know some blocks which could help me i would be very
>> thankfull
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] serial port source/sink

[John Malsbury]

I can look into my repos.  Those blocks were meant for a customer who
specifically had to interact with a GR app through serial, due to legacy
interfaces/software.  This allow them the interface to a GNU Radio app
through virtual serial connections (ie. SOCAT), just as if they were
connected to an 90's vintage radio.

Is there a specific reason you want to do this through serial?  Can you
explain your architecture?

-John



On Tue, Oct 28, 2014 at 11:35 AM, Julián Andrés Quenardelle <
julian.quenarde...@gmail.com> wrote:

> Hey there! i'm working on a proyect of comunications and i need to get my
> serial data stream into gnuradio companion, so i'm looking for a block (2
> actually) that can make this work, i tried to install pyserial and
> gr-pyserial but repository is down, so i'm looking for alternatives, that
> make me skip programming it myself (becoues of my low programing skills ),
> so i though serial port is pretty comun, some one else had to build it
> before, if you know some blocks which could help me i would be very
> thankfull
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] serial port source/sink

[Julián Andrés Quenardelle]

Hey there! i'm working on a proyect of comunications and i need to get my
serial data stream into gnuradio companion, so i'm looking for a block (2
actually) that can make this work, i tried to install pyserial and
gr-pyserial but repository is down, so i'm looking for alternatives, that
make me skip programming it myself (becoues of my low programing skills ),
so i though serial port is pretty comun, some one else had to build it
before, if you know some blocks which could help me i would be very
thankfull
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CPU Affinity vs Hier Blocks

[Iain Young, G7III]

Hi Folks,

A quick question on CPU affinity when using hier blocks. I can set the
affinity in each of the blocks that makes up the heir block, but I can
also set it once I instantiate my hier block in my main flowgraph.

Anyone know the behaviour in this case ? If I leave all the blocks
within the heir block with no CPU affinity defined, will they inherit
what I configure in the heir block itself ?

If I put a CPU affinity on those blocks within the heir block, I guess
that would be honoured over what I configure for the hier block itself ?

Can anyone confirm ? I'm doing some multiple frequency RX, with
identical receive chains, which I'd like to put into a hier block, thus
simplifying my main flowgraph, but keep all processing for that chain on
one CPU


Iain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] skiphead block with reset

[Anderson, Douglas J.]

Hi all,

I was looking into the possibility of adding a reset ability (ala the head 
block) to skiphead.

In my search to find out if it had already been done, I came up with this 
commit message:

commit 9aabbe0601919c9fecd46e4e418e5c94183fca45
Author: Tom Rondeau 
Date:   Thu Jul 5 22:01:45 2012 -0400

core: adding ability to change and reset skiphead parameters.


But I couldn't find that capability or commit in the current github code.

Does anyone have a hint at where I could find that modification or, barring 
that, any hints on how to accomplish it myself? I'm hoping it will be as 
straightforward as pull the reset bits from the head block.

-Doug
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] skiphead block with reset

[Michael Berman]

Taking a quick look at a branch of that hash tag, the Reset function simply
sets d_nitems = 0.  There are 4 helper functions within the Skip Head block
of old that are not in the current one; namely setting the number of items
to skip, checking how many items are to be skipped, checking how many items
have currently been skipped, and resetting the block.  The code below is
from the hash tag given, and should be trivial to implement into the
current block (the variable names are even still the same).

void
gr_skiphead::set_nitems_to_skip(uint64_t nitems_to_skip)
{
  d_nitems_to_skip = nitems_to_skip;
  reset();
}

uint64_t
gr_skiphead::nitems_to_skip() const
{
  return d_nitems_to_skip;
}

uint64_t
gr_skiphead::nitems_skiped() const
{
  return d_nitems;
}

void
gr_skiphead::reset()
{
  d_nitems = 0;
}

Michael Berman

On Tue, Oct 28, 2014 at 10:59 AM, Martin Braun 
wrote:

> Doug,
>
> that commit is in master. Note that it's old, and committed *before* the
> 3.7 API change, so the changes are moved to the corresponding new block
> in gr-blocks.
>
> M
>
> On 10/28/2014 06:54 PM, Anderson, Douglas J. wrote:
> > Hi all,
> >
> > I was looking into the possibility of adding a reset ability (ala the
> > head block) to skiphead.
> >
> > In my search to find out if it had already been done, I came up with
> > this commit message:
> >
> > commit 9aabbe0601919c9fecd46e4e418e5c94183fca45
> > Author: Tom Rondeau 
> > Date:   Thu Jul 5 22:01:45 2012 -0400
> >
> > core: adding ability to change and reset skiphead parameters.
> >
> > But I couldn't find that capability or commit in the current github code.
> >
> > Does anyone have a hint at where I could find that modification or,
> > barring that, any hints on how to accomplish it myself? I'm hoping it
> > will be as straightforward as pull the reset bits from the head block.
> >
> > -Doug
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] skiphead block with reset

[Martin Braun]

Doug,

that commit is in master. Note that it's old, and committed *before* the
3.7 API change, so the changes are moved to the corresponding new block
in gr-blocks.

M

On 10/28/2014 06:54 PM, Anderson, Douglas J. wrote:
> Hi all,
> 
> I was looking into the possibility of adding a reset ability (ala the
> head block) to skiphead.
> 
> In my search to find out if it had already been done, I came up with
> this commit message:
> 
> commit 9aabbe0601919c9fecd46e4e418e5c94183fca45
> Author: Tom Rondeau 
> Date:   Thu Jul 5 22:01:45 2012 -0400
> 
> core: adding ability to change and reset skiphead parameters.
> 
> But I couldn't find that capability or commit in the current github code.
> 
> Does anyone have a hint at where I could find that modification or,
> barring that, any hints on how to accomplish it myself? I'm hoping it
> will be as straightforward as pull the reset bits from the head block.
> 
> -Doug
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio over Zynq

[Jonathon Pendlum]

I know we have been talking over email, but I wanted to post this for
everyone to see.

The Zynq build wiki has gotten a little out of date and over the next few
weeks I'll be updating it to fix various issues that have been brought up.
As well, there has been a lot great work on the Open Embedded side that
makes building images even easier, so expect a rather large update to the
wiki.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Gnuradio-over-Zynq-tp51051p51061.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] rational_resampler vs pfb_arb_resampler filter design -- why such strange cut frequencies in both cases?

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 23.10.2014 01:39, Lev Serebryakov wrote:

> (1) Why rational resampler doesn't take decimation in account when 
> calculates bandwidth? It design filter which will correctly reject
> all images in upsample, but looks like aliasing is possibly when
> effective ratio is less than 1, as only interpolation is used in
> bandwidth calculation and resulting filter "effectively" works at
> upsampled rate.
 Here I'm right, according to other thread.

> (2) Why arbitrary resampler set Fs to number of filters and AFTER 
> that pass bandwidth numbers as normalized to 1, not to this Fs?!
> 0.3 is perfectly good (may be slighly conservative, but Ok)
> transition band center, but in this case this 0.3 will be taken for
> FS=1, and here FS=32 (number of filters) is used, so it will be 32
> times too low (!).
 And here I'mn wrong, and code is right, as filter effectively work
and "higher" frequency and all frequencies should be properly scaled.

- -- 
// Black Lion AKA Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUT4WZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePvfAQAIljuBr95qllFCA49uBqTtjQ
sZq9bCrTR+gYfrNgPEb10GO/8981cmN+4eJFEiJRPVf9g5I1uSqa0vDiqPuyDXCQ
DQIxbsvGi+F82FpWEZRm3OWuoYHoY/MNm+T8evkOL+LKG4Fo7ohgFghDnZ6csaY/
0h0BLFUkBV9cGW2Havy0RWR5QZoRQnc9ATwUdYuVY7HeIbFKET3E+IJp36yC82lc
yyMRfneCTvHuMC59M4OO138ZmXkL4h+OptdQKd094IVNlpMEJyw0q+XQFukSj/RD
t+gx3tPNgW9uII7syUYk11ASmZc17NcFQEdSoEIuRNdhkp3UzEeCSUMrRk1DN+ki
HiZcMDJ4rWXhKv7hJ8QIhcvQOmHxjnqV0izjir6YChIKbibp8pSRajoL2jRm5726
MoezAPmG5jmAuqaw0nacXgIZCombMWNS7KQkn901VKBDypGpRCdS/GUi7bvmOhB/
PEEvL51grQ6pCXgUnnJ2rYlEKmBlPxIU8CAmGxUW5oEWnr2TLnFc9X27bFiTsS0I
y2pLqhCOzaCzKxL+Et0mZM/7eof932DNnoesjqw/VBGDlDZPPc8+svlwHn7KjiVY
Go3AcqUzIfVED1MkZGs9wgWzaQJX7bS9jdQPy5mhJfcs5/cUdN4BWV0VLcq2yeew
wjVJtxt1ReS3OaXy7bDX
=hyaw
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 28.10.2014 14:47, Andy Walls wrote:

> Right, or something similar.  Basically design_filter() should
> design the narrower of the required anti-image postfilter or
> anti-alias prefilter.
> 
> Section 12.6 on page 691 of this book has a nice explanation: 
> http://www.ece.rutgers.edu/~orfanidi/intro2sp/ 
> http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf
> 
> I'll submit a bug to the issue tracker.
 So, I'm not mad, and understand this problem right (see my message
without answer with subject "rational_resampler vs pfb_arb_resampler
filter design -- why such strange cut frequencies in both cases?"), good.

- -- 
// Black Lion AKA Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUT4VQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePlOkP/2bV9N3BYUv3PD8lkw+p9fe9
HQ1p9mnwuKOkhOulZK4bA2Nd00/KsnpsBQ1kNtSdCiH5ikkbvIXNgPvSjXi/5U5I
0kFypk75TAI7Lubvzv9+uoIP3N2CenpbfYv9d1UhYoZA+agdk3aO4vwi1HpcmVwP
DG1SOmpmqNFPh0cVEaF35AuOCFdm1ieLwHQjloBA1uh8IyeMNvpons7upPVmUWOq
Bb2NyuidftOzc8zDtw/GJ2rDMp/MAJuZthoRKE9wZ+3IP7ellec0n+B6bNCnqGAR
aP094kdYgRkd7ydDX9lXRuE3ponSgOILbYQfKrdYtIxfEiTBVgyr6VxNOEXMt5jx
QOqSx1/GT9i7j94mZwOLGU03G2DrgzhhTBJLK9EyLTrOrGb63oa5vUn8Qil3cQna
F3aDEV/x5MwuN/Yhq8h6Vx6uvqIrsoke90kHty0bmuczk4DTMeF0Iy7kAYHKNhq3
jl/urV4eKGYBFjFUTUGFW93BNXjNUsiFM1kMNAmXRbvSlMr33kKAso4tHl+1SmSn
8uj7rVbNrJNa8Cn7Y96GcccVGDpKENXslNj0HtpL+86VhyR9PrBytesBFJVbWFh6
nh3mhD2NZXCEA4T0fKRZNiD2+Sc2M1nDGFrueyD3yfzYheTMW4IbOIKZK9/tDWxa
c5RMvdetxkJb0xE1LMxv
=bZiC
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [UHD 3.8.0] Release Announcement

[Martin Braun]

Hello lists,

at this point, we are releasing our UHD version 3.8.0. There were some
minor changes since the release candidate, but mainly regarding
documentation, the Boost version and minor build fixes to make sure UHD
works on all platforms.

You can get this release by either pulling master branch, or checking
out the release's tag:
https://github.com/EttusResearch/uhd/tree/release-003_008_000

If you haven't pulled master for a while, it will be a huge diff (might
take a bit, don't worry). A couple of notes on this release:

- We have reorganized the firmware and fpga subdirectories. The former
was simply moved around, but the latter is now a git submodule. Run 'git
submodule init' and 'git submodule update' if you want to read and
change the fppga source code. As a result, the source tarballs will be
much smaller.
- B200 updates: We've fixed the issue with B200 rapidly losing
connection on some devices (this particular issue never existed on
maint, but for a while it was in master). The reason was the version of
the SDK we used to compile the firmware. Altogether, B200 initialization
is now much faster.
- E310: This release includes support for our upcoming embedded device.
News on the actual device will follow in the near future, so please be
patient.
- CMake improvements: Among some fixes, we now distribute a
UHDConfig.cmake file which you can use to more easily build applications
linking to UHD. We provide an example on how to do that in
host/examples/init_usrp/.

We will be resetting maint branch to master soon. From then on, the
development will happen as usual:
- All bug fixes go into maint. This branch can be considered 'stable'.
- New features etc. go into master. This branch should be considered
'unstable'.

Binary installers will follow this week.
More features and products are coming up!

Cheers,
Martin

## Changelog for 3.8.0
* Added E310 support
* B200/B210: Moved AD9361 controls from firmware to host
* Added several tools: ZPU dissector, improved CHDR dissector,
  kitchen sink, B200/B210 USB debugging utility, latency
  measurement tool.
* Reorganized firmware/ directory structure. Refactored some
  firmware.
* Removed FPGA sources, is now in own repository (submoduled).
* Cleaned up command line arguments for some tools
* Added math namespace, plus a unified float comparison infrastructure
* Fixed tuning-related bugs
* Moved manual over to Doxygen, also several manual bug fixes and
  amendments
* Added many missing virtual destructors (less build warnings)
* Added support for NI-RIO 14.0
* X300 fixes: Not found over PCIe with no eth interfaces
* CMake improvements: Now comes with own UHDConfig.cmake and example
  to build standalone UHD apps, build fixes on Apple, interoperability
  with GNU Radio
* OctoClock fixes and improvements: Ethernet initialization, external
  ref detection, stability fixes, host driver (UHD can now talk to
  OctoClock)
* Examples: Improved GPIO example, rx_samples_to_file
* Bumped minimum Boost version to 1.46


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

[Jeff Long]

On 10/28/2014 07:47 AM, Andy Walls wrote:


From:
Jeff Long
Subject:
Re: [Discuss-gnuradio] Filter in
rational resampler
Date:
Tue, 28 Oct 2014 04:31:30 -0400


On Oct 27, 2014 6:36 PM, "Jeff Long"  wrote:


On 10/27/2014 04:40 PM, Andy Walls wrote:


On Thu, 2014-07-31 at 12:01 -0400, address@hidden
wrote:


Message: 5
Date: Wed, 30 Jul 2014 18:42:14 +0200
From: Daniele Nicolodi 
To: GNURadio 
Subject: [Discuss-gnuradio] Filter in rational resampler

Hello,

I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a

doubt

about the low pass filter generated by the design_filter()

function.


It seems that the generated filter does not take into account the
decimation factor. Is that correct? I don't see how this may

result in

the correct anti-aliasing filter when it is applied by
rational_resampler_base_xxx.

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,
Daniele



Daniele,

I just had occasion to use the rational resampler for a 25 Ksps ->

16

Ksps resampling and low-pass filtering all in one step, with a LPF

that

cut off frequencies higher than 3000 Hz.  I started by using this
_expression_ for the taps, following the filter design in
gr-filter/python/rational_resampler.py:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0,

500.0/16.0, filter.firdes.WIN_KAISER, 5.0)


That filter only includes the interpolation factor, 16.0, and

seemed to

do the wrong thing.  The FFT scope showed the rolloff started at

around

~4700 Hz, about 25/16 * 3000 Hz.

This _expression_ for the taps, which included the decimation

factor of

25.0, appeared to do the right thing:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0,

500.0/25.0, filter.firdes.WIN_KAISER, 5.0)



Can someone else take a closer look at
gr-filter/python/rational_resampler.py and confirm it is doing the

wrong

thing?

Regards,
Andy



It looks like the default filter is only valid where interp > decim,

and it's not really meant to have an arbitrary cutoff. As Daniele
pointed out, decim is not taken into account.


I think that 'interpolation' in design_filter() should be replaced

with 'max(interpolation,decimation).


Right, or something similar.  Basically design_filter() should design
the narrower of the required anti-image postfilter or anti-alias
prefilter.

Section 12.6 on page 691 of this book has a nice explanation:
http://www.ece.rutgers.edu/~orfanidi/intro2sp/
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf

I'll submit a bug to the issue tracker.


Andy,

I already put a bug report in last night. Fix default filter, plus maybe 
documentation of what user taps really means.


- Jeff




  If taps are supplied by the caller, it needs to understand how the
taps will be used.


Andy, to mimic design_filter, you'd need to do:

   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)

Not that I know if that's right, but that's what design_filter()

does.



Andy, ignore that last part. Your params are right and that filter
actually makes sense.


Yeah.  I experimentally knew what I had was right.  I just needed to go
back and confirm it, by reading my Orfanidis book to refresh my memory
on what I learned over 17 years ago. :P

FWIW, after the upsampling, for my specific case, the Fs of the filter
is 16 * 25000 sps.  So to get my desired 3000 Hz cutoff, which is
narrower than both the required anti-image and anti-alias filter
cutoffs, I should have used:

  low_pass(16.0, 16.0*25000.0, 3250.0, 500.0, ...)

but

  low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, ...)

is equivalent.


  The filter is applied after interp and before decim, which is not
obvious from the API.

- Jeff


Thanks for looking at this!

Regards,
Andy





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

[Andy Walls]

From: 
Jeff Long
Subject: 
Re: [Discuss-gnuradio] Filter in
rational resampler
Date: 
Tue, 28 Oct 2014 04:31:30 -0400

> On Oct 27, 2014 6:36 PM, "Jeff Long"  wrote:
> >
> > On 10/27/2014 04:40 PM, Andy Walls wrote:
> >>
> >> On Thu, 2014-07-31 at 12:01 -0400, address@hidden
> >> wrote:
> >>
> >>> Message: 5
> >>> Date: Wed, 30 Jul 2014 18:42:14 +0200
> >>> From: Daniele Nicolodi 
> >>> To: GNURadio 
> >>> Subject: [Discuss-gnuradio] Filter in rational resampler
> >>>
> >>> Hello,
> >>>
> >>> I was studying the code of the rational resampler block in
> >>> gnuradio/gr-filter/pythoin/rational_resampler.py and I have a
> doubt
> >>> about the low pass filter generated by the design_filter()
> function.
> >>>
> >>> It seems that the generated filter does not take into account the
> >>> decimation factor. Is that correct? I don't see how this may
> result in
> >>> the correct anti-aliasing filter when it is applied by
> >>> rational_resampler_base_xxx.
> >>>
> >>> Can someone point me to a relevant explanation?
> >>>
> >>> Thanks a lot. Cheers,
> >>> Daniele
> >>
> >>
> >> Daniele,
> >>
> >> I just had occasion to use the rational resampler for a 25 Ksps ->
> 16
> >> Ksps resampling and low-pass filtering all in one step, with a LPF
> that
> >> cut off frequencies higher than 3000 Hz.  I started by using this
> >> _expression_ for the taps, following the filter design in
> >> gr-filter/python/rational_resampler.py:
> >>
> >> filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0,
> 500.0/16.0, filter.firdes.WIN_KAISER, 5.0)
> >>
> >> That filter only includes the interpolation factor, 16.0, and
> seemed to
> >> do the wrong thing.  The FFT scope showed the rolloff started at
> around
> >> ~4700 Hz, about 25/16 * 3000 Hz.
> >>
> >> This _expression_ for the taps, which included the decimation
> factor of
> >> 25.0, appeared to do the right thing:
> >>
> >> filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0,
> 500.0/25.0, filter.firdes.WIN_KAISER, 5.0)
> >>
> >>
> >> Can someone else take a closer look at
> >> gr-filter/python/rational_resampler.py and confirm it is doing the
> wrong
> >> thing?
> >>
> >> Regards,
> >> Andy
> >
> >
> > It looks like the default filter is only valid where interp > decim,
> and it's not really meant to have an arbitrary cutoff. As Daniele
> pointed out, decim is not taken into account.
> >
> > I think that 'interpolation' in design_filter() should be replaced
> with 'max(interpolation,decimation).

Right, or something similar.  Basically design_filter() should design
the narrower of the required anti-image postfilter or anti-alias
prefilter.

Section 12.6 on page 691 of this book has a nice explanation:
http://www.ece.rutgers.edu/~orfanidi/intro2sp/
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf

I'll submit a bug to the issue tracker.

>  If taps are supplied by the caller, it needs to understand how the
> taps will be used.
> >
> > Andy, to mimic design_filter, you'd need to do:
> >
> >   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)
> >
> > Not that I know if that's right, but that's what design_filter()
> does.
> >
> Andy, ignore that last part. Your params are right and that filter
> actually makes sense.

Yeah.  I experimentally knew what I had was right.  I just needed to go
back and confirm it, by reading my Orfanidis book to refresh my memory
on what I learned over 17 years ago. :P

FWIW, after the upsampling, for my specific case, the Fs of the filter
is 16 * 25000 sps.  So to get my desired 3000 Hz cutoff, which is
narrower than both the required anti-image and anti-alias filter
cutoffs, I should have used:

 low_pass(16.0, 16.0*25000.0, 3250.0, 500.0, ...)

but 

 low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, ...)

is equivalent.

>  The filter is applied after interp and before decim, which is not
> obvious from the API.
> 
> - Jeff

Thanks for looking at this!

Regards,
Andy



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

On 28/10/14 11:54, Martin Braun wrote:
> On 10/28/2014 12:58 AM, Daniele Nicolodi wrote:
>> This is to inform you that I'm giving up trying to transition the swig
>> bindings to generate builtin classes. I may revisit this decision if
>> I'll get encouraging answers from swig developers on the swig mailing
>> lists, but I believe this is very unlikely.
>>
>> While the changes to the interface definition files are nominally
>> extremely small, I'm hitting bugs in swig that make the exercise
>> extremely painful and I fear impossible without patching swig itself.
>> I also fear that no matter what I can do, the binding egenrated are
>> going to stay sub-optimal due to intrinsic limitations of swig.
>>
>> I prefer to spent my spare time doing something more rewarding that
>> fighting an under documented, inconsistent, and buggy system.
> 
> Thanks for trying. Can't blame you for being fed up with SWIG.

It is not that I'm fed up, it is simply that SWIG cannot do what I would
like it to do. To help others that may venture down the same route, I
think the decision has to be better circumstanced.

The first road block I encountered is the fact that there is a bug in
SWIG that prevents to mix the -builtin (to enable the generation of
nicer python builtin objects instead of the usual abomination) and the
-keyword parameter (to enable calling the generated methods with keyword
arguments) when wrapping std::vector template instances. The generated
C++ simply does not compile.

Part of the problem comes from the fact that the C++ code SWIG generates
to wrap std::vector uses overloaded methods, and SWIG refuses to enable
keywords arguments for those. From there things are very brittle and
breaks in numerous ways.

By accident I found out that keyword arguments can be enabled and
disabled for specific classes (this is AFAIK undocumented), therefore
the problem could be in principle be circumvented adding some additional
SWIG directives to the interface description files.

The second road block is related to the first: the make() method of many
GNURadio blocks is an overloaded method, and for those SWIG refuses to
enable keywords arguments. For some reason keywords arguments work
anyway when bindings are generated without the -builtin option, but do
not work with it. Looking at the generated C++ code, it seems that
keywords arguments are enabled in some layers of the wrapping code, but
disabled where it matters.

A solution would be to give up the use of keyword arguments to method
calls, but I think this would be loosing a nice feature, just for a
limitation of a stupid tool.

While fixing SWIG is probably non trivial but possible, I don't think
that requiring a very recent SWIG would be accepted by the maintainers.
Therefore I decided to give up, the advantages are not worth fighting.

I prefer investing some times to experiment with the idea of generating
Cython wrappers and drop SWIG completely.

Cheers,
Daniele


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Martin Braun]

On 10/28/2014 12:58 AM, Daniele Nicolodi wrote:
> This is to inform you that I'm giving up trying to transition the swig
> bindings to generate builtin classes. I may revisit this decision if
> I'll get encouraging answers from swig developers on the swig mailing
> lists, but I believe this is very unlikely.
> 
> While the changes to the interface definition files are nominally
> extremely small, I'm hitting bugs in swig that make the exercise
> extremely painful and I fear impossible without patching swig itself.
> I also fear that no matter what I can do, the binding egenrated are
> going to stay sub-optimal due to intrinsic limitations of swig.
> 
> I prefer to spent my spare time doing something more rewarding that
> fighting an under documented, inconsistent, and buggy system.

Thanks for trying. Can't blame you for being fed up with SWIG.

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Usrper Program

[Martin Braun]

On 10/27/2014 08:55 PM, Will Lunden wrote:
> Dear Martin,
> 
> Thanks for clearing that up for me. The problem is, I have inherited
> a variety of python programs which all want to call usrper. Is there
> no currently supported command that works in a similar way?

What tasks do you need from usrper? I believe uhd_usrp_probe replaces
most of its functionality. However, you might not need it at all: With
current UHD, initializing the device will also set it up.

Martin

> 
> Will
> 
>> On Oct 27, 2014, at 3:27 PM, Martin Braun via USRP-users
>>  wrote:
>> 
>>> On 10/27/2014 07:02 PM, Will Lunden via USRP-users wrote: Is this
>>> command no longer included in recent versions of uhd or gnuradio?
>>> Or perhaps I'm missing something very basic?
>> 
>> Will,
>> 
>> usrper has been deprecated a long, long time ago. I would suggest 
>> upgrading your code.
>> 
>> Cheers, Martin
>> 
>> ___ USRP-users mailing
>> list usrp-us...@lists.ettus.com 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

[Jeff Long]

On Oct 27, 2014 6:36 PM, "Jeff Long"  wrote:
>
> On 10/27/2014 04:40 PM, Andy Walls wrote:
>>
>> On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
>> wrote:
>>
>>> Message: 5
>>> Date: Wed, 30 Jul 2014 18:42:14 +0200
>>> From: Daniele Nicolodi 
>>> To: GNURadio 
>>> Subject: [Discuss-gnuradio] Filter in rational resampler
>>>
>>> Hello,
>>>
>>> I was studying the code of the rational resampler block in
>>> gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
>>> about the low pass filter generated by the design_filter() function.
>>>
>>> It seems that the generated filter does not take into account the
>>> decimation factor. Is that correct? I don't see how this may result in
>>> the correct anti-aliasing filter when it is applied by
>>> rational_resampler_base_xxx.
>>>
>>> Can someone point me to a relevant explanation?
>>>
>>> Thanks a lot. Cheers,
>>> Daniele
>>
>>
>> Daniele,
>>
>> I just had occasion to use the rational resampler for a 25 Ksps -> 16
>> Ksps resampling and low-pass filtering all in one step, with a LPF that
>> cut off frequencies higher than 3000 Hz.  I started by using this
>> expression for the taps, following the filter design in
>> gr-filter/python/rational_resampler.py:
>>
>> filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0, 500.0/16.0,
filter.firdes.WIN_KAISER, 5.0)
>>
>> That filter only includes the interpolation factor, 16.0, and seemed to
>> do the wrong thing.  The FFT scope showed the rolloff started at around
>> ~4700 Hz, about 25/16 * 3000 Hz.
>>
>> This expression for the taps, which included the decimation factor of
>> 25.0, appeared to do the right thing:
>>
>> filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0,
filter.firdes.WIN_KAISER, 5.0)
>>
>>
>> Can someone else take a closer look at
>> gr-filter/python/rational_resampler.py and confirm it is doing the wrong
>> thing?
>>
>> Regards,
>> Andy
>
>
> It looks like the default filter is only valid where interp > decim, and
it's not really meant to have an arbitrary cutoff. As Daniele pointed out,
decim is not taken into account.
>
> I think that 'interpolation' in design_filter() should be replaced with
'max(interpolation,decimation). If taps are supplied by the caller, it
needs to understand how the taps will be used.
>
> Andy, to mimic design_filter, you'd need to do:
>
>   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)
>
> Not that I know if that's right, but that's what design_filter() does.
>
Andy, ignore that last part. Your params are right and that filter actually
makes sense. The filter is applied after interp and before decim, which is
not obvious from the API.

- Jeff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Gnuradio over Zynq

[Daniel Camara]

Hi,

   I would like to run the example from the GNURadio adaptation for Zynq (
http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq), but I am not able
to run it, it gives me a coredump.

 I managed to create the bootable card, at least I think so as the example
does not work.

 What I did:

zedboard> cat zedboard.bin > /dev/xdevcfg
zedboard> cat /sys/devices/amba.0/f8007000.ps7-dev-cfg/prog_done
1

zedboard> ./zynq_fir_filter_example
Read the FPGA status...
/sys/devices/amba.0/f8007000.ps7-dev-cfg/prog_done = 1
Setup the driver...
Segmentation fault (core dumped)

zedboard> file zynq_fir_filter_example
zynq_fir_filter_example: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16,
BuildID[sha1]=b241efee0c9289c30bd2c24975a628f74c270b4d, not stripped

zedboard> uname -a
Linux zedboard-zynq7 3.14.2-xilinx #1 SMP PREEMPT Fri Oct 24 09:13:25 CEST
2014 armv7l GNU/Linux

zedboard> # gdb
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-oe-linux-gnueabi".
For bug reporting instructions, please see:
.
(gdb) core core
[New LWP 882]
Core was generated by `./zynq_fir_filter_example'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6eade80 in ?? ()
(gdb) bt
#0  0xb6eade80 in ?? ()
#1  0x966c in ?? ()
#2  0x966c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


The compilation of the example was OK, no error, the compilation and
installation of gr-zynq module, the same.

Have some one else tried this zynq  implementation recently?

-- 
Best regards...

 Daniel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio