Re: [Discuss-gnuradio] [Discuss-GR] Filter output float to complex

[Michael Dickens]

You're calling the "filter" method with a pointer to a single float
value, but it is expecting an array. See also <
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fir_filter.cc#L111
>. - MLD
On Fri, Jan 5, 2018, at 7:56 PM, Sakthivel Velumani wrote:
> Please check now. I cleaned up the code a bit but don't know what
> wrong with the indentation. It looks ok in my text editor (gedit) but
> bad on GitHub.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Discuss-GR] Filter output float to complex

[Sakthivel Velumani]

Hi Michael,

Please check now. I cleaned up the code a bit but don't know what wrong
with the indentation. It looks ok in my text editor (gedit)but bad on
GitHub.

Best regards
Sakthivel

On 06-Jan-2018 1:21 AM, "Michael Dickens"  wrote:

> Hi Sakthivel - I can't view your Github repo; please recheck it. - MLD
>
> On Fri, Jan 5, 2018, at 8:33 AM, Sakthivel Velumani wrote:
>
> Please find the code here https://github.com/saki92/oqpsk-sync-block . I
> am trying to build a clock sync block for oqpsk with pfb_clock_sync as
> reference. It does not show any error message from Python or C++. The
> flowgraph runs for less than a second and stops. Some times I get a return
> code -11.
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Boost 1.66.0 Compatibility: GNU Radio & Volk & UHD

[Michael Dickens]

I and other MacPorts developers have been testing out boost 1.66.0 for a
while now & it seems very stable. There are a ton of ports that rely on
Boost, and it takes time to go through them to verify that they at least
build & hopefully function too. I expect we'll be updating from 1.65.1
by mid-January, but it really depends on how quickly we can work through
the dependent ports. Cheers! - MLD
On Fri, Jan 5, 2018, at 10:19 AM, Ben Hilburn wrote:
> Thanks so much for the test & report, Mike!
> How are you dealing with this on the packaging side for macOS?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python import error on swig modules

[Michael Dickens]

Hi Sakthivel - It's not clear whether you are trying to test in place
or after "make install" ... clearly you've tried installing, but that
doesn't mean that's the way you're testing. Your info on the install
location & path seems correct; maybe there's an import error in the
compiled SWIG module? You can try manually by doing "import
" directly in Python. This may or not fail. If it does,
one option is to edit the file "/usr/local/lib/python2.7/dist-
packages//_swig.py" and look for the
function "swig_import_helper" for Python >= 2.7.0 (near the top of the
file), and comment out the "try:", "except:", and final function line
("return importlib.import_module('__swig')"). With those
lines commented out, you should see the actual import error. Hope this
helps! - MLD
On Fri, Jan 5, 2018, at 1:13 PM, Sakthivel Velumani wrote:
> I have been trying to do the simplest qa test for my qpsk demod C++
> block from the tutorials. When I run the qa_.py im getting
> an import error: No module named _swig. This happens for
> every C++ blocks.> 
> I can see that _swig.py is being installed into 
> /usr/local/lib/python2.7/dist-
> packages//_swig.py, pyc and .pyo .> And when I 
> checked sys.path in python, I can see the path /usr/local/lib/python2.7/dist-
> packages along with many other paths.> 
> Any help would be appreciated.

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

>1. The gnuradio-runtime propagated tags with double arithmetic; the
>fractional resampler block used mixed float & double arithmetic to
>propagate tags.
>

Oops:

mixed float & double arithmetic to generate output sample intervals.

-Andy

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

Re: [Discuss-gnuradio] Python import error on swig modules

[Cinaed Simson]

On 01/05/2018 10:13 AM, Sakthivel Velumani wrote:
> Hi,
> 
> I have been trying to do the simplest qa test for my qpsk demod C++
> block from the tutorials. When I run the qa_.py im getting
> an import error: No module named _swig. This happens for
> every C++ blocks.
The easiest thing to do is look at one of the build directories for just
about any OOT module - and see how it's done.

The enclosed example script is from gr-lte OOT module.

Note that the

  ./gr-lte/build/swig

