Re: [Discuss-gnuradio] source code of the block "WX GUI FFT Sink"

[Marcus Müller]

Hello Xianda,
1. gnuradio/gr-wxgui/python/fftsink* . It doesn't calculate power. It
shows the magnitude of the complex value of the FFT.
2. This is a bit of a complicated question. N210 only works with gr-uhd,
not with the old-timey libusrp. gr-uhd was functional in 3.5.0.
Now, if you use 3.5.0, you should directly go for 3.6.5, which is far
superior by means of build system and features. Generally, the question
is intriguing why you would want an old version, as this is usually bad.

Greetings,
Marcus

On 07.10.2014 03:43, xianda wrote:
> Hi all:
>   Thanks in advance.I want to ask two questions:
>   1.Where is the source code of the block "WX GUI FFT Sink"?How does 
> it calculate the power?
>   2.Which version of the gnuradio start to support the USRP N210?I 
> just want to know the answer.Thanks.I know the latest one is 3.7.* although.
> Best regards,
> xd
> 
>
>
> ___
> 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] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Marcus Müller]

This looks like a linker error.
In your main CMakeList.txt, you have to add DIGITAL to the line containing

set(GR_REQUIRED_COMPONENTS ...


If you already have that, sometimes make clean helps, when for some
reason linker/ccache/black magic involving CMake failed.

Greetings,
Marcus

On 07.10.2014 03:58, Zhe Feng wrote:
> Dear all,
>
> I'm trying to derive a *packet_header2* class in my own OOT module based on
> *gr::digital::packet_header_default*. I followed the way in
> *packet_heade_ofdm*  of gr-digital and made packet_header2.h and
> packet_header2.cc in my own OOT module.
>
> But when I tried to import my_oot in python, it returned an undefined
> symbol error like this:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/dist-packages/my_oot/__init__.py", line
> 45, in 
> from my_oot_swig import *
>   File "/usr/local/lib/python2.7/dist-packages/my_oot/my_oot_cdma.py", line
> 26, in 
> _my_oot_swig = swig_import_helper()
>   File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_swig.py", line 22,
> in swig_import_helper
> _mod = imp.load_module('_my_oot_swig', fp, pathname, description)
> ImportError: /usr/local/lib/libgnuradio-my_oot.so: undefined symbol:
> _ZTIN2gr7digital21packet_header_defaultE
>
> I searched the list and found a previous answered question below
> http://gnuradio.4.n7.nabble.com/so-undefined-symbol-ZN2gr6blocks12count-bits16E-td46270.html
>
> where Marcus suggested editing the CMakeList.txt files by adding the module
> I needed. So I added
>
> *set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)*  in CMakeLists.txt.
>
> and then. This above error disappeared when I import my_oot again in
> python. But this problem isn't solved. I tried to access some functions of
> packet_header_default like formatter and base, it returned me an
> AtrributeError like this:
>
> AttributeError: 'packet_header2_sptr' object has no attribute 'formatter',
> which means the packet_header2 wasn't really a derived class of
> packet_header_default.
>
> I confirmed my conjecture by checking the
> /usr/local/lib/python2.7/dist-packages/my_oot/my_oot_swig.py where the
> classes are stored in python.  I found that the class packet_header2 is
> defined as *class packet_header2(object)*. So the packet_header2 *isn't*
> installed as a derived class of *gr::digital::packet_header_default*.  what
> I expected was *packet_header2(gr::digital::packet_header_default)*.
>
> So I'm asking you that how to correctly derive my class (eg:
> packet_header2) in my own oot module based on a class (eg:
> packet_header_default) in an existing module (eg: gr-digital)?
>
> My packet_header2.h and packet_header2.cc are attached for your reference.
>
> Thanks!
> Best,
> Zhe
>
>
>
> ___
> 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] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Martin Braun]

