Re: Demodulating slow phase-modulated data

[Patrick Sathyanathan]

Hi Philip,

Converting real valued signal to I-Q is a simple transformation:


  1.  Pick an LO frequency, F_lo,  greater than 200Hz, the signal bandwidth
  2.  Pick a sample interval, deltaT, smaller than 1/(2*F_lo)
  3.  Generate I-Q digital local oscillator signal: [cos(2*pi*F_lo*i*deltaT), 
j*sin(2*pi*F_lo*i*deltaT] for i depending of the length of your sampling 
interval, i*deltaT
  4.  Multiply each real valued signal value, s, from your WAV file, by each of 
the above LO values to generate the I-O signal

Then use whatever I-Q signal processing you to to process the samples.

Note that there is nothing to be gained by performing the above transformation. 
Unless you have some existing I-Q processing code, you might be better off 
analyzing the real valued signal.

Good luck,

--Patrick


From: Discuss-gnuradio  on 
behalf of Philip Pemberton 
Sent: Wednesday, November 3, 2021 9:28 AM
To: discuss-gnuradio@gnu.org 
Subject: Demodulating slow phase-modulated data

Hi all,

I'm working on a project to reverse-engineer the data format used by an old 
navigation system called Datatrak. I've got a project page on my website about 
it: https://www.philpem.me.uk/datatrak/start

The data is sent by phase-modulating a ~133kHz or ~146kHz (longwave) carrier at 
a very slow rate -- the modulating wave is sinusoidal, either 37.5Hz or 50Hz 
depending on the part of the signal being sent. The signal bandwidth is about 
200Hz.

I've been given some single-channel WAV format recordings from LW SDR 
receivers, 44100Hz sample rate, with a LO frequency of 128kHz. Sadly they're 
not I-Q recordings. I'd like to try and demodulate the signals in these 
recordings to recover the 64 bits of "Goldcode" synchronisation code (from the 
Trigger slot) and the 128 bits of Clock signal (from the Clock slot). I already 
know what the Goldcode value should be.

Can anyone suggest a way I could do this with Gnuradio/GRC or some other tool?

I figure I need to convert the WAV file into a complex (I-Q) signal, mix the 
signal of interest down to baseband, then filter it with a 200Hz bandpass 
filter. I'm not sure what I need to do after that to recover the modulating 
phase signal.

Thanks,
--
Phil.
phil...@philpem.me.uk (preferred)
phil...@gmail.com (alternate)
http://www.philpem.me.uk/

Re: [Discuss-gnuradio] Read FM signal

[Patrick Sathyanathan]

Hi Ivo,

The binary format depends on what you have set as the "Input Type" in the file 
sink. The default is "Complex" in which case the values are 32-bit float I 
followed by 32-bit float Q. The order of the 4-bytes in the float likely 
depends on the endianness of your host system.

--Patrick

From: Discuss-gnuradio  on 
behalf of rear1019 
Sent: Wednesday, April 18, 2018 9:58 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Read FM signal

On Tue, 17 Apr 2018 at 14:32:17 -0300, Ivo Carlson wrote:
> […]
> The file sink saves the data in a binary format, but I don't know what
> this data represents. How do I interpret this data? What does this data
> represent?

This question can not be answered as we don’t know how your flowgraph
looks like. Provide your flowgraph (.grc file) or a screenshot (open the
flowgraph in GNU Radio Companion, go to File menu and select “Screen
Capture”).

___
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-users] Dynamically Sweep Center Frequency for USRP2

[Patrick Sathyanathan]

You can look at usrp_spectrum_sense script. This sweeps a specified frequency 
range, does an FFT, and outputs one line for every bin where the magnitude 
exceeds a specified limit.


You could modify it to just write the samples to a file/pipe like uhd_rx_cfile.


--Patrick


From: USRP-users  on behalf of Rohit 
Kulkarni via USRP-users 
Sent: Sunday, October 29, 2017 6:02 PM
To: usrp-us...@lists.ettus.com
Subject: Re: [USRP-users] Dynamically Sweep Center Frequency for USRP2

Hi,

Can someone help me with this?


Thanks,
Rohit

On Thu, Oct 26, 2017 at 2:47 PM, Rohit Kulkarni 
> wrote:
Hi,

I am working on a project that requires capturing the analog signal in a 
particular band with the help of USRP2 and then it sends the data over the GigE 
connection to the host machine for further processing. Currently, I am using 
uhd_rx_cfile -A $ANTENNA -r $SAMPLE_RATE_SPS -f $FREQ_HZ -g $GAIN command to 
set the center frequency.

Next, I want to write a program/use an existing program/script which uniformly 
sweeps the center frequency in some particular range (say 100MHz to 1 GHz). Can 
you tell me if there is any existing script that does this? Any pointers on how 
I can write a new script from scratch?

Apologies if this exact question is answered before!

Thanks,
Rohit

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

Re: [Discuss-gnuradio] GNURadio OOT vector input/output with different size

[Patrick Sathyanathan]

Try this instead:


const std::vector inputs{4000,4000,4000,4000,4000,4000,4000,4000};

and make sure you compile with c++11 enabled.

--Patrick


From: Discuss-gnuradio  on 
behalf of Ali <03do...@gmail.com>
Sent: Thursday, July 20, 2017 12:13 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNURadio OOT vector input/output with different 
size

Hi,

I dont have any background about C++. So I could not generate the 
std::vector with the desired content and could not fınd anything on the 
internet.

const std::vector inputs[] = {4000,4000,4000,4000,4000,4000,4000,4000};

does not work. I am getting the following error:

"conversion from 'int' to non-scalar type 'std::vector' requested"

Best,
Ali




2017-07-18 11:51 GMT+03:00 Marcus Müller 
>:

Hi Ali,

I think this should also work, shouldn't it?
no, that's why I explained what you need to do (use makev).

Does this part need to be changed since I am working with the vectors?
No, not really. The vectors are still only consecutive numbers in memory.


Best regards,

Marcus

On 18.07.2017 07:51, Ali wrote:
Hi,

1- Actually I am using the followings

make(8,8,1000*sizeof(float))
make3(4,4,1000*sizeof(float),1000*sizeof(float),4*sizeof(float))

I think this should also work, shouldn't it?

2- Under the general work function I am using the followings:

const float *in1 = (const float *) input_items[0]
...
float *out1 = (float *) output_items[0]

Does this part need to be changed since I am working with the vectors?

Thanks,
Ali




2017-07-17 16:42 GMT+03:00 Marcus Müller 
>:

Hi Ali,

So, you want one block with:

  *   8 inputs, itemsize0…7 = 1000*4B = 4000B
  *   4 outputs, itemsize0=itemsize1=4000B, itemsize2=itemsize3=16B

Correct?

You need to generate two std::vector with content

{4000,4000,4000,4000,4000,4000,4000,4000}

and

{4000,4000,16,16}

respectively, and use gr::io_signature::makev(int min_streams, int max_streams, 
vector) to generate the io_signatures[1] that you use in your block's 
constructor. The question whether your block should be a general, or a sync 
block, is independent from the item sizes of the in and outputs, but depends on 
whether there's always a fixed ratio of produced output items to consumed input 
items, as explained in [2].

Best regards,

Marcus

[1] 
https://gnuradio.org/doc/doxygen/classgr_1_1io__signature.html#a99e0f9e8de8e7ce16ed92d9f2655e66c
[2] 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B#4.3.2_Specific_block_categories

On 07/17/2017 03:31 PM, Ali wrote:
Hi to all,

I want to design my own OOT module with the following I/O:

8 inputs (length of 1000 and each element is type of float)
2 outputs (length of 1000 and each element is type of float)
2 outputs (length of 4 and each element is type of float)

I used general type block but I could not get the desired outputs. Do you 
suggest other type of blocks? Is there any example similar to this work that I 
can study on? Can you suggest a module name or a link?

Best,
Ali




___
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


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

Re: [Discuss-gnuradio] Why does I channel have non-zero data for Q direct sampling mode

[Patrick Sathyanathan]

Ok, I read the original thread that discussed the direct sampling mod on the 
google group here: 
https://groups.google.com/forum/#!topic/ultra-cheap-sdr/cG988R1D8uE . That has 
a good explanation of how the mod works.


It seems you do get I/Q samples and not just Q samples as the name "Q branch 
direct sampling" seemed to imply.

[http://www.google.com/images/icons/product/groups-128.png]<https://groups.google.com/forum/#!topic/ultra-cheap-sdr/cG988R1D8uE>

What is RTL-SDR direct sampling 
mode?<https://groups.google.com/forum/#!topic/ultra-cheap-sdr/cG988R1D8uE>
groups.google.com
Posted 7/15/12 10:52 AM, 25 messages


--Patrick




From: Discuss-gnuradio <discuss-gnuradio-bounces+wpats=hotmail....@gnu.org> on 
behalf of Patrick Sathyanathan <wp...@hotmail.com>
Sent: Thursday, June 1, 2017 11:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Why does I channel have non-zero data for Q direct 
sampling mode


Hi All,


Not sure which forum to direct this question. I am using a Soft66Q device which 
is an rtl-sdr with Q branch direct sampling mod.



I observed the I and Q channels in direct sampling mode using the osmocom_fft 
program in scope mode run as follows:


osmocom_fft --args="rtl,direct_samp=2" -s 2.4M -f 1.2M -S


I expected the I channel to be 0 or a copy of the Q channel. But I see that 
they are different. Why is this so ? Does the gr-osmosdr driver convert the Q 
channel signal to complex I/Q ? And if so how ?


Thanks for any information,


--Patrick

____
From: Patrick Sathyanathan <wp...@hotmail.com>
Sent: Thursday, June 1, 2017 6:41 PM
To: kazunori miura
Subject: Re: Fw: ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 
band filter R820T2, VLF


Thanks, Kazunori. The device works very well.


--Patrick


From: kazunori miura <kazu...@st.rim.or.jp>
Sent: Thursday, June 1, 2017 5:40 PM
To: Patrick Sathyanathan
Subject: Re: Fw: ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 
band filter R820T2, VLF

yes, ant input has capacitor.HF and VHF each.

On 2017/06/02 9:36, Patrick Sathyanathan wrote:
> Hi,
>
>
> I want to connect a signal source with a dc bias to the input of
> soft66q. Does the input has dc blocking capacitor ? Or should I provide
> one externally.
>
>
> Thanks,
>
>
> --Patrick
>
>
>
> 
> *From:* eBay <e...@ebay.com>
> *Sent:* Saturday, September 24, 2016 2:19 AM
> *To:* wp...@hotmail.com
> *Subject:* ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4
> band filter R820T2, VLF
>
> Confirmed. ETA: Mon. Oct. 24 - Wed. Nov. 9. eBay will update the
> estimate when it ships to 15861 Northup Way.
>
> eBay
> <http://rover.ebay.com/rover/0/e11400.m1831.l3127/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fstart%2Fshop=bu=bu>
>
>
>
>   Hi Patrick - Order confirmed. eBay will update you when your order
>   ships to 15861 Northup Way
>
> PAID : $52.00 with PayPal
>
> View order details
> <http://rover.ebay.com/rover/0/e11400.m44.l1503/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
> RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 band filter
> R820T2, VLF...
> <http://rover.ebay.com/rover/0/e11400.m1842.l5920/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
>
> RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 band filter
> R820T2, VLF
> 
> <http://rover.ebay.com/rover/0/e11400.m1842.l5919/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
> Estimated delivery: Mon. Oct. 24 - Wed. Nov. 9
>
> Item Id: 201660671703
> Transaction Id 1428115037010
> Quantity: 1
>
>
>   To complement your purchase
>
> SAMS Photofact CB Radio Series Books ...
> <http://rover.ebay.com/rover/0/e11400.m3767.l1120/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F272373139583%3F_trksid%3Dp11400.c100368.m3767%26_trkparms%3Daid%253D333008%2526algo%253DRIC.MBE%2526ao%253D1%2526asc%253D20150120121922%2526meid%253De1df987eb11947ebb70723165ec49c5e%2526pid%253D100368%2526rk%253D1%2526rkt%253D8%2526sd%253D201660671703=bu=bu>
>
>
>
>   SAMS Photofact CB Radio Series Books ...
>   
> <http://rover.ebay.com/rover/0/e11400.m3767.l3160/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=4421081

[Discuss-gnuradio] Why does I channel have non-zero data for Q direct sampling mode

[Patrick Sathyanathan]

Hi All,


Not sure which forum to direct this question. I am using a Soft66Q device which 
is an rtl-sdr with Q branch direct sampling mod.



I observed the I and Q channels in direct sampling mode using the osmocom_fft 
program in scope mode run as follows:


osmocom_fft --args="rtl,direct_samp=2" -s 2.4M -f 1.2M -S


I expected the I channel to be 0 or a copy of the Q channel. But I see that 
they are different. Why is this so ? Does the gr-osmosdr driver convert the Q 
channel signal to complex I/Q ? And if so how ?


Thanks for any information,


--Patrick

____
From: Patrick Sathyanathan <wp...@hotmail.com>
Sent: Thursday, June 1, 2017 6:41 PM
To: kazunori miura
Subject: Re: Fw: ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 
band filter R820T2, VLF


Thanks, Kazunori. The device works very well.


--Patrick


From: kazunori miura <kazu...@st.rim.or.jp>
Sent: Thursday, June 1, 2017 5:40 PM
To: Patrick Sathyanathan
Subject: Re: Fw: ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 
band filter R820T2, VLF

yes, ant input has capacitor.HF and VHF each.

On 2017/06/02 9:36, Patrick Sathyanathan wrote:
> Hi,
>
>
> I want to connect a signal source with a dc bias to the input of
> soft66q. Does the input has dc blocking capacitor ? Or should I provide
> one externally.
>
>
> Thanks,
>
>
> --Patrick
>
>
>
> 
> *From:* eBay <e...@ebay.com>
> *Sent:* Saturday, September 24, 2016 2:19 AM
> *To:* wp...@hotmail.com
> *Subject:* ORDER: RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4
> band filter R820T2, VLF
>
> Confirmed. ETA: Mon. Oct. 24 - Wed. Nov. 9. eBay will update the
> estimate when it ships to 15861 Northup Way.
>
> eBay
> <http://rover.ebay.com/rover/0/e11400.m1831.l3127/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fstart%2Fshop=bu=bu>
>
>
>
>   Hi Patrick - Order confirmed. eBay will update you when your order
>   ships to 15861 Northup Way
>
> PAID : $52.00 with PayPal
>
> View order details
> <http://rover.ebay.com/rover/0/e11400.m44.l1503/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
> RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 band filter
> R820T2, VLF...
> <http://rover.ebay.com/rover/0/e11400.m1842.l5920/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
>
> RTL-SDR Soft66Q 3kHz to 1.7GHz RTL2832U with RF anp 4 band filter
> R820T2, VLF
> 
> <http://rover.ebay.com/rover/0/e11400.m1842.l5919/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fvod%3Ftransid%3D1428115037010%26itemid%3D201660671703%26qu%3D1=bu=bu>
>
>
> Estimated delivery: Mon. Oct. 24 - Wed. Nov. 9
>
> Item Id: 201660671703
> Transaction Id 1428115037010
> Quantity: 1
>
>
>   To complement your purchase
>
> SAMS Photofact CB Radio Series Books ...
> <http://rover.ebay.com/rover/0/e11400.m3767.l1120/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F272373139583%3F_trksid%3Dp11400.c100368.m3767%26_trkparms%3Daid%253D333008%2526algo%253DRIC.MBE%2526ao%253D1%2526asc%253D20150120121922%2526meid%253De1df987eb11947ebb70723165ec49c5e%2526pid%253D100368%2526rk%253D1%2526rkt%253D8%2526sd%253D201660671703=bu=bu>
>
>
>
>   SAMS Photofact CB Radio Series Books ...
>   
> <http://rover.ebay.com/rover/0/e11400.m3767.l3160/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F272373139583%3F_trksid%3Dp11400.c100368.m3767%26_trkparms%3Daid%253D333008%2526algo%253DRIC.MBE%2526ao%253D1%2526asc%253D20150120121922%2526meid%253De1df987eb11947ebb70723165ec49c5e%2526pid%253D100368%2526rk%253D1%2526rkt%253D8%2526sd%253D201660671703=bu=bu>
>
> $3.99
> Buy it now
>
> PLL LCD Digital 87-108MHZ FM Radio Re...
> <http://rover.ebay.com/rover/0/e11400.m3767.l1120/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F282109051777%3F_trksid%3Dp11400.c100368.m3767%26_trkparms%3Daid%253D333008%2526algo%253DRIC.MBE%2526ao%253D1%2526asc%253D20150120121922%2526meid%253De1df987eb11947ebb70723165ec49c5e%2526pid%253D100368%2526rk%253D2%2526rkt%253D8%2526sd%253D201660671703=bu=bu>
>
>
>
>   PLL LCD Digital 87-108MHZ FM Radio Re...
>   
> <http://rover.ebay.com/rover/0/e11400.m3767.l3160/7?euid=fdf06ae49a07477bb1ee49fe0e9be6fe=44210816341=http%3A%

Re: [Discuss-gnuradio] Global namespace Errors with Complex and xlocNum

[Patrick Sathyanathan]

Hi Melvin,


I just found out there is nothing wrong with that version, it is correct. I got 
another suggestion from asking around:

From: Billy O'Neal (VC LIBS)
Sent: Friday, March 17, 2017 4:34 PM
Subject: Re: Any idea what could be causing this on MSVC17 ?



We are not aware of any bugs that would cause things like



xstring_insert.h(24): error C2143: syntax error: missing ';' before '{'



Is it possible that a ; is missing in the user's code at the end of stdafx.h?

--Patrick


From: Melvin J Malave Sanchez <melvin.mal...@upr.edu>
Sent: Wednesday, March 15, 2017 5:20 PM
To: Patrick Sathyanathan
Cc: Marcus Müller; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Global namespace Errors with Complex and xlocNum

Hey Patrick,

That is correct, is the current version wrong or causing incompatibility issues?
Should be noted im a novice to c++ and the handling of library has been quite 
troubling.
UPDATE: I removed Iostream since I commented out all cin,cout lines in order to 
just have the blocks declarations and connections,  and the original errors 
returned.  Ill include the flowgraph of what the code is supposed to resemble 
in case it helps.

On Wed, Mar 15, 2017 at 7:22 PM, Patrick Sathyanathan 
<wp...@hotmail.com<mailto:wp...@hotmail.com>> wrote:

Hi Melvin,


>From the error message it appears you are using version 14.10.25017 headers 
>with MSVC17. Why is this ? Were these part of the MSVC17 distribution ?

c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include

--Patrick



From: Discuss-gnuradio 
<discuss-gnuradio-bounces+wpats=hotmail@gnu.org<mailto:hotmail@gnu.org>>
 on behalf of Melvin J Malave Sanchez 
<melvin.mal...@upr.edu<mailto:melvin.mal...@upr.edu>>
Sent: Wednesday, March 15, 2017 4:14 PM
To: Marcus Müller
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Global namespace Errors with Complex and xlocNum

The complex and locNum errors stopped once i moved stdafx.h to the very top, 
thanks for the tip. However, now im getting string errors? Specifically towards 
xstring and string, Ill provide a few lines of those:
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xstring_insert.h(24): 
error C2143: syntax error: missing ';' before '{'
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xstring_insert.h(24): 
error C2447: '{': missing function header (old-style formal list?)
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\string(20): error 
C2988: unrecognizable template declaration/definition
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\string(20): error 
C2143: syntax error: missing ';' before '<'

I've added  and  but the issue still hasn't been solved and i 
have no clue on how to proceed. Its a real pain

You mentioned you never build gr with msvc17, what do you use?


Respectfully,

Melvin

On Wed, Mar 15, 2017 at 4:01 PM, Marcus Müller 
<marcus.muel...@ettus.com<mailto:marcus.muel...@ettus.com>> wrote:

Hey :)

Ah, ok, didn't realize that. Looks like some compiler confusion, then. So, I've 
gotta admit, never tried to build GR with MSVC17, so here's a bit of guesswork:

* Not overly familiar with things under visual studio, but isn't it somehow 
customary to include stdafx.h as the very first thing?

* Since I don't immediately spot where you're using any of its functions: Why 
not remove #include  and see if it helps?

Best regards,

Marcus

PS: please make sure to keep the whole list in your replies – that way, more 
than one person has a chance to answer!

On 03/15/2017 08:41 PM, Melvin J Malave Sanchez wrote:

Hey Marcus,

thanks for the quick reply, the problem is more C++ oriented than GNU. But, im 
not using those math functions or any in fact explicitely anywhere in the code 
which leads me to believe the problem is related to the libraries and since you 
guys understand them more than i do im hoping for some insight on the issue.

Respectfully,

Melvin


On Mar 15, 2017 3:28 PM, "Marcus Müller" 
<marcus.muel...@ettus.com<mailto:marcus.muel...@ettus.com>> wrote:

Hi Melvin,

Not 100% sure, it's getting late, but if you use #include cmath, wouldn't it be 
std::pow instead of pow? I don't really see the connection of your problem to 
GNU Radio, to be totally honest.

Best regards,
Marcus

On 03/15/2017 07:23 PM, Melvin J Malave Sanchez wrote:
Hi there,

I'm coding a program in C++ whose purpose is data logging, in it i'm using GNU 
radio libraries. In addition, i'm declaring gr hierarchical blocks in the code 
as they have a connect function that simplifies the complexity of the program.

I'm using Visual studio IDE with visual C compiler to run th

Re: [Discuss-gnuradio] Global namespace Errors with Complex and xlocNum

[Patrick Sathyanathan]

Hi Melvin,


>From the error message it appears you are using version 14.10.25017 headers 
>with MSVC17. Why is this ? Were these part of the MSVC17 distribution ?

c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include

--Patrick



From: Discuss-gnuradio  on 
behalf of Melvin J Malave Sanchez 
Sent: Wednesday, March 15, 2017 4:14 PM
To: Marcus Müller
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Global namespace Errors with Complex and xlocNum

The complex and locNum errors stopped once i moved stdafx.h to the very top, 
thanks for the tip. However, now im getting string errors? Specifically towards 
xstring and string, Ill provide a few lines of those:
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xstring_insert.h(24): 
error C2143: syntax error: missing ';' before '{'
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xstring_insert.h(24): 
error C2447: '{': missing function header (old-style formal list?)
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\string(20): error 
C2988: unrecognizable template declaration/definition
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\string(20): error 
C2143: syntax error: missing ';' before '<'

I've added  and  but the issue still hasn't been solved and i 
have no clue on how to proceed. Its a real pain

You mentioned you never build gr with msvc17, what do you use?


Respectfully,

Melvin

On Wed, Mar 15, 2017 at 4:01 PM, Marcus Müller 
> wrote:

Hey :)

Ah, ok, didn't realize that. Looks like some compiler confusion, then. So, I've 
gotta admit, never tried to build GR with MSVC17, so here's a bit of guesswork:

* Not overly familiar with things under visual studio, but isn't it somehow 
customary to include stdafx.h as the very first thing?

* Since I don't immediately spot where you're using any of its functions: Why 
not remove #include  and see if it helps?

Best regards,

Marcus

PS: please make sure to keep the whole list in your replies – that way, more 
than one person has a chance to answer!

On 03/15/2017 08:41 PM, Melvin J Malave Sanchez wrote:

Hey Marcus,

thanks for the quick reply, the problem is more C++ oriented than GNU. But, im 
not using those math functions or any in fact explicitely anywhere in the code 
which leads me to believe the problem is related to the libraries and since you 
guys understand them more than i do im hoping for some insight on the issue.

Respectfully,

Melvin


On Mar 15, 2017 3:28 PM, "Marcus Müller" 
> wrote:

Hi Melvin,

Not 100% sure, it's getting late, but if you use #include cmath, wouldn't it be 
std::pow instead of pow? I don't really see the connection of your problem to 
GNU Radio, to be totally honest.

Best regards,
Marcus

On 03/15/2017 07:23 PM, Melvin J Malave Sanchez wrote:
Hi there,

I'm coding a program in C++ whose purpose is data logging, in it i'm using GNU 
radio libraries. In addition, i'm declaring gr hierarchical blocks in the code 
as they have a connect function that simplifies the complexity of the program.

I'm using Visual studio IDE with visual C compiler to run the program and as i 
do i get various errors which i have been trying to figure out for days. I've 
googled similar errors and asked in stackoverflow but i've had no luck.

Ill include some of the lines of errors i'm getting as well as some lines of 
code(the program is small) to make this email as clear as possible. In the 
attachment i included a txt file that contains the full code and errors.

-ERRORS 
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xlocnum(64): error 
C2039: 'pow': is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xlocnum(64): error 
C3861: 'pow': identifier not found
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xlocnum(81): error 
C2039: 'powf': is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\xlocnum(81): error 
C3861: 'powf': identifier not found
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\complex(256): error 
C2039: 'atan2l': is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual 
studio\2017\community\vc\tools\msvc\14.10.25017\include\complex(256): error 
C3861: 'atan2l': identifier not found

--CODE--

int UHD_SAFE_MAIN(int argc, char 

Re: [Discuss-gnuradio] input of Signal Source blocks

[Patrick Sathyanathan]

Hi Marc,


You could take a look at osmocom_spectrum_sense which is part of the gr-osmosdr 
package. It does exactly what you seem to want to do. Running it with "--help" 
lists the command line options. It is a python script so should be relatively 
easy to figure out.


--Patrick



From: Discuss-gnuradio  on 
behalf of Marcus Müller 
Sent: Friday, January 13, 2017 10:43 AM
To: Marc Pàmies Massip; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] input of Signal Source blocks


Sure! That sounds pretty possible :)

I'm not so much of an expert on the osmocom source, myself, but you can just 
use a variable (like you would with a slider) for the frequency.

You'd then probably programmatically change that from within python; the 
problem really is that you can never tell when the effect is going to take 
place in the sample stream (because the HackRF and your PC run asynchronous to 
each other – you tell gr-osmosdr to change the center frequency, it calls 
libhackrf, which sends a USB packet to the hackRF, which changes the frequency 
– but all the while,the normal streaming operation goes on and you simply don't 
know which sample the tuning happens at). So you'll need to include a lot of 
"blanking time" where you ignore the samples coming out of the osmocom source, 
because you don't know whether they're still from the old frequency or already 
from the new one.

If you want to contribute to the gr-osmosdr project (and potentially make 
Dimitri happy), I'd recommend you add a message port to the osmocom source and 
made that react to the same type of messages as other blocks (dictionaries of 
command-value pairs), and use that to issue your tuning commands – that way, 
you could stay within the GNU Radio framework and wouldn't have to modify the 
python code the GNU Radio Companion generates out of your (graphical) flow 
graph.

