From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Saturday, October 13, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 13
Send Discuss-gnuradio mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Problem with vector insert (Volker Schroer)
2. Re:
Problem with vector insert (Tom Rondeau)
3. usrp_nbfm_ptt.py in Gnu Radio Companion. (Sajjad Safdar)
4. Re: usrp_nbfm_ptt.py in Gnu Radio Companion. (Martin Braun (CEL))
5. Re: Can the io signatur of the gnuradio blocks be dynamically
updated? (Alex Zhang)
6. Re: [ USRP configuration with/without MIMO in unshared
Ethernet mode ] (Ashish Raste)
7. Re: cannot make new signal processing block (nexy_sm)
8. grextras "make test" failure (Rick Graham)
9. Re: grextras "make test" failure (Josh Blum)
10. OOK Modulation (sibar002)
11. OOK Modulation (sibar002)
12. Re: Can the io signatur of the gnuradio blocks be dynamically
updated? (Alex Zhang)
13. Re: GRC: set order of block instantiations (Josh
Blum)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Oct 2012 18:02:59 +0200
From: Volker Schroer <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Problem with vector insert
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hi all,
I just tried to play around with the vector insert block.
It works if the elements are of type byte.
But if I try another type such as int I get the error
File "./top_block.py", line 29, in __init__
self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4,
3)
AttributeError: 'module' object has no attribute 'vector_insert_i'
If I look into the build directory I see only gr_vector_insert _b.* files.
So I tried to modify the generate_common.py in
gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find
the proper place. Only gr_vector_insert _b.* files will be generated.
Any ideas ?
Thanks -- Volker
------------------------------
Message: 2
Date: Fri, 12 Oct 2012 12:06:37 -0400
From: Tom Rondeau <
address@hidden>
To: Volker Schroer <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Problem with vector insert
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 12:02 PM, Volker Schroer <
address@hidden> wrote:
> Hi all,
>
> I just tried to play around with the vector insert block.
> It works if the elements are of type byte.
> But if I try another type such as int I get the error
>
> File "./top_block.py", line 29, in __init__
> self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4, 3)
> AttributeError: 'module' object has no attribute 'vector_insert_i'
>
> If I look into the build directory I see only gr_vector_insert _b.*
files.
>
> So I tried to modify the generate_common.py in
> gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find the
> proper place. Only gr_vector_insert _b.* files will be generated.
>
> Any ideas ?
>
> Thanks -- Volker
Volker,
Take a look at gengen/CMakeLists.txt on line 85. You should just be
able to add the data types you want there. Depending on the guys of
the vector_insert block, you should be able to use any of the standard
data types.
Tom
------------------------------
Message: 3
Date: Fri, 12 Oct 2012 09:13:52 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio Companion.
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not sure whether I have translated the code into graphical manner right or there is something wrong, because there is always error.??
Screen shoot is attached for reference.
Best Regards,
SAJJAD SAFDAR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ptt_recieve.grc.png
Type: image/png
Size: 98289 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.png>
------------------------------
Message: 4
Date: Fri, 12 Oct 2012 18:30:09 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio
Companion.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Fri, Oct 12, 2012 at 09:13:52AM -0700, Sajjad Safdar wrote:
> I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not
> sure whether I have translated the code into graphical manner right or there is
> something wrong, because there is always error.
In that case, there's probably something wrong :)
Everything that's marked red, you must check. Also, check the error
messages. Perhaps you haven't set the rates to integer values?
MB
--
Karlsruhe Institute of Technology
(KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/f9fb238d/attachment.pgp>
------------------------------
Message: 5
Date: Fri, 12 Oct 2012 11:39:04 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
blocks be dynamically updated?
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom, thanks for the response, but I am still have questions regarding
your
comments as below inline:
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically
adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
>
It seems that the event stream scheduler can only handle finite
options for
selection?
This is different with what I am expecting. Sometimes, you don't know the
actual options and the dynamic parameters is computed based on some other
optimization algorithm. Thus I can not pre-configure finite graphs for my
selection, but just adjust the exiting graph with specified parameter.
BTW, maybe my expectation is kind of over-design which brings more risk
than benefits. But from the Software defined radio perspective, the
dynamic/adaptive signal processing chain with expecting flexibility really
deserves more attention.
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks
framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just believe.
>
>>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/829cfe67/attachment.html>
------------------------------
Message: 6
Date: Sat, 13 Oct 2012 01:06:04 +0800
From: Ashish Raste <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
in unshared Ethernet mode ]
Message-ID:
<CALAnUMTS-qjq+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
*Thanks Josh.
Now I've got a
clear idea on how the MIMO acts in different Ethernet
configurations**.
*
>
>
> Message: 1
> Date: Thu, 11 Oct 2012 11:34:39 -0700
> From: Josh Blum <
address@hidden>
> To:
address@hidden> Subject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
> in unshared Ethernet mode ]
> Message-ID: <
address@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> > received/transmitted via its own Ethernet interface and the master?s
> > basedband data within the GRC design is received/transmitted via its own
> > Ethernet
interface? So, this means that the MIMO cable is only used for
> > sending the clock and time signals from the Master to the Slave ?*
>
> Thats correct. When each USRP has its own ethernet link, the MIMO cable
> is only used for clock and time signals.
>
> >
> > * *
> >
> > *Next, I retained the MIMO cable, set the Master USRP?s clock source to
> > external and have a 10MHz source connected to the Reference input. The
> > slave USRP?s clock source and time source remained as MIMO mode. So my
> > question is would the Slave USRP received the 10MHz Reference via the
> MIMO
> > cable ? *
> >
>
> Yes. The slave device will still get 10MHz over the MIMO cable. This is
> regardless of how the master gets his reference.
>
> > * *
> >
> > *My second question is:
>
> In a 4X4 USRP setup, how can we synchronize all the 4 USRPs without a
> MIMO
> > connection (between 2 USRPs within a pair), using a 10MHz reference split
> > to each of the USRP and a PPS source?
>
> Yes, you can split 10MHz and PPS signal to all 4 units.
>
>
--
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121013/67039a4d/attachment.html>
------------------------------
Message: 7
Date: Fri, 12 Oct 2012 11:04:57 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Python path is OK. Gnuradio works fine, I have tried some examples using GRC,
etc.
I also used gr-modtool like it was explained on the website.
I haven't looked at swig interface file since it was not part of the
tutorial, but I think it should have been generated correctly by gr-modtool.
How can I check installation of the SWIG?
Anyway I will not have chance to try anything until monday.
Regards and thanks
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37982.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 8
Date: Fri, 12 Oct 2012 17:06:52 -0400
From: Rick Graham <
address@hidden>
To: gnuradio <
address@hidden>
Subject: [Discuss-gnuradio] grextras "make test" failure
Message-ID:
<CAF+zCGQ+Hj8X9WVpemCUybZ7xv-dbPNd=
address@hidden>
Content-Type: text/plain;
charset=ISO-8859-1
Is this a cause for concern?
[from "ctest -V"]
Start 4: qa_noise_source
4: Test command: /bin/sh
"/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
4: Test timeout computed to be: 9.99988e+06
4: linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
Boost_104700; UHD_003.004.003-255-gc7054ce5
4:
4: F
4: ======================================================================
4: FAIL: test_001 (__main__.test_noise_source)
4: ----------------------------------------------------------------------
4: Traceback (most recent call last):
4: File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
line 55, in test_001
4: self.assertEqual (expected_result, dst_data)
4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
(-6.88858699798584, 26.1499595...
4:
4: First differing
element 10:
4: 1.21760773659
4: 1.21761083603
4:
4: (-6.88858699798584,
4: 26.149959564208984,
4: 20.575775146484375,
4: -7.934014320373535,
4: 5.335927486419678,
4: -12.552099227905273,
4: 6.333674430847168,
4: -23.830753326416016,
4: -16.603046417236328,
4: 2.9676761627197266,
4: - 1.2176077365875244,
4: + 1.2176108360290527,
4: 15.100193977355957)
4:
4: ----------------------------------------------------------------------
4: Ran 1 test in 0.008s
4:
4: FAILED (failures=1)
4/9 Test #4: qa_noise_source ..................***Failed 0.35 sec
------------------------------
Message: 9
Date: Fri, 12 Oct 2012 14:37:12 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] grextras "make test" failure
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/12/2012 02:06 PM, Rick Graham wrote:
> Is this a cause for concern?
Nah, just a slight rounding issue. And in one of the blocks that doesnt
even need predictable output :-) I will take a look...
-josh
>
> [from "ctest -V"]
> Start 4: qa_noise_source
>
> 4: Test command: /bin/sh
> "/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
> 4: Test timeout computed to be: 9.99988e+06
> 4:
linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
> Boost_104700; UHD_003.004.003-255-gc7054ce5
> 4:
> 4: F
> 4: ======================================================================
> 4: FAIL: test_001 (__main__.test_noise_source)
> 4: ----------------------------------------------------------------------
> 4: Traceback (most recent call last):
> 4: File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
> line 55, in test_001
> 4: self.assertEqual (expected_result, dst_data)
> 4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
> (-6.88858699798584, 26.1499595...
> 4:
> 4: First differing element 10:
> 4: 1.21760773659
> 4: 1.21761083603
> 4:
> 4: (-6.88858699798584,
> 4: 26.149959564208984,
> 4: 20.575775146484375,
> 4:
-7.934014320373535,
> 4: 5.335927486419678,
> 4: -12.552099227905273,
> 4: 6.333674430847168,
> 4: -23.830753326416016,
> 4: -16.603046417236328,
> 4: 2.9676761627197266,
> 4: - 1.2176077365875244,
> 4: + 1.2176108360290527,
> 4: 15.100193977355957)
> 4:
> 4: ----------------------------------------------------------------------
> 4: Ran 1 test in 0.008s
> 4:
> 4: FAILED (failures=1)
> 4/9 Test #4: qa_noise_source ..................***Failed 0.35 sec
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 10
Date: Fri, 12 Oct 2012 14:39:41 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37985.htmlSent from the GnuRadio mailing list archive at
Nabble.com.
------------------------------
Message: 11
Date: Fri, 12 Oct 2012 14:43:54 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello,
I am working on creating a OOK Modulation block. I have created a block
using the bpsk.py file as an example. I changed the constellation points
such that 1+0j and 0+0j. I am now trying to change the waveform that is
outputted from the USRP. I would like to transmit a square wave for 1 and
nothing for 0.
I am not sure how I can do these. I would greatly appreciate
any help or advise that any one could give me. Thank you for your time and
help.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37986.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 12
Date: Fri, 12 Oct 2012 16:57:52 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
blocks be dynamically updated?
Message-ID:
<CA+FEAnciERbLpgKtJ-_=5Tvbp-JfgNuJ=
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom,
There is the other thing I need to confirm:
It looks that the block's output buffer size can not be changed after its
construction, right?
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose
samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks
framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just believe.
>
>>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/a6561e96/attachment.html>
------------------------------
Message: 13
Date: Fri, 12 Oct 2012 18:39:18 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] GRC: set order of block instantiations
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/11/2012 12:03 PM, Gerald Baier wrote:
> Hi list,
>
> is there a way to set the order of block instantiations in GNU Radio
> companion?
> The reason I am asking is, that I want to pass one block as a
parameter
> to another block to get access to its methods. Is there an easier way to
> do this?
I think the order is either 1) alphabetical or 2) the z dimension of the
blocks in the flowgrah.
>
> Somehow related: Variables configured in GRC are defined before the
> block instantiations. Is it possible to tell GRC where in the final
> python script a variable should be defined?
>
The variable blocks are sorted by order of dependency amongst each other.
-josh
> Best regards
>
> Gerald
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 119, Issue 13
*************************************************