[Discuss-gnuradio] bug in gri_fft.cc

[Marek Czerski]

Hi all,

I found a bug in gnuradio-core/src/lib/general/gri_fft.cc, in function:
static const char * wisdom_filename ()

It returns pointer to char string from temporary object created by call
to path.string(). Obviously, this pointer is pointing to garbage after exit
from wisdom_filename() function.

I propose something like this:

 gnuradio-core/src/lib/general/gri_fft.cc | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gnuradio-core/src/lib/general/gri_fft.cc
b/gnuradio-core/src/lib/general/gri_fft.cc
index 68e7e69..906279b 100644
--- a/gnuradio-core/src/lib/general/gri_fft.cc
+++ b/gnuradio-core/src/lib/general/gri_fft.cc
@@ -73,18 +73,19 @@ gri_fft_planner::mutex()
   return s_planning_mutex;
 }

-static const char *
+static std::string
 wisdom_filename ()
 {
   static fs::path path;
   path = fs::path(gr_appdata_path()) / ".gr_fftw_wisdom";
-  return path.string().c_str();
+  return path.string();
 }

 static void
 gri_fftw_import_wisdom ()
 {
-  const char *filename = wisdom_filename ();
+  const std::string & s = wisdom_filename ();
+  const char *filename = s.c_str ();
   FILE *fp = fopen (filename, "r");
   if (fp != 0){
 int r = fftwf_import_wisdom_from_file (fp);
@@ -114,7 +115,8 @@ gri_fftw_config_threading (int nthreads)
 static void
 gri_fftw_export_wisdom ()
 {
-  const char *filename = wisdom_filename ();
+  const std::string & s = wisdom_filename ();
+  const char *filename = s.c_str ();
   FILE *fp = fopen (filename, "w");
   if (fp != 0){
 fftwf_export_wisdom_to_file (fp);
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem in uhd_fft

[Karan Talasila]

Hi,
  I am using a basic tx and basic rx daughterboard for transmission and
reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But
when i run transmitter and check the uhd_fft at receiver, after 32 Mhz,
there is no signal. If i set the transmitter frequency in my flowgraph as
33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as
-31Mhz in the uhd_fft i get a received signal on my fft. why does this
happen? If it's in the range of daughter board it should be receiving it at
that particular frequency right.

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

[Discuss-gnuradio] Horizon 2020 GNSS research call for ideas workshop.

[Andrew Back]

Hi All,

The National Physical Laboratory is hosting a workshop on Friday 5th
July that may be of interest to any UK based GNSS hackers on the list:

  
http://www.npl.co.uk/events/5-jul-2013-horizon-2020-gnss-research-call-for-ideas-workshop

Cheers,

Andrew

--
Andrew Back
http://carrierdetect.com

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

[Discuss-gnuradio] GNU Radio shared library versioning

[Philip Balister]

I've been looking at splitting up the library packages in OE for
embedded GNU Radio and have run across this issue in master.

[libgnuradio-filter-3.7git.so.0.0.0]
[libgnuradio-core-3.7git.so.0.0.0]
[libboost_date_time-mt.so.1.48.0]

Comparing the strings extracted from the .so with readelf, we can see
the gnuradio libraries are not properly versioned (I show the boost one
for comparison).

I expect to see:

libgnuradio-filter.so.3.7.0

Not having a sane version number creates headaches for me when trying to
package the libraries cleanly and without a lot of hacking around.
Fixing the root problem would be a good thing, and make GNU Radio look
more like a professional system and not a prototyping one.

Does anyone have any inight into why this is like this before I start
looking at the problem?

Philip

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

Re: [Discuss-gnuradio] GNU Radio shared library versioning

[Sylvain Munaut]

Hi,

> [libboost_date_time-mt.so.1.48.0]

Not necessarely so, see on my system :

lrwxrwxrwx 1 root root36 Dec 16  2012
/usr/lib/libboost_date_time-mt-1_49.so ->
libboost_date_time-mt-1_49.so.1.49.0
-rwxr-xr-x 1 root root 72168 Dec 16  2012
/usr/lib/libboost_date_time-mt-1_49.so.1.49.0
lrwxrwxrwx 1 root root29 Dec 16  2012
/usr/lib/libboost_date_time-mt.so -> libboost_date_time-mt-1_49.so

> Comparing the strings extracted from the .so with readelf, we can see
> the gnuradio libraries are not properly versioned (I show the boost one
> for comparison).
>
> I expect to see:
>
> libgnuradio-filter.so.3.7.0

You should read
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

The 3 numbers there are the 3 numbers after the .so.xxx

Imagine you have libXXX.so.1.2.3   and the libXXX.so  & libXXX.so.1
symbolic link which is the common style.

In general the libXXX.so should point to whatever you want to link to
when compiling a new software and using -lXXX
The binary will then contain the info that it will try to load
libXXX.so.1  and that implies that all libXX.so.1.N.N have the same
ABI.
The .2.3 part should only be used for internal revisions that don't
change any thing externally so that a software compiled against an
older lib will be able to load the new one without any issue.

This would clearly not be the case for libgnuradio.3 ...

Cheers,

Sylvain

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

[Discuss-gnuradio] Trying to increase power/amplitude of signal sent from USRP using GnuRadio.

[dhenke]

I am working on a project were a program receives information from a location
beacon and allows the computer to know its location in relation to the
beacon. Now we are trying to see the affects if that signal has interference
or is jammed.

The beacon sends out a frequency at 433Mhz and we are trying to use the USRP
to cause interference or to jam the signal altogether. I have been using the
benchmark_tx.py code within gnu radio to try and send the signal at the same
frequency but it doesn't cause interference. I need to increase the power of
the amplitude of the signal enough to cause interference with the location
beacon. 

I have try to use the option in the benchmark_tx.py command --tx_amplitude=
but this has to be between 0<=amp<1 and therefore doesn't really allow me to
increase the power of the signal.

I have also messed around with GRC but haven't seen anything in there that
would allow me to increase the power either. So any help would be great.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Trying-to-increase-power-amplitude-of-signal-sent-from-USRP-using-GnuRadio-tp42264.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] GNU Radio shared library versioning

[Philip Balister]

On 06/27/2013 10:18 AM, Sylvain Munaut wrote:
> Hi,
> 
>> [libboost_date_time-mt.so.1.48.0]
> 
> Not necessarely so, see on my system :
> 
> lrwxrwxrwx 1 root root36 Dec 16  2012
> /usr/lib/libboost_date_time-mt-1_49.so ->
> libboost_date_time-mt-1_49.so.1.49.0
> -rwxr-xr-x 1 root root 72168 Dec 16  2012
> /usr/lib/libboost_date_time-mt-1_49.so.1.49.0
> lrwxrwxrwx 1 root root29 Dec 16  2012
> /usr/lib/libboost_date_time-mt.so -> libboost_date_time-mt-1_49.so
> 
>> Comparing the strings extracted from the .so with readelf, we can see
>> the gnuradio libraries are not properly versioned (I show the boost one
>> for comparison).
>>
>> I expect to see:
>>
>> libgnuradio-filter.so.3.7.0
> 
> You should read
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> 
> The 3 numbers there are the 3 numbers after the .so.xxx
> 
> Imagine you have libXXX.so.1.2.3   and the libXXX.so  & libXXX.so.1
> symbolic link which is the common style.
> 
> In general the libXXX.so should point to whatever you want to link to
> when compiling a new software and using -lXXX
> The binary will then contain the info that it will try to load
> libXXX.so.1  and that implies that all libXX.so.1.N.N have the same
> ABI.
> The .2.3 part should only be used for internal revisions that don't
> change any thing externally so that a software compiled against an
> older lib will be able to load the new one without any issue.
> 
> This would clearly not be the case for libgnuradio.3 ...

So you are suggesting 3.7 should really be 4.0.0 for shared lib
versioning sanity?

Philip

> 
> Cheers,
> 
> Sylvain
> 
> 

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

Re: [Discuss-gnuradio] GNU Radio shared library versioning

[Sylvain Munaut]

> So you are suggesting 3.7 should really be 4.0.0 for shared lib
> versioning sanity?

If you wanted to remove the version number from the lib name itself,
yes, there would be no real relation between the official "version"
3.7.x and the actual .so name.

Including the official name in the library itself seems common
(looking at my /usr/lib) when you have so drastic changes between
versions that you might as well consider them separate libs with no
change of operating anyway.

So I guess the current choice is probably not an accident and most
likely a good one.

Cheers,

Sylvain

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

[Discuss-gnuradio] DSSS problem

[Gonzalo Flores De La Parra]

Hi all,
I've working with GNU-Radio for a couple of months doing different
modulations and coding related work.
My problem now is that i'm trying to implement DSSS, fist simulated and
then OTA with USRPn210. I've done almost the whole system but i'm having
problems with the chip rate.
The thing is that i don't know how to set two different rates: one for my
bits and one for the chips, without facing a two clock problem.
How can i separate each bit of a file source in order to operate an XOR
with each chip of my spreading sequence (Barker's sequence form 802.11b)
which obviously has a higher rate that my original data.
Any thoughts, ideas or suggestions are welcome.
Greetings

-- 
Ing. Gonzalo Flores De La Parra
Electrónica en Comunicaciones
Universidad Autónoma Metropolitana
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Operation of short to char

[Stephen Harrison]

Hi,

Just wondering if the operation of short to char is a bug or intentional.
The most significant 8 bits of the short gets converted to char, ie:

0-255 (short) -> 0 (char)
256-511 (short) -> 1 (char)
512-767 (short) -> 2 (char)

This is not the operation I expected, but the unit test allows it to work
this way, so I am confused.

Regards,

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

Re: [Discuss-gnuradio] Operation of short to char

[Nemanja Savic]

I think that I posted something similar few weeks ago. I also didn't expect
that 0-255 short goes to 0 char, and spent like a day trying to figure out
the bug, but at the end it is like that.


On Thu, Jun 27, 2013 at 8:34 PM, Stephen Harrison
wrote:

> Hi,
>
> Just wondering if the operation of short to char is a bug or intentional.
> The most significant 8 bits of the short gets converted to char, ie:
>
> 0-255 (short) -> 0 (char)
> 256-511 (short) -> 1 (char)
> 512-767 (short) -> 2 (char)
>
> This is not the operation I expected, but the unit test allows it to work
> this way, so I am confused.
>
> Regards,
>
> Stephen
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Operation of short to char

[Monahan-Mitchell, Tim]

Oh, like the lower 8 bits are like additional precision “digits” that are being 
truncated… I would not have expected that either. Comments in the GRC XML file 
would be good…

From: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org 
[mailto:discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] On Behalf 
Of Nemanja Savic
Sent: Thursday, June 27, 2013 1:09 PM
To: Stephen Harrison; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Operation of short to char

I think that I posted something similar few weeks ago. I also didn't expect 
that 0-255 short goes to 0 char, and spent like a day trying to figure out the 
bug, but at the end it is like that.

On Thu, Jun 27, 2013 at 8:34 PM, Stephen Harrison 
mailto:msteveharri...@gmail.com>> wrote:
Hi,

Just wondering if the operation of short to char is a bug or intentional. The 
most significant 8 bits of the short gets converted to char, ie:

0-255 (short) -> 0 (char)
256-511 (short) -> 1 (char)
512-767 (short) -> 2 (char)

This is not the operation I expected, but the unit test allows it to work this 
way, so I am confused.

Regards,

Stephen

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



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

[Discuss-gnuradio] FM Mod / Demod Sensitivity and Quad. Gain Parameters

[Dan CaJacob]

We use the FM Mod and Quadrature Demod blocks to modulate and demodulate
GFSK packetized data.  In the past, we have used sensitivity values for
these blocks that were provided for us, but their meaning was opaque.

I did some digging in the list and the web and found two prevalent
definitions for sensitivity from examples.  Both definitions were
consistent in saying that the Demod parameter 'Quadrature Gain' should be
the inverse of the sensitivity parameter for the Mod block.

The competing definitions for sensitivity were:

1. sensitivity = (pi / 2) / samples_pr_symbol  #
from gnuradio/blksimpl/gmsk.py

and

2. sensitivity = 2 * pi * max_deviation / sample_rate  #
from gnuradio/blks2impl/nbfm_tx.py

In my own recent work, I have been using the second definition because it
seems to work and it gives me control over the deviation (I define max
deviation using modulation index and baud rate).

However, when I attempt to use 1/sensitivity for the Quadrature Gain of the
RX, it does not seem to work, while altering the RX definition of
sensitivity to be 1 / (2 * pi * max_deviation / baud_rate) does seem to
work.

Am I missing something fundamental about how these parameters work?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] delete_head_blocking()

[Shashank Gaur]

Hi All,

I have been trying to understand delete_head_blocking() function from
gr_basic_block, but couldn't understand much clearly. Can anybody shed some
light on this. Also I want to understand pair(car-cdr as well), any info
would help.

Thanks a lot.

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

Re: [Discuss-gnuradio] delete_head_blocking()

[Bastian Bloessl]

Hi,

On 06/27/2013 11:18 PM, Shashank Gaur wrote:

I have been trying to understand delete_head_blocking() function from
gr_basic_block, but couldn't understand much clearly. Can anybody shed
some light on this.


I think this function is useful if you have a block with a message input 
and a stream output (i.e., the block has a work function). To avoid that 
the scheduler has to call the work function all the time even if there 
is no message to handle, you can block in the work with 
delete_head_blocking() until you receive a message.




Also I want to understand pair(car-cdr as well), any
info would help.


car and cdr seam to be some old school functions from Lisp times.
They are used to access the first and respectively second element of a 
pair. You might want to use them in conjunction with PDUs, as PDUs are 
pairs of a dictionary with metadata (1st element) and a blob with the 
actual payload (2nd element).


Best,
Bastian

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

Re: [Discuss-gnuradio] delete_head_blocking()

[Martin Braun (CEL)]

On Thu, Jun 27, 2013 at 11:18:51PM +0200, Shashank Gaur wrote:
> Hi All,
> 
> 
> I have been trying to understand delete_head_blocking() function from
> gr_basic_block, but couldn't understand much clearly. Can anybody shed some
> light on this. Also I want to understand pair(car-cdr as well), any info would
> help.

If you want to learn from my mistakes, check out the rev history on
header_payload_demux :)

Synopsis: Don't block in work() => don't use this call.
Perhaps it makes sense to register a message handler (think of it as a
work function for a specific message).

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpqjLRXAfQKa.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio