[Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open!

[John Malsbury]

Greetings,

We just wanted to let everyone know that registration for GNU Radio
Conference 2014 is now open.  Here is a quick overview of the event for
those of you who have missed previous announcements:

*Date: *September 15-19, 2014

*Location: *The District Architecture Center  in
Washington, DC (USA) - an interesting, modern event facility. Unlike
previous conference values, we will be renting out an entire floor and will
have access to several divided spaces that will allow us to add new
components to the conference.

 *Attendance:*  We are expecting to have somewhere between 120 and 150
attendees.  A great mix of new users, experienced developers, students,
professors, engineers and researchers.  This is the perfect mix  for
everyone to share their experiences with GNU Radio, learn more about it,
and help build the future of SDR.

*New Components: *Hacker/demo space, poster session, 'New Developers Day'
to attract new/beginning users, an open lounge for people to socialize and
mingle, and daily working groups.
For more information, and links to the registration page, please see the GNU
Radio Conference Website .  We will be
posting a preliminary agenda, and more details about the facility soon.

I'd also like to take this opportunity to remind everyone about the Call
for Presentations ,
which is open until March 31.  We've seen some great submissions up to this
point, and look forward to receiving more!

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

[Discuss-gnuradio] gr-ctrlport

[Abhishek Bhowmick]

I am building GNU Radio 3.7.3 from source and wish to
enable the CTRLPORT module. I have already installed
Ice-3.5.1 for C++ in the location /opt/Ice-3.5.1
(satisfying required dependencies)
My current gcc version is 4.8.1
But, cmake is not able to locate ice 3.5.1 and hence disables support
for gr-ctrlport.
I tried by passing the flags, -DICE_MANUALL_INSTALL_PATH=/opt/Ice-2.5.1/
and -DENABLE_GR_CTRLPORT=ON, but to no avail. Any suggestions ?

Here is the relevant cmake output :

--
-- Python checking for Ice >= 3.5
-- Python checking for Ice >= 3.5 - not found
-- ICE 3.5 not found. Looking for 3.4
--   package 'Ice-3.4' not found
-- 
-- Configuring gr-ctrlport support...
--   Dependency Boost_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency ICE_FOUND =
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Disabling gr-ctrlport support.
--   Override with -DENABLE_GR_CTRLPORT=ON/OFF


I couldn't build python extensions for ice 3.5.1 on ubuntu 12.04 (something
wrong with the tarball available for download). Has anyone got this to work
correctly ?
Else, do I have to revert to ice 3.4.x with something less than gcc-4.6 ?

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

[Discuss-gnuradio] Controlport error in GRC

[sarankumar]

Hi,
I am trying to run a GRC flow graph with control port probe and control
port monitor.
I get the following error in GRC:

Traceback (most recent call last):
  File "/usr/local/bin/gr-ctrlport-monitor", line 30, in 
from gnuradio.ctrlport.IceRadioClient import *
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
line 27, in 
from gnuradio.ctrlport import GNURadio
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadio/__init__.py",
line 8, in 
import gnuradio_ice
  File "/usr/local/lib/python2.7/dist-packages/gnuradio_ice.py", line 98,
in 
_M_gnuradio.ctrlport.GNURadio._t_Knob =
IcePy.defineClass('::GNURadio::Knob', Knob, -1, (), False, False, None, (),
())
TypeError: function takes exactly 7 arguments (9 given)

can anyone help me with the problem?
GNU Radio companion version: 3.7.4

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

Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Florian,

the generic implementation serves 2 purposes, at least in my opinion.
Firstly, in case the necessary hardware extension is not available on
the target hardware, there is a backup default.
Secondly, the generic implementation is usually easier to read and
thus preferable as a reference. I know that this is a 'the code is the
documentation' argument. But even though documentation might be really
good, sometimes looking at the code just makes things clearer.

happy hacking
Johannes

On 11.03.2014 23:08, Florian Kaltenberger wrote:
> Hi Nathan and Abhishek,
> 
> On 10/03/2014 23:22, West, Nathan wrote:
>> Ah! So there was a slight miscommunication. Yes, porting the
>> OpenAirInterfaces SIMD code to VOLK is a good option as well. The
>> turbo channel coder/decoder is part of that. I've *briefly*
>> looked at the code to see what is currently there, and it's my
>> understanding that the work involved will be to write generic C
>> implementations of vectorized code where the generic version does
>> not exist. Beyond that porting to newer/different ISAs (AVX or
>> NEON depending on your preference and hardware availability). I
>> think Florian is on the gr-discuss mailing list, but I've CCed
>> him to hopefully provide more details as he's more familiar with
>> the original code base.
> I only joined this mailing list recently, so I probably missed a
> part of the discussion. Let me summarize briefly what
> OpenAirInterface can provide. We have optimized SIMD (SSE4)
> implementations of the LTE turbo encoder and decoder as well as the
> LTE tail-biting Viterbi encoder and decoder. We also have the
> 802.11 Viterbi encoder and decoder. The only functions for which we
> have generic non-vectorized functional equivalents is the LTE turbo
> decoder. I am not sure I understand why it is necessary to write
> generic versions for the already optimized SIMD code. My idea was
> to port the optimized SIMD code from OpenAirInterface to VOLK, such
> that is can be used by GR applications. I am not familiar with VOLK
> (yet) but this might just be as easy as writing a wrapper
> function. As Nathan suggested, the more interesting part is
> probably to upgrade the code to AVX2 or similar.
> 
> Cheers, Florian.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTH56MAAoJEO7fmkDsqywMb+AP/jNXrJoV7Cs6wY7Cx9AHkllM
NEo1mxxBhaALsxWv9xwTImaGpA83guiBZ8o0CufYj65oN/i1mN8dUHgK9D/SlLSn
GhWTZSBlBiVvIUtxFskDaAA0sqg/2Ae+iYoDKm0yxJerU49K5YGrTBFhzgl7i/r5
fZz+BIGPm29rP1kHyRfw/ROmonXOlz1z+jIR7PGK7DEQbw/Uy9eITchVVKMNsdjm
X73+vJHF9UXftzbpwEF/CsgwWVnTvWEVy3YjvxaKRMET/2zQWtEJst51l+aVWFLp
M4ejRtf4zmuSBx5JUMf0/eY1lnNWUkqdlcEaLkddalDwl5chkkfxtS+Gwd6YEqJH
pdqIa7BfHMaPwrKJ/bX3Wp9u9czWcwI9c8A9GjxnFrASIy2g+QLzU21XDdmImFWm
iqaOB0p+/y6bK/V91a4ZjL9gtTBRahlmlmB2EIcPsxlnW+PjJZKNPA833BkuqEE8
gU7w9diq5nbEQYhsvxeqz0WX16yZNwJlz98ane8+oZaVNt9JRI0cjuj0JX24EEPT
9wUfPkmnr1325NJISFJx8X7w2mAQV3zrf5Md1wOfI6Ls9Byfp8+WjeRYrTfzC95b
kXvcTVID0XZdoTItSjQUEbbJAbl8IkfwWaQCNgHCcJzfZLdJ2hHy7RqpiBAkMmAv
QzLU1GZSSHXzEPKUI1fM
=INm4
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] looping with work() function

[Activecat]

Dear Sumedha Goyal,

On Wed, Mar 12, 2014 at 1:51 AM, Sumedha Goyal  wrote:
> 1. There is a file source that frames data packets for the test_demo. This
> is part of a transmitter USRP.
> 2. I have another USRP as receiver that sends an ACK upon reception of data
> packets to the transmitter.
> 3. Start sign is a threshold value. If the packet information (calculated by
> some method) exceeds this threshold, transmission starts and upon receiving
> an ACK stops.

It sounds like you are trying to transfer file from PC#1 to PC#2,
connected via USRPs.
At PC#1, user payload is read from a file on harddisk. This data is
fed into a custom block. This block will start transmitting when
certain criteria is met. When PC#2 receive the packets, it will send
ACK back to PC#1.

If this is what you try to accomplished, of course this could be
implemented by gnuradio.
There are thousands of such setup being tested using gnuradio.

You should have told us the big picture, let us figure out the
implementation details for you, not the opposite way.
Forget about your initial python code because that limit us to dead end.

> 4. I change this threshold value for every new iteration and count how many
> packets were transmitted before receiving a success ACK.
> I can do this manually for every iteration but how to automate it for say
> some 1000 iterations?

When you automate it you must have a calculation formula or decision algorithm.
Please give a simple example of such calculation formula.

Now I am still in the midst of trying to understand your requirements correctly.

Meanwhile, please do not top-post.
Refer 
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors#How-should-I-format-my-message

Regards,
Activecat

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

[Discuss-gnuradio] FW: output operand requires a reduction, but reduction is not enabled

[David Halls]

From: David Halls
Sent: 11 March 2014 16:10
To: Martin Braun; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

Hi,

Yes, the len(output_items[0]), is either 1 or 2...

If I set_output_multiple to 10, then this value raises to 10.

It is dominated by the fact that one of the inputs to my block is much lower 
than the other?? Input[0] is the data stream and has say 768 items, input[1] is 
the packet average SNR, so it only has 1 or 2 items in the same period.

Forecast is currently

For I in range (len(ninput_items_required)):
Ninput_items_required[i] = noutput_items

Does this need to be altered for my case where I have two inputs with very 
different requirements.

If I ever get my head around the scheduler in GNU radio, it will be a happy day 
:)

D

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 15:27
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

On 03/11/2014 04:24 PM, David Halls wrote:
> Please see the papers we've submitted so far this year. Not exactly
> WNC, yet... We're putting one together as we speak though.
>
> I am not sure I understand your reply fully...
>
> Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

Is this before or after you assign something? What's len(output_items[0])?

> How can I extend the length of out_bA1, so I can output all of est_bA1m?

You can't, not in the work function. You can do things like
set_output_multiple() to influence the size of the output buffer.

> Or alternatively Is it possible for me to set
>
> "output_items[0][0:len(est_bA1m)] = est_bA1m"

That would work, if len(est_bA1m) < len(output_items[0]) AND they have the 
right "shape" (in matrix terms).

___
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 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] Google Summer of Code 2014 applicant : Optimization with VOLK

[Florian Kaltenberger]

Hi Nathan and Abhishek,

On 10/03/2014 23:22, West, Nathan wrote:
> Ah! So there was a slight miscommunication. Yes, porting the OpenAirInterfaces
> SIMD code to VOLK is a good option as well. The turbo channel coder/decoder
> is part of that. I've *briefly* looked at the code to see what is
> currently there, and
> it's my understanding that the work involved will be to write generic
> C implementations
> of vectorized code where the generic version does not exist. Beyond
> that porting to
> newer/different ISAs (AVX or NEON depending on your preference and hardware
> availability). I think Florian is on the gr-discuss mailing list, but
> I've CCed him to
> hopefully provide more details as he's more familiar with the original
> code base.
I only joined this mailing list recently, so I probably missed a part of
the discussion. Let me summarize briefly what OpenAirInterface can
provide. We have optimized SIMD (SSE4) implementations of the LTE turbo
encoder and decoder as well as the LTE tail-biting Viterbi encoder and
decoder. We also have the 802.11 Viterbi encoder and decoder. The only
functions for which we have generic non-vectorized functional
equivalents is the LTE turbo decoder.
I am not sure I understand why it is necessary to write generic versions
for the already optimized SIMD code. My idea was to port the optimized
SIMD code from OpenAirInterface to VOLK, such that is can be used by GR
applications. I am not familiar with VOLK (yet) but this might just be
as easy as writing a wrapper function.
As Nathan suggested, the more interesting part is probably to upgrade
the code to AVX2 or similar. 

Cheers,
Florian.

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

[Discuss-gnuradio] [Fwd: Re: HPRT receiving station]

[Patrik Tast]

--- Begin Message ---
Hi Pablo,

NOAA HRPT is Manchester BPSK. I used Johnathan's noaa_hrpt_decoder.cc/h
and enhanced the deframer.

Perhaps Johnathan can help you more?
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/350726ae56d46d2c7c1adf71b7049369a428d455/show/gr-noaa/lib


Patrik

On Tue, 2014-03-11 at 17:48 +0100, Pablo Fernández Alonso wrote:
> Hello Patrik,
> 
> Where can  I find a detailed explanation for the structure of the HRPT 
> receiver in GNU radio? I saw several examples, but I don't understand how the 
> signa lis demodulated.
> 
> Regards,
> 
> Pablo.
> 
> -Mensaje original-
> De: Patrik Tast [mailto:pat...@poes-weather.com] 
> Enviado el: miércoles, 5 de marzo de 2014 13:47
> Para: Pablo Fernández Alonso
> Asunto: Re: HPRT receiving station
> 
> Hi Pablo,
> 
> Before you order I suspect you could use an offset dish (70 x 50cm) I guess 
> you can buy on for €1, as a start?
> Patrik
> 
> 
> On Wed, 2014-03-05 at 12:11 +0100, Pablo Fernández Alonso wrote:
> > Hi Patrik,
> > 
> > 
> > I am going to order a 1.5 m parabolic dish and the distance between 
> > the dish and the PC is around 40 meters. I designed helix feed with 9 
> > dB of gain for F/D = 0.5. I need a (cheap) lnb downconverter to vhf in 
> > order to reduce the cable attenuation.
> > 
> > 
> > Regards,
> > 
> > 
> > Pablo.
> > 
> > 
> > 2014-03-05 10:52 GMT+01:00 Patrik Tast :
> > Hi Pablo,
> > 
> > 8.5dB (at the receiver) and a LHCP helix feed designed for
> > "that" dish
> > will work.
> > We must know your COAX cable type and length so we can
> > calculate your
> > loss.
> > When designing the helix feed, use dish 10 dB taper, usually 3
> > turns for
> > a parabolic dish but if an offset dish is used use +6 turns.
> > 
> > If you provide me data of your dish size (parabolic or
> > offset), f/D and
> > COAX type and length I can quickly help you with an option.
> > 
> > A good enough LNA can be found here
> > http://lna4all.blogspot.fi/
> > 
> > Regards,
> > Patrik
> > 
> > On Wed, 2014-03-05 at 10:35 +0100, Pablo Fernández Alonso
> > wrote:
> > > Hi Patrik,
> > >
> > >
> > > Do you think it is possible to receive HRPT using the dish
> > but without
> > > a LNA? I saw an article where the author receives with an
> > helical
> > > antenna with 8.5 dB of gain and a 20 dB LNA. I tried to
> > contact with
> > > them, but I received no answer.
> > >
> > >
> > >
> > 
> > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1488531&tag=1
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > > Pablo.
> > >
> > >
> > > 2014-02-26 21:04 GMT+01:00 Patrik Tast
> > :
> > > Hi Pablo,
> > >
> > > No, you will run into problems, as you can see I'm
> > using a
> > > 1.5m dish and
> > > you need to track the satellite
> > >
> > > Patrik
> > >
> > > On Wed, 2014-02-26 at 13:02 +0100, Pablo Fernández
> > Alonso
> > > wrote:
> > > > Hello Patrik,
> > > >
> > > >
> > > > You replied my question about an HRPT receiver
> > using GNU
> > > radio. I am
> > > > designing the station, and I don't know the gain
> > needed to
> > > receive
> > > > this sort of images correctly, so if you could
> > help me I
> > > would be
> > > > really helpful. I am designing a microstrip array
> > to do it
> > > but I don't
> > > > know if the gain would be enough.
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Pablo Fernandez
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > 
> > 
> 
> 
> 

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

[Discuss-gnuradio] flow graph fails when the complexity increased (without USRP device)

[Nasi]

 Hi all,

I am using GNURADIO 3.7, Ubuntu 13.04

I want to generate dictionary elements using flow graph.

dvbt_dictionary block connects to FFT block it connects to dvbt_dictionary2 and 
again after FFT block it connects to dvbt_dictionary3.
dvbt_dictionary2.cc saves files as a dictionary elements.

The problem is that when I increase the complexity (generate more elements) it 
does not work (For example when I want to generate more than 100 elements).
I attach three .cc files and flow graph.

Can someone help me?

-- 
NE

dvbt_dic.py
Description: Binary data


dvbt_dic.grc
Description: Binary data


dvbt_dictionary.cc
Description: Binary data


dvbt_dictionary3.cc
Description: Binary data


dvbt_dictionary2.cc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] looping with work() function

[Sumedha Goyal]

1. There is a file source that frames data packets for the test_demo. This
is part of a transmitter USRP.
2. I have another USRP as receiver that sends an ACK upon reception of data
packets to the transmitter.
3. Start sign is a threshold value. If the packet information (calculated
by some method) exceeds this threshold, transmission starts and upon
receiving an ACK stops.
4. I change this threshold value for every new iteration and count how many
packets were transmitted before receiving a success ACK.
I can do this manually for every iteration but how to automate it for say
some 1000 iterations?

I hope it explains everything.
On Mar 11, 2014 7:28 PM, "Activecat"  wrote:

> Dear Sumedha Goyal,
>
> > The "test_demo" checks for a "start sign"(given by the user) and
> > participates in data transmission process and upon receiving an ACK for
> > success should stop further transmission.
>
> Q1: What do you mean by "participates in data transmission process"?
> Does it just send out what it receives, or insert any new data?
> Q2: For "upon receiving an ACK":-  from where the ACK will comes from,
> from upstream, downstream, or somewhere else?
>
> > At this point, the flowgraph should stop and start again with a new
> "start
> > sign" for next iteration and so on. I am planning to plot the number of
> > packets transmitted before receiving an ACK against this "start sign".
>
> If I understand you requirement correctly, you need a block that
> continuously getting input from somewhere.
> This input contains "start sign" and later followed by "ACK".
> Upon receiving "start sign", this block will pass through all it
> receives to its output port.
> Upon receiving "ACK", this block will stop the pass through (means no
> output), until it receive another "start sign" again.
> Meanwhile, you want the block to count the number of inputs between
> the "start sign" and "ACK", and use this number to plot graph.
>
> Is this what you want?  If yes then I am able to help you.
> Let's clarify your requirements first.
>
> Regards,
> Activecat
>
> ___
> 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] Transmit from RF1, receive from RF2

[Dimitris Siafarikas]

Ok, let's say I want to Tx from port1 and receive from port2. How am I
supposed to do that on GRC?

 

Or is set when I add a USRP source and a USRP sink automatically?

 

From: Ralph A. Schmid, dk5ras [mailto:ra...@schmid.xxx] 
Sent: Tuesday, March 11, 2014 3:34 PM
To: 'Dimitris Siafarikas'; 'Matt Ettus'
Cc: 'GNURadio'
Subject: RE: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

This board has one receiver, one transmitter. You can transmit and receive
simultaneously with it, but only on different ports. No TX and RX at the
same time on one port, no RX and RX at the same time at all.

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org

[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Dimitris Siafarikas
Sent: Tuesday, March 11, 2014 1:59 PM
To: 'Matt Ettus'
Cc: 'GNURadio'
Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

I am using SBX board. I read somewhere that this board can transmit and
receive from port 1 and only receive from port 2. Is this correct?

 

Is there any way, using this board, to transmit and receive simultaneously
even from only one port? If yes, how may I do this in GRC?

 

From: Matt Ettus [mailto:m...@ettus.com] 
Sent: Tuesday, March 11, 2014 4:31 AM
To: Dimitris Siafarikas
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

 

 

Which daughterboard are you using?  The only ones where you can receive 2
signals at once are BasicRX, LFRX, and TVRX2.  The others only allow you to
receive from one antenna port at a time.

 

Matt

 

On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas mailto:jimsia...@hotmail.com> > wrote:

Hi list,

 

here is the thing. I would like to know, how I can create a flow with blocks
in GNU Radio companion, in order to receive a signal from the RF1 port of my
URSP N210 and simultaneously , receive another signal from the RF2 port of
the same USRP.

 

Is there any option defining the port of the USRP when selecting USRP
source/sink block?

 

Thank you in advance.


___
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] output operand requires a reduction, but reduction is not enabled

[David Halls]

Hi,

Yes, the len(output_items[0]), is either 1 or 2...

If I set_output_multiple to 10, then this value raises to 10.

It is dominated by the fact that one of the inputs to my block is much lower 
than the other?? Input[0] is the data stream and has say 768 items, input[1] is 
the packet average SNR, so it only has 1 or 2 items in the same period.

Forecast is currently

For I in range (len(ninput_items_required)):
Ninput_items_required[i] = noutput_items

Does this need to be altered for my case where I have two inputs with very 
different requirements.

If I ever get my head around the scheduler in GNU radio, it will be a happy day 
:)

D

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 15:27
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

On 03/11/2014 04:24 PM, David Halls wrote:
> Please see the papers we've submitted so far this year. Not exactly
> WNC, yet... We're putting one together as we speak though.
>
> I am not sure I understand your reply fully...
>
> Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

Is this before or after you assign something? What's len(output_items[0])?

> How can I extend the length of out_bA1, so I can output all of est_bA1m?

You can't, not in the work function. You can do things like
set_output_multiple() to influence the size of the output buffer.

> Or alternatively Is it possible for me to set
>
> "output_items[0][0:len(est_bA1m)] = est_bA1m"

That would work, if len(est_bA1m) < len(output_items[0]) AND they have the 
right "shape" (in matrix terms).

___
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 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] get_tags_in_range

[Nowlan, Sean]

>On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean  
>wrote:
>>>On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun  wrote:
 On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
> I'm using get_tags_in_range with bounds outside the absolute sample 
> offsets presented in each work function. I'm using this to add 
> end-of-burst tags at offset K-1 for every start-of-burst tag that I 
> find at offset K (except the very first K).
>
> I just want to confirm that this is valid. All my tests have shown 
> that it is, since I believe the underlying deque is completely 
> independent of the data stream except that offsets are used for 
> both absolute sample offsets and tag bookkeeping.

 I think you're right, but only if you do this *after* the current 
 bounds, not before.

 M
>>
>>>Yes, the scheduler prunes all tags before the window after work is done. 
>>>Basically, since we're tagging a data sample, if that sample is no longer 
>>>available to you, neither is it's >>tag. You'll have to get them and store 
>>>them locally for your uses later.
>>
>>>Tom
>>
>> Ok, that makes sense; I'd be unable to read tags from the past. But what 
>> happens if I *create* a tag on a past data sample? Will it be propagated or 
>> ignored?
>>
>> (   A  )  { B   }
>> (0   1)  { 2   3   4 }  5 ...
>>
>> Let's say section ( A ) is from a previous call to work. Let's also say { B 
>> } is the current work window, i.e., nitems_read(0) == 2 and noutput_items == 
>> 3. If I find a start-of-burst tag on absolute offset 2, is it impossible to 
>> create a new tag on absolute offset 1?
>>
>> The vast majority of the time, this would not be a problem. The boundary 
>> condition is really the only source of trouble. I suppose I could  use 
>> set_history(2) so that I can always see the tags at the offset range 
>> endpoints. Do you advise this? Does history ensure the scheduler doesn't 
>> prune tags from the history region?
>>
>> Sean
>
>
>Yeah, if you set a tag to a time in the past, the following blocks will 
>(likely, based on the dynamics of the scheduler) prune it before your 
>follow-on block can process it.
>
>I'd have to double check and think about the case where you use set_history 
>for this. It seems like it should work, but just remember that set history 
>really just initializes your read pointers back by
>history()-1 number of items. So the tag wouldn't go on item-2 in the stream 
>since index 0 of the buffer /is/ item-2 already.
>
Ok, I guess I should go poke around the prune_tags logic and see how it works. 
If it respects history(), it wouldn't prune tags from any item that is 
available at the start of the read pointer, including history. If it doesn't, 
tags may be abandoned/pruned even though I have access to history()-1 number of 
previous items, and I'm still stuck.

Functionally speaking, if I can read a sample, I should be able to read its 
associated tags. But history() only involves input buffers, not output buffers, 
so perhaps I'm still falling into the trap mentioned above, i.e., the tag may 
be pruned before the downstream block can see it.

>But something like this, if not exactly, should work, yes.
>
I'm trying to determine an "exact" solution. This is another way to work around 
PFB arb resampler tag propagation issues (discussed in issue #652). Basically 
I'm adding a start-of-burst tag to the first sample of a stream pre-resampler, 
and then once things have been resampled, I go back and fill in end-of-burst 
tags. This avoids having to know when the PFB arb resampler adds +/- 1 samples. 
This block I've written is a sync_block that simply does a memcpy of samples 
and the tag processing mentioned above.

Now I'm thinking a workaround could be to return noutput_items-1 items. This 
way I get to check the last item of a work input buffer, 
nitems_read(0)+noutput_items-1, for a start-of-burst tag and place an 
end-of-burst tag at nitems_read(0)+noutput_items-2. At the next call to work, 
that last item of the previous input buffer is the first item of the input 
buffer, and I can put an end-of-burst tag at nitems_read(0) if I find a tag at 
nitems_read(0)+1. Makes sense in my head, at least...

>Tom

Sean

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

Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[Martin Braun]

On 03/11/2014 04:24 PM, David Halls wrote:
> Please see the papers we've submitted so far this year. Not exactly WNC,
> yet... We're putting one together as we speak though.
> 
> I am not sure I understand your reply fully...
> 
> Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

Is this before or after you assign something? What's len(output_items[0])?

> How can I extend the length of out_bA1, so I can output all of est_bA1m?

You can't, not in the work function. You can do things like
set_output_multiple() to influence the size of the output buffer.

> Or alternatively Is it possible for me to set
> 
> "output_items[0][0:len(est_bA1m)] = est_bA1m"

That would work, if len(est_bA1m) < len(output_items[0]) AND they have
the right "shape" (in matrix terms).

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

Re: [Discuss-gnuradio] GSoC'14: "Read Me" Links

[Martin Braun]

On 03/11/2014 03:03 PM, Michael Dickens wrote:
> To all GSoC'14 potential participants: The application period for
> GSoC'14 is open (as of Monday, March 10).  The deadline for getting
> your application in is Friday, March 21 @ 19:00 UTC (3 PM/US/ET).
> I've added some "read me" links to the GR Wiki GSoC Manifest page <
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCManifest#Related-reading
> >.  I encourage all GSoC potential participants to read them (they
> are not very long), no matter which type of participant you are;
> there is good wisdom for all of us in these pages! - MLD 

Michael, thanks for putting this up.

To all students: You will get subjective negative points if you don't
read everything before posting/asking questions, so please take this
seriously.

M

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

Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[Martin Braun]

On 03/11/2014 03:30 PM, David Halls wrote:
> Thanks Martin, this is clear and makes sense. I should have read the
> numpy data types more thoroughly and worked it out. Anyway...
> 
> My collaborators are writing their Wireless Network Coding bits in
> Python. Once I get this block working, I can combined it with the relay
> work I was doing and we will have a pretty exciting setup to report!! :)

That is very interesting to hear -- I hope you'll be publishing some
papers and code around network coding!

> I have one more problem though...
> 
> I have
> 
> "out_bA1 = output_items[0]
> 
> ...
> ...code
> ...
> 
> out_bA1[0:len(est_bA1m)] = est_bA1m"
> 
> where
> 
> out_bA1.shape = (1,)
> est_bA1m.shape = (3840,)
> 
> I get the error " output operand requires a reduction, but reduction is
> not enabled"
> 
> *Sometimes* I get
> 
> out_bA1.shape = (2,)
> est_bA1m.shape = (3840,)
> 
> and I get the error "operands could not be broadcast together with
> shapes (2) (3840)"
> 
> I wondered if the problem is with 'forecast' (which I have not changed
> since the template was created by gr_modtool) or having to
> set_output_multiple? The scheduling aspect of GNU radio seems complex.

This is a Python error, basically it's saying that the arrays have the
wrong shapes.

Note that in your example, out_bA1 has a limited size before you do any
assigning. Make sure you stay within valid index ranges.

If you want to do it very fool-proof (albeit ugly), try:

for i in range(len(out_bA1)):
out_bA1[i] = # whatever
if i (matches whatever condition):
break

> If I use
> 
> " out_bA1 = est_bA1m"
> 
> Then it *runs* OK, but the output of the block i.e. output_items[0] is
> then no longer altered and 0's are output.

That's because you're rebinding out_bA1, and the original buffer is not
written to.

MB
> 
> Many thanks,
> 
> David
> 
> 
> -Original Message-
> From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
> 
> [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org]
> On Behalf Of Martin Braun
> Sent: 11 March 2014 08:33
> To: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch
> 
> On 03/11/2014 02:06 AM, David Halls wrote:
>> You're a genius! It works.
>>
>> Interestingly for a float it requires numpy.float32 or a similar error
>> occurs.
> 
> Yes, in GNU Radio we consistently use 32-bit floats. A complex value
> consists of two of these, hence the 64 bits.
> 
> Note that this is just for buffers. A lot of blocks use double
> internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason.
> However, for signals, it's just a waste of bandwidth (most of time, SNR
> will trump quantization noise anyway).
> 
> M
> 
> 
> ___
> 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 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] output operand requires a reduction, but reduction is not enabled

[David Halls]

Thanks Martin, this is clear and makes sense. I should have read the numpy data 
types more thoroughly and worked it out. Anyway...

My collaborators are writing their Wireless Network Coding bits in Python. Once 
I get this block working, I can combined it with the relay work I was doing and 
we will have a pretty exciting setup to report!! :)

I have one more problem though...

I have

"out_bA1 = output_items[0]

...
...code
...

out_bA1[0:len(est_bA1m)] = est_bA1m"

where

out_bA1.shape = (1,)
est_bA1m.shape = (3840,)

I get the error " output operand requires a reduction, but reduction is not 
enabled"

*Sometimes* I get

out_bA1.shape = (2,)
est_bA1m.shape = (3840,)

and I get the error "operands could not be broadcast together with shapes (2) 
(3840)"

I wondered if the problem is with 'forecast' (which I have not changed since 
the template was created by gr_modtool) or having to set_output_multiple? The 
scheduling aspect of GNU radio seems complex.

If I use

" out_bA1 = est_bA1m"

Then it *runs* OK, but the output of the block i.e. output_items[0] is then no 
longer altered and 0's are output.

Many thanks,

David


-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 08:33
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch

On 03/11/2014 02:06 AM, David Halls wrote:
> You're a genius! It works.
>
> Interestingly for a float it requires numpy.float32 or a similar error
> occurs.

Yes, in GNU Radio we consistently use 32-bit floats. A complex value consists 
of two of these, hence the 64 bits.

Note that this is just for buffers. A lot of blocks use double internally (i.e. 
64-bit float, or 128-bit complex) for accuracy reason.
However, for signals, it's just a waste of bandwidth (most of time, SNR will 
trump quantization noise anyway).

M


___
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 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] how to limit the size of buffer/queue for a block?

[Martin Braun]

On 03/11/2014 02:20 PM, Sumedha Goyal wrote:
> Hello
> 
> The flowgraph of my top_block has test_demo as one of the blocks. The
> work() function associated with it has only one print statement.
> When I execute the flowgraph, the statement keeps on printing the
> statement " I AM IN WORK" on the screen. Why does it happen?
> My flowgraph is : 
> File source--->stream to datagram--->test_demo>datagram to
> stream->file sink
> 
> test_demo.py is :

Sumedha,

when posting Python code, make sure the indents get preserved (ideally,
don't send HTML emails).

M

> 
> import timing
> import numpy
> import gras
> import Queue
> import thread
> from gnuradio import gr
> from gnuradio import digital
> from gnuradio import uhd
> import grextras
> 
> 
> class test_demo(gras.Block):
> 
> def __init__(self, threshold):
> gras.Block.__init__(self,name="test_demo",
> in_sig = [numpy.uint8,numpy.uint8,numpy.uint8],
> out_sig = [numpy.uint8,numpy.uint8])
> self.input_config(0).reserve_items = 0
> self.input_config(1).reserve_items = 0
> self.output_config(1).reserve_items = 4096
> self.output_config(0).reserve_items = 4096
> self.threshold=threshold
> print "inside test_demo"
> 
> def work(self,ins,outs):
> print "I AM IN WORK"
> 
> If it is due to the size of buffer/queue of the block then how can I
> limit it?
> I understand that work() keeps on executing till the block receives
> something at its input ports. I want work() to return the control to
> main flowgraph upon satisfying a user specified condition such as 
> if (i=5):
> self.mark_done()
> It should ignore all the pending packets of the buffer/queue.
> I want to start my flowgraph fresh after this process.
> 
> 
> ___
> 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] looping with work() function

[Martin Braun]

Please stay on the mailing list.

On 03/11/2014 02:37 PM, Sumedha Goyal wrote:
> I haven't shown the whole code here but the top_class has all the
> connect() functions required to connect the various blocks. I've gone
> through the link that you have sent me. In this example, the work()
> function is not used anywhere. I would like to do a similar thing but
> cannot avoid work(). Is there a way around?

work() is called in every single block. This is how blocks work. Have a
look at the "out of tree module" tutorial.

Martin

> 
> 
> On Tue, Mar 11, 2014 at 6:19 PM, Martin Braun  > wrote:
> 
> On 03/11/2014 01:31 PM, Sumedha Goyal wrote:
> > My top_block class represents the whole flowgraph. The class
> "test_demo"
> 
> No, it doesn't. It doesn't have any connect() calls or anything. This is
> not a flow graph.
> 
> > is one of the blocks of this flowgraph for which its own work()
> function
> > is defined.
> > The "test_demo" checks for a "start sign"(given by the user) and
> > participates in data transmission process and upon receiving an
> ACK for
> > success should stop further transmission.
> > At this point, the flowgraph should stop and start again with a new
> > "start sign" for next iteration and so on. I am planning to plot the
> > number of packets transmitted before receiving an ACK against this
> > "start sign". Therefore, I need my flowgraph to execute several times.
> > I hope this description explains my intention. I am not very familiar
> > with scheduler. How can I use the scheduler to do this?
> 
> If you're using a flow graph, you use the scheduler automatically, you
> don't need to set it up or anything.
> 
> Have a look at the file I recommended. If you feel you don't understand
> something, first read the introductory documents on the wiki, as well as
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations.
> 
> Good luck,
> Martin
> 
> 
> >
> >
> > On Tue, Mar 11, 2014 at 3:12 PM, Activecat  
> > >> wrote:
> >
> > On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun
> > mailto:martin.br...@ettus.com>
> >> wrote:
> >
> > On 03/11/2014 06:10 AM, Sumedha Goyal wrote:
> > > Hello
> > >
> > > I am executing a flowgraph where I pass different parameters
> > to the
> > > work() function of my block in every iteration.
> >
> >
> > If the "parameters" could be fed into work() as input
> elements, than
> > that is possible.
> > Please  describe the parameters in details.
> >
> >
> > > 1. I would like my flowgraph to execute once with a
> certain set of
> > > parameters and on satisfying a certain condition, it
> should stop
> > > execution (even if the queue/buffer of the block is not
> empty).
> > > 2. The control should come back to the main() function
> and the
> > next
> > > iteration should start with a new set of parameters and
> again upon
> > > satisfying a certain condition the flowgraph should exit.
> >
> >
> > In flow-graph there is no main() function, but only the
> scheduler in
> > the background.
> > Please give specific examples of what you are trying to
> accomplish.
> >
> > Regards,
> > Activecat
> >
> > ___
> > 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] GSoC'14: "Read Me" Links

[Michael Dickens]

To all GSoC'14 potential participants: The application period for GSoC'14 is 
open (as of Monday, March 10).  The deadline for getting your application in is 
Friday, March 21 @ 19:00 UTC (3 PM/US/ET).  I've added some "read me" links to 
the GR Wiki GSoC Manifest page < 
http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCManifest#Related-reading 
>.  I encourage all GSoC potential participants to read them (they are not very 
long), no matter which type of participant you are; there is good wisdom for 
all of us in these pages! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] looping with work() function

[Activecat]

Dear Sumedha Goyal,

> The "test_demo" checks for a "start sign"(given by the user) and
> participates in data transmission process and upon receiving an ACK for
> success should stop further transmission.

Q1: What do you mean by "participates in data transmission process"?
Does it just send out what it receives, or insert any new data?
Q2: For "upon receiving an ACK":-  from where the ACK will comes from,
from upstream, downstream, or somewhere else?

> At this point, the flowgraph should stop and start again with a new "start
> sign" for next iteration and so on. I am planning to plot the number of
> packets transmitted before receiving an ACK against this "start sign".

If I understand you requirement correctly, you need a block that
continuously getting input from somewhere.
This input contains "start sign" and later followed by "ACK".
Upon receiving "start sign", this block will pass through all it
receives to its output port.
Upon receiving "ACK", this block will stop the pass through (means no
output), until it receive another "start sign" again.
Meanwhile, you want the block to count the number of inputs between
the "start sign" and "ACK", and use this number to plot graph.

Is this what you want?  If yes then I am able to help you.
Let's clarify your requirements first.

Regards,
Activecat

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

Re: [Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm

[Bogdan Diaconescu]

I totally agree with Martin regarding PFB channelizer. The PFB for gsm will be 
also a good challenge for gnuradio in general as obtaining only a moderate 
number of channels(say 50) takes a lot of processing power and achieving 
realtime processing is not possible currently. Split per thereads and VOLK 
should be taken in consideration.

Bogdan







On Tuesday, March 11, 2014 2:30 PM, Martin Braun  wrote:
 
On 03/11/2014 11:14 AM, zhenhua han wrote:
> -- Forwarded message --
> From: *zhenhua han* mailto:hzhua...@gmail.com>>
> Date: 2014-03-11 16:00 GMT+08:00
> Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
> To: Bogdan Diaconescu  >
> 
> 
> Thank you, Bogdan. Your work is a great help in developing the channel
> hopping part.
> As there are only 14 weeks in GSoC,
 the schedule is a little tight. 
> However, I will continue working on this project after GSoC (if I am
> selected). And Channel hopping will be the first task after I finish all
> the tasks planned in GSoC.

You should definitely check out the PFB channelization, though. For
multi-ARFCN applications, this will always be a requirement.


M


___
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] Transmit from RF1, receive from RF2

[Ralph A. Schmid, dk5ras]

This board has one receiver, one transmitter. You can transmit and receive
simultaneously with it, but only on different ports. No TX and RX at the
same time on one port, no RX and RX at the same time at all.

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Dimitris Siafarikas
Sent: Tuesday, March 11, 2014 1:59 PM
To: 'Matt Ettus'
Cc: 'GNURadio'
Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

I am using SBX board. I read somewhere that this board can transmit and
receive from port 1 and only receive from port 2. Is this correct?

 

Is there any way, using this board, to transmit and receive simultaneously
even from only one port? If yes, how may I do this in GRC?

 

From: Matt Ettus [mailto:m...@ettus.com] 
Sent: Tuesday, March 11, 2014 4:31 AM
To: Dimitris Siafarikas
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

 

 

Which daughterboard are you using?  The only ones where you can receive 2
signals at once are BasicRX, LFRX, and TVRX2.  The others only allow you to
receive from one antenna port at a time.

 

Matt

 

On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas mailto:jimsia...@hotmail.com> > wrote:

Hi list,

 

here is the thing. I would like to know, how I can create a flow with blocks
in GNU Radio companion, in order to receive a signal from the RF1 port of my
URSP N210 and simultaneously , receive another signal from the RF2 port of
the same USRP.

 

Is there any option defining the port of the USRP when selecting USRP
source/sink block?

 

Thank you in advance.


___
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] Running GNU Radio on Linux in VMware Workstation

[Tom Rondeau]

On Mon, Mar 10, 2014 at 5:08 PM, Mike Harpe  wrote:
> I have been working for a week or so on getting GNU Radio going on a Debian
> Linux platform running inside a VM.
>
> GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle.
> Using 'plughw:0,0' got rid of the audio stuttering problem. After struggling
> with a couple of the demo flowgraphs I downloaded and built gqrx.
>
> It runs. I can tune it to the local NOAA Weather Radio transmitter. I use
> that for testing because its very strong where I am. I have the same problem
> there that I have in GNU Radio: no receive audio.
>
> Can anyone give me some advice how to proceed? To answer the one question,
> yes, I am pursuing building a Debian system on a flash drive that I can boot
> natively.
>
> Mike Harpe, N4PLE
> Sellersburg, IN, USA


You can specify the audio output device globally for your system by
editing $prefix/etc/gnuradio/conf.d/gr-audio-alsa.conf (I'm assuming
that's what you are working with given the use of plughw). You can set
that 'plughw:0,0' in as the 'default_output_device' argument. If you
are running PulseAudio, you can use 'pulse' for this, too, which tends
to work more reliably for me these days.

Tom

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

Re: [Discuss-gnuradio] get_tags_in_range

[Tom Rondeau]

On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean
 wrote:
>>On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun  wrote:
>>> On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
 I'm using get_tags_in_range with bounds outside the absolute sample
 offsets presented in each work function. I'm using this to add
 end-of-burst tags at offset K-1 for every start-of-burst tag that I
 find at offset K (except the very first K).

 I just want to confirm that this is valid. All my tests have shown
 that it is, since I believe the underlying deque is completely
 independent of the data stream except that offsets are used for both
 absolute sample offsets and tag bookkeeping.
>>>
>>> I think you're right, but only if you do this *after* the current
>>> bounds, not before.
>>>
>>> M
>
>>Yes, the scheduler prunes all tags before the window after work is done. 
>>Basically, since we're tagging a data sample, if that sample is no longer 
>>available to you, neither is it's >tag. You'll have to get them and store 
>>them locally for your uses later.
>
>>Tom
>
> Ok, that makes sense; I'd be unable to read tags from the past. But what 
> happens if I *create* a tag on a past data sample? Will it be propagated or 
> ignored?
>
> (   A  )  { B   }
> (0   1)  { 2   3   4 }  5 ...
>
> Let's say section ( A ) is from a previous call to work. Let's also say { B } 
> is the current work window, i.e., nitems_read(0) == 2 and noutput_items == 3. 
> If I find a start-of-burst tag on absolute offset 2, is it impossible to 
> create a new tag on absolute offset 1?
>
> The vast majority of the time, this would not be a problem. The boundary 
> condition is really the only source of trouble. I suppose I could  use 
> set_history(2) so that I can always see the tags at the offset range 
> endpoints. Do you advise this? Does history ensure the scheduler doesn't 
> prune tags from the history region?
>
> Sean


Yeah, if you set a tag to a time in the past, the following blocks
will (likely, based on the dynamics of the scheduler) prune it before
your follow-on block can process it.

I'd have to double check and think about the case where you use
set_history for this. It seems like it should work, but just remember
that set history really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the
stream since index 0 of the buffer /is/ item-2 already.

But something like this, if not exactly, should work, yes.

Tom

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

[Discuss-gnuradio] how to limit the size of buffer/queue for a block?

[Sumedha Goyal]

Hello

The flowgraph of my top_block has test_demo as one of the blocks. The
work() function associated with it has only one print statement.
When I execute the flowgraph, the statement keeps on printing the statement
" I AM IN WORK" on the screen. Why does it happen?
My flowgraph is :
File source--->stream to datagram--->test_demo>datagram to
stream->file sink

test_demo.py is :

import timing
import numpy
import gras
import Queue
import thread
from gnuradio import gr
from gnuradio import digital
from gnuradio import uhd
import grextras


class test_demo(gras.Block):

def __init__(self, threshold):
gras.Block.__init__(self,name="test_demo",
in_sig = [numpy.uint8,numpy.uint8,numpy.uint8],
out_sig = [numpy.uint8,numpy.uint8])
self.input_config(0).reserve_items = 0
self.input_config(1).reserve_items = 0
 self.output_config(1).reserve_items = 4096
self.output_config(0).reserve_items = 4096
self.threshold=threshold
 print "inside test_demo"

 def work(self,ins,outs):
print "I AM IN WORK"

If it is due to the size of buffer/queue of the block then how can I limit
it?
I understand that work() keeps on executing till the block receives
something at its input ports. I want work() to return the control to main
flowgraph upon satisfying a user specified condition such as
if (i=5):
self.mark_done()
It should ignore all the pending packets of the buffer/queue.
I want to start my flowgraph fresh after this process.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

[Dimitris Siafarikas]

I am using SBX board. I read somewhere that this board can transmit and
receive from port 1 and only receive from port 2. Is this correct?

 

Is there any way, using this board, to transmit and receive simultaneously
even from only one port? If yes, how may I do this in GRC?

 

From: Matt Ettus [mailto:m...@ettus.com] 
Sent: Tuesday, March 11, 2014 4:31 AM
To: Dimitris Siafarikas
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

 

 

 

Which daughterboard are you using?  The only ones where you can receive 2
signals at once are BasicRX, LFRX, and TVRX2.  The others only allow you to
receive from one antenna port at a time.

 

Matt

 

On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas mailto:jimsia...@hotmail.com> > wrote:

Hi list,

 

here is the thing. I would like to know, how I can create a flow with blocks
in GNU Radio companion, in order to receive a signal from the RF1 port of my
URSP N210 and simultaneously , receive another signal from the RF2 port of
the same USRP.

 

Is there any option defining the port of the USRP when selecting USRP
source/sink block?

 

Thank you in advance.


___
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] looping with work() function

[Martin Braun]

On 03/11/2014 01:31 PM, Sumedha Goyal wrote:
> My top_block class represents the whole flowgraph. The class "test_demo"

No, it doesn't. It doesn't have any connect() calls or anything. This is
not a flow graph.

> is one of the blocks of this flowgraph for which its own work() function
> is defined.
> The "test_demo" checks for a "start sign"(given by the user) and
> participates in data transmission process and upon receiving an ACK for
> success should stop further transmission.
> At this point, the flowgraph should stop and start again with a new
> "start sign" for next iteration and so on. I am planning to plot the
> number of packets transmitted before receiving an ACK against this
> "start sign". Therefore, I need my flowgraph to execute several times. 
> I hope this description explains my intention. I am not very familiar
> with scheduler. How can I use the scheduler to do this?

If you're using a flow graph, you use the scheduler automatically, you
don't need to set it up or anything.

Have a look at the file I recommended. If you feel you don't understand
something, first read the introductory documents on the wiki, as well as
http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations.

Good luck,
Martin


> 
> 
> On Tue, Mar 11, 2014 at 3:12 PM, Activecat  > wrote:
> 
> On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun
> mailto:martin.br...@ettus.com>> wrote:
> 
> On 03/11/2014 06:10 AM, Sumedha Goyal wrote:
> > Hello
> >
> > I am executing a flowgraph where I pass different parameters
> to the
> > work() function of my block in every iteration.
> 
> 
> If the "parameters" could be fed into work() as input elements, than
> that is possible.
> Please  describe the parameters in details.
> 
> 
> > 1. I would like my flowgraph to execute once with a certain set of
> > parameters and on satisfying a certain condition, it should stop
> > execution (even if the queue/buffer of the block is not empty).
> > 2. The control should come back to the main() function and the
> next
> > iteration should start with a new set of parameters and again upon
> > satisfying a certain condition the flowgraph should exit.
> 
> 
> In flow-graph there is no main() function, but only the scheduler in
> the background.
> Please give specific examples of what you are trying to accomplish.
> 
> Regards,
> Activecat
> 
> ___
> 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] looping with work() function

[Sumedha Goyal]

My top_block class represents the whole flowgraph. The class "test_demo" is
one of the blocks of this flowgraph for which its own work() function is
defined.
The "test_demo" checks for a "start sign"(given by the user) and
participates in data transmission process and upon receiving an ACK for
success should stop further transmission.
At this point, the flowgraph should stop and start again with a new "start
sign" for next iteration and so on. I am planning to plot the number of
packets transmitted before receiving an ACK against this "start sign".
Therefore, I need my flowgraph to execute several times.
I hope this description explains my intention. I am not very familiar with
scheduler. How can I use the scheduler to do this?


On Tue, Mar 11, 2014 at 3:12 PM, Activecat  wrote:

> On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun wrote:
>
>> On 03/11/2014 06:10 AM, Sumedha Goyal wrote:
>> > Hello
>> >
>> > I am executing a flowgraph where I pass different parameters to the
>> > work() function of my block in every iteration.
>>
>
> If the "parameters" could be fed into work() as input elements, than that
> is possible.
> Please  describe the parameters in details.
>
>
> > 1. I would like my flowgraph to execute once with a certain set of
>> > parameters and on satisfying a certain condition, it should stop
>> > execution (even if the queue/buffer of the block is not empty).
>> > 2. The control should come back to the main() function and the next
>> > iteration should start with a new set of parameters and again upon
>> > satisfying a certain condition the flowgraph should exit.
>>
>
> In flow-graph there is no main() function, but only the scheduler in the
> background.
> Please give specific examples of what you are trying to accomplish.
>
> Regards,
> Activecat
>
> ___
> 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] Fwd: Proposal for GSoC on gr-gsm

[Martin Braun]

On 03/11/2014 11:14 AM, zhenhua han wrote:
> -- Forwarded message --
> From: *zhenhua han* mailto:hzhua...@gmail.com>>
> Date: 2014-03-11 16:00 GMT+08:00
> Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
> To: Bogdan Diaconescu  >
> 
> 
> Thank you, Bogdan. Your work is a great help in developing the channel
> hopping part.
> As there are only 14 weeks in GSoC, the schedule is a little tight. 
> However, I will continue working on this project after GSoC (if I am
> selected). And Channel hopping will be the first task after I finish all
> the tasks planned in GSoC.

You should definitely check out the PFB channelization, though. For
multi-ARFCN applications, this will always be a requirement.

M


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

Re: [Discuss-gnuradio] WSR14 and Hackfest

[Martin Braun]

Quick reminder that we will have a meet-up in Vogelbräu tonight at
19:00. This is not limited to WSR participants! All GNU Radio
enthusiasts are invited.

I've booked a table and will be there slightly before 7. Our table
should be easy to find, just scan for the homing beacon signal I'll be
transmitting at 785 MHz, or should I forgot to do so because this is a
pub after all, look out for GNU Radio logos.

Martin

On 02/16/2014 11:25 PM, Martin Braun wrote:
> Sebastian, thanks for organizing this!
> 
> On Tuesday, March 11th, there will also be the (by now traditional)
> meeting of GR enthusiasts in Vogelbräu [1]. I'll book a table for 19:00.
> 
> MB
> 
> [1] Address: Kapellenstraße 50, http://www.vogelbraeu.de/
> 
> On 02/16/2014 03:58 PM, Sebastian Koslowski wrote:
>> After the workshop we'll hold a 3-day hackfest here at the CEL- 2
>> 1/2 days to be exact, that is March 13-15. Over the last years hackfests
>> have become a regular event for GR developers to get together and work
>> on new features, bug fixes, and discuss where to go next. As far as I
>> know this will be the first hackfest in Europe and so we would like to
>> invite everyone interested to stay a few days longer in Karlsruhe and do
>> some GR coding.
> 
> 
> 
> 
> 
> 


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

[Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm

[zhenhua han]

-- Forwarded message --
From: zhenhua han 
Date: 2014-03-11 16:00 GMT+08:00
Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
To: Bogdan Diaconescu 


Thank you, Bogdan. Your work is a great help in developing the channel
hopping part.
As there are only 14 weeks in GSoC, the schedule is a little tight.
However, I will continue working on this project after GSoC (if I am
selected). And Channel hopping will be the first task after I finish all
the tasks planned in GSoC.

Best wishes,
Zhenhua




2014-03-11 15:34 GMT+08:00 Bogdan Diaconescu :

 Hi Zhenhua,
>
> gr-gsm should be a good project for you and for the community. I wish you
> success.
>
> You may want to look at the slow frequency hopping implementation of
> airprobe that is placed here:
> https://github.com/BogdanDIA/airprobe-hopping.
> It uses PFB to split a 20mhz band received with USRP-N210 into GSM
> channels and then use all of them according to the hopping algorithm
> decoded on the Immediate Assignment message and SI 1. It is not a perfect
> implementation as airprobe is not perfect too, that is why I think this
> will be a good project.
> The hopping patch has been done two years ago and has API for gnuradio3.6
> era. I did not update it yet on 3.7. Here is small paper I wrote at the
> moment of creating a patch. It may be of help to you.
>
>
> http://yo3iiu.ro/blog/wp-content/uploads/2012/04/Evaluating_GSM_hopping_V1.1.pdf
>
> Bogdan
>
>
>On Tuesday, March 11, 2014 5:40 AM, zhenhua han 
> wrote:
>   Hi all,
>
> As Martin Braun noticed in the mail list yesterday, I haven't open my
> proposal here.
>
> Here is the link:
> https://github.com/hzhua/grgsm_proposal
>
> If you have any suggestions, please don't be hesitate to contact me.
>
> Thanks to Sylvain Munaut for his help on reviewing my first draft.
> Thanks to Piot Krysik for his suggestions on gr-gsm.
>
> Best wishes,
> Zhenhua
>
>
> ___
> 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] looping with work() function

[Activecat]

On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun wrote:

> On 03/11/2014 06:10 AM, Sumedha Goyal wrote:
> > Hello
> >
> > I am executing a flowgraph where I pass different parameters to the
> > work() function of my block in every iteration.
>

If the "parameters" could be fed into work() as input elements, than that
is possible.
Please  describe the parameters in details.


> 1. I would like my flowgraph to execute once with a certain set of
> > parameters and on satisfying a certain condition, it should stop
> > execution (even if the queue/buffer of the block is not empty).
> > 2. The control should come back to the main() function and the next
> > iteration should start with a new set of parameters and again upon
> > satisfying a certain condition the flowgraph should exit.
>

In flow-graph there is no main() function, but only the scheduler in the
background.
Please give specific examples of what you are trying to accomplish.

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

Re: [Discuss-gnuradio] GSoC 2014: Wireless Network in the loop

[Otterbach, Nico]

Hi Asma,

this sounds very interesting, especially the implementation of new channel 
models would be a great enhancement to the WiNeLo project (and, if implemented 
as standard GR blocks, to GR in general). Concerning this matter - and as an 
additional option - one could possibly also improve and extend the already 
existing gr-channelsounder OOT (see 
https://github.com/gbaier/gr_channelsounder).

Your second thought is also a great  idea, but to me it sounds more like a demo 
application for the WiNeLo framework. I am really looking forward to see such 
applications running on top of WiNeLo, but I think that we should invest all 
the valuable development effort in the framework itself or the hardware and 
channel models right now.

I am looking forward to read your opinion on these ideas!

Nico

Von: discuss-gnuradio-bounces+nico.otterbach=student.kit@gnu.org 
[discuss-gnuradio-bounces+nico.otterbach=student.kit@gnu.org] im Auftrag 
von Asma Afzal [asmaafz...@gmail.com]
Gesendet: Montag, 10. März 2014 10:57
An: discuss-gnuradio@gnu.org
Betreff: [Discuss-gnuradio] GSoC 2014: Wireless Network in the loop

Dear All,

My name is Asma Afzal. I am currently pursuing a PhD in Electrical Engineering 
(Wireless Communication ) from the University of Leeds, UK.

I am interested in working on the WiNeLo GSoC project. WiNeLo  is an 
in-the-loop simulation framework for communication networks based on the GNU 
Radio software radio toolkit. gr-winelo mimics the behavior of common RF 
frontends such as the USRP, but instead of sending the signal over the air, a 
central server plays the role of the wireless communication channel. Arbitrary 
channel models can be simulated, by passing their respective GNU Radio 
processing block to the server. Since this whole setup is completely 
transparent to GNU Radio applications, it is at any moment possible to switch 
between simulations and real-world tests.

After watching the FOSDEM video, I believe I can make (part of) the following 
additions to the ongoing project

1. Implementation of various analytical channel models on the server to mimic 
real wireless channel. (Rayleigh, Nakagami-m, Rician, Weibull fading, Lognormal 
Shadowing)

2. Implementation of different transmission strategies such as CDM or 
interference free TDM with different digital modulation schemes.

A user will be provisioned to input various controlling parameters like the 
frequency, rate of symbol transmission, wireless environment (indoor/outdoor), 
etc.

With reference to these points, I wanted to ask senior members of the community 
regarding which tasks would be beneficial to the community immediately?

I will appreciate your input to point out the exact goal.

I believe that my skills are particularly well suited for this project.

I did my Masters in Telecommunication and Networks from NUST, Pakistan. I 
studied Wireless communication and Wireless networks in detail. I am familiar 
with modulation schemes and wireless channel impairments like path loss, 
slow/fast fading, shadowing, noise and interference. My current research is 
based on stochastic modeling of wireless networks in presence of path loss and 
fading. I have recently presented a paper at Globecom 2013. The paper hasn’t 
come on IEEE Xplore yet but you can find an electronic copy on this link.

http://ipt.seecs.nust.edu.pk/Pubs/Asma%20Globecom%202013.pdf

Although I don’t have prior experience with GNU Radios, but I have strong 
programming skills in C/C++ and Matlab. During my masters, I worked on a 
collaborative project with Cypress Semi-Conductor, USA. The project involved 
implementation of AES-128 encryption and a part of thermal management system on 
Programmable System on Chip (PSoC). As a result of successful implementation, I 
got two technical articles published (listed below).

http://www.embedded.com/design/safety-and-security/4417178/Enhancing-system-efficiency-of-embedded-encryption-applications

http://www.embedded.com/design/prototyping-and-development/4422955/Building-an-efficient--intelligent--and-flexible-thermal-management-system

I am a keen learner and I have always wanted to apply my theoretical knowledge 
on practical systems. This is my chance to do that. It will be extremely 
beneficial for my understanding of wireless systems and since this project is 
so relevant to my research, I would like to pursue it after summer as well and 
contribute to the GNU Radio open source community.

Thank you.

Kind Regards,
Asma Afzal.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm

[zhenhua han]

Thank you, Martin.
I will check these and extend my proposal with more details.

Best wishes,
Zhenhua


2014-03-11 17:00 GMT+08:00 Martin Braun :

> On 03/11/2014 04:40 AM, zhenhua han wrote:
> > Hi all,
> >
> > As Martin Braun noticed in the mail list yesterday, I haven't open my
> > proposal here.
> >
> > Here is the link:
> > https://github.com/hzhua/grgsm_proposal
> >
> > If you have any suggestions, please don't be hesitate to contact me.
> >
> > Thanks to Sylvain Munaut for his help on reviewing my first draft.
> > Thanks to Piot Krysik for his suggestions on gr-gsm.
>
> Hey,
>
> congrats on publishing the first proposal! It looks quite good.
>
> It's unclear if you have good algorithms to implement your deliverables.
> A few hints:
>
> - The FCH detection can be efficiently implemented using an adaptive
> filter. Here's a paper that explains the technique, although it's very
> poorly written:
>
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1404796&url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1404796
>
> There's also some code for this somewhere... can't find it right now.
>
> - A CEL student wrote a highly optimized MLSE, specifically for GSM, a
> while back (a *long* while back, it still uses autotools). Still, the
> code is very good, and there's a lot to be taken out of this. He tried
> out a lot of compiler switches, too, so check out lib/Makefile.am.
>
> https://github.com/pgoeser/gnuradio-mlse.git
>
> It assumes frame synchronization (i.e. post-SCCH sync), but you just
> drop in a frame, and it returns the equalized result.
>
> MB
>
>
> ___
> 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] Should return the number of input or the number of output?

[Activecat]

Yes I agree with you all.
Everything are now clear and readable.
Thank you very much.

Regards,
Activecat


On Tue, Mar 11, 2014 at 5:08 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Well, it's basically the idea of not writing a special case for a
> single type of block; and if you are aware that sync blocks are only
> subclasses of normal blocks that implement a general_work which
> consumes *and* produces the return value of work, than everything is
> clear and readable :)
> Greetings,
> Marcus
>
> On 11.03.2014 01:34, Activecat wrote:
> > Dear Martin,
> >
> > Apparently the consistency of code across different source files is
> > more emphasized than its clarity in individual file. Nevertheless
> > that is clear now, thanks.
> >
> > Regards, Activecat
> >
> >
> > On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun
> > wrote:
> >
> >> OK, I admit I was unclear. Let's try from scratch:
> >>
> >> - The return function from work() or general_work() is the amount
> >> of items that were *produced*. - In a sync block, the number of
> >> items produced is the number of items consumed, so we can use
> >> that to save the developer from manually consuming(). In other
> >> words, in a sync block, the return value is *both* the number of
> >> produced and consumed items. - Sinks and sources are syncs,
> >> therefore the mechanic is always the same. - Sinks are a special
> >> case because they don't produce anything. However, the scheduler
> >> knows the block's io signature, and knows what to do. The
> >> consume/produce mechanic stays the same, for consistency's sake,
> >> as with all other sync blocks.
> >>
> >> Hope this clears things up!
> >>
> >> M
> >>
> >>
> >> On 03/10/2014 02:09 PM, Activecat wrote:
> >>> If the return value of work() is used to tell the scheduler how
> >>> much we have consumed, than it is very clear!
> >>>
> >>> In general_work() of new templates generated by gr_modtool, we
> >>> always see this, even for sink blocks:
> >>>
> >>> // Tell runtime system how many output items we produced.
> >>> return noutput_items;
> >>>
> >>> The comment sounds like the return value of general_work() is
> >>> to tell the scheduler how many output items have produced. If
> >>> this is true, for sink block, we should actually returned zero
> >>> because sink block doesn't produce any output item.
> >>>
> >>> To avoid confusion, and to be more consistent, I suggest to put
> >>> this instead into work() of new templates of sink block:
> >>>
> >>> // Tell runtime system how many input items have been
> >>> consumed. return noutput_items;
> >>>
> >>> Because when I look into sync_block.cc, the return value of
> >>> work() is actually used for consume_each(r).
> >>>
> >>> Just a silly suggestion. Thanks.
> >>>
> >>> Regards, Activecat
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP
> M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5
> 8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI
> mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco
> t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD
> rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY=
> =4uZc
> -END PGP SIGNATURE-
>
> ___
> 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] Pybombs make error

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Saran,
you're system is missing the doxygen executable. Install doxygen using
your package manager.

Greetings,
Marcus