directory is in the script's PYTHONPATH, the

  ./gr-lte/build/python

directory is in the script's PATH, and the

  ./gr-lte/build/lib

directory is in the script's LD_LIBRARY_PATH.

-- Cinaed




> 
> I can see that _swig.py is being installed into 
> /usr/local/lib/python2.7/dist-packages//_swig.py,
> pyc and .pyo .
> And when I checked sys.path in python, I can see the path
> /usr/local/lib/python2.7/dist-packages along with many other paths.
> 
> Any help would be appreciated.
> 
> Best regards,
> Sakthivel
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



qa_sync_frequency_c_test.sh
Description: application/shellscript
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote:
> Hi Eugene
> 
> > From:   Eugene Grayver
> > Date:   Thu, 9 Nov 2017 19:52:35 +
> > 
> > There is a major problem with the way tags are propagated in blocks
> > with non-integer relative rate. If the ratio is not a power of two,
> > the numerical accuracy of the floating point will cause the output
> > tags to diverge from the input tags.  Consider the fractional
> > resampler. It accumulates the timing offset in the range of 0 to 1.
> > However tag propagation multiplies the ratio by the sample number.
> > As
> > the sample number grows the LSB accuracy of the ratio gets scaled
> > by
> > the ever larger value. For a ratio of 1.001 we saw divergence of
> > 1000s of samples over a few minutes at 10msps.

OK, I've got a working fix for this:

https://github.com/gnuradio/gnuradio/pull/1543
or
https://github.com/awalls-cx18/gnuradio.git  branch tag_fix4

You will need to install the mpir and mpir-devel packages for your
distro, as this change adds a dependency on the MPIR library
(libmpirxx.so and libmpir.so).

With the attached GRC flowgraph, the fixed code shows no slips after 8
hours of continuous running on a modest laptop.  Compare that with the
baseline of gnuradio master, where after 8 hours, the tags have slipped
5 output samples to the right.

You were right about it being a floating point precision problem, but
the problem with the fractional resampler over short runs was (moslty)
not in the gnuradio runtime, but the fractional resampler block itself:

1. The gnuradio-runtime propagated tags with double arithmetic; the
fractional resampler block used mixed float & double arithmetic to
propagate tags.

2. Floating point reciprocals aren't exact in the lsb's, so specifying
set_relative_rate(1.0/resamp_ratio) was also introducing errors.  I.e.:

[andy@pinto sw]$ ./rational3 1.001
Resample ratio: 1.0009
Resample ratio: 2254051613498933/2251799813685248
Numerator: 2254051613498933
Denominator: 2251799813685248

Relative rate: 0.99900099900099915
Relative rate: 4499100526843653/4503599627370496
Numerator: 4499100526843653
Denominator: 4503599627370496

Notice how the relative rate's numerator and denominator are not the
same as the resample ratio's denominator and numerator.

Geof:

Could you please take a look at the newly added cmake module
FindMPIR.cmake to see if it need changes for the Windows build?


Jeff and Marcus:

I'll address possible solutions for your observations (non-fixed
relative rate and fraction tag offsets) in a separate post.
I have a concept on how to address both, I think, but they can't be on
master branch due to API changes.

Regards,
Andy


tag_prop_test.grc
Description: XML document
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
double resamp_ratio = strtod(argv[1], NULL);
double relative_rate = 1/resamp_ratio;