On 10/07/2014 09:54 AM, Marcus Müller wrote:
> This looks like a linker error.
> In your main CMakeList.txt, you have to add DIGITAL to the line containing
> 
> set(GR_REQUIRED_COMPONENTS ...

The OP mentioned he'd already done that, but I still agree with your
suspicion. It's actually more likely some SWIG/linking issue.

Are you referencing the correct header files in your SWIG file?

M




> If you already have that, sometimes make clean helps, when for some
> reason linker/ccache/black magic involving CMake failed.
> 
> Greetings,
> Marcus
> 
> On 07.10.2014 03:58, Zhe Feng wrote:
>> Dear all,
>>
>> I'm trying to derive a *packet_header2* class in my own OOT module based on
>> *gr::digital::packet_header_default*. I followed the way in
>> *packet_heade_ofdm*  of gr-digital and made packet_header2.h and
>> packet_header2.cc in my own OOT module.
>>
>> But when I tried to import my_oot in python, it returned an undefined
>> symbol error like this:
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/local/lib/python2.7/dist-packages/my_oot/__init__.py", line
>> 45, in 
>> from my_oot_swig import *
>>   File "/usr/local/lib/python2.7/dist-packages/my_oot/my_oot_cdma.py", line
>> 26, in 
>> _my_oot_swig = swig_import_helper()
>>   File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_swig.py", line 22,
>> in swig_import_helper
>> _mod = imp.load_module('_my_oot_swig', fp, pathname, description)
>> ImportError: /usr/local/lib/libgnuradio-my_oot.so: undefined symbol:
>> _ZTIN2gr7digital21packet_header_defaultE
>>
>> I searched the list and found a previous answered question below
>> http://gnuradio.4.n7.nabble.com/so-undefined-symbol-ZN2gr6blocks12count-bits16E-td46270.html
>>
>> where Marcus suggested editing the CMakeList.txt files by adding the module
>> I needed. So I added
>>
>> *set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)*  in CMakeLists.txt.
>>
>> and then. This above error disappeared when I import my_oot again in
>> python. But this problem isn't solved. I tried to access some functions of
>> packet_header_default like formatter and base, it returned me an
>> AtrributeError like this:
>>
>> AttributeError: 'packet_header2_sptr' object has no attribute 'formatter',
>> which means the packet_header2 wasn't really a derived class of
>> packet_header_default.
>>
>> I confirmed my conjecture by checking the
>> /usr/local/lib/python2.7/dist-packages/my_oot/my_oot_swig.py where the
>> classes are stored in python.  I found that the class packet_header2 is
>> defined as *class packet_header2(object)*. So the packet_header2 *isn't*
>> installed as a derived class of *gr::digital::packet_header_default*.  what
>> I expected was *packet_header2(gr::digital::packet_header_default)*.
>>
>> So I'm asking you that how to correctly derive my class (eg:
>> packet_header2) in my own oot module based on a class (eg:
>> packet_header_default) in an existing module (eg: gr-digital)?
>>
>> My packet_header2.h and packet_header2.cc are attached for your reference.
>>
>> Thanks!
>> Best,
>> Zhe
>>
>>
>>
>> ___
>> 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] Packet Encoder-Decoder

[Thanasis Balafoutis]

Hi,
In the followning basic setup:
File Source (Byte) > Packet Encoder (Byte) -> File Sink (byte)

My input file is just a "Hello World" message
If the Repeat property of my file source is set to "No" the File Sink
remains empty Why? Do I have buffering issues?
If I set Repeat="yes" file sink seems to work, But when I insert a Packet
Decoder:

File Source > Packet Encoder ->Packet Decoder -> File Sink

The output file is empty again!

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

Re: [Discuss-gnuradio] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 I should pay closer attention; sorry!

On 07.10.2014 11:16, Martin Braun wrote:
> On 10/07/2014 09:54 AM, Marcus Müller wrote:
>> This looks like a linker error. In your main CMakeList.txt, you
>> have to add DIGITAL to the line containing
>> 
>> set(GR_REQUIRED_COMPONENTS ...
> 
> The OP mentioned he'd already done that, but I still agree with
> your suspicion. It's actually more likely some SWIG/linking issue.
> 
> Are you referencing the correct header files in your SWIG file?
> 
> M
> 
> 
> 
> 
>> If you already have that, sometimes make clean helps, when for
>> some reason linker/ccache/black magic involving CMake failed.
>> 
>> Greetings, Marcus
>> 
>> On 07.10.2014 03:58, Zhe Feng wrote:
>>> Dear all,
>>> 
>>> I'm trying to derive a *packet_header2* class in my own OOT
>>> module based on *gr::digital::packet_header_default*. I
>>> followed the way in *packet_heade_ofdm*  of gr-digital and made
>>> packet_header2.h and packet_header2.cc in my own OOT module.
>>> 
>>> But when I tried to import my_oot in python, it returned an
>>> undefined symbol error like this:
>>> 
>>> Traceback (most recent call last): File "", line 1, in
>>>  File
>>> "/usr/local/lib/python2.7/dist-packages/my_oot/__init__.py",
>>> line 45, in  from my_oot_swig import * File
>>> "/usr/local/lib/python2.7/dist-packages/my_oot/my_oot_cdma.py",
>>> line 26, in  _my_oot_swig = swig_import_helper() File
>>> "/usr/local/lib/python2.7/dist-packages/cdma/cdma_swig.py",
>>> line 22, in swig_import_helper _mod =
>>> imp.load_module('_my_oot_swig', fp, pathname, description) 
>>> ImportError: /usr/local/lib/libgnuradio-my_oot.so: undefined
>>> symbol: _ZTIN2gr7digital21packet_header_defaultE
>>> 
>>> I searched the list and found a previous answered question
>>> below 
>>> http://gnuradio.4.n7.nabble.com/so-undefined-symbol-ZN2gr6blocks12count-bits16E-td46270.html
>>>
>>>
>>> 
where Marcus suggested editing the CMakeList.txt files by adding the module
>>> I needed. So I added
>>> 
>>> *set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)*  in
>>> CMakeLists.txt.
>>> 
>>> and then. This above error disappeared when I import my_oot
>>> again in python. But this problem isn't solved. I tried to
>>> access some functions of packet_header_default like formatter
>>> and base, it returned me an AtrributeError like this:
>>> 
>>> AttributeError: 'packet_header2_sptr' object has no attribute
>>> 'formatter', which means the packet_header2 wasn't really a
>>> derived class of packet_header_default.
>>> 
>>> I confirmed my conjecture by checking the 
>>> /usr/local/lib/python2.7/dist-packages/my_oot/my_oot_swig.py
>>> where the classes are stored in python.  I found that the class
>>> packet_header2 is defined as *class packet_header2(object)*. So
>>> the packet_header2 *isn't* installed as a derived class of
>>> *gr::digital::packet_header_default*.  what I expected was
>>> *packet_header2(gr::digital::packet_header_default)*.
>>> 
>>> So I'm asking you that how to correctly derive my class (eg: 
>>> packet_header2) in my own oot module based on a class (eg: 
>>> packet_header_default) in an existing module (eg: gr-digital)?
>>> 
>>> My packet_header2.h and packet_header2.cc are attached for your
>>> reference.
>>> 
>>> Thanks! Best, Zhe
>>> 
>>> 
>>> 
>>> ___ 
>>> 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUM7IEAAoJEAFxB7BbsDrLiX8H/3gPnytHZ8+TLDJb4zWSj2yR
mn8do7lA7QmuKU5sPq9xUbUyvaN+HhzJFiap1wYop/N7rVP5VESzPFoLrcci23RR
/zfjy+pMyHw4WudpjpBVB0laSwQR6+SjyiKZEl0O/wlWxoTWSGOx5Q18YfOdW/i5
xWWTn9XDU5gmNnPNZElowyIEyG6yy7rpha8lIjzdaV6V5kPdNcw8nopOx4P5gb+z
eUUAF0Z/3UCq5Og7u95hHA2F17hhh1aVy2yTYMU3JA/KpcUq/qk58K50AbS/Ycaw
miFV5hKpMne/AxIPnEIlL2EVwpirGIjgTAbk6vbMfmIz0I5QBPeZDA6fYF4Bk70=
=pGV9
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Bastian Bloessl]

Hi,

I did that in gr-ieee802-11 and IIRC I had to define GR_API in the swig config

https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i#L18

Hope that helps,
Bastian

On 07 Oct 2014, at 11:27, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
>  I should pay closer attention; sorry!
> 
> On 07.10.2014 11:16, Martin Braun wrote:
>> On 10/07/2014 09:54 AM, Marcus Müller wrote:
>>> This looks like a linker error. In your main CMakeList.txt, you
>>> have to add DIGITAL to the line containing
>>> 
>>> set(GR_REQUIRED_COMPONENTS ...
>> 
>> The OP mentioned he'd already done that, but I still agree with
>> your suspicion. It's actually more likely some SWIG/linking issue.
>> 
>> Are you referencing the correct header files in your SWIG file?
>> 
>> M
>> 
>> 
>> 
>> 
>>> If you already have that, sometimes make clean helps, when for
>>> some reason linker/ccache/black magic involving CMake failed.
>>> 
>>> Greetings, Marcus
>>> 
>>> On 07.10.2014 03:58, Zhe Feng wrote:
 Dear all,
 
 I'm trying to derive a *packet_header2* class in my own OOT
 module based on *gr::digital::packet_header_default*. I
 followed the way in *packet_heade_ofdm*  of gr-digital and made
 packet_header2.h and packet_header2.cc in my own OOT module.
 
 But when I tried to import my_oot in python, it returned an
 undefined symbol error like this:
 
 Traceback (most recent call last): File "", line 1, in
  File
 "/usr/local/lib/python2.7/dist-packages/my_oot/__init__.py",
 line 45, in  from my_oot_swig import * File
 "/usr/local/lib/python2.7/dist-packages/my_oot/my_oot_cdma.py",
 line 26, in  _my_oot_swig = swig_import_helper() File
 "/usr/local/lib/python2.7/dist-packages/cdma/cdma_swig.py",
 line 22, in swig_import_helper _mod =
 imp.load_module('_my_oot_swig', fp, pathname, description) 
 ImportError: /usr/local/lib/libgnuradio-my_oot.so: undefined
 symbol: _ZTIN2gr7digital21packet_header_defaultE
 
 I searched the list and found a previous answered question
 below 
 http://gnuradio.4.n7.nabble.com/so-undefined-symbol-ZN2gr6blocks12count-bits16E-td46270.html
 
 
 
> where Marcus suggested editing the CMakeList.txt files by adding the module
 I needed. So I added
 
 *set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)*  in
 CMakeLists.txt.
 
 and then. This above error disappeared when I import my_oot
 again in python. But this problem isn't solved. I tried to
 access some functions of packet_header_default like formatter
 and base, it returned me an AtrributeError like this:
 
 AttributeError: 'packet_header2_sptr' object has no attribute
 'formatter', which means the packet_header2 wasn't really a
 derived class of packet_header_default.
 
 I confirmed my conjecture by checking the 
 /usr/local/lib/python2.7/dist-packages/my_oot/my_oot_swig.py
 where the classes are stored in python.  I found that the class
 packet_header2 is defined as *class packet_header2(object)*. So
 the packet_header2 *isn't* installed as a derived class of
 *gr::digital::packet_header_default*.  what I expected was
 *packet_header2(gr::digital::packet_header_default)*.
 
 So I'm asking you that how to correctly derive my class (eg: 
 packet_header2) in my own oot module based on a class (eg: 
 packet_header_default) in an existing module (eg: gr-digital)?
 
 My packet_header2.h and packet_header2.cc are attached for your
 reference.
 
 Thanks! Best, Zhe
 
 
 