On 11.03.2014 06:25, sarankumar wrote:
> hi, I am trying to install GNU Radio through PyBombs in Ubuntu
> 12.04. I get the following error,
> 
> [ 21%] Built target pygen_gr_uhd_examples_python_d7761 [ 21%] Built
> target _pmt_swig_doc_tag Scanning dependencies of target
> pmt_swig_swig_doc [ 21%] Generating doxygen xml for pmt_swig_doc
> docs /bin/sh: 1: DOXYGEN_EXECUTABLE-NOTFOUND: not found make[2]:
> *** [gnuradio-runtime/swig/pmt_swig_doc_swig_docs/xml/index.xml] 
> Error 127 make[1]: ***
> [gnuradio-runtime/swig/CMakeFiles/pmt_swig_swig_doc.dir/all] Error
> 2 make[1]: *** Waiting for unfinished jobs [ 22%] Building CXX
> object 
> gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_unv.cc.o [
> 22%] [ 22%] [ 22%] Building CXX object 
> gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt.cc.o 
> Building CXX object 
> gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_io.cc.o [
> 22%] Building CXX object 
> gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_pool.cc.o 
> Building CXX object 
> gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_serialize.cc.o
>
> 
Linking C shared library libvolk.so
> [ 22%] Built target volk Linking CXX shared library
> libgnuradio-pmt-3.7.4git.so [ 22%] Built target gnuradio-pmt make:
> *** [all] Error 2 ERROR:root:PyBOMBS Make step failed for package
> (gnuradio) please see bash output above for a reason (hint: look
> for the word Error)
> 
> I also tried to reconfigure with builddocs=OFF. But I get the
> following error on doing so.
> 
> Install Prefix Traceback (most recent call last): File "./pybombs",
> line 198, in  pybombs_ops.config_init(config, True) File
> "/home/tslsb/pybombs/mod_pybombs/cfg.py", line 70, in config_init 
> if os.path.basename(pwd)=="pybombs": File
> "/usr/lib/python2.7/posixpath.py", line 112, in basename i =
> p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute
> 'rfind'
> 
> Can anyone help me?
> 
> Regards, Saran
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTHtNFAAoJEBQ6EdjyzlHt3xgH/2VkAIr/mdnyGBSZW3iiaMsv
Y3/azZ9k3uzMup0DqpaqyK3lwLLIYW1q6YdpwddNCtTTYL+b6ht0aJqxgQv2Y5vz
BPhDiA26HY7WqNmneWQXob8cxL0pZsivxom7biB2Sh2axdlO86X4RP4LMC3O975r
VfpBDpchkJlcOIpc0ATinkghtqIMicJvo6YJmck/H+qWhtoYhiW5Fj/lRq8zxps2
B5Qy20j+dqHpmVLHY9CLwCIAaEq4zvdZHBmJM0Gnw54qSoroRaPHWau9fJJQF7Sb
SCBe9gtaQ4f/dBCsVr5ZEqhwHSHQtuX+sOdam59UvzUyRJTCOA0/LFLhN0h75l8=
=TO/M
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Should return the number of input or the number of output?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Well, it's basically the idea of not writing a special case for a
single type of block; and if you are aware that sync blocks are only
subclasses of normal blocks that implement a general_work which
consumes *and* produces the return value of work, than everything is
clear and readable :)
Greetings,
Marcus

On 11.03.2014 01:34, Activecat wrote:
> Dear Martin,
> 
> Apparently the consistency of code across different source files is
> more emphasized than its clarity in individual file. Nevertheless
> that is clear now, thanks.
> 
> Regards, Activecat
> 
> 
> On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun
> wrote:
> 
>> OK, I admit I was unclear. Let's try from scratch:
>> 
>> - The return function from work() or general_work() is the amount
>> of items that were *produced*. - In a sync block, the number of
>> items produced is the number of items consumed, so we can use
>> that to save the developer from manually consuming(). In other
>> words, in a sync block, the return value is *both* the number of
>> produced and consumed items. - Sinks and sources are syncs,
>> therefore the mechanic is always the same. - Sinks are a special
>> case because they don't produce anything. However, the scheduler
>> knows the block's io signature, and knows what to do. The 
>> consume/produce mechanic stays the same, for consistency's sake,
>> as with all other sync blocks.
>> 
>> Hope this clears things up!
>> 
>> M
>> 
>> 
>> On 03/10/2014 02:09 PM, Activecat wrote:
>>> If the return value of work() is used to tell the scheduler how
>>> much we have consumed, than it is very clear!
>>> 
>>> In general_work() of new templates generated by gr_modtool, we
>>> always see this, even for sink blocks:
>>> 
>>> // Tell runtime system how many output items we produced. 
>>> return noutput_items;
>>> 
>>> The comment sounds like the return value of general_work() is
>>> to tell the scheduler how many output items have produced. If
>>> this is true, for sink block, we should actually returned zero 
>>> because sink block doesn't produce any output item.
>>> 
>>> To avoid confusion, and to be more consistent, I suggest to put
>>> this instead into work() of new templates of sink block:
>>> 
>>> // Tell runtime system how many input items have been
>>> consumed. return noutput_items;
>>> 
>>> Because when I look into sync_block.cc, the return value of
>>> work() is actually used for consume_each(r).
>>> 
>>> Just a silly suggestion. Thanks.
>>> 
>>> Regards, Activecat
>>> 
>>> 
>>> 
>>> ___ 
>>> 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
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP
M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5
8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI
mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco
t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD
rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY=
=4uZc
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] looping with work() function

[Martin Braun]

On 03/11/2014 06:10 AM, Sumedha Goyal wrote:
> Hello
> 
> I am executing a flowgraph where I pass different parameters to the
> work() function of my block in every iteration.

I'm not sure I'm understanding you correctly, but this is not how you
use GNU Radio blocks.

Have a look at gr-digital/examples/berawgn.py. Is this what you want to do?

> 1. I would like my flowgraph to execute once with a certain set of
> parameters and on satisfying a certain condition, it should stop
> execution (even if the queue/buffer of the block is not empty). 
> 2. The control should come back to the main() function and the next
> iteration should start with a new set of parameters and again upon
> satisfying a certain condition the flowgraph should exit.

You shut down a flow graph by returning WORK_DONE (or -1) from the work
function.

M

> 
> *The work() function is of the block "test_demo":*
> *new_test_tx.py#*
> class test_demo(gras.Block):
>  def__init__(self,parameters):
> gras.Block.__init__(self,name="test",
> in_sig = [numpy.uint8,numpy.uint8,numpy.uint8],
> out_sig = [numpy.uint8,numpy.uint8])
> 
> def work(self, ins, outs):
> --some process here
> 
> *The top_block is as following and has code for all the connections(not
> shown here):*
> 
> class top_block(grc_wxgui.top_block_gui):
> 
> def __init__(self,options,llr):
> grc_wxgui.top_block_gui.__init__(self, title="Top Block")
> _icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
> self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
> 
>   self.=new_test_tx.test_demo(options.parameters)
> def main():
> 
> parser = OptionParser(option_class=eng_option, conflict_handler="resolve")
> parser.add_option("", "--args",default="",
>  help="set the address of usrp_device [default='']")
> (options, args) = parser.parse_args ()
> # build the graph
> tb=top_block(options,param)
> tb.Run(True)
> if __name__=="__main__":
> main()
> 
> I am able to execute the flowgraph once and then the main() function exits.
> I would like to perform this action for some 1000 iterations. It is a
> kind of for loop that I use during C/Python programming. How can I use
> it with GNURadio and Python.
> 
> 
> Thanks and Regards,
> Sumedha
> 
> 
> ___
> 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] Proposal for GSoC on gr-gsm

[Martin Braun]

On 03/11/2014 04:40 AM, zhenhua han wrote:
> Hi all,
> 
> As Martin Braun noticed in the mail list yesterday, I haven't open my
> proposal here.
> 
> Here is the link:
> https://github.com/hzhua/grgsm_proposal
> 
> If you have any suggestions, please don't be hesitate to contact me.
> 
> Thanks to Sylvain Munaut for his help on reviewing my first draft.
> Thanks to Piot Krysik for his suggestions on gr-gsm.

Hey,

congrats on publishing the first proposal! It looks quite good.

It's unclear if you have good algorithms to implement your deliverables.
A few hints:

- The FCH detection can be efficiently implemented using an adaptive
filter. Here's a paper that explains the technique, although it's very
poorly written:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1404796&url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1404796

There's also some code for this somewhere... can't find it right now.

- A CEL student wrote a highly optimized MLSE, specifically for GSM, a
while back (a *long* while back, it still uses autotools). Still, the
code is very good, and there's a lot to be taken out of this. He tried
out a lot of compiler switches, too, so check out lib/Makefile.am.

https://github.com/pgoeser/gnuradio-mlse.git

It assumes frame synchronization (i.e. post-SCCH sync), but you just
drop in a frame, and it returns the equalized result.

MB


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

Re: [Discuss-gnuradio] Python block, itemsize mismatch

[Martin Braun]

On 03/11/2014 02:06 AM, David Halls wrote:
> You're a genius! It works.
> 
> Interestingly for a float it requires numpy.float32 or a similar error
> occurs.

Yes, in GNU Radio we consistently use 32-bit floats. A complex value
consists of two of these, hence the 64 bits.

Note that this is just for buffers. A lot of blocks use double
internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason.
However, for signals, it's just a waste of bandwidth (most of time, SNR
will trump quantization noise anyway).

M


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

Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm

[Bogdan Diaconescu]

Hi Zhenhua,

gr-gsm should be a good project for you and for the community. I wish you 
success.


You may want to look at the slow frequency hopping implementation of airprobe 
that is placed here: https://github.com/BogdanDIA/airprobe-hopping.
It uses PFB to split a 20mhz band received with USRP-N210 into GSM channels and 
then use all of them according to the hopping algorithm decoded on the 
Immediate Assignment message and SI 1. It is not a perfect implementation as 
airprobe is not perfect too, that is why I think this will be a good project.

The hopping patch has been done two years ago and has API for gnuradio3.6 era. 
I did not update it yet on 3.7. Here is small paper I wrote at the moment of 
creating a patch. It may be of help to you.


http://yo3iiu.ro/blog/wp-content/uploads/2012/04/Evaluating_GSM_hopping_V1.1.pdf


Bogdan




On Tuesday, March 11, 2014 5:40 AM, zhenhua han  wrote:
 
Hi all,

As Martin Braun noticed in the mail list yesterday, I haven't open my proposal 
here.


Here is the link:https://github.com/hzhua/grgsm_proposal

If you have any suggestions, please don't be hesitate to contact me.


Thanks to Sylvain Munaut for his help on reviewing my first draft.
Thanks to Piot Krysik for his suggestions on gr-gsm.


Best wishes,
Zhenhua

___
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