Re: [Discuss-gnuradio] IMSI Catcher Catcher?

2016-06-20 Thread Ron Economos 
There's a talk scheduled for DEFCON 24 called "Discovering and 
Triangulating Rogue Cell Towers" by Eric Escobar.


https://defcon.org/html/defcon-24/dc-24-speakers.html

About halfway down the page.

Ron

On 06/20/2016 07:21 PM, Ronald F. Guilmette wrote:

In message <182b157d-0f2c-b5b9-a07a-6812cccd2...@gmail.com>,
Cinaed Simson  wrote:


Actually, you would need 2 HackRF One devices since they are half duplex
- better to buy a bladerf which is full duplex

  https://www.nuand.com

If you want to buy a working device, Alibaba has them for sale

  https://www.alibaba.com/product-detail/IMSI-catcher_135958750.html


I'm sorry to have to say this, but I believe that you are confused on two
rather important points relating to my query:

1)  As is made clear by the fact that you gave a link to a place where I
(or anyone) could purchase a stingray device, it is apparent that you did
not understand that I wish to see the construction of a device that would
*detect* the local operation of stingrays.  I do not want a stingray.  I want
to detect them.

1) As far as I am aware at this time, detection of stingrays is just a matter
of merely _listening_ to a proper set of specific frequencies and then
correctly interpreting the received data.  Thus, your point about obtaining
a full duplex device, in prefrence to a half duplex device, also seems
rather entirely off the mark.


Regards,
rfg


P.S. While I appreciate general and non-specific statements of support for
"interesting projects" either based on or relating to GNURadio, I did not
join this mailing list merely to collect such generalized well wishes.
I need to find people who will actually construct what I am seeking, i.e.
a low cost portable stingray detector of the kind depicted in the following
facinating and informative Vice News video:

https://www.youtube.com/watch?v=rzBWoVh4qhk

(Note that I have already attempted to make contact with the fellow from
Privacy International who is shown using the stingray detector in this video...
so that I may ask him to describe the exact hardware and software he is using...
but so far I have been unable contact him.)


___
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] IMSI Catcher Catcher?

2016-06-20 Thread Andrew Back 
On 21 Jun 2016 06:02, "Ronald F. Guilmette"  wrote:
>
>
> In message <182b157d-0f2c-b5b9-a07a-6812cccd2...@gmail.com>,
> Cinaed Simson  wrote:
>
> >Actually, you would need 2 HackRF One devices since they are half duplex
> >- better to buy a bladerf which is full duplex
> >
> >  https://www.nuand.com
> >
> >If you want to buy a working device, Alibaba has them for sale
> >
> >  https://www.alibaba.com/product-detail/IMSI-catcher_135958750.html
>
>
> I'm sorry to have to say this, but I believe that you are confused on two
> rather important points relating to my query:
>
> 1)  As is made clear by the fact that you gave a link to a place where I
> (or anyone) could purchase a stingray device, it is apparent that you did
> not understand that I wish to see the construction of a device that would
> *detect* the local operation of stingrays.  I do not want a stingray.  I
want
> to detect them.
>
> 1) As far as I am aware at this time, detection of stingrays is just a
matter
> of merely _listening_ to a proper set of specific frequencies and then
> correctly interpreting the received data.  Thus, your point about
obtaining
> a full duplex device, in prefrence to a half duplex device, also seems
> rather entirely off the mark.
>
>
> Regards,
> rfg
>
>
> P.S. While I appreciate general and non-specific statements of support for
> "interesting projects" either based on or relating to GNURadio, I did not
> join this mailing list merely to collect such generalized well wishes.
> I need to find people who will actually construct what I am seeking, i.e.
> a low cost portable stingray detector of the kind depicted in the
following
> facinating and informative Vice News video:
>
>https://www.youtube.com/watch?v=rzBWoVh4qhk
>
> (Note that I have already attempted to make contact with the fellow from
> Privacy International who is shown using the stingray detector in this
video...
> so that I may ask him to describe the exact hardware and software he is
using...
> but so far I have been unable contact him.)

It sounds like you may have more success if you contact an RF/DSP
engineering company with your requirement, since it appears you have a
budget for this work.

Regards,

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

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

2016-06-20 Thread Ronald F. Guilmette 

In message <182b157d-0f2c-b5b9-a07a-6812cccd2...@gmail.com>, 
Cinaed Simson  wrote:

>Actually, you would need 2 HackRF One devices since they are half duplex
>- better to buy a bladerf which is full duplex
>
>  https://www.nuand.com
>
>If you want to buy a working device, Alibaba has them for sale
>
>  https://www.alibaba.com/product-detail/IMSI-catcher_135958750.html


I'm sorry to have to say this, but I believe that you are confused on two
rather important points relating to my query:

1)  As is made clear by the fact that you gave a link to a place where I
(or anyone) could purchase a stingray device, it is apparent that you did
not understand that I wish to see the construction of a device that would
*detect* the local operation of stingrays.  I do not want a stingray.  I want
to detect them.

1) As far as I am aware at this time, detection of stingrays is just a matter
of merely _listening_ to a proper set of specific frequencies and then
correctly interpreting the received data.  Thus, your point about obtaining
a full duplex device, in prefrence to a half duplex device, also seems
rather entirely off the mark.


Regards,
rfg


P.S. While I appreciate general and non-specific statements of support for
"interesting projects" either based on or relating to GNURadio, I did not
join this mailing list merely to collect such generalized well wishes.
I need to find people who will actually construct what I am seeking, i.e.
a low cost portable stingray detector of the kind depicted in the following
facinating and informative Vice News video:

   https://www.youtube.com/watch?v=rzBWoVh4qhk

(Note that I have already attempted to make contact with the fellow from
Privacy International who is shown using the stingray detector in this video...
so that I may ask him to describe the exact hardware and software he is using...
but so far I have been unable contact him.)


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

Re: [Discuss-gnuradio] Pythonic way of how to quit the process if U is displayed on output

2016-06-20 Thread Martin Braun 
Yeah, they're the obsolete style. Marcus Müller has been working on a
patch to use the PMT messages, but some obnoxious maintainer[1] keeps
finding issues with his code :)

M

[1] That's me. And we'll figure out those issues :)

On 06/20/2016 04:29 PM, Dave NotTelling wrote:
> Martin,
> 
>  Are there any examples of using that thing?  I see that is uses
> messages, but they appear to be different from PMT messages.  There are
> some examples that use a callback in the Python script generated by GRC,
> but I haven't ever been able to make one of those things work.  It's
> very possible that I'm just screwing things up.
> 
> Thanks!
> 
> On Mon, Jun 20, 2016 at 5:04 PM, Martin Braun  > wrote:
> 
> You can instantiate a USRP Async Msg block, and poll that for underruns.
> 
> M
> 
> On 06/17/2016 11:37 AM, Pavan Yedavalli wrote:
> > Hi,
> >
> > Sometimes my computer acts up and displays Us on the output, meaning
> > that there are underruns. However, this does not happen too often, but
> > is a pain when I am running an automated trial because it freezes the
> > entire program. Is there a way in python to tell whether a U is
> printed
> > out and then quit it so that I can try again?
> >
> > I have been trying to think of ways to get the screen output and
> do some
> > logic based on that, but I'm wondering if there is a
> quicker/easier way
> > since this is a relatively common problem.
> >
> > --
> > Pavan
> >
> >
> > ___
> > 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] IMSI Catcher Catcher?

2016-06-20 Thread Cinaed Simson 
Actually, you would need 2 HackRF One devices since they are half duplex
- better to buy a bladerf which is full duplex

  https://www.nuand.com

If you want to buy a working device, Alibaba has them for sale

  https://www.alibaba.com/product-detail/IMSI-catcher_135958750.html

Harris Corp - developer of the Stingray also developed KingFish the
person-mobile battery powered device for GSM and CDMA interrogation.

Maybe you could apply for a grant from Home Land Security to develop the
compact version of the KingFish device.


On 06/20/2016 01:34 PM, Ronald F. Guilmette wrote:
> 
> I just wanted to check again, one last time, before I exit this
> mailing list.  I got no truly useful replies to my earlier post,
> so I just wanted to ask again...
> 
> Nobody here either knows of, or has any particular interest in creating
> an off-the-shelf stingray detector (aka "IMSI Catcher Catcher")?
> 
> Is that correct?
> 
> If so, that's a pity.  I would have thought that GNURadio would have
> been a perfect basis for this kind of thing, certainly code-wise, but
> also because of the typical and widespread political leanings of most
> GNU communities, which tend to favor individual freedom in preference
> to state-sanctioned orthodoxy.
> 
> 
> Regards,
> rfg
> 
> ___
> 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] Pythonic way of how to quit the process if U is displayed on output

2016-06-20 Thread Dave NotTelling 
Martin,

 Are there any examples of using that thing?  I see that is uses
messages, but they appear to be different from PMT messages.  There are
some examples that use a callback in the Python script generated by GRC,
but I haven't ever been able to make one of those things work.  It's very
possible that I'm just screwing things up.

Thanks!

On Mon, Jun 20, 2016 at 5:04 PM, Martin Braun 
wrote:

> You can instantiate a USRP Async Msg block, and poll that for underruns.
>
> M
>
> On 06/17/2016 11:37 AM, Pavan Yedavalli wrote:
> > Hi,
> >
> > Sometimes my computer acts up and displays Us on the output, meaning
> > that there are underruns. However, this does not happen too often, but
> > is a pain when I am running an automated trial because it freezes the
> > entire program. Is there a way in python to tell whether a U is printed
> > out and then quit it so that I can try again?
> >
> > I have been trying to think of ways to get the screen output and do some
> > logic based on that, but I'm wondering if there is a quicker/easier way
> > since this is a relatively common problem.
> >
> > --
> > Pavan
> >
> >
> > ___
> > 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] IMSI Catcher Catcher?

2016-06-20 Thread Nick Foster 
The GNU Radio community is always excited to see new applications for the
platform. We have an excellent history of supporting new developers with
interesting ideas who wish to work to turn those ideas into working
software.

--n

On Mon, Jun 20, 2016 at 2:19 PM Ronald F. Guilmette 
wrote:

>
> I just wanted to check again, one last time, before I exit this
> mailing list.  I got no truly useful replies to my earlier post,
> so I just wanted to ask again...
>
> Nobody here either knows of, or has any particular interest in creating
> an off-the-shelf stingray detector (aka "IMSI Catcher Catcher")?
>
> Is that correct?
>
> If so, that's a pity.  I would have thought that GNURadio would have
> been a perfect basis for this kind of thing, certainly code-wise, but
> also because of the typical and widespread political leanings of most
> GNU communities, which tend to favor individual freedom in preference
> to state-sanctioned orthodoxy.
>
>
> Regards,
> rfg
>
> ___
> 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: Re: Changing sample rate during runtime

2016-06-20 Thread Martin Braun 
Wait, are you using a single channel? That would be very weird if you
saw that issue, that's true.

Otherwise, do you get this when you're switching from low rates to
really high rates, or regardless of the change?

M

On 06/17/2016 03:55 AM, olvhammar wrote:
> 
> 
> Hi Martin,
> 
> These are the rates I need to able to change between: { "50.0" "25.0"
> "20.0" "10.0" "5.0" "2.5" "2.0" "1.0" "0.8" "0.5" "0.2" } MHz
> It seems to work fine even tough i get the Error and I have no need to
> time align or sync the two RX channels.
> But still I'm a bit worried about it and would like to get rid of it.
> 
> Regards Simon
> 
> 
> On 2016-06-17 01:33, Martin Braun wrote:
>> From which rate to which new rate are you changing your sample rates?
>>
>> M
>>
>> On 06/16/2016 07:33 AM, olvhammar wrote:
>>> Hi,
>>>
>>> For several reasons I need to change the sample rate during runtime (i.e
>>> flowgraph running) in my gnuradio program. I use Ettus X310 and receive
>>> on two UBX-160 cards. The error that I get when I change the sample rate
>>> is the following:
>>>
>>> UHD Error:
>>> The receive packet handler failed to time-align packets.
>>> 1002 received packets were processed by the handler.
>>> However, a timestamp match could not be determined.
>>>
>>> Any ideas on how to address this?
>>>
>>> Regards Simon
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] Stream tag/Message passing loops

2016-06-20 Thread Martin Braun 
Ngai,

we have an example for this in uhd_msg_tune.grc. Maybe that'll give you
a clue.

M

On 06/14/2016 12:14 PM, Ngai-Han Liu wrote:
> Hi there,
> 
> I've been playing around with message passing and stream tags as a
> beginner and am trying to allow the centre frequency of my USRP be
> changed via message passing command based on some basic if statements.
> 
> I made a conceptual system where when my custom sink block receives a
> propagated stream tag (rx_freq from the USRP). It enters the IF
> statement which then passes a message to USRP source to change its
> frequency.
> 
> It looks something like this:
> 
> std::vector tags;
> get_tags_in_range(
> tags,
> 0,
> abs_N,
> end_N,
> pmt::intern("rx_freq")
> );
> 
> pmt::pmt_t command = pmt::cons( // Make a pair
> pmt::mp("freq"), // Key is 'freq' => sets the frequency
> pmt::mp(98.8e6)); // Set the frequency to 1.1 GHz
> 
> if (tags.size()>0)
> {
> message_port_pub(pmt::mp("freq"),command);
> double b = pmt::to_double(tags[0].value);
> cout << b << endl;
> }
> 
> When I first start the flow graph, even if my default frequency is
> something arbitrary e.g. 200mhz, the stream tag on startup sends the
> command and the USRP recentres to 98.8MHz. So far so good...
> 
> I also have QT gui variable which allows me to change the frequency of
> USRP using a slider. What I anticipated for this loop to do is when the
> slider is moved, it causes USRP to change frequency which triggers its
> stream tag to propagate. Which then causes it tune back to 98.8.
> 
> 
> Now the strange thing is when my sink block receives this message. It
> goes into the if loop, and sends the command. But it is completely
> ignored!! Could anyone tell me why this might be?
> 
> 
> Many thanks,
> Ngai
> 
> 
> 
> ___
> 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] Pythonic way of how to quit the process if U is displayed on output

2016-06-20 Thread Martin Braun 
You can instantiate a USRP Async Msg block, and poll that for underruns.

M

On 06/17/2016 11:37 AM, Pavan Yedavalli wrote:
> Hi,
> 
> Sometimes my computer acts up and displays Us on the output, meaning
> that there are underruns. However, this does not happen too often, but
> is a pain when I am running an automated trial because it freezes the
> entire program. Is there a way in python to tell whether a U is printed
> out and then quit it so that I can try again?
> 
> I have been trying to think of ways to get the screen output and do some
> logic based on that, but I'm wondering if there is a quicker/easier way
> since this is a relatively common problem.
> 
> -- 
> Pavan
> 
> 
> ___
> 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] Error when switching between QPSK and BPSK modulations

2016-06-20 Thread Damindra Bandara 
Hi,

I am developing an application which changes between the QPSK and BPSK
modulations based on the signal level. My transmitter path is set as
follows.

File source --> Packet Encoder --> Constellation modulator --.>  USRP sink.

Initially, the constellation of the 'Constellation modulator' is set to a
QPSK  Constellation Rect. Object. To change the modulation to BPSK I change
the Constellation Rect. Object to BPSK.
Everything works fine for the change from QPSK to BPSK. But when I try to
change back to QPSK from BPSK I get the following error.

sched:  is requesting more input data
  than we can provide.
  ninput_items_required = 13525
  max_possible_items_available = 8191
  If this is a filter, consider reducing the number of taps.

I appreciate if you could help me to solve this problem.

Thank you
Damindra
-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

2016-06-20 Thread Ronald F. Guilmette 

I just wanted to check again, one last time, before I exit this
mailing list.  I got no truly useful replies to my earlier post,
so I just wanted to ask again...

Nobody here either knows of, or has any particular interest in creating
an off-the-shelf stingray detector (aka "IMSI Catcher Catcher")?

Is that correct?

If so, that's a pity.  I would have thought that GNURadio would have
been a perfect basis for this kind of thing, certainly code-wise, but
also because of the typical and widespread political leanings of most
GNU communities, which tend to favor individual freedom in preference
to state-sanctioned orthodoxy.


Regards,
rfg

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

Re: [Discuss-gnuradio] Load Preset parameters in block

2016-06-20 Thread Mark Arlinghaus 
Maybe "defaults" is not the correct word to describe what I am trying to 
accomplish.  The parameter values that pop up when you first drop the block 
down onto a flowgraph aren't necessarily important.  But once the user double 
clicks the block to open the properties dialog, I want them to be able to 
select from a drop down menu list of presets that will auto-fill the rest of 
the parameters according to which option was selected.  Note that I would like 
the user to still be able to change the values that were "auto-filled" 
previously, so they can enter a setup that deviates slightly from the preset 
without having to enter all of the parameters manually.

I can add all of the necessary info in the xml file.  I just don't know how to 
set the parameters to the proper values based on the selected option.  It seems 
like there should be some mechanism to do it because I can hide or show 
parameters based on the selected options (conditional statements seem to work 
inside of  tags), so there must be some callback mechanism in place.  But 
no way to change the values of the parameters based on a selected option?

Mark

From: Marcus D. Leech [mle...@ripnet.com]
Sent: Monday, June 20, 2016 3:49 PM
To: Mark Arlinghaus; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Load Preset parameters in block

On 06/20/2016 03:17 PM, Mark Arlinghaus wrote:
Hi Marcus,

Thank you for your quick response.  Sorry I wasn't clear.  I'm actually talking 
about GRC construction.  Once the code is running the parameters won't need to 
be changed.  If we need to change the parameters, stopping the flowgraph is 
acceptable.  It's really just meant to make the block slightly easier/faster to 
set up by the user.  I'm hoping that this makes the solution simpler!?

Mark
Defaults for block parameters in GRC are defined in the .xml description of the 
block, but there's no way to override what ever is in
  the .xml when you first instantiate a block in GRC.



From: Discuss-gnuradio 
[discuss-gnuradio-bounces+marlinghaus=girdsystems@gnu.org]
 on behalf of Marcus D. Leech 
[mle...@ripnet.com]
Sent: Monday, June 20, 2016 3:09 PM
To: 
discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Load Preset parameters in block

On 06/20/2016 02:15 PM, Mark Arlinghaus wrote:
Hello,

Is there a way to load preset default parameters in a block.  For example, I 
have a channel model block that takes several parameters, such as the doppler 
spread, path delays, path gains, doppler spectrum, etc., and I want to have 
presets that will auto-populate the parameters in the GRC block for pre-defined 
channel models.  I can make a drop-down menu that has the pre-defined channel 
models, but I don't know how to change the values that populate in the other 
parameters.  I would like to do this using the xml file.  Is there a way to put 
a conditional parameter in the  tags that would depend on the setting in 
the drop down menu (It seems conditionals can be used in the  and 
 tags, but not inside the  tags)?  Is there a way to do it using 
the  tags?  Is there a list of valid options and what they do anywhere?  
It seems the  val:XXX <\opt> tags might do it, but I can't seem to get any 
of them to work.

Although I could pass in a preset parameter to the C++ function and simply 
override everything coming from the GUI, I'd rather have it populate the 
parameters in the block, but still let them be changed.  This way, if someone 
wanted to load the settings for a "Channel X" preset, except with a different 
Doppler spread, it could be done easily.

Note this is a similar problem as posted here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html,
 but it doesn't appear the previous question was ever answered.

Thank you in advance for your help.

Mark Arlinghaus



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


It's not clear whether you're talking about *runtime* or during GRC 
construction.

For runtime, I'd write a little Python module that contains a function for each 
parameter:

setter_function(configfilename, command-line-parameter, widget-control-value)

You then have logic in the function to determine the priority of what gets 
returned:

config-->command-line-->widget-control-value

I've done that in the past.



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

Re: [Discuss-gnuradio] Question about tagged_stream_block

2016-06-20 Thread Martin Braun 
It'll crash. If you know your packet size a priori, you can tell the
scheduler to only provide multiples of a 1000 samples.

Cheers,
M

On 06/20/2016 07:17 AM, bob wole wrote:
> Hi,
> My  flowgraph contains a tagged_stream_block, B, and it has a
> length_tag_key, say "pkt_len". Each packet has a length of 1000 samples.
> The upstream block (A-->B) tags first sample with key "pkt_len" and
> value 1000 and then the upstream block tags sample number 901 with key
> "pkt_len" and value 1000 instead of tagging sample number 1001. This
> could happen in case of overflow and I know using receive tags that 100
> samples has been lost. So, samples from 901 to 1900 contains a new
> packet. Will the flowgraph work or will it crash?
> 
> I want to write a block that processes exactly only 1000 samples, one
> packet, in a call to work. And the packets start from a specific time
> for example when the rx_time of the sample is mid of any second. 
> 
> 
> --
> Bob
> 
> 
> ___
> 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] Load Preset parameters in block

2016-06-20 Thread Marcus D. Leech 

On 06/20/2016 03:17 PM, Mark Arlinghaus wrote:

Hi Marcus,

Thank you for your quick response.  Sorry I wasn't clear.  I'm 
actually talking about GRC construction.  Once the code is running the 
parameters won't need to be changed.  If we need to change the 
parameters, stopping the flowgraph is acceptable.  It's really just 
meant to make the block slightly easier/faster to set up by the user. 
 I'm hoping that this makes the solution simpler!?


Mark
Defaults for block parameters in GRC are defined in the .xml description 
of the block, but there's no way to override what ever is in

  the .xml when you first instantiate a block in GRC.




*From:* Discuss-gnuradio 
[discuss-gnuradio-bounces+marlinghaus=girdsystems@gnu.org] on 
behalf of Marcus D. Leech [mle...@ripnet.com]

*Sent:* Monday, June 20, 2016 3:09 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Load Preset parameters in block

On 06/20/2016 02:15 PM, Mark Arlinghaus wrote:

Hello,

Is there a way to load preset default parameters in a block.  For 
example, I have a channel model block that takes several parameters, 
such as the doppler spread, path delays, path gains, doppler 
spectrum, etc., and I want to have presets that will auto-populate 
the parameters in the GRC block for pre-defined channel models.  I 
can make a drop-down menu that has the pre-defined channel models, 
but I don't know how to change the values that populate in the other 
parameters.  I would like to do this using the xml file.  Is there a 
way to put a conditional parameter in the  tags that would 
depend on the setting in the drop down menu (It seems conditionals 
can be used in the  and  tags, but not inside the 
 tags)?  Is there a way to do it using the  tags?  Is 
there a list of valid options and what they do anywhere?  It seems 
the  val:XXX <\opt> tags might do it, but I can't seem to get 
any of them to work.


Although I could pass in a preset parameter to the C++ function and 
simply override everything coming from the GUI, I'd rather have it 
populate the parameters in the block, but still let them be changed.  
This way, if someone wanted to load the settings for a "Channel X" 
preset, except with a different Doppler spread, it could be done easily.


Note this is a similar problem as posted here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html, 
 but it doesn't appear the previous question 
was ever answered.


Thank you in advance for your help.

Mark Arlinghaus


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
It's not clear whether you're talking about *runtime* or during GRC 
construction.


For runtime, I'd write a little Python module that contains a function 
for each parameter:


setter_function(configfilename, command-line-parameter, 
widget-control-value)


You then have logic in the function to determine the priority of what 
gets returned:


config-->command-line-->widget-control-value

I've done that in the past.




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

Re: [Discuss-gnuradio] Audio underrun when using Audio Sink

2016-06-20 Thread Paul S 
Hi Kevin & Marcus,

thank you for your answers. After a while of testing I've got interesting
results. Firstly, even though it brought 100% CPU load on one core, the
packet encoder is not a problem as the underruns also occured without it.
Anyway, thank you for your suggestion, I'll certainly look into it. Do you
have a link for a thread or something like that where Felix Wunsch mentioned
this? And your example: Does that mean I could use this method on on one
frequency alone?

Secondly, I had about 25% CPU load on all cores for the first flowgraph,
except for when I got these underruns where my CPU load promptly exploded to
100%. However, I'd blame this rise on the underruns themselves as everything
was fine shortly before (maybe because of busy waiting?).
Nevertheless I've splitted the resampler and I am now using 4 resamplers in
a row to get a interpolation of ~100. Both the Socket PDU and the File
Source are producing only occasionally underruns but apart from this they
are doing fine now. Unfortunately the TunSource block is still producing
lots of them (although it's less frequently now). Here's the code for the
TunSource. Maybe you can see what's wrong.


def work(self, input_items, output_items):
out = output_items[0]   
# Read from tun device 
packet = tun.read()
tun.printPkg(packet)

# Extract the header
header = packet[:20]
unpacked = unpack('!BBHHHBBH4s4s',header)
size = unpacked[4]
buf = packet[32:]
# cast buffer to (iterable) list
myarray = list(buf)

# Counter variable for position in output array
j = 0
for i in myarray:
num = 0
try:
num = (numpy.int8(ord(i)))
except ValueError:
num = chr(0)
output_items[0][j] = num
j = j+1
return len(buf)


Regards
Paul



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Audio-underrun-when-using-Audio-Sink-tp60547p60568.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Load Preset parameters in block

2016-06-20 Thread Mark Arlinghaus 
Hi Marcus,

Thank you for your quick response.  Sorry I wasn't clear.  I'm actually talking 
about GRC construction.  Once the code is running the parameters won't need to 
be changed.  If we need to change the parameters, stopping the flowgraph is 
acceptable.  It's really just meant to make the block slightly easier/faster to 
set up by the user.  I'm hoping that this makes the solution simpler!?

Mark

From: Discuss-gnuradio 
[discuss-gnuradio-bounces+marlinghaus=girdsystems@gnu.org] on behalf of 
Marcus D. Leech [mle...@ripnet.com]
Sent: Monday, June 20, 2016 3:09 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Load Preset parameters in block

On 06/20/2016 02:15 PM, Mark Arlinghaus wrote:
Hello,

Is there a way to load preset default parameters in a block.  For example, I 
have a channel model block that takes several parameters, such as the doppler 
spread, path delays, path gains, doppler spectrum, etc., and I want to have 
presets that will auto-populate the parameters in the GRC block for pre-defined 
channel models.  I can make a drop-down menu that has the pre-defined channel 
models, but I don't know how to change the values that populate in the other 
parameters.  I would like to do this using the xml file.  Is there a way to put 
a conditional parameter in the  tags that would depend on the setting in 
the drop down menu (It seems conditionals can be used in the  and 
 tags, but not inside the  tags)?  Is there a way to do it using 
the  tags?  Is there a list of valid options and what they do anywhere?  
It seems the  val:XXX <\opt> tags might do it, but I can't seem to get any 
of them to work.

Although I could pass in a preset parameter to the C++ function and simply 
override everything coming from the GUI, I'd rather have it populate the 
parameters in the block, but still let them be changed.  This way, if someone 
wanted to load the settings for a "Channel X" preset, except with a different 
Doppler spread, it could be done easily.

Note this is a similar problem as posted here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html,
 but it doesn't appear the previous question was ever answered.

Thank you in advance for your help.

Mark Arlinghaus



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


It's not clear whether you're talking about *runtime* or during GRC 
construction.

For runtime, I'd write a little Python module that contains a function for each 
parameter:

setter_function(configfilename, command-line-parameter, widget-control-value)

You then have logic in the function to determine the priority of what gets 
returned:

config-->command-line-->widget-control-value

I've done that in the past.


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

Re: [Discuss-gnuradio] Load Preset parameters in block

2016-06-20 Thread Marcus D. Leech 

On 06/20/2016 02:15 PM, Mark Arlinghaus wrote:

Hello,

Is there a way to load preset default parameters in a block. For 
example, I have a channel model block that takes several parameters, 
such as the doppler spread, path delays, path gains, doppler spectrum, 
etc., and I want to have presets that will auto-populate the 
parameters in the GRC block for pre-defined channel models.  I can 
make a drop-down menu that has the pre-defined channel models, but I 
don't know how to change the values that populate in the other 
parameters.  I would like to do this using the xml file.  Is there a 
way to put a conditional parameter in the  tags that would 
depend on the setting in the drop down menu (It seems conditionals can 
be used in the  and  tags, but not inside the  
tags)? Is there a way to do it using the  tags?  Is there a list 
of valid options and what they do anywhere?  It seems the  
val:XXX <\opt> tags might do it, but I can't seem to get any of them 
to work.


Although I could pass in a preset parameter to the C++ function and 
simply override everything coming from the GUI, I'd rather have it 
populate the parameters in the block, but still let them be changed.  
This way, if someone wanted to load the settings for a "Channel X" 
preset, except with a different Doppler spread, it could be done easily.


Note this is a similar problem as posted here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html, 
 
but it doesn't appear the previous question was ever answered.


Thank you in advance for your help.

Mark Arlinghaus


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
It's not clear whether you're talking about *runtime* or during GRC 
construction.


For runtime, I'd write a little Python module that contains a function 
for each parameter:


setter_function(configfilename, command-line-parameter, 
widget-control-value)


You then have logic in the function to determine the priority of what 
gets returned:


config-->command-line-->widget-control-value

I've done that in the past.


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

[Discuss-gnuradio] Load Preset parameters in block

2016-06-20 Thread Mark Arlinghaus 
Hello,

Is there a way to load preset default parameters in a block.  For example, I 
have a channel model block that takes several parameters, such as the doppler 
spread, path delays, path gains, doppler spectrum, etc., and I want to have 
presets that will auto-populate the parameters in the GRC block for pre-defined 
channel models.  I can make a drop-down menu that has the pre-defined channel 
models, but I don't know how to change the values that populate in the other 
parameters.  I would like to do this using the xml file.  Is there a way to put 
a conditional parameter in the  tags that would depend on the setting in 
the drop down menu (It seems conditionals can be used in the  and 
 tags, but not inside the  tags)?  Is there a way to do it using 
the  tags?  Is there a list of valid options and what they do anywhere?  
It seems the  val:XXX <\opt> tags might do it, but I can't seem to get any 
of them to work.

Although I could pass in a preset parameter to the C++ function and simply 
override everything coming from the GUI, I'd rather have it populate the 
parameters in the block, but still let them be changed.  This way, if someone 
wanted to load the settings for a "Channel X" preset, except with a different 
Doppler spread, it could be done easily.

Note this is a similar problem as posted here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html,
 but it doesn't appear the previous question was ever answered.

Thank you in advance for your help.

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

Re: [Discuss-gnuradio] Software Defined Radio Academy 2016

2016-06-20 Thread Ben Hilburn 
Thanks, Markus!

I have added this event to the website: http://gnuradio.org/events/

Cheers,
Ben

On Mon, Jun 20, 2016 at 7:38 AM, Markus Heller  wrote:

> Dear lists,
>
> the SDRA-2016 is right ahead! Next Saturday, 25.06. the SDRA will be
> hosted as a subconference to the big HAMRADIO conference at
> Friedrichshafen trade fair.
>
> The SDRA will be hosted in the room "BERLIN" in the east part of the
> conference center and talks will start at 10:00 hrs.
>
> Please check the details at:
>
>  http://www.sdra-2016.de/
>
> Here is the programme:
>
> >
> 1000-1010 Introduction
> Prof. Dr. Michael Hartje, DK5HH and Markus Heller, DL8RDS
>
> 1010-1040 From my Microphone to the Ether – An example-based
> introduction to SDR
> Marcus Müller, ETTUS
>
> 1040-1105 An update on the mcHF SDR Transceiver and Microwave SDR
> David Minchin, VK5KK
>
> 1105-1130 Debunking Direct Sampling Receiver Performance Myths
> Gerald Youngblood, K5SDR, FLEXRADIO
>
> 1130-1155 Red Pitaya - Measurement device and emulation of
> SDR-Transceivers
> Prof. Dr. Michael Hartje, DK5HH, Univ. of Appl. Sciences Bremen
>
> 1155-1340 OpenHPSDR
> John Melton, G0ORX/N6LYT: Stand-alone HPSDR Transceiver using low-cost
> processors
>
> Phil Harman, VK6PH: Direct Fourier Conversion (DFC) – An alternative
> architecture for Software Defined Radios.
>
> Dr. Warren C. Pratt, NR0V: Advanced Algorithms for Noise Blanking and
> Noise Reduction
>
> Adam Farson, VA7OJ/AB4OJ: Evaluating Digital Receivers
>
> 1340-1425 Lunch break
> 1425-1450 Signal Intelligence with Software Defined Radio
> Sebastian Müller, Univ. Karlsruhe
>
> 1450-1515 OPEN matters! A critical perspective on proprietary systems
> Frank Werner-Krippendorf, HB9FXQ
>
> 1515-1540 SDR in Contest Practice
> Prof. Dr. Harald Gerlach, DL2SAX, Univ of Appl. Sciences Neu-Ulm
>
> 1540-1605 GQRX as a Graphical Frontend for Digital Receivers
> Bastian Blössl, DF1BBL, Univ. Paderborn
>
> 1605-1630 Recent work on OpenWebRX and csdr
> András Retzler, HA7ILM, Univ. Budapest
>
> 1630-1655 Reversing digital signals with inspectrum
> Mike Walters
>
> 1655-1720 The Panoradio: A wideband direct sampling SDR with 250 Msps
> Stefan Scholl, DC9ST, Univ. Kaiserslautern
>
> 1720-1745 TBD
> Chris Kuethe, KJ6GVE
>
> 1745-1800 Summary and Outlook
> <
>
> There is no special registration for the SDRA, the HAMRADIO ticket will
> let you in. We will have ~150 seats in the room.
>
> After the SDRA, we will walk over to the big HAM NIGHT party.
>
> I'm looking forward to see you all!
>
> best regards / vy73
> markus
> dl8rds
>
>
>
> ___
> 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] [SOCIS] SCF

2016-06-20 Thread Ben Hilburn 
Hi Chris -

For your Tensor Flow work, will you be using Tim O'Shea's OOT module?

https://github.com/osh/gr-tf

As part of your SOCIS, do you anticipate submitting any new blocks to that
OOT project?

Cheers,
Ben

On Sun, Jun 19, 2016 at 11:34 AM, Christopher Richardson <
chrisrichardso...@gmail.com> wrote:

> Hi All,
>
> I've just posted a blog post on what I've been working
> on these past weeks and what I will be working on next week.
>
>
> https://signalsintelligence.wordpress.com/2016/06/09/dft-spectral-coherence-function/
>
> cheers
>
> Chris
>
> ___
> 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] GRCon 16 Latex Files

2016-06-20 Thread Richard Bell 
The website that should have the Latex template files for paper submission
is broken,
http://gnuradio.org/grcon-2016/papers/

If this cannot be quickly fixed, would someone send out the template files
to the mailing list please?

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

Re: [Discuss-gnuradio] Re channel state information on rx_ofdm.grc

2016-06-20 Thread avinash kalyanaraman 
Thanks Marcus.

Following up on the rx_time format, I notice from the link that the
timestamp format is the same as uhd::time_spec_t . Therefore the timestamp
printed out on a tag is of the form:  full_seconds and a fractional_seconds.

For e.g., I see:  Offset: 667  Source: n/a Key: rx_time   Value: {2317
0.394114}
2317 is the full second and 0.39 is the fraction of that 2317th second ?

Could you please tell me what these seconds calculated are with respect to
- i.e. 2317 seconds since when ?

When does the fraction of second roll over?
For example, I see:
  Offset: 1034  Source: n/a Key: rx_time   Value: {2317 1.39162}
  Offset: 1035  Source: n/a Key: rx_time   Value: {2318 0.393495}

What does it mean to have a fraction of 1.39 of a second ?

Thanks!


On Fri, Jun 17, 2016 at 1:12 PM, Marcus Müller 
wrote:

> Hi Avinash,
>
> that's pretty much a basic OFDM question:
>
> You take the DFT of the input signal. Hence, the bins of the DFT are
> f_nyquist/l_fft spaced.
>
> Best regards,
>
> Marcus
> On 17.06.2016 17:57, avinash kalyanaraman wrote:
>
> Thanks Marcus - that helps.
>
> Could you please let me know what's the bandwidth of each sub-carrier? How
> can I calculate that and reconfigure the same?
>
>
> On Sat, Jun 18, 2016 at 12:50 AM, Marcus Müller 
> wrote:
>
>> Hi Avinash,
>>
>> On 06/16/2016 03:29 PM, avinash kalyanaraman wrote:
>>
>> i) These 64 complex values (a + ib) represent the 64 sub-carriers and I
>> can get the amplitude and phase of each sub-carrier as sqrt( a^2 + b^2) and
>> arctan(b/a) respectively ?
>>
>> Yes.
>>
>>
>> ii) I see that the CSI calculation is per tag. I understand from your
>> link that the tag represents additional information/metadata attached to a
>> specific item. However, in this case, I am unsure what a tag denotes? In
>> other words, could you please tell me what a “tag” is being attached to
>> here, on which a channel estimate is calculated?
>>
>> If I remember correctly:
>> To the first sample of the "chunk" of samples that were used for
>> estimation, that is, on the first sample of the OFDM symbol.
>>
>> I do think that if you're into channel estimation, reading the source
>> code is very much worth your time, and you'll notice variable and method
>> names were chosen sensibly to make understanding what's happening easier.
>> Go for the get_chan_taps() method in ofdm_chanest_vcvc_impl.cc; you'll find
>> it in your GNU Radio source tree; be sure to use a recent version of GNU
>> Radio (3.7.7 or later).
>>
>>
>> iii) Please let me know what is the unit of rx_time ? Seconds?
>>   Offset: 76  Source: n/a Key: rx_time   Value: {7 0.303}
>>   Offset: 77  Source: n/a Key: rx_time   Value: {7 0.399}
>>
>> http://gnuradio.org/doc/doxygen/page_uhd.html
>>
>> look for "timestamp" on that page.
>>
>> Best regards,
>> Marcus
>>
>
>
>
> --
> Avinash
>
>
>


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

Re: [Discuss-gnuradio] Control the transmission rate of TX_OFDM.grc

2016-06-20 Thread Marcus Müller 
Replace the random source with

message strobe-> random pdu generator->pdu to tagged stream

Best regards,
Marcus

On 06/20/2016 04:31 PM, avinash kalyanaraman wrote:
> Hi All,
>
> I am doing an OFDM transmission with tx_ofdm.grc and receiving it with
> rx_ofdm.grc. I am using the Random Source of the tx_ofdm unmodified. I
> want to be able to control the packet transmission rate - for e.g. 10
> packets every 100ms. How can I modify the grc to be able to do this ?
>
> Thanks!
> -- 
> Avinash
>
>
> ___
> 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] Control the transmission rate of TX_OFDM.grc

2016-06-20 Thread avinash kalyanaraman 
Hi All,

I am doing an OFDM transmission with tx_ofdm.grc and receiving it with
rx_ofdm.grc. I am using the Random Source of the tx_ofdm unmodified. I want
to be able to control the packet transmission rate - for e.g. 10 packets
every 100ms. How can I modify the grc to be able to do this ?

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

[Discuss-gnuradio] Question about tagged_stream_block

2016-06-20 Thread bob wole 
Hi,
My  flowgraph contains a tagged_stream_block, B, and it has a
length_tag_key, say "pkt_len". Each packet has a length of 1000 samples.
The upstream block (A-->B) tags first sample with key "pkt_len" and value
1000 and then the upstream block tags sample number 901 with key "pkt_len"
and value 1000 instead of tagging sample number 1001. This could happen in
case of overflow and I know using receive tags that 100 samples has been
lost. So, samples from 901 to 1900 contains a new packet. Will the
flowgraph work or will it crash?

I want to write a block that processes exactly only 1000 samples, one
packet, in a call to work. And the packets start from a specific time for
example when the rx_time of the sample is mid of any second.


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

Re: [Discuss-gnuradio] Audio underrun when using Audio Sink

2016-06-20 Thread Marcus Müller 
Hi Paul,
I'd like to second Kevin's notion that if anything is limiting your
sample flow, it's the filter in the resampler. I don't know exactly what
type of filter you chose, but I did the following (in python):

from gnuradio import filter as gr_filter
res = gr_filter.rational_resampler_ccf(200,1) # this is a 200-interpolation, 
floating point taps filter resampler
taps = res.taps()
print "length of taps is {:d}.".format(len(taps))


and it gave me 6600 taps.

Which is a lot. But then again... at these rates, I'd expect this to be
computationally limiting on a beefy toaster, but not on a PC; for
example, the following flow graph:

flowgraph

gives me the info that my trusty old subnotebook on battery does nearly
20 MS/s per second... I don't see how doing 48kS/s would become a
problem quickly.
Which leaves us with your band pass filter; what's that?

I also don't have overly much trust in your "Packet Encoder" block; it's
an ancient, hopefully-soon-to-be-dead Python block, which doesn't care
or know about tagged streams etc. It might really be inefficient (but
usually not to the point of limiting usefulness).

If you find
/usr/(local/)share/gnuradio/examples/digital/ofdm/tx_ofdm.grx (or
wherever GNU Radio is installed), you'll find, instead of that,
something that does

tx_ofdm packetizer
and the header and payload streams are/can be then modulated with
different constellations separately, and then, using "Tagged Stream Mux"
be put together to one sample stream again. This should behave nicer!
However, this is missing some kind of preambling. It might be worth it
to simply "mux" in a "known preamble" stream from a vector source into
the header bit stream, and use that for correlation on the receive side.
Felix Wunsch built something like this a couple of days ago for some
educational reason, I think he might share his wisdom if we ask nicely :)

Best regards,
Marcus

On 06/19/2016 10:46 PM, Kevin Reid wrote:
> On Jun 18, 2016, at 19:07, Paul S  wrote:
>> Currently, I am trying to send data over ultrasound signals based on [1],
>> using the audio sink and several sources. The problem is that I get often
>> consecutive audio underruns (for several seconds straight).
>> This is my flowgraph:
>>  
>> The TunSource just reads data from a Tun-Device but I get these underruns
>> with other blocks like the depicted Socked PDU or even a File Source, too
>> (though not as frequently).
>> So it basically boils down to (Byte?)-Source -> GFSK Mod -> Rational
>> Resampler -> Frequency Xlating FIR Filter-> Audio Sink.
> [...]
>> My assumption is that this is a "two clock problem" which I've read about in
>> other posts.
> If you get this underrun when you are using a file source then you definitely 
> do not have a two-clock problem, because the only clock in your flowgraph is 
> the audio sink.
>
> That being the case, the only reason you should see underruns is if your CPU 
> is not able to keep up, but that seems unlikely at your low sample rates. 
> Check your system monitor for any cores running at 100% -- that would 
> indicate that some one of your blocks is doing too much work.
>
> If that actually is the problem, the most likely culprit is your 200:1 
> resampler -- you could try breaking it up into multiple stages (e.g. 
> interpolate by 20 then interpolate by 10) or using a FFT filter block to do 
> the antialias filtering.
> ___
> 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] Displaying angle measurements with a nice GUI

2016-06-20 Thread Meny Sidar 
Thank you all for your comments!
and sorry for late response.

I tried using WX DOA Compass, it seems exactly what i need.
but i can't get it to work.

I'm using "probe signal", "function probe", and the "WX DOA Compass" blocks.
But when i execute the flow graph it's immediately terminate.
Tried it with the simplest flow graph, just probing a signal a plotting on
the compass. still doesn't work.
if i'm not mistaken, the "Direction" value of the compass should be the
variable in the "function probe"?
what am i doing wrong? :P

Thanks a lot,
Meny




2016-06-16 7:18 GMT+03:00 Nate Temple :