std::cout.precision(std::numeric_limits::max_digits10);
//-
// Using MPIR's C++ interface
static const mpq_class one_half(1,2);
mpq_class resamp_ratio_q(resamp_ratio);
mpq_class relative_rate_q(relative_rate);
//ratio.canonicalize();
std::cout << "Resample ratio: " << resamp_ratio << std::endl;
std::cout << "Resample ratio: " << resamp_ratio_q << std::endl;
std::cout << "Numerator: " << resamp_ratio_q.get_num().get_ui() << std::endl;
std::cout << "Denominator: " << resamp_ratio_q.get_den().get_ui() << std::endl;
std::cout << std::endl;
std::cout << "Relative rate: " << relative_rate << std::endl;
std::cout << "Relative rate: " << relative_rate_q << std::endl;
std::cout << "Numerator: " << relative_rate_q.get_num().get_ui() << std::endl;
std::cout << "Denominator: " << relative_rate_q.get_den().get_ui() << std::endl;
std::cout << std::endl;
#if 0
//mpz_class offset(0x0803);
uint64_t offset = 0x0803;
mpq_class scaled = offset*ratio;
mpz_class rscaled(scaled + one_half);
mpz_class rscaled2;
rscaled2 = offset * ratio + one_half;
rscaled2 = offset * ratio + one_half + 2;
std::cout << "Offset:" << offset << std::endl;
std::cout << "Scaled offset: " << scaled << std::endl;
std::cout << "Rounded scaled offset: " << rscaled << std::endl;
std::cout << "Rounded scaled offset2: " << rscaled2 << std::endl;
uint64_t rscaledint = rscaled.get_ui();
std::cout << "Native rounded scaled offset: " << rscaledint << std::endl;
#endif
exit(0);
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python import error on swig modules

[Sims, William Herb (MSFC-ES63)]

I too am having a similar problem.  I am trying to install the gr-correctiq 
(github) and gnuradio-companion cannot find them.  I followed the threads 
specifically for gr-correctiq (paths, etc.) and NOTHING works.  I’m running on 
a Mac.

Thanks,

herb


Dr. Herb Sims
EV41
Bldg. 4600 / Room 4113
Control Systems Design & Analysis Branch
MSFC, AL 35812
256-961-3214
---
I want to tell the whole world that I love my wife and kids - what better way 
than one email at a time

Ich will der ganzen Welt sagen, dass ich meine Frau und Kinder liebe – wie ist 
das besser zu machen als Mail für Mail, eine nach der anderen.
---




From: Discuss-gnuradio  on 
behalf of Sakthivel Velumani 
Date: Friday, January 5, 2018 at 12:15 PM
To: GNURadio Discussion List 
Subject: [Discuss-gnuradio] Python import error on swig modules

Hi,

I have been trying to do the simplest qa test for my qpsk demod C++ block from 
the tutorials. When I run the qa_.py im getting an import error: No 
module named _swig. This happens for every C++ blocks.

I can see that _swig.py is being installed into
/usr/local/lib/python2.7/dist-packages//_swig.py, pyc 
and .pyo .
And when I checked sys.path in python, I can see the path 
/usr/local/lib/python2.7/dist-packages along with many other paths.

Any help would be appreciated.

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

[Discuss-gnuradio] Python import error on swig modules

[Sakthivel Velumani]

Hi,

I have been trying to do the simplest qa test for my qpsk demod C++ block
from the tutorials. When I run the qa_.py im getting an import
error: No module named _swig. This happens for every C++
blocks.

I can see that _swig.py is being installed into
/usr/local/lib/python2.7/dist-packages//_swig.py,
pyc and .pyo .
And when I checked sys.path in python, I can see the path
/usr/local/lib/python2.7/dist-packages along with many other paths.

Any help would be appreciated.

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

Re: [Discuss-gnuradio] Boost 1.66.0 Compatibility: GNU Radio & Volk & UHD

[Ben Hilburn]

Thanks so much for the test & report, Mike!

How are you dealing with this on the packaging side for macOS?

Cheers,
Ben

On Mon, Jan 1, 2018 at 11:41 AM, Michael Dickens 
wrote:

> In initial testing, Boost 1.66.0 is fully compatible with the current GNU
> Radio and Volk GIT master & current releases. There's an issue with UHD
> that has already been fixed in the GIT master, but the new boost otherwise
> seems to work with UHD & the backport to the latest release is very
> straight forward. Cheers! - MLD
>
> ___
> 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] Filter output float to complex

[Sakthivel Velumani]

Hi,

Please find the code here https://github.com/saki92/oqpsk-sync-block . I am
trying to build a clock sync block for oqpsk with pfb_clock_sync as
reference.
It does not show any error message from Python or C++. The flowgraph runs
for less than a second and stops. Some times I get a return code -11.