Cheers,

Marcus

On 01/13/2017 07:23 PM, Marc Pàmies Massip wrote:
Ah! I see it now. I don't want the chirp... Initially I was asking to tune the 
HackRF with a simple sine or cosine wave whose frequency changes automatically 
(not manually with a slider, for example). Then you suggested me to implement a 
chirp (because in that first message you didn't know what I was planning to do) 
and for some reason I thought that it could work... but obviously is not 
possible to tune the device using a chirp signal.

I think there's been a misunderstanding between us, maybe I should have changed 
the original question because it was quite confusing. What I intend to do is to 
"automatically" re-tune a HackRF so that it can scan a whole GSM band doing 
discrete steps. Can it be done in GNUradio?

Marc.

On 13/01/2017 19:08:27, Marcus Müller 
 wrote:

Hi Marc,

if in doubt, keep the list in. If it's too specific, someone will complain (or 
not. Simply sorting away mails you don't care about is what you need to do when 
using a mailing list).

I don't get what you say yet. What do you mean with "tell the hackrf to 
re-tune"? The only way that I see to do this is by software (using gnuradio).
Well, but you *don't* retune the HackRF by generating a chirp in software.

This is were I get lost. In my opinion, if for example the Osmocom Source sees 
the band from 900MHz to 920MHz is because the center frequency of the block is 
set to 910MHz (and sample rate of 20MHz),
yes,
so I just have to make this parameter change (center freq) to see the "unknown 
signal" you're talking about,
yes,
because the hackrf can see much further in the spectrum. Isn't changing the 
center frequency of the Osmocom Source equivalent to "tune the hackrf" ?
It is. But it has nothing to do with generating a chirp.

Let me ask this a tenth time: What were you planning to do with your chirp?

Best regards,
Marcus
On 01/13/2017 06:59 PM, Marc Pàmies Massip wrote:
Okay, I am new using the mailing list and I didn't know if I had to answer you 
individually or by doing a broadcast.

I don't get what you say yet. What do you mean with "tell the hackrf to 
re-tune"? The only way that I see to do this is by software (using gnuradio).
You can also think about it this way: The Osmocom source only gives you what it 
sees. Those are the 20 MHz. There's nothing in the world that you could 
multiply to something that doesn't contain the unknown signal you're interested 
in to make it show you that unknown signal.

This is were I get lost. In my opinion, if for example the Osmocom Source sees 
the band from 900MHz to 920MHz is because the center frequency of the block is 
set to 910MHz (and sample rate of 20MHz), so I just have to make this parameter 
change (center freq) to see the "unknown signal" you're talking about, because 
the hackrf can see much further in the spectrum. Isn't changing the center 
frequency of the Osmocom Source equivalent to "tune the 

Re: [Discuss-gnuradio] OOT Module Issue

[Patrick Sathyanathan]

Try running "nm -u -C libgnuradio-ins_blocks.so" and search for any class 
methods that are supposed to be defined in the module.
 
--Patrick
 
Date: Wed, 1 Jun 2016 12:01:04 -0700
From: richard.be...@gmail.com
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] OOT Module Issue

Hi,

This is on Ubuntu 14.04 with GNU Radio 3.7.10

I have a module that I use just for altering existing GNU Radio blocks. 
Currently, it has the header/payload demux block and the packet_header_parser 
block in it, which I copied and pasted from the built-in block files. The HPD 
block was working fine yesterday, but today when I added the 
packet_header_parser block, it appears to have broken not only itself, but the 
hpd block as well.

The issue is that I'm getting 

AttributeError: 'module' object has no attribute 'packet_headerparser_b_ins'

when I have either of these blocks included in a flowgraph. I did not forget to 
'sudo ldconfig'.

Here is the output of ldd

bell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-ins_blocks/build/lib$
 ldd libgnuradio-ins_blocks.so 
linux-vdso.so.1 =>  (0x7fff000ea000)
libboost_system.so.1.54.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7fa5de816000)
libgnuradio-runtime-3.7.10git.so.0.0.0 => 
/usr/local/lib/libgnuradio-runtime-3.7.10git.so.0.0.0 (0x7fa5de53a000)
libgnuradio-pmt-3.7.10git.so.0.0.0 => 
/usr/local/lib/libgnuradio-pmt-3.7.10git.so.0.0.0 (0x7fa5de2ef000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa5ddfeb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa5ddce4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fa5ddace000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa5dd709000)
libvolk.so.1.2.2 => /usr/local/lib/libvolk.so.1.2.2 (0x7fa5dd2a)
libboost_filesystem.so.1.54.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7fa5dd08a000)
libboost_thread.so.1.54.0 => 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7fa5dce74000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fa5dcc55000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7fa5dca15000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fa5dc80d000)
/lib64/ld-linux-x86-64.so.2 (0x7fa5dec64000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7fa5dc5f2000)

When I run the top level python flowgraph under gdb, I get no useful feedback, 
it only tells me the attributeError line that I already knew.

What is something that causes all blocks in a module to produce this sort of 
error?

Thanks,
Rich


___
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] Installation issue -gnuradio-companion disable

[Patrick Sathyanathan]

>From the log below it may be because SWIG version check failed:


> -- Disabling SWIG because version check failed

and

> -- Configuring python-support support... 
> --   Dependency PYTHONLIBS_FOUND = TRUE 
> --   Dependency SWIG_FOUND = FALSE 
> --   Dependency SWIG_VERSION_CHECK = FALSE 
> --   Disabling python-support support. 
> --   Override with -DENABLE_PYTHON=ON/OFF 
>

You may need to install a later version of SWIG...

--Patrick

__
> Date: Thu, 7 Apr 2016 00:21:16 -0700 
> From: yj...@eng.ucsd.edu 
> To: Discuss-gnuradio@gnu.org 
> Subject: [Discuss-gnuradio] Installation issue -gnuradio-companion disable 
>  
> During installation gnuradio, I encounter this issue. It seems  
> gnuradio-companion is not enable. 
> I found this recommendation though, it is not simple to install cheetah  
> and lxml. 
> Numpy is installed for sure in my VM(Ubuntu 14.04), but not sure of  
> cheetah and lxml. 
>  
>  
> Any advices welcomes 
>  
> Thanks, 
> Harold 
> -- 
> GNU Radio Companion 
>  
>*   for the GNU Radio Companion (GRC) you need to install  
> python-numpy, python-cheetah and python-lxml 
>  
>  
> -- 
>  
> harold@ubuntu:~/Documents/gr_source/build$ cmake ../ 
> -- Build type set to Release. 
> -- Extracting version information from git describe... 
> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 
> Copyright (C) 2013 Free Software Foundation, Inc. 
> This is free software; see the source for copying conditions.  There is NO 
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden  
> -Wsign-compare -Wall -Wno-uninitialized 
> /usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall  
> -Wno-uninitialized 
> -- ADDING PERF COUNTERS 
> -- Building Static Libraries: OFF 
> -- Boost version: 1.54.0 
> -- Found the following Boost libraries: 
> --   date_time 
> --   program_options 
> --   filesystem 
> --   system 
> --   thread 
> --  
> -- Checking for module SWIG 
> -- Found SWIG version 2.0.11. 
> -- Requested SWIG version is at least . 
> -- Disabling SWIG because version check failed. 
> --  
> -- The build system will automatically enable all components. 
> -- Use -DENABLE_DEFAULT=OFF to disable components by default. 
> --  
> -- Configuring python-support support... 
> --   Dependency PYTHONLIBS_FOUND = TRUE 
> --   Dependency SWIG_FOUND = FALSE 
> --   Dependency SWIG_VERSION_CHECK = FALSE 
> --   Disabling python-support support. 
> --   Override with -DENABLE_PYTHON=ON/OFF 
> --  
> -- Configuring testing-support support... 
> --   Dependency CPPUNIT_FOUND = TRUE 
> --   Enabling testing-support support. 
> --   Override with -DENABLE_TESTING=ON/OFF 
> --  
> -- Configuring VOLK support... 
> -- Build type set to Release. 
> -- Extracting version information from git describe... 
> --  
> -- Python checking for python>= 2.5 
> -- Python checking for python>= 2.5 - found 
> --  
> -- Python checking for Cheetah>= 2.0.0 
> -- Python checking for Cheetah>= 2.0.0 - found 
> -- Boost version: 1.54.0 
> -- Found the following Boost libraries: 
> --   filesystem 
> --   system 
> --   unit_test_framework 
> --   program_options 
> -- checking for module 'orc-0.4> 0.4.11' 
> --   package 'orc-0.4> 0.4.11' not found 
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE) 
> -- QA Testing is enabled. 
> --   Modify using: -DENABLE_TESTING=ON/OFF 
> -- Compiler name: GNU 
> -- x86* CPU detected 
> -- ORC support not found, Overruled arch orc 
> -- CPU width is 64 bits, Overruled arch 32 
> -- Available architectures:  
> generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
>  
> -- Available machines:  
> generic;sse2_64_mmx;sse3_64_mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;avx_64_mmx;avx2_64_mmx
>  
> -- BUILD TYPE = RELEASE 
> -- Base cflags = -O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall  
> -Wno-uninitialized -Wall 
> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden  
> -Wsign-compare -Wall -Wno-uninitialized -Wall 
> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 
> -- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 
> -- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 -mssse3 
> -- BUILD INFO ::: sse4_a_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 -msse4a -mpopcnt 
> -- BUILD INFO ::: sse4_1_64_mmx ::: GNU ::: -O3 

Re: [Discuss-gnuradio] Setting cmake variable with pyBOMBS

[Patrick Sathyanathan]

Any suggestions ?
 
Thanks,
 
--Patrick
 
From: wp...@hotmail.com
To: discuss-gnuradio@gnu.org
Date: Wed, 30 Mar 2016 00:03:10 -0700
Subject: [Discuss-gnuradio] Setting cmake variable with pyBOMBS




 Hi,
 
I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. 
However none of the hardware directories got configured with 
-DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can use to 
set this cmake option globally ? I do not want to cd into each of the build 
directories and run "cmake -DINSTALL_UDEV_RULES=ON .." and run "make" and "sudo 
make install".
 
Thanks for any help,
 
--Patrick
  

___
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] Setting cmake variable with pyBOMBS

[Patrick Sathyanathan]

 Hi,
 
I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. 
However none of the hardware directories got configured with 
-DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can use to 
set this cmake option globally ? I do not want to cd into each of the build 
directories and run "cmake -DINSTALL_UDEV_RULES=ON .." and run "make" and "sudo 
make install".
 
Thanks for any help,
 
--Patrick
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Patrick Sathyanathan]

Sorry, typo "...as Marcus D. Leech points out..."
 
--Patrick
 
From: wp...@hotmail.com
To: rfeng...@me.com; discuss-gnuradio@gnu.org; hup...@gmail.com
Date: Wed, 16 Mar 2016 20:44:23 -0700
Subject: Re: [Discuss-gnuradio] dive into gnu-radio




Hi Desmond,
 
I have a similar CS background combined with a youthful interest in radios from 
the distant past. I initially approached GNUradio with a similar attitude, i.e. 
it's just software, I can figure out what it does. But sadly that is not true, 
and as Martin Leech points out in a different reply on this thread, GNUradio 
combines expertise from many different disciplines and you need some level of 
familiarity with all of them to extract the maximum utility from the package. 
With my knowledge the mechanics of writing an OOT module and getting it to show 
up in GRC is fairly simple. It's the knowledge of radio signals and digital 
signal processing where I have the most difficulty. To address DSP I bought the 
Richard Lyons books and am working my way through it. I strongly recommend that 
book for the harmony between theory and practice in presentation. I am 
simultaneously going through an online course on electrodynamics hoping that 
when I'm done I will have the ability to use GNUradio efficiently in 
interesting ways.
 
--Patrick
 
> Date: Wed, 16 Mar 2016 13:55:55 -0700
> From: rfeng...@me.com
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dive into gnu-radio
> 
> You are not in the same boat, by far.  I'm an EE RF/MW hardware guy with zero
> formal software training (other than a FORTRAN undergrad course requirement;
> if that hints to my age).  SDR is a rather new field that requires a LOT of
> cross discipline; it's software + radio.  I have been  messing with GR for a
> few years, and have halted until I teach myself C++, which I'm 1/2 way
> through my book.  I have done some fun stuff with GRC and Python, but need
> C++ to go further.
> 
> For DSP I would suggest Richard Lyons book.  That will cover sampling,
> filtering, etc..  Really good book.
> 
> For digital comms try Benard Sklar's book.  That will tell you why you want
> an RRC filter.  Grad school level book, but it's all in there.
> 
> Really just have to buckle down and hit the books  I'm having to do it with
> the software side.
> 
> Lou
> 
> 
> 
> Desmond Crozby wrote
> > 
> > Hope anyone has the nerves, time and courtesy to write back. I'm certain
> > it
> > will serve as a nice starting point to future enthusiasts.
> > 
> > Best,
> > Desmond
> > 
> > ___
> > Discuss-gnuradio mailing list
> 
> > Discuss-gnuradio@
> 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/dive-into-gnu-radio-tp58828p58838.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
  

___
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] dive into gnu-radio

[Patrick Sathyanathan]

Hi Desmond,
 
I have a similar CS background combined with a youthful interest in radios from 
the distant past. I initially approached GNUradio with a similar attitude, i.e. 
it's just software, I can figure out what it does. But sadly that is not true, 
and as Martin Leech points out in a different reply on this thread, GNUradio 
combines expertise from many different disciplines and you need some level of 
familiarity with all of them to extract the maximum utility from the package. 
With my knowledge the mechanics of writing an OOT module and getting it to show 
up in GRC is fairly simple. It's the knowledge of radio signals and digital 
signal processing where I have the most difficulty. To address DSP I bought the 
Richard Lyons books and am working my way through it. I strongly recommend that 
book for the harmony between theory and practice in presentation. I am 
simultaneously going through an online course on electrodynamics hoping that 
when I'm done I will have the ability to use GNUradio efficiently in 
interesting ways.
 
--Patrick
 
> Date: Wed, 16 Mar 2016 13:55:55 -0700
> From: rfeng...@me.com
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dive into gnu-radio
> 
> You are not in the same boat, by far.  I'm an EE RF/MW hardware guy with zero
> formal software training (other than a FORTRAN undergrad course requirement;
> if that hints to my age).  SDR is a rather new field that requires a LOT of
> cross discipline; it's software + radio.  I have been  messing with GR for a
> few years, and have halted until I teach myself C++, which I'm 1/2 way
> through my book.  I have done some fun stuff with GRC and Python, but need
> C++ to go further.
> 
> For DSP I would suggest Richard Lyons book.  That will cover sampling,
> filtering, etc..  Really good book.
> 
> For digital comms try Benard Sklar's book.  That will tell you why you want
> an RRC filter.  Grad school level book, but it's all in there.
> 
> Really just have to buckle down and hit the books  I'm having to do it with
> the software side.
> 
> Lou
> 
> 
> 
> Desmond Crozby wrote
> > 
> > Hope anyone has the nerves, time and courtesy to write back. I'm certain
> > it
> > will serve as a nice starting point to future enthusiasts.
> > 
> > Best,
> > Desmond
> > 
> > ___
> > Discuss-gnuradio mailing list
> 
> > Discuss-gnuradio@
> 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/dive-into-gnu-radio-tp58828p58838.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
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B200mini and Raspberry Pi 2 Connectivity

[Patrick Sathyanathan]

Hi Michael,
 
To get GNUradio to build correctly from source on the RPi2 you need to do a 
couple of things:

1. Increase the swap space on the device
2. Build single threaded (make -j 1)
3. Make a source fix in one of the volk ARM asm files. Did you run into this 
error when you tried your build ?
 
BTW the RPi2 is able to handle the 2.4Msps sample rate of an RTL-SDR dongle. 
And about the same rate for the sdrplay and airspy. It does not handle higher 
sample rates supported by B200mini etc.
 
--Patrick
 
Date: Wed, 24 Feb 2016 15:26:40 -0500
From: mskag...@umbc.edu
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] B200mini and Raspberry Pi 2 Connectivity

Hello all,
After sorting out my power issues with the B200mini (it required a dual USB to 
3.0 mini cable, due to browning out the single USB 3.0 connection), I'm now 
trying to connect my B200mini to a Raspberry Pi 2.
I was excited when I found that Raspbian has a gnuradio and gnuradio-dev 
package available, but that excitement quickly faded when I found that it was 
GNURadio version 3.7.5 and UHD version 3.007.003. I'm not sure if the GNURadio 
version is an issue, but I know that UHD 3.007.003 is far too old to recognize 
the B200mini (I tried multiple times before realizing my problem).
The GNURadio package on Raspbian works like a charm, but cannot detect the 
B200mini due to UHD. I have installed UHD from source on the RPi2, and 
successfully probed the B200mini, but could not get GNURadio to compile from 
source correctly. If I install a newer version of UHD after installing the 
gnuradio and gnuradio-dev packages, I get the "uhd_find_devices: undefined 
symbol" error.
I'm trying to find a middle ground. My question is, is there a way that I can 
update the Raspbian package of UHD that it could both detect the B200mini and I 
can use GNURadio Companion?
Thanks,Michael

___
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] Can wrong connection of spyverter damage it ?

[Patrick Sathyanathan]

Hi Chris,
 
Thanks for the info. What would the symptoms of a spyverter failure be ? I 
tested it with a shortwave loop antenna and it picks up the local AM stations 
fine with sdrsharp. But some bands the spectrum display a series of evenly 
spaced spikes that are not AM signals. Could this be due to damage ?
 
I posted the same question to the airspy contact address but have got no 
response. I have found the airspy folks to be less than helpful for other 
queries.
 
--Patrick
 
From: chris.kue...@gmail.com
Date: Tue, 15 Dec 2015 16:24:49 -0800
Subject: Re: [Discuss-gnuradio] Can wrong connection of spyverter damage it ?
To: wp...@hotmail.com
CC: discuss-gnuradio@gnu.org

It it quite possible that you damaged it. You should contact the airspy folks 
to be sure though - http://airspy.com/contact/
On Tue, Dec 15, 2015 at 4:18 PM, Patrick Sathyanathan <wp...@hotmail.com> wrote:



Hi,
 
I recently purchased the airspy/spyverter combo. The spyverter did not have any 
markings indicating antenna input and output. Assuming that the lettering on 
the top of the two devices lined up I initially wrongly connected the antenna 
input of spyverter to the input of the airspy and ran sdrsharp with the bias 
supply enabled. Eventually after much web surfing I was able to find a picture 
indicating the correct connection and I followed that.
 
Does anybody know  if the bias supply from the airspy could have damaged the 
spyverter ? Also any pointers to a forum that might have the answer would be 
appreciated.
 
Thanks for any help,
 
--Patrick
 
  

___

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Can wrong connection of spyverter damage it ?

[Patrick Sathyanathan]

Hi,
 
I recently purchased the airspy/spyverter combo. The spyverter did not have any 
markings indicating antenna input and output. Assuming that the lettering on 
the top of the two devices lined up I initially wrongly connected the antenna 
input of spyverter to the input of the airspy and ran sdrsharp with the bias 
supply enabled. Eventually after much web surfing I was able to find a picture 
indicating the correct connection and I followed that.
 
Does anybody know  if the bias supply from the airspy could have damaged the 
spyverter ? Also any pointers to a forum that might have the answer would be 
appreciated.
 
Thanks for any help,
 
--Patrick
 
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mouse/keyboard events not working raspberry pi 2

[Patrick Sathyanathan]

Hi Tom,

Thanks much, that was exactly what was happening ! I tried with a sample rate 
of 250k and the window responds just fine to keyboard/mouse. That's great since 
I don't know much about keyboard/mouse event handling and was dreading having 
to debug it.

The Raspberry pi 2 has a quad core processor and as long as the flow-graph does 
not take more than ~25-28% CPU (one entire processor) with nothing else running 
the GUI window responds fine. Go above that and it stops responding.

I am new to the Pi 2 and having seen this issue reported on the Pi 2 forums 
thought it was an obscure software bug.

--Patrick


> From: t...@trondeau.com 
> Date: Tue, 27 Oct 2015 10:23:23 -0400 
> Subject: Re: [Discuss-gnuradio] Mouse/keyboard events not working  
> raspberry pi 2 
> To: wp...@hotmail.com 
> CC: discuss-gnuradio@gnu.org 
>  
> On Mon, Oct 26, 2015 at 6:10 PM, Patrick Sathyanathan  
> <wp...@hotmail.com<mailto:wp...@hotmail.com>> wrote: 
> Hi, 
>  
>  
> I managed to build gnuradio from source using pybombs on a raspberry pi  
> 2 machine running raspbian. It took many tries and the build itself  
> took a day and only worked after increasing the swapfile size to 2GB. 
>  
>  
> I am able to run osmocom_fft at 2.4Msps sample rate with an rtl-sdr  
> dongle plugged in. However, the window does not respond to keyboard or  
> mouse interactions. I unable to change the frequency in the text box.  
> Nor can I move the slider. I have verified that gnuradio-companion  
> works fine and accepts mouse/keyboard inputs. However, flowgraphs  
> generated using GRC do not accept mouse/keyboard. 
>  
>  
> Any idea what the problem could be ? If I switch to other windows when  
> osmocom_fft is running the keyboard/mouse work just fine. I am using a  
> wireless mouse and keyboard that share a single usb dongle. 
>  
>  
> Thanks for any help, 
>  
>  
> --Patrick 
>  
>  
> It's quite possible that you are just overloading the rpi2's processor.  
> What if you take the sample rate down to 250 ksps? 
>  
> Tom 
>  
  
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Mouse/keyboard events not working raspberry pi 2

[Patrick Sathyanathan]

Hi,


I managed to build gnuradio from source using pybombs on a raspberry pi 2 
machine running raspbian. It took many tries and the build itself took a day 
and only worked after increasing the swapfile size to 2GB. 


I am able to run osmocom_fft at 2.4Msps sample rate with an rtl-sdr dongle 
plugged in. However, the window does not respond to keyboard or mouse 
interactions. I unable to change the frequency in the text box. Nor can I move 
the slider. I have verified that gnuradio-companion works fine and accepts 
mouse/keyboard inputs. However, flowgraphs generated using GRC do not accept 
mouse/keyboard.


Any idea what the problem could be ? If I switch to other windows when 
osmocom_fft is running the keyboard/mouse work just fine. I am using a wireless 
mouse and keyboard that share a single usb dongle.


Thanks for any help,


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

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

[Patrick Sathyanathan]

Hi David,




Making the parameter vary at runtime is simple and just needs some extra XML 
and python code. The parameter should be an argument to the __init__ method 
(constructor) of your block and should have a "" declaration in the matching 
XML file. Let's say the parameter name is "variable_param" with a declaration 
like:






   Variable parameter

   variable_param

   42

   int






Then you need to add the following in the XML file:




set_variable_param($variable_param)




And you need to implement the "set_variable_param" method in your python class 
to take whatever action is needed when the parameter value changes. This method 
will be called every time the value of the expression in the underlined 
"Variable parameter" box in the GUI changes. The method will look like:





 def set_variable_param(self, new_value):

   whatever code




This should make GRC underline the variable_param in the GUI and it will be 
variable at runtime.




Thanks,




--Patrick


> From: mcqui...@sfu.ca 
> Date: Thu, 24 Sep 2015 10:35:34 -0700 
> To: david.ha...@toshiba-trel.com 
> CC: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks 
> 
> Hi David: 
> 
> I'm a relative newbie myself, but I can say that I had this same issue. 
> I had a block with a static parameter that I wanted to be able to 
> change dynamically at runtime. 
> 
> I looked at the block's source code, and also at a block that had a 
> dynamically adjustable parameter. 
> 
> Basically, and with a little help from the list (Marcus Muller in 
> particular) as I had to learn c++, I was able to use the code from the 
> dynamic block as an example, and modify the static block to change the 
> parameter to be dynamically changeable. It all came down to at most a 
> couple dozen lines of code. The bigger challenge was learning about 
> Gnuradio's architecture, to know what to do. 
> 
> I would suggest a similar approach. You will find the list members 
> very helpful. I'd also look at the guided tutorials, there are good 
> examples there under "how to write a c++ block". 
> 
> I will help if I can but alas, I am still quite a newbie, so others 
> will be able to help much more efficiently! 
> 
> Kevin 
> 
> Sent from my iPad 
> 
> On Sep 23, 2015, at 4:12 AM, David Halls 
>  
> wrote: 
> 
> 
> ​Hi guys, 
> 
> 
> I am familiar with using function probes to update values to blocks. 
> This is straightforward with built in blocks like Multiply Const, where 
> the input is underline in the GRC dialogue box. 
> 
> 
> How do I create a block, specifically a Python block, that allows me to 
> update parameters in this fashion so that they are not fixed at 
> runtime? 
> 
> 
> Regards, 
> 
> 
> David 
> 
>  
> 
> NOTE: The information in this email and any attachments may be 
> confidential and/or legally privileged. This message may be read, 
> copied and used only by the intended recipient. If you are not the 
> intended recipient, please destroy this message, delete any copies held 
> on your system and notify the sender immediately. 
> 
> Toshiba Research Europe Limited, registered in England and Wales 
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road, 
> Cambridge CB4 0GZ, England. Web: 
> www.toshiba.eu/research/trl 
> 
> 
> 
>  
> This email has been scanned for email related threats and delivered 
> safely by Mimecast. 
> For more information please visit http://www.mimecast.com 
>  
> ___ 
> 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] Function Probe and OOT Blocks

[Patrick Sathyanathan]

Attaching reply as text since outlook.com insists on eating XML and formatting.


--Patrick


> From: mcqui...@sfu.ca 
> Date: Thu, 24 Sep 2015 10:35:34 -0700 
> To: david.ha...@toshiba-trel.com 
> CC: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks 
> 
> Hi David: 
> 
> I'm a relative newbie myself, but I can say that I had this same issue. 
> I had a block with a static parameter that I wanted to be able to 
> change dynamically at runtime. 
> 
> I looked at the block's source code, and also at a block that had a 
> dynamically adjustable parameter. 
> 
> Basically, and with a little help from the list (Marcus Muller in 
> particular) as I had to learn c++, I was able to use the code from the 
> dynamic block as an example, and modify the static block to change the 
> parameter to be dynamically changeable. It all came down to at most a 
> couple dozen lines of code. The bigger challenge was learning about 
> Gnuradio's architecture, to know what to do. 
> 
> I would suggest a similar approach. You will find the list members 
> very helpful. I'd also look at the guided tutorials, there are good 
> examples there under "how to write a c++ block". 
> 
> I will help if I can but alas, I am still quite a newbie, so others 
> will be able to help much more efficiently! 
> 
> Kevin 
> 
> Sent from my iPad 
> 
> On Sep 23, 2015, at 4:12 AM, David Halls 
> > 
> wrote: 
> 
> 
> ​Hi guys, 
> 
> 
> I am familiar with using function probes to update values to blocks. 
> This is straightforward with built in blocks like Multiply Const, where 
> the input is underline in the GRC dialogue box. 
> 
> 
> How do I create a block, specifically a Python block, that allows me to 
> update parameters in this fashion so that they are not fixed at 
> runtime? 
> 
> 
> Regards, 
> 
> 
> David 
> 
>  
> 
> NOTE: The information in this email and any attachments may be 
> confidential and/or legally privileged. This message may be read, 
> copied and used only by the intended recipient. If you are not the 
> intended recipient, please destroy this message, delete any copies held 
> on your system and notify the sender immediately. 
> 
> Toshiba Research Europe Limited, registered in England and Wales 
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road, 
> Cambridge CB4 0GZ, England. Web: 
> www.toshiba.eu/research/trl 
> 
> 
> 
>  
> This email has been scanned for email related threats and delivered 
> safely by Mimecast. 
> For more information please visit http://www.mimecast.com 
>  
> ___ 
> 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   
>   Hi David, 

Making the parameter vary at runtime is simple and just needs 
some extra XML and python code. The parameter should be an argument to 
the __init__ method (constructor) of your block and should have a "" 
declaration in the matching XML file. Let's say the parameter name is 
"variable_param" with a declaration like:


   Variable parameter
   variable_param
   42
   int


Then you need to add the following in the XML file: 

set_variable_param($variable_param)

And you need to implement the "set_variable_param" method in your python class 
to take whatever action is needed when the parameter value changes. This method 
will be called every time the value of the expression in the underlined 
"Variable parameter" box in the GUI changes. The method will look like: 

   def set_variable_param(self, new_value): 
  whatever code 
  
This should make GRC underline the variable_param in the GUI and it will be 
variable 
at runtime. 

Thanks, 

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

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

[Patrick Sathyanathan]

Retrying in plain text, since browser/outlook ate the XML I had typed:


Hi David, 


Making the parameter vary at runtime is simple and just needs some extra XML 
and python code. 

The parameter should be an argument to the __init__ method (constructor) of 
your block and should 

have a "" declaration in the matching XML file. Let's say the parameter name is 

"variable_param" with a declaration like:



   Variable parameter
   variable_param
   42
   int



Then you need to add the following in the XML file: 


set_variable_param($variable_param)


And you need to implement the "set_variable_param" method in your python class 
to take whatever 

action is needed when the parameter value changes. This method will be called 
every time the value 

of the expression in the underlined "Variable parameter" box in the GUI 
changes. The method will look 

like: 


   def set_variable_param(self, new_value): 
  whatever code 
  
This should make GRC underline the variable_param in the GUI and it will be 
variable at runtime. 


Thanks, 


--Patrick 

From: mcqui...@sfu.ca
Date: Thu, 24 Sep 2015 10:35:34 -0700
To: david.ha...@toshiba-trel.com
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks


Hi David:




I'm a relative newbie myself, but I can say that I had this same issue.  I had 
a block with a static parameter that I wanted to be able to change dynamically 
at runtime.




I looked at the block's source code, and also at a block that had a dynamically 
adjustable parameter.




Basically, and with a little help from the list (Marcus Muller in particular) 
as I had to learn c++, I was able to use the code from the dynamic block as an 
example, and modify the static block to change the parameter to be dynamically 
changeable. It all came down to at most a couple dozen lines of code. The 
bigger challenge was learning about Gnuradio's architecture, to know what to do.




I would suggest a similar approach. You will find the list members very 
helpful. I'd also look at the guided tutorials, there are good examples there 
under "how to write a c++ block".




I will help if I can but alas, I am still quite a newbie, so others will be 
able to help much more efficiently!




Kevin

Sent from my iPad


On Sep 23, 2015, at 4:12 AM, David Halls  wrote:




​Hi guys,





I am familiar with using function probes to update values to blocks. This is 
straightforward with built in blocks like Multiply Const, where the input is 
underline in the GRC dialogue box.





How do I create a block, specifically a Python block, that allows me to update 
parameters in this fashion so that they are not fixed at runtime?





Regards,





David





 NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

 Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl





This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com 


___
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] OOT Module Attribute Error module object has no attribute 'blockname'

[Patrick Sathyanathan]

I see the following in the output of nm -C -u:
 U gr::ACK::Text_Sanitize_impl::forecast(int, std::vectorint, 
std::allocatorint )
This was the undefined symbol that was causing the module import to fail... as 
you have discovered yourself. Now that the module import has succeeded you are 
seeing a different error. 
This error is because of the following in the generated python file:
   self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
Note that this will invoke Text_Sanitize::make which expects a char * 
message argument. That causes the error message below. For some reason GRC is 
not adding that parameter in the above statement. Did you add a declaration for 
that parameter in the XML file ?
To verify that the XML file is the issue just try editing the generated python 
file and changing the above to:
   self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(some string)
and running it from the command line (run python top_block.py in a terminal 
window).
--Patrick
Date: Thu, 20 Aug 2015 11:08:56 -0500
From: lwas...@ostatemail.okstate.edu
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no 
attribute 'blockname'

Nathan and Patrick,

Thanks for the tips!

I started with running: nm -C -u libgnuradio-modulename.so

and the results of that can be found here: 
https://gist.github.com/loganwashbourne under the nm -C -u 
libgnuradio-modulename.so file. (I think github thinks I'm a robot so I can't 
link to the direct page yet).

I'll be honest, I'm not really sure what I'm looking at in this return, I do 
see some error statements but I'm not sure if they are just stating how it 
would handle an error or if it is an actual error.

I really don't think I have any callbacks in my XML code, I just reference 
certain input variables in the XML code.

Next, the ACK_swig.i file can be found here : 
 https://gist.github.com/loganwashbourne under the same file name. I checked it 
against the gr-tutorial swig file and the only difference was that the 
ACK_swig.i file included a magic2 function call for each of my OOT blocks(check 
and Text_Sanitize), while the gr-tutorial didn't.

Last thing, I realized that I am creating the forecast function in the 
Text_Sanitize_impl.h file but not referencing it it the .cc file (I commented 
it out). I tried commenting out the void deceleration of the forecast function 
in the .h file but then I get a new error when I try to run the grc file(which 
is just a constant int source connected to my Text_Sanitize block, which is 
connected the the message debug print port).

The new error is :

Traceback (most recent call last):
  File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
tb = top_block()
  File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
  File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399, in 
make
return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
TypeError: Required argument 'message' (pos 1) not found

I do apologize for the long questions, if any of you feel like I need to spend 
more time looking into this myself before asking the mailing list, please don't 
hesitate to mention it.


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)



On Wed, Aug 19, 2015 at 5:06 PM, Patrick Sathyanathan wp...@hotmail.com wrote:



Hi Logan,
I have faced the same error twice recently in my OOT module and finally tracked 
it down to two causes. The basic reason for the 'object has no attribute' error 
is that Python's import of your module failed. In the two cases that I saw it 
was due to undefined symbols in the shared library for my module. My module was 
called 'tutorial' so the corresponding library is libgnuradio-tutorial.so and 
you can find it in the .../build/lib directory. To find out the undefined 
symbols do the following:
nm -C -u libgnuradio-modulename.so
and search for method names in your class. So if your class is 'MyClass' you 
could do:
nm -C -u libgnuradio-modulename.so | grep MyClass
The two cases that I ran into were:
1. A non-virtual method in my implementation class was undefined because I had 
forgotten to prefix the method definition with the class name. So the .cc file 
had void foo(...) instead of void MyClass_impl::foo(...) and foo was 
compiled as a ordinary function. Then the command above will report 
MyClass_impl::foo as undefined.
2. The second case I ran into was with defining callbacks in the XML file. If 
you do then you will need to add matching virtual function declarations in the 
header file. This is needed for SWIG to work correctly. For my case the 
callback foo needed a virtual function declaration virtual sometype 
foo(...) = 0; in the actual class declaration (not the ..._impl version) in 
the header file.
Do you have callbacks ? If this is the issue then you should do a make clean 
before running make again to force SWIG to run.
Hope this helps.
--Patrick

Date: Wed

Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Patrick Sathyanathan]