> There is the "WX DOA Compass" in gr-baz
>
> https://github.com/balint256/gr-baz
>
> https://github.com/balint256/gr-baz/blob/master/grc/doa_compass.xml
>
> -- Nate
>
>
> > On Jun 15, 2016, at 10:44 AM, Philip Balister 
> wrote:
> >
> > On 06/15/2016 01:06 PM, Nick Foster wrote:
> >> You ought to be able to use PyQwt's compass widget:
> >
> > Qwt is OK, but please do not use PyQwt. It is unmaintained. See:
> >
> > https://sourceforge.net/p/pyqwt/mailman/message/30352623/
> >
> > Philip
> >
> >>
> >> http://qwt.sourceforge.net/class_qwt_compass.html
> >>
> >> I used it for gr-air-modes and, while ugly, it does work. There's no
> >> integration into GRC so the Python to integrate the widget will, of
> course,
> >> be your responsibility.
> >>
> >> --n
> >>
> >> On Wed, Jun 15, 2016 at 9:45 AM Martin Braun 
> wrote:
> >>
> >>> Meny,
> >>>
> >>> no, we don't. A compass was one of the suggestions for this year's
> GSoC,
> >>> but no one signed up for that.
> >>>
> >>> M
> >>>
> >>> On 06/15/2016 04:34 AM, Meny Sidar wrote:
>  Hi guys
> 
>  I'm looking for a nice GUI that can plot my AoA calculations in a some
>  kind of a compass looking GUI.
>  Does anything like that exists? or do i have to build one of my own?
>  Don't really know how, and would prefer not to start learning Python
>  right now (on a deadline).
> 
>  Any help would be much appreciated!
>  Thanks,
>  Meny
> 
> 
> 
>  ___
>  Discuss-gnuradio mailing list
>  Discuss-gnuradio@gnu.org
>  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> >>>
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Software Defined Radio Academy 2016

2016-06-20 Thread Markus Heller 
Dear lists,

the SDRA-2016 is right ahead! Next Saturday, 25.06. the SDRA will be
hosted as a subconference to the big HAMRADIO conference at
Friedrichshafen trade fair. 

The SDRA will be hosted in the room "BERLIN" in the east part of the
conference center and talks will start at 10:00 hrs. 

Please check the details at:

 http://www.sdra-2016.de/

Here is the programme:

>
1000-1010 Introduction
Prof. Dr. Michael Hartje, DK5HH and Markus Heller, DL8RDS

1010-1040 From my Microphone to the Ether – An example-based
introduction to SDR
Marcus Müller, ETTUS

1040-1105 An update on the mcHF SDR Transceiver and Microwave SDR
David Minchin, VK5KK

1105-1130 Debunking Direct Sampling Receiver Performance Myths
Gerald Youngblood, K5SDR, FLEXRADIO

1130-1155 Red Pitaya - Measurement device and emulation of
SDR-Transceivers
Prof. Dr. Michael Hartje, DK5HH, Univ. of Appl. Sciences Bremen

1155-1340 OpenHPSDR
John Melton, G0ORX/N6LYT: Stand-alone HPSDR Transceiver using low-cost
processors

Phil Harman, VK6PH: Direct Fourier Conversion (DFC) – An alternative
architecture for Software Defined Radios.

Dr. Warren C. Pratt, NR0V: Advanced Algorithms for Noise Blanking and
Noise Reduction

Adam Farson, VA7OJ/AB4OJ: Evaluating Digital Receivers

1340-1425 Lunch break
1425-1450 Signal Intelligence with Software Defined Radio
Sebastian Müller, Univ. Karlsruhe

1450-1515 OPEN matters! A critical perspective on proprietary systems
Frank Werner-Krippendorf, HB9FXQ

1515-1540 SDR in Contest Practice
Prof. Dr. Harald Gerlach, DL2SAX, Univ of Appl. Sciences Neu-Ulm

1540-1605 GQRX as a Graphical Frontend for Digital Receivers
Bastian Blössl, DF1BBL, Univ. Paderborn

1605-1630 Recent work on OpenWebRX and csdr
András Retzler, HA7ILM, Univ. Budapest

1630-1655 Reversing digital signals with inspectrum
Mike Walters

1655-1720 The Panoradio: A wideband direct sampling SDR with 250 Msps
Stefan Scholl, DC9ST, Univ. Kaiserslautern

1720-1745 TBD
Chris Kuethe, KJ6GVE

1745-1800 Summary and Outlook
<

There is no special registration for the SDRA, the HAMRADIO ticket will
let you in. We will have ~150 seats in the room. 

After the SDRA, we will walk over to the big HAM NIGHT party. 

I'm looking forward to see you all!

best regards / vy73
markus
dl8rds



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

Re: [Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

2016-06-20 Thread Markus Heller 
Hello everybody,

next Saturday 25.06. there will be a big "HAM NIGHT" party at
Friedrichshafen's HAMRADIO fair. 

To those of you who attend the HAMRADIO fair: 

Right after the Software Defined Radio Academy (SDRA) will have ended at
1800 hrs, we will walk to the party together. The SDRA will be at room
"BERLIN" in the east part of the conference area. 

German announcement:

"In diesem Jahr lässt es der DARC auf der HAM NIGHT am Samstagabend auf
dem Messegelände krachen: Ab 18 Uhr erwarten die Gäste einige
Überraschungen. Die Partyband Popp deluxe sorgt mit ihrer musikalischen
Bandbreite von Pop, Soul, Funk über Latin und Jazz für Stimmung und eine
Feuerakrobatin heizt den Gästen im weiteren Verlauf des Abends mächtig
ein. Stoßen Sie mit uns auf die ersten beiden Messetage in gemütlicher
Atmosphäre an!"

Looking forward to see you all!

br / vy73
markus
dl8rds



Am Mittwoch, den 30.03.2016, 21:32 +0200 schrieb Daniel Pocock:
> 
> On 30/03/16 21:23, Markus Heller wrote:
> > Hi Daniel,
> > 
> > let me organize something. I guess we'll arrange an informal SDR &
> > GNURadio dinner after the SDRA somewhere in the city, with the SDRA
> > speakers and all GNURadio folks. Of course it will be open to all open
> > source people. 
> > 
> > I'll let you know as soon as I have news.
> 
> 
> I also raised Friedrichshafen on the debain-hams, debian-events-eu and
> debian.ch mailing lists (Friedrichsahfen being so close to Zurich),
> there may be some interest there.  We may have the resources to run a
> Debian/Debian Hams table or maybe just collaborate on a community table
> there.
> 
> Regards,
> 
> Daniel
> 
> ___
> 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] Construction of BEC channel

2016-06-20 Thread jacksk1005 
Hi everyone,
I'm a beginner on GNURadio and trying to simulate the Binary Symmetric
Channel and Binary Erase Channel with AWGN. 
So I use a BPSK-mapper at the transmitter and relevant demapper at the
receiver, then mapper-channel-demapper is equivalten to a BSC. 


 

But for construncion of BEC on the basis of changing the BSC simulation, I
have no idea. Can anyone give me some tips?

Many thanks!
Jacksk



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Construction-of-BEC-channel-tp60553.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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