Best regards,
Sakthivel

On Fri, Jan 5, 2018 at 2:20 PM, Müller, Marcus (CEL) <
marcus.muell...@kit.edu> wrote:

> Hi Sakthivel,
>
> this will be impossible to answer without you sharing your code,
> instead of just this pseudocode, alongside with the actual meaning of
> "it crashes". Does it segfault without a message? does it give a python
> error? A C++ exception?
>
> Best regards,
> Marcus
>
>
> On Fri, 2018-01-05 at 10:53 +0100, Sakthivel Velumani wrote:
> > Hi all,
> >
> > I am writing a block which takes in complex samples and performs
> > filtering and other operations on real and imag part separately and
> > then combines them to output as complex. When I combine two
> > fir_filter_fff outputs like -
> >
> > out[i].real(filterObject.filter();
> > out[i].imag(filterObject.filter();
> >
> > the flowgraph crashes. But when I do something like -
> >
> > out[i].real();
> > out[i].imag();
> >
> > it runs fine with the specified output value. So I guess the problem
> > is with the output of fir_filter_fff. In the documentation, its
> > return type is float and I also tried type casting to (float) before
> > passing to out[i].real(). Does anyone have a clue where the problem
> > would be?
> >
> > Best regards,
> > Sakthivel
> > ___
> > 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] USRP X310 frontend name problem

[Nicolas GALLAND]

Hello,

Happy new year to everybody !

Thanks a lot, Derek, it worked perfectly like that. I just had to change 
again the FPGA image, but it is pretty easy with the command lines given 
on the wiki.


Thanks again !

    Best regards,

    Nicolas


Le 15/12/2017 à 16:10, Derek Kozel a écrit :

Hello Nicholas,

You were most likely using UHD version 3.9.x or earlier on your 
previous computer. If possible it'd be good to check what version you 
were using. I believe that reverting to the latest Long Term Support 
release of UHD, 3.9.7, will solve your issue. I believe that the 
build-gnuradio script can be run with `-ut release_003_009_007` as an 
argument and will install that version.


Regards,
Derek

On Fri, Dec 15, 2017 at 2:58 PM, Marcus D. Leech > wrote:


On 12/15/2017 06:31 AM, Galland Nicolas wrote:

Hello everyone !

I am using a USRP x310 for more than a year, and for some
reasons I had to change the computer. On a new installation of
Ubuntu 16.04, I then installed uhd and gnuradio from the
source using Marcus Leech's build-gnuradio script. The
installation was successful, but I had to load a new FPGA
image beause of version compatibility.

In the end, I am able to find the x310 and use it for some
tests (typically, everythong described on the "Verifying the
Operation of the USRP Using UHD and GNU Radio" page of ettus
knowledge is working)

However, when I want to try the flowgraph I used before
reinstallation, I have an error about the frontend name :

RuntimeError: RuntimeError: Invalid daughterboard frontend name: A

I am using two LFRX and the subdev specification is "A:A B:A".
Moreover, it's working with the subdev specification "A:AB
B:AB", which is not what I want...
When I use the uhd_usrp_probe command, it gives me the name of
all the frontends, and A is one of those names.

Can it be some problem in the gnuradio uhd library ?
Or some parameters I should put somewhere after Installation ?

Any help would be useful.

Have a nice day !

best regards,
     Nicolas


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


Could you share the output from uhd_usrp_probe ?




___
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] Filter output float to complex

[Sakthivel Velumani]

Hi all,

I am writing a block which takes in complex samples and performs filtering
and other operations on real and imag part separately and then combines
them to output as complex. When I combine two fir_filter_fff outputs like -

out[i].real(filterObject.filter();
out[i].imag(filterObject.filter();

the flowgraph crashes. But when I do something like -

out[i].real();
out[i].imag();

it runs fine with the specified output value. So I guess the problem is
with the output of fir_filter_fff. In the documentation, its return type is
float and I also tried type casting to (float) before passing to
out[i].real(). Does anyone have a clue where the problem would be?

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