Hi Logan,
I have faced the same error twice recently in my OOT module and finally tracked 
it down to two causes. The basic reason for the 'object has no attribute' error 
is that Python's import of your module failed. In the two cases that I saw it 
was due to undefined symbols in the shared library for my module. My module was 
called 'tutorial' so the corresponding library is libgnuradio-tutorial.so and 
you can find it in the .../build/lib directory. To find out the undefined 
symbols do the following:
nm -C -u libgnuradio-modulename.so
and search for method names in your class. So if your class is 'MyClass' you 
could do:
nm -C -u libgnuradio-modulename.so | grep MyClass
The two cases that I ran into were:
1. A non-virtual method in my implementation class was undefined because I had 
forgotten to prefix the method definition with the class name. So the .cc file 
had void foo(...) instead of void MyClass_impl::foo(...) and foo was 
compiled as a ordinary function. Then the command above will report 
MyClass_impl::foo as undefined.
2. The second case I ran into was with defining callbacks in the XML file. If 
you do then you will need to add matching virtual function declarations in the 
header file. This is needed for SWIG to work correctly. For my case the 
callback foo needed a virtual function declaration virtual sometype 
foo(...) = 0; in the actual class declaration (not the ..._impl version) in 
the header file.
Do you have callbacks ? If this is the issue then you should do a make clean 
before running make again to force SWIG to run.
Hope this helps.
--Patrick

Date: Wed, 19 Aug 2015 14:51:27 -0400
From: n...@ostatemail.okstate.edu
To: lwas...@ostatemail.okstate.edu
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no 
attribute 'blockname'

My gut is telling me this is a swig problem. I don't know that it's frowned 
upon, but it's not easy to read without some kind of highlighting that we'd get 
from github or a gist with files. If I'm correct we'd also need to see 
swig/ACK.i (probably missing an include and/or gr swig block magic. compare to 
tutorial swig for sanity check)
On Wed, Aug 19, 2015 at 10:38 AM, Washbourne, Logan 
lwas...@ostatemail.okstate.edu wrote:
Hello all,

I know this question has been asked before, several times, but I didn't find a 
solution that allowed me to use my OOT blocks without running into the error 
stated in the subject of this email.

I scoured through this 
webpage(http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig)
 and tried adding:
set(GR_REQUIRED_COMPONENTS RUNTIME PMT)

to my top level CMakeLists.txt file, because I am using PMT objects in my 
block, but that didn't get rid of the error.

The full error thrown is this:

Executing: /home/comm1/Logan/Thesis/top_block.py

Traceback (most recent call last):
  File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
tb = top_block()
  File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
AttributeError: 'module' object has no attribute 'Text_Sanitize'


I looked on the mailing list for that last line error and it pointed me to 
doing what I mentioned above with the CMakeLists.txt file, but could it be an 
actual problem with the top_block.py file?

In the addendum is all of the files I could think would be necessary for 
someone to look at if they chose to, if including this much text is frowned 
upon, please let me know.

 
Addendum:

Text_Sanitize_impl.cc
*
#ifdef HAVE_CONFIG_H
#include config.h
#endif

#include gnuradio/io_signature.h
#include Text_Sanitize_impl.h
#include pmt/pmt.h
#include stdio.h
#include string
#include iostream
#include cstdio

namespace gr {
  namespace ACK {

Text_Sanitize::sptr
Text_Sanitize::make(char* message)
{
  return gnuradio::get_initial_sptr
(new Text_Sanitize_impl(message));
}

void
Text_Sanitize_impl::print_message(pmt::pmt_t d_message)
{
pmt::print(d_message);
}



  
/*
void
Text_Sanitize_impl::forecast (int noutput_items, gr_vector_int 
ninput_items_required)
{
 +forecast+ e.g. ninput_items_required[0] = noutput_items 
}
*/
int
Text_Sanitize_impl::general_work (int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items)
{
const int *in = (int *) input_items[0];
pmt::pmt_t *out = (pmt::pmt_t *) output_items[0];


d_out_msg = pmt::string_to_symbol(d_message);
//for(int i = 0; istrlen(d_message); i++)
//{
//pmt::vector_set(d_out_msg,i,d_message[i]);
//}

// Do +signal processing+
// Tell runtime system how many input items we consumed on
// each input stream.

[Discuss-gnuradio] Does any source block support Signalhound BB60C ?

[Patrick Sathyanathan]

Hi,

This device is marketed as a Real Time Spectrum Analyzer but can also function 
as a general purpose SDR. Is there GNUradio support for this device ?

Or is any source block under development ? Any info appreciated...

--Patrick


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

Re: [Discuss-gnuradio] Calling C++ method from Python

[Patrick Sathyanathan]

Thanks much, Marcus. That was the issue. I had missed adding the declarations 
for the callbacks in the non-impl class. As in the analog signal source block, 
just adding pure virtual function declarations for the callbacks did the trick.
 
I'm not familiar with SWIG and I don't know why this works. But I'm happy it 
does without having to dig into SWIG details.
 
Thanks,
 
--Patrick
 
 Date: Mon, 6 Jul 2015 09:53:16 +0200
 From: marcus.muel...@ettus.com
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Calling C++ method from Python
 
 Hi Patrick,
 
 the typical problem with C++ blocks is that people add public methods to
 their _impl, but forget to declare these same methods in their public
 non-impl class.
 Have you done the same expand magic with the header in your
 include/CMakeLists.txt?
 
 Best regards,
 Marcus
 
 
 On 07/06/2015 04:09 AM, Patrick Sathyanathan wrote:
  Hi,
 
  I have worked my way through the Guided Tutorials on gnuradio.org. I have 
  written OOT blocks in Python and managed to expose some set methods in the 
  block as callbacks. Now I have written an OOT C++ block sweeper_cpp_f and I 
  want to expose a couple of setter methods in my block's class as callbacks 
  that can be invoked from Python. Initially I just defined the methods in my 
  sweeper_cpp_f_impl.cc file and added the following to the matching XML file:
 
callbackset_direction($direction)/callback
callbackset_trigger_level($trigger_level)/callback
 
  This builds fine and I am able to use the block in a GRC flow-graph. But at 
  runtime when one of the above methods is invoked as a result of GUI input I 
  get an error message:
 
  File /home/wpats/ettus/grc/new_sweep_cpp.py, line 141, in 
  set_variable_chooser_direction
  
  self.tutorial_sweeper_cpp_f_0.set_direction(self.variable_chooser_direction)
  AttributeError: 'sweeper_cpp_f_sptr' object has no attribute 'set_direction'
 
  I looked at built in module sig_source_X_impl.h.t and 
  sig_source_X_impl.cc.t (this is the analog signal source block) in 
  gr-analog as an example for what I am trying to accomplish. I converted my 
  sources into a similar format and modified the CMakeLists.txt in the 
  .../gr-tutorial/lib directory to add:
 
  
  # Invoke macro to generate various sources and headers
  
  include(GrMiscUtils)
  GR_EXPAND_X_CC_H(tutorial sweeper_cpp_X_impl f)
 
  This again builds fine after I edit the generate_helper.py generated script 
  to find an import module. I assumed that the above would do the necessary 
  magic to generate the wrappers for my callback methods but no such luck. I 
  still get the attribute error when invoking my C++ method.
 
  What is the right way to do this ? Any help/suggestions/pointers would be 
  appreciated. I can't be the first one to try to do this seemingly simple 
  task...
 
  Thanks,
 
  --Patrick
 

  ___
  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] Calling C++ method from Python

[Patrick Sathyanathan]

Hi,

I have worked my way through the Guided Tutorials on gnuradio.org. I have 
written OOT blocks in Python and managed to expose some set methods in the 
block as callbacks. Now I have written an OOT C++ block sweeper_cpp_f and I 
want to expose a couple of setter methods in my block's class as callbacks that 
can be invoked from Python. Initially I just defined the methods in my 
sweeper_cpp_f_impl.cc file and added the following to the matching XML file:

  callbackset_direction($direction)/callback
  callbackset_trigger_level($trigger_level)/callback

This builds fine and I am able to use the block in a GRC flow-graph. But at 
runtime when one of the above methods is invoked as a result of GUI input I get 
an error message:

File /home/wpats/ettus/grc/new_sweep_cpp.py, line 141, in 
set_variable_chooser_direction
    self.tutorial_sweeper_cpp_f_0.set_direction(self.variable_chooser_direction)
AttributeError: 'sweeper_cpp_f_sptr' object has no attribute 'set_direction'

I looked at built in module sig_source_X_impl.h.t and sig_source_X_impl.cc.t 
(this is the analog signal source block) in gr-analog as an example for what I 
am trying to accomplish. I converted my sources into a similar format and 
modified the CMakeLists.txt in the .../gr-tutorial/lib directory to add:


# Invoke macro to generate various sources and headers

include(GrMiscUtils)
GR_EXPAND_X_CC_H(tutorial sweeper_cpp_X_impl f)

This again builds fine after I edit the generate_helper.py generated script to 
find an import module. I assumed that the above would do the necessary magic to 
generate the wrappers for my callback methods but no such luck. I still get the 
attribute error when invoking my C++ method.

What is the right way to do this ? Any help/suggestions/pointers would be 
appreciated. I can't be the first one to try to do this seemingly simple task...

Thanks,

--Patrick

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