> 

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/


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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

Hi,

I can’t help you much without the code, but did you see the example frame in 
Annex L of the standard?

Maybe it helps you to debug your scripts.

Bastian

On 06 Oct 2014, at 22:19, Ernest Szczepaniak  wrote:

> Ok, so i decoded all of the payload (123 data symbols, de-interleaving every
> one in receiver's loop). After Viterbi and descrambling it gives some
> strange results:
> 
> 7 of SERVICE bits are random - OK (i read in standard that those 7 bits are
> 0's at the transmitter, and will set receivers descrambler to correct
> initial state).
> 9x0's in RESERVED field - OK.
> 
> and now:
> 
> FRAME CONTROL - !incorrect!
> 
> TAIL bit's looks fine (11x0's - 6 zeros from TAIL field and probably 5 PAD
> bits).
> 
> I also checked autocorelation function of received data bits. It indicates
> that there is some cyclicness in payload (every 96 bits function shows a
> simple peak). Assuming that your frame consist of text:Hello world! - its 12
> characters, 8 bits each - together 96 bits repeating sequence, but cant find
> Hello world text.
> 
> Its rather imposible, that those results are correct.
> 
> You have mentioned that i should try with some test sequence (dont have any
> one). If i will try to generate it on my own, i wouldnt be sure that its
> following the standard :(
> 
> PS.
> 
> I was also searching for 48x"1" bit broadcast adress. Found only 43x"1" in
> row. Close but not the same :D
> 
> Best, 
> Ernest
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50639.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] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Bastian Bloessl]

On 07 Oct 2014, at 12:02, Bastian Bloessl  wrote:
> 
> I did that in gr-ieee802-11 and IIRC I had to define GR_API in the swig config

arg, sorry! I had to #define DIGITAL_API and include packet_header_default.h

> 
> https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i#L18

I think that I also had some problems with the swig bindings without those 
includes and defines.


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

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

I am having problems with the clock.
I need to track the real time of the signal. I have tried to get it with a
sample counter and a throttle (to maintain the rate), but it doesn't work.
The clock is faster or slower than the current signal time.

Any idea? ;)

2014-09-23 20:13 GMT+02:00 Tom Rondeau :

> On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com> wrote:
>
>> - SIGNAL: 1023 samples/s
>>
>> - CLOCK: Counter that increments +0.001 when passing 10230 samples.
>>
>> - SATELLITE ORBIT: Calculate the satellite orbit and delay.
>>
>>
>> ​
>>
>
> Ok. My problem with this is that we're trying to get away from using
> streaming data ports for control like this. Changing the state of a block
> should be left to stream tags or messages.
>
> For your application, it might make sense if each data input to the block
> matches to a very quickly-changing delay difference. In that case, though,
> I would suggest that you keep an OOT module with your own implementation of
> the delay block that does this for you.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Circular dependency caught in sort_variables only String type

[Murray Thomson]

Thanks for your comments,

Is there an open issue for this problem? Is this a bug or am I doing
something that I shouldn't?
I cannot hard-code the string because I need to be able to change the IP
address of a UDP Sink block.

Thanks,
Murray





On 6 October 2014 20:02, Chris Kuethe  wrote:

> I ran into this just last week, trying to have editable text fields for
> configuration information ("hackrf=0", "rtl=0", ...) that would be store in
> the config block. I ended up punting on the issue, and just hard-coding
> those strings into my flow graph. Glad to know it wasn't something I did
> wrong.
>
> On Mon, Oct 6, 2014 at 8:00 AM, Tom Rondeau  wrote:
>
>> On Mon, Oct 6, 2014 at 4:39 AM, Murray Thomson <
>> murraythomson...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm getting this error with string type variables using gnuradio 3.7.5
>>> and I cannot figure out how to solve it. I'm using a normal variable plus a
>>> config variable in this way:
>>>
>>> Variable:
>>>id: variable_A
>>>value: config_variable_A
>>>
>>> Variable Config:
>>>id: config_variable_A
>>>...
>>>WriteBack: variable_A
>>>
>>>
>>> This way the variable reads the config file at the start and the
>>> variable config writes the latest value of the variable at the end. It
>>> works very well with Integers.
>>>
>>> When I change the Config variable type to "String" and I generate the
>>> flow graph, I get the error:
>>>
>>> Generate Error: circular dependency caught in sort_variables
>>>
>>> Could anyone please help me to get this behaviour for a String type
>>> variable please?
>>>
>>> Thank you,
>>> Murray
>>>
>>
>> Yeah, this is a fundamental issue with the way that the GRC templates are
>> formatted and described. The circular issue has come up rarely in the past,
>> but it's certainly been a problem for me here and there.
>>
>> Tom
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

Ok, you'll have to explain why you'd need throttle, as this is almost
never the case, especially not when a) working in a simulation or b)
working with "real" hardware, as that usually enforces a sampling rate.
If you know the physical sampling rate, counting samples *must* work,
unless your sampling clock drifts significantly, or you have *really*
fast moving satellites for which relativity is a concern at such low
frequencies.

Anyway, as an advisor told me once, if you want something done
mathematically right, do it mathematically right (that was on the
subject on simulating delay for radar targets):
Transform your signal to frequency domain, multiply it with a complex
sine of the frequency representing your time shift, and transform it
back to time domain. This allows you (within numerical precision of the
complex float and the length of your FFT) to have arbitrary accurate
shifts, to dynamically update the frequency (depending on how you
generate the complex sinusoid) and costs only moderately many ressources
(OK, at roughly 10MS/s, this might still be relevant).

Greetings,
Marcus

On 07.10.2014 12:48, Carlos Alberto Ruiz Naranjo wrote:
> I am having problems with the clock.
> I need to track the real time of the signal. I have tried to get it with a
> sample counter and a throttle (to maintain the rate), but it doesn't work.
> The clock is faster or slower than the current signal time.
>
> Any idea? ;)
>
> 2014-09-23 20:13 GMT+02:00 Tom Rondeau :
>
>> On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com> wrote:
>>
>>> - SIGNAL: 1023 samples/s
>>>
>>> - CLOCK: Counter that increments +0.001 when passing 10230 samples.
>>>
>>> - SATELLITE ORBIT: Calculate the satellite orbit and delay.
>>>
>>>
>>>
>>>
>> Ok. My problem with this is that we're trying to get away from using
>> streaming data ports for control like this. Changing the state of a block
>> should be left to stream tags or messages.
>>
>> For your application, it might make sense if each data input to the block
>> matches to a very quickly-changing delay difference. In that case, though,
>> I would suggest that you keep an OOT module with your own implementation of
>> the delay block that does this for you.
>>
>> Tom
>>
>>
>
>
> ___
> 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] Question on how to derive a class in an out-of-tree module based on a gnuradio class

[Zhe Feng]

Hi Marcus, Martin and Bastian,

Thanks for your help!

You are right, it's a linker error, the reason is absolutely what Martin
mentioned that I didn't refer the header files I used i.e
packet_header_default.h in my swig file.
I checked Bastian's swig file and made this class working as expected!

Thanks again!
Best,
Zhe

On Tue, Oct 7, 2014 at 6:39 AM, Bastian Bloessl 
wrote:

>
> On 07 Oct 2014, at 12:02, Bastian Bloessl  wrote:
> >
> > I did that in gr-ieee802-11 and IIRC I had to define GR_API in the swig
> config
>
> arg, sorry! I had to #define DIGITAL_API and include
> packet_header_default.h
>
> >
> >
> https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i#L18
>
> I think that I also had some problems with the swig bindings without those
> includes and defines.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Zhe Feng

Electrical Engineering: System

University of Michigan Ann Arbor

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

[Discuss-gnuradio] GNURadio or Labview interface to USRP N210/N200

[Sagar Simha]

Hello All,

I have Ettus Research N210 and N200. I have been running GNURadio on USRP.
I wanted to experiment with LabView. I have two questions,

1) Is it possible to run the firmware given by NI in the below link on N210
or N200

http://www.ni.com/download/ni-usrp-1.1/2949/en/

2) If the above is possible, would I be able to flash the UHD firmware back
on the USRPN210/N200?


Thanks,

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

Re: [Discuss-gnuradio] GNURadio or Labview interface to USRP N210/N200

[Martin Braun]

For LabView questions, you probably want the usrp-users mailing list.

Gist of it: You can flash firmwares back and forth, but you might not
even need to change the firmware depending on which version you're
running. Give it a try, you can't break anything.

M

On 10/07/2014 03:25 PM, Sagar Simha wrote:
> 
> Hello All,
> 
> I have Ettus Research N210 and N200. I have been running GNURadio on
> USRP. I wanted to experiment with LabView. I have two questions,
> 
> 1) Is it possible to run the firmware given by NI in the below link on
> N210 or N200
> 
> http://www.ni.com/download/ni-usrp-1.1/2949/en/
> 
> 2) If the above is possible, would I be able to flash the UHD firmware
> back on the USRPN210/N200?
> 
> 
> Thanks,
> 
> Sagar
> 
> 
> ___
> 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] CC encoder definition (variable_cc_encoder_def)

[David Halls]

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don't expect any sympathy 
but there is a reason why we can't upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading...

I can't get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
'variable_cc_encoder_def_list.xml'. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




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

Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

[David Halls]

The problem appears to be using  and  in the xml files.

Presumably this is a new(ish) additional functionality in GNU Radio, which my 
old version can’t parse?

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of David Halls
Sent: 07 October 2014 15:21
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don’t expect any sympathy 
but there is a reason why we can’t upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading…

I can’t get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




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




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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

Nope, 

Any way to get it? Is it downloadable?

Should be helpfull indeed.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50661.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] CC encoder definition (variable_cc_encoder_def)

[Tom Rondeau]

On Tue, Oct 7, 2014 at 10:40 AM, David Halls 
wrote:

>  The problem appears to be using  and  in the xml
> files.
>
>
>
> Presumably this is a new(ish) additional functionality in GNU Radio, which
> my old version can’t parse?
>

Yes, those are new in 3.7 (3.7.4, I think but would have to check to
verify). It's a way of letting us build objects within GRC and use them as
such in other areas of the flowgraph. So you can define an FEC variable and
call methods on it, like cc.K() to get the CC's constraint length.

You can probably remove these from the .xml files and lose that
functionality. It's a nice convenience but not necessary. You can replace
it by having another variable, say for K, and use that in any place you
might require it instead of pulling it straight from the CC variable itself.

Tom



>
>
> *From:* discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
> [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] *On
> Behalf Of *David Halls
> *Sent:* 07 October 2014 15:21
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] CC encoder definition
> (variable_cc_encoder_def)
>
>
>
> Dear All,
>
>
>
> I am trying to get the latest gr-fec code running in an older version of
> GNU Radio. I know this sounds like a terrible idea, and I don’t expect any
> sympathy but there is a reason why we can’t upgrade to the newest GNU
> Radio, due to some legacy issues.
>
>
>
> If you are still reading…
>
>
>
> I can’t get the CC Encoder Definition block to appear in GNU Radio, we are
> using 3.7.2. I have copied the whole of the gr-fec folder from the latest
> install including the grc folder which contains
> ‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally
> missing from older version of GNU Radio to support this kind of definition
> block?
>
>
>
> Thanks!
>
>
>
> David
>
>
>
> ---
>
> David Halls Ph.D.
>
> Research Engineer
>
> Toshiba Research Europe Limited
>
> 32 Queen Square, Bristol, BS1 4ND, UK
>
> Tel: +44 (0) 117 906 0790
>
>
>
>
>  --
>
>
> 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
>  --
>
> --
>
> 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

Re: [Discuss-gnuradio] Circular dependency caught in sort_variables only String type

[Tom Rondeau]

On Tue, Oct 7, 2014 at 8:14 AM, Murray Thomson 
wrote:

> Thanks for your comments,
>
> Is there an open issue for this problem? Is this a bug or am I doing
> something that I shouldn't?
> I cannot hard-code the string because I need to be able to change the IP
> address of a UDP Sink block.
>
> Thanks,
> Murray
>


It's not really a bug since it's part of the design of the variables.
However, it could be a feature in a future release of GRC. We're working on
overhauling GRC in a number of ways that might help us better support this.
Instead of making this an Issue in our Issue tracker, probably better for
the GRC Roadmap:

http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap

Thanks,
Tom




> On 6 October 2014 20:02, Chris Kuethe  wrote:
>
>> I ran into this just last week, trying to have editable text fields for
>> configuration information ("hackrf=0", "rtl=0", ...) that would be store in
>> the config block. I ended up punting on the issue, and just hard-coding
>> those strings into my flow graph. Glad to know it wasn't something I did
>> wrong.
>>
>> On Mon, Oct 6, 2014 at 8:00 AM, Tom Rondeau  wrote:
>>
>>> On Mon, Oct 6, 2014 at 4:39 AM, Murray Thomson <
>>> murraythomson...@gmail.com> wrote:
>>>
 Hi,

 I'm getting this error with string type variables using gnuradio 3.7.5
 and I cannot figure out how to solve it. I'm using a normal variable plus a
 config variable in this way:

 Variable:
id: variable_A
value: config_variable_A

 Variable Config:
id: config_variable_A
...
WriteBack: variable_A


 This way the variable reads the config file at the start and the
 variable config writes the latest value of the variable at the end. It
 works very well with Integers.

 When I change the Config variable type to "String" and I generate the
 flow graph, I get the error:

 Generate Error: circular dependency caught in sort_variables

 Could anyone please help me to get this behaviour for a String type
 variable please?

 Thank you,
 Murray

>>>
>>> Yeah, this is a fundamental issue with the way that the GRC templates
>>> are formatted and described. The circular issue has come up rarely in the
>>> past, but it's certainly been a problem for me here and there.
>>>
>>> Tom
>>>
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

[David Halls]

From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau 
[t...@trondeau.com]
Sent: 07 October 2014 16:27
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

On Tue, Oct 7, 2014 at 10:40 AM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
The problem appears to be using  and  in the xml files.

Presumably this is a new(ish) additional functionality in GNU Radio, which my 
old version can’t parse?

Yes, those are new in 3.7 (3.7.4, I think but would have to check to verify). 
It's a way of letting us build objects within GRC and use them as such in other 
areas of the flowgraph. So you can define an FEC variable and call methods on 
it, like cc.K() to get the CC's constraint length.

You can probably remove these from the .xml files and lose that functionality. 
It's a nice convenience but not necessary. You can replace it by having another 
variable, say for K, and use that in any place you might require it instead of 
pulling it straight from the CC variable itself.

Tom


Thanks Tom, that is a useful piece of functionality indeed. I commented out the 
 and  and have instead

"self.$(id) = $(id) = fec.cc_encoder_make($framebits, $k, $rate, $polys, 
$state_start, $mode, $padding)"

Is that OK? I can also manually create the Encoder Objects variable as

fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,  
fec.CC_TERMINATED, padding)

how would I add the parallelism

(fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,  
fec.CC_TERMINATED, padding);fec.cc_encoder_make(frame_size*8, k, rate, (polys), 
start_state,  fec.CC_TERMINATED, padding))

or similar?


From: 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org]
 On Behalf Of David Halls
Sent: 07 October 2014 15:21
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don’t expect any sympathy 
but there is a reason why we can’t upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading…

I can’t get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




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




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




NOTE: The information in this email and any attachments may be confidential 
and/or le

Re: [Discuss-gnuradio] Circular dependency caught in sort_variables only String type

[Murray Thomson]

Thanks for the explanation Tom.

Regards,
Murray

On 7 October 2014 16:30, Tom Rondeau  wrote:

> On Tue, Oct 7, 2014 at 8:14 AM, Murray Thomson  > wrote:
>
>> Thanks for your comments,
>>
>> Is there an open issue for this problem? Is this a bug or am I doing
>> something that I shouldn't?
>> I cannot hard-code the string because I need to be able to change the IP
>> address of a UDP Sink block.
>>
>> Thanks,
>> Murray
>>
>
>
> It's not really a bug since it's part of the design of the variables.
> However, it could be a feature in a future release of GRC. We're working on
> overhauling GRC in a number of ways that might help us better support this.
> Instead of making this an Issue in our Issue tracker, probably better for
> the GRC Roadmap:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap
>
> Thanks,
> Tom
>
>
>
>
>> On 6 October 2014 20:02, Chris Kuethe  wrote:
>>
>>> I ran into this just last week, trying to have editable text fields for
>>> configuration information ("hackrf=0", "rtl=0", ...) that would be store in
>>> the config block. I ended up punting on the issue, and just hard-coding
>>> those strings into my flow graph. Glad to know it wasn't something I did
>>> wrong.
>>>
>>> On Mon, Oct 6, 2014 at 8:00 AM, Tom Rondeau  wrote:
>>>
 On Mon, Oct 6, 2014 at 4:39 AM, Murray Thomson <
 murraythomson...@gmail.com> wrote:

> Hi,
>
> I'm getting this error with string type variables using gnuradio 3.7.5
> and I cannot figure out how to solve it. I'm using a normal variable plus 
> a
> config variable in this way:
>
> Variable:
>id: variable_A
>value: config_variable_A
>
> Variable Config:
>id: config_variable_A
>...
>WriteBack: variable_A
>
>
> This way the variable reads the config file at the start and the
> variable config writes the latest value of the variable at the end. It
> works very well with Integers.
>
> When I change the Config variable type to "String" and I generate the
> flow graph, I get the error:
>
> Generate Error: circular dependency caught in sort_variables
>
> Could anyone please help me to get this behaviour for a String type
> variable please?
>
> Thank you,
> Murray
>

 Yeah, this is a fundamental issue with the way that the GRC templates
 are formatted and described. The circular issue has come up rarely in the
 past, but it's certainly been a problem for me here and there.

 Tom


 ___
 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building with MSVC v16

[Gisle Vanem]

"Tom Rondeau"  wrote:


Just to begin with, we do not currently have good support and testing for
Windows systems and are actively discussing how to handle this OS. I
believe that any support for Windows at all, such as through the current
binaries provided by Ettus Research, require VS 2012 or something (really
not sure, but I believe later than what you're using).


I use VS 2010 and Ettus, yes seems to be using VS 2012. I fail to see why
VS 2010 isn't good enough. It was little tweaking to get it to work.


No they add nothing and I'm not a fan of them. My guess is that some of it
was that code was prototyped in Python and converted over to C++ and these
were carried along with it. It's a hard thing to grep for, but I'll be
patching a few of the cases that I found.


Adding a "#include " to my specially crafted "config.h" fixed that.
GCC includes that unconditionally (thanks to Josh Blum for tipping me on that).

--gv

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

[Discuss-gnuradio] Using volk

[Mostafa Alizadeh]

Hello all,

I wondered about volk. I want it to compute mean to peak value of a complex
array. How could I do this?
Besides, I really need to know is there any example of using volk? The code
itself, doesn't reflect input and output parameters explicitly.

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

[Discuss-gnuradio] Gnuradio DCS Module

[Martin Holst Swende]

Hi list,

I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a
startup experiment, I wanted to communicate with simple handheld radio
devices (toy radios). These radios used DCS, and in order for my
computer to bypass their squelch, I need to
1) Determine DCS-code
2) Add DCS to my transmissions

Since I didn't find any suitable tools for that (?), I have now
implemented a gnuradio module to decode DCS. The source code is at
bitbucket [1].

I started out by implementing the DCS decoder via a message block in
python. This seemed a bit hacky, so I decided to implement it in C++
instead following the "Out-of-tree modules" tutorial [2]. In the end, I
implemented it as a Stream Tag block. My thought was that it would add
tags to an audio stream, and a UI component somewhere would pick up the
tags and display to the user (needless to say, a DCS-squelch could be
built using the tagged stream).

I now have a few question, both regarding the digital signal processing
in general, and regarding gnuradio.

1. Currently, my block takes digital input. Here [3] you can see a
picture of how I go from 960 hz sampled audio stream via DC-blocker,
thresholding , interpolation and decimation into a digital signal (to
the 'old' message sink). In the next stage, I'd like to take an audio
source (with a few selectable common audion samplerates) instead, which
means that my block must do all those things within the block itself.
How is this normally done? Do I create a hierarchical block containing
these blocks "under the hood", plus my new digital-in-DCS-decode block?

2. Does it make sense to have DCS as a tagged stream? Should I chose
some other type to communicate DCS ?

3. Are there better ways to extract the digital signal from the audio
source than my schematic above? Am I doing something stupid?

4. Are there any suitable UI-components I can use to display DCS
information - e.g. something which show information from streamed tags ,
or mechanisms to modify variables based on tag info?

Grateful for suggestions and ideas.
Martin Holst Swende


[1] https://bitbucket.org/holiman/gnuradio-dcs
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
[3] http://martin.swende.se/graph_part.png

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

Re: [Discuss-gnuradio] Gnuradio DCS Module

[Jeff Long]

Martin,

Some ideas inline ... hope some of this is useful.

On 10/07/2014 03:30 PM, Martin Holst Swende wrote:

Hi list,

I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a
startup experiment, I wanted to communicate with simple handheld radio
devices (toy radios). These radios used DCS, and in order for my
computer to bypass their squelch, I need to
1) Determine DCS-code
2) Add DCS to my transmissions

Since I didn't find any suitable tools for that (?), I have now
implemented a gnuradio module to decode DCS. The source code is at
bitbucket [1].

I started out by implementing the DCS decoder via a message block in
python. This seemed a bit hacky, so I decided to implement it in C++
instead following the "Out-of-tree modules" tutorial [2]. In the end, I
implemented it as a Stream Tag block. My thought was that it would add
tags to an audio stream, and a UI component somewhere would pick up the
tags and display to the user (needless to say, a DCS-squelch could be
built using the tagged stream).

I now have a few question, both regarding the digital signal processing
in general, and regarding gnuradio.

1. Currently, my block takes digital input. Here [3] you can see a
picture of how I go from 960 hz sampled audio stream via DC-blocker,
thresholding , interpolation and decimation into a digital signal (to
the 'old' message sink). In the next stage, I'd like to take an audio
source (with a few selectable common audion samplerates) instead, which
means that my block must do all those things within the block itself.
How is this normally done? Do I create a hierarchical block containing
these blocks "under the hood", plus my new digital-in-DCS-decode block?


There's no right way. You can make a hier block in GRC, Python, C++, or 
leave it in the top level flow graph. GRC hier block is the easiest if 
it works for you.




2. Does it make sense to have DCS as a tagged stream? Should I chose
some other type to communicate DCS ?


The choice of messages or tagged streams has to do with how you want to 
process the data downstream. If a downstream block needs the info 
associated with a sample (like a squelch) then tags are good. If it's 
thought of more as data (like for logging) then messages are good. There 
is also a tag-to-message block, so you can have it both ways.




3. Are there better ways to extract the digital signal from the audio
source than my schematic above? Am I doing something stupid?


A low pass filter should be used to cut out voice. A rational resampler 
can replace the interpolate and 1-in-N blocks. You could combine the LPF 
and DC blocker into the taps for the resampler if you want to get fancy. 
The threshold can go after the resampler.


I'm not familiar with DCS, but typically a synchronizer block of some 
sort is used before the bits are processed. Otherwise, your bit 
alignment is due to luck (or short sequences).




4. Are there any suitable UI-components I can use to display DCS
information - e.g. something which show information from streamed tags ,
or mechanisms to modify variables based on tag info?


The QT time sink will display tags.



Grateful for suggestions and ideas.
Martin Holst Swende


[1] https://bitbucket.org/holiman/gnuradio-dcs
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
[3] http://martin.swende.se/graph_part.png

___
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