Re: [Discuss-gnuradio] HELP: USRP1+WBXv3 "Overflow"

[Marcus Müller]

Hello SKA15,

well, I'm pretty sure there is some way to do this in GRC; but honestly,
this sounds like something that would be very little lines of code in
python; I recommend going through the guided tutorials [1] in order to
understand how to write a python block that will emit the right stream
tags at the right time.

Greetings,
Marcus

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

On 12/23/2014 04:40 AM, Thesis 2015 wrote:
> Good Day,
>
> We are able to receive FM signals using the USRP1 with WBXv3 50-2200
> having a 750cm solid wire that serves as an antenna. We were wondering
> how to modify the generated GRC python code. We are planning on
> changing the center frequency automatically with an interval of 200MHz
> in a specified time. Thank you.
>
> -SKA15-
>
> On Thu, Dec 18, 2014 at 12:19 AM, Gerry Creager - NOAA Affiliate
> mailto:gerry.crea...@noaa.gov>> wrote:
>
> Considering the saturation level of most commercial FM stations,
> using a simple whip antenna will prove more than adequate. While a
> wide-range log-periodic antenna might prove useful as you get
> farther into your research, especially for broadband signals
> requiring a directional antenna, using simpler tools while
> learning is usually beneficial.
>
> gerry
>
> On Wed, Dec 17, 2014 at 4:06 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> I'm afraid you did not make a mistake -- the LP0410 [1] is
> specified for usage between 400 and 1200 MHz. Whilst it will
> still pick up some signal at frequencies below 400MHz,
> operating it at a quarter of the lower cutoff freq. will lead
> to very suboptimal results.
>
> If you know your frequency range as well as you do, I
> recommend trying Ralph's proposed 1/2 wavelength monopole antenna.
>
> Greetings,
> Marcus
>
> [1]http://www.ettus.com/product/details/LP0410
>
> On 12/17/2014 09:43 AM, Thesis 2015 wrote:
>> We're sorry. We made a mistake with the frequency range that
>> the antenna could receive. It is actually 40MHz - 1.2GHz.
>>
>> -SKA15-
>>
>>
>> ___
>> 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
>
>
>
>
> -- 
> Gerry Creager
> NSSL/CIMMS
> 405.325.6371 
> ++
> “Big whorls have little whorls,
> That feed on their velocity; 
> And little whorls have lesser whorls, 
> And so on to viscosity.” 
> Lewis Fry Richardson (1881-1953)
>
> ___
> 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] Help me help myself

[Vanush Vaswani]

Use cscope and/or ctags next time

On Tue, Dec 23, 2014 at 11:47 AM, Marcus D. Leech  wrote:
> On 12/22/2014 07:31 PM, Richard Bell wrote:
>>
>> MLeech I really understand where you're coming from. But I think that's
>> the point of a community. If you are personally tired of answering low level
>> questions, then you should not feel like you have to. Others in the
>> community might be happy to do it, and you can stick to the advanced
>> questions. Correct me if I'm wrong, but this is how other communities seem
>> to work that I've been involved with.
>>
>> MMuller, thank you. I do my best to help myself before I ask a question
>> here. Often, I feel like I'm asking a legit question, until the responses
>> make me feel like i just asked the equivalent of "what does 2+2 equal?" Its
>> always hard until you ask. Shrug.
>>
>> Rich
>
> Richard:
>
> I certainly didn't mean to imply that you'd asked a "stupid question".
> There aren't any stupid questions.  Only stupid/ill-considered answers.
>
> Your post just triggered one of my many soap-box moments.  If I had a beard,
> it would be grey.  Think of me as the grumpy old greybeard
>   muttering incoherently over there in the corner...
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> ___
> 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] HELP: USRP1+WBXv3 "Overflow"

[Thesis 2015]

Good Day,

We are able to receive FM signals using the USRP1 with WBXv3 50-2200 having
a 750cm solid wire that serves as an antenna. We were wondering how to
modify the generated GRC python code. We are planning on changing the
center frequency automatically with an interval of 200MHz in a specified
time. Thank you.

-SKA15-

On Thu, Dec 18, 2014 at 12:19 AM, Gerry Creager - NOAA Affiliate <
gerry.crea...@noaa.gov> wrote:

> Considering the saturation level of most commercial FM stations, using a
> simple whip antenna will prove more than adequate. While a wide-range
> log-periodic antenna might prove useful as you get farther into your
> research, especially for broadband signals requiring a directional antenna,
> using simpler tools while learning is usually beneficial.
>
> gerry
>
> On Wed, Dec 17, 2014 at 4:06 AM, Marcus Müller 
> wrote:
>
>>  I'm afraid you did not make a mistake -- the LP0410 [1] is specified for
>> usage between 400 and 1200 MHz. Whilst it will still pick up some signal at
>> frequencies below 400MHz, operating it at a quarter of the lower cutoff
>> freq. will lead to very suboptimal results.
>>
>> If you know your frequency range as well as you do, I recommend trying
>> Ralph's proposed 1/2 wavelength monopole antenna.
>>
>> Greetings,
>> Marcus
>>
>> [1]http://www.ettus.com/product/details/LP0410
>>
>> On 12/17/2014 09:43 AM, Thesis 2015 wrote:
>>
>> We're sorry. We made a mistake with the frequency range that the antenna
>> could receive. It is actually 40MHz - 1.2GHz.
>>
>> -SKA15-
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Gerry Creager
> NSSL/CIMMS
> 405.325.6371
> ++
> “Big whorls have little whorls,
> That feed on their velocity;
> And little whorls have lesser whorls,
> And so on to viscosity.”
> Lewis Fry Richardson (1881-1953)
>
> ___
> 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] Help me help myself

[Marcus D. Leech]

On 12/22/2014 07:31 PM, Richard Bell wrote:
MLeech I really understand where you're coming from. But I think 
that's the point of a community. If you are personally tired of 
answering low level questions, then you should not feel like you have 
to. Others in the community might be happy to do it, and you can stick 
to the advanced questions. Correct me if I'm wrong, but this is how 
other communities seem to work that I've been involved with.


MMuller, thank you. I do my best to help myself before I ask a 
question here. Often, I feel like I'm asking a legit question, until 
the responses make me feel like i just asked the equivalent of "what 
does 2+2 equal?" Its always hard until you ask. Shrug.


Rich

Richard:

I certainly didn't mean to imply that you'd asked a "stupid question".  
There aren't any stupid questions.  Only stupid/ill-considered answers.


Your post just triggered one of my many soap-box moments.  If I had a 
beard, it would be grey.  Think of me as the grumpy old greybeard

  muttering incoherently over there in the corner...

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] Help me help myself

[Richard Bell]

MLeech I really understand where you're coming from. But I think that's the
point of a community. If you are personally tired of answering low level
questions, then you should not feel like you have to. Others in the
community might be happy to do it, and you can stick to the advanced
questions. Correct me if I'm wrong, but this is how other communities seem
to work that I've been involved with.

MMuller, thank you. I do my best to help myself before I ask a question
here. Often, I feel like I'm asking a legit question, until the responses
make me feel like i just asked the equivalent of "what does 2+2 equal?" Its
always hard until you ask. Shrug.

Rich

On Mon, Dec 22, 2014 at 4:21 PM, Marcus D. Leech  wrote:

>  On 12/22/2014 06:59 PM, Richard Bell wrote:
>
>  Actually, your replies helped. I was not aware or in the mindset that
> branchless_clip was a generally used method for clamping fixed or floating
> point values. Because of that, I was limiting my searches to gnuradio
> related stuff (googling "gnuradio branchless_clip"). Now I know it is a
> general method of doing something.
>
>  Helping people who are getting comfortable is a good thing to do. It will
> ensure they use the tools. There is a limit to this of course. No one wants
> to see basic level questions being asked all day.
>
> I've been on this mailing list for, gosh, a decade?
>
> In that time, what I've noticed is that in the last couple of years,
> there's a significant fraction of folks who are encountering not only Gnu
> Radio and
>   SDR/DSP for the first time, but *software development in general*.   I'm
> not sure why that is, but I'm pretty sure that the list isn't, in
>   general, well-equipped to deal with that kind of thing.
>
> My own patience for that type of thing varies considerably, and I try to
> avoid giving any answers at all when my patience is perhaps not as
>   generous as it should be, and try to give cheerful answers when possible.
>
> I certainly don't want people to leave with the impression that we're
> unhelpful here, but on the other hand, I don't think it would be good for
>  the list (and the community) if we became a "free CS101 course" for the
> huddled masses.  Just my opinion
>
> ...funny anecdote time.
>
> I once helped run an internal help-desk doing Unix technical support
> within the Nortel empire.  We'd assembled a team of
>   pretty-darned-competent people to do front-line support.  *Vastly*
> better than your typical help-desk.  Like, could debug shell scripts
>   for customers while waiting on the phone. So, we got a bit of a
> reputation of being pretty-much the best at what we did.  To the extent
>   that our phone number leaked out into the greater world, and we started
> getting support calls from random not-Nortel places, which
>   we obviously couldn't support, since it wasn't our mandate.
>
> Sometimes, I think we do that here...
>
>
>
> On Mon, Dec 22, 2014 at 3:47 PM, Marcus D. Leech 
> wrote:
>
>> On 12/22/2014 06:45 PM, Philip Balister wrote:
>>
>>> On 12/22/2014 06:42 PM, Marcus D. Leech wrote:
>>>
>>>  I'm not as smart as Marcus, so I googled "branchless clip",
>>>
>>>
>>> http://stackoverflow.com/questions/427477/fastest-way-to-clamp-a-real-fixed-floating-point-value
>>>
>>> Philip
>>>
>> I think that at the end of the day, questions like this boil down to "how
>> do I get comfortable with the tools of the trade in software development".
>>
>> That's not something that the Gnu Radio community can economically
>> address.
>>
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>>   ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help me help myself

[Marcus D. Leech]

On 12/22/2014 06:59 PM, Richard Bell wrote:
Actually, your replies helped. I was not aware or in the mindset that 
branchless_clip was a generally used method for clamping fixed or 
floating point values. Because of that, I was limiting my searches to 
gnuradio related stuff (googling "gnuradio branchless_clip"). Now I 
know it is a general method of doing something.


Helping people who are getting comfortable is a good thing to do. It 
will ensure they use the tools. There is a limit to this of course. No 
one wants to see basic level questions being asked all day.

I've been on this mailing list for, gosh, a decade?

In that time, what I've noticed is that in the last couple of years, 
there's a significant fraction of folks who are encountering not only 
Gnu Radio and
  SDR/DSP for the first time, but *software development in general*.   
I'm not sure why that is, but I'm pretty sure that the list isn't, in

  general, well-equipped to deal with that kind of thing.

My own patience for that type of thing varies considerably, and I try to 
avoid giving any answers at all when my patience is perhaps not as

  generous as it should be, and try to give cheerful answers when possible.

I certainly don't want people to leave with the impression that we're 
unhelpful here, but on the other hand, I don't think it would be good for
 the list (and the community) if we became a "free CS101 course" for 
the huddled masses.  Just my opinion


...funny anecdote time.

I once helped run an internal help-desk doing Unix technical support 
within the Nortel empire.  We'd assembled a team of
  pretty-darned-competent people to do front-line support.  *Vastly* 
better than your typical help-desk.  Like, could debug shell scripts
  for customers while waiting on the phone. So, we got a bit of a 
reputation of being pretty-much the best at what we did.  To the extent
  that our phone number leaked out into the greater world, and we 
started getting support calls from random not-Nortel places, which

  we obviously couldn't support, since it wasn't our mandate.

Sometimes, I think we do that here...




On Mon, Dec 22, 2014 at 3:47 PM, Marcus D. Leech > wrote:


On 12/22/2014 06:45 PM, Philip Balister wrote:

On 12/22/2014 06:42 PM, Marcus D. Leech wrote:

I'm not as smart as Marcus, so I googled "branchless clip",


http://stackoverflow.com/questions/427477/fastest-way-to-clamp-a-real-fixed-floating-point-value

Philip

I think that at the end of the day, questions like this boil down
to "how do I get comfortable with the tools of the trade in
software development".

That's not something that the Gnu Radio community can economically
address.




-- 
Marcus Leech

Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Help me help myself

[Marcus Müller]

Hi Richard,

actually, I kind of liked your question and the answers you've got :)
As a community, it's always kind of hard to know where people actually
encounter obstacles, and you're *exactly* the kind of future user we'd
like to address: Able and willing to solve one's own problems, but not
to shy to ask questions on how to do stuff. Also, you don't seem to be a
complete stranger to the concepts of GNU Radio, so yours is an
interesting angle.

Being part of the GNU Radio development easily makes one blind to the
problems "normal people" have when getting into GNU Radio. For example,
we've created a set of new guided tutorials, which I now habitually link
to [1], but they were written by people who "guess" what new users
should know based on the questions that get asked. And the questions
that actually get asked might be quite different from the questions new
users actually have. So we asked people to give their feedback on that
(please feel encouraged to do so, too!). This all illustrates what
Marcus L. concluded in "something that the GR community can't
economically address", and I sure hope you'll feel motivated to find
your very own way through Software (defined radio) Development!

Keep up the good questions,

Greetings,
Marcus

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
On 12/23/2014 12:59 AM, Richard Bell wrote:
> Actually, your replies helped. I was not aware or in the mindset that
> branchless_clip was a generally used method for clamping fixed or
> floating point values. Because of that, I was limiting my searches to
> gnuradio related stuff (googling "gnuradio branchless_clip"). Now I
> know it is a general method of doing something.
>
> Helping people who are getting comfortable is a good thing to do. It
> will ensure they use the tools. There is a limit to this of course. No
> one wants to see basic level questions being asked all day.
>
> On Mon, Dec 22, 2014 at 3:47 PM, Marcus D. Leech  > wrote:
>
> On 12/22/2014 06:45 PM, Philip Balister wrote:
>
> On 12/22/2014 06:42 PM, Marcus D. Leech wrote:
>
> I'm not as smart as Marcus, so I googled "branchless clip",
>
> 
> http://stackoverflow.com/questions/427477/fastest-way-to-clamp-a-real-fixed-floating-point-value
>
> Philip
>
> I think that at the end of the day, questions like this boil down
> to "how do I get comfortable with the tools of the trade in
> software development".
>
> That's not something that the Gnu Radio community can economically
> address.
>
>
>
>
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> ___
> 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] Help me help myself

[Richard Bell]

Actually, your replies helped. I was not aware or in the mindset that
branchless_clip was a generally used method for clamping fixed or floating
point values. Because of that, I was limiting my searches to gnuradio
related stuff (googling "gnuradio branchless_clip"). Now I know it is a
general method of doing something.

Helping people who are getting comfortable is a good thing to do. It will
ensure they use the tools. There is a limit to this of course. No one wants
to see basic level questions being asked all day.

On Mon, Dec 22, 2014 at 3:47 PM, Marcus D. Leech  wrote:

> On 12/22/2014 06:45 PM, Philip Balister wrote:
>
>> On 12/22/2014 06:42 PM, Marcus D. Leech wrote:
>>
>> I'm not as smart as Marcus, so I googled "branchless clip",
>>
>> http://stackoverflow.com/questions/427477/fastest-way-
>> to-clamp-a-real-fixed-floating-point-value
>>
>> Philip
>>
> I think that at the end of the day, questions like this boil down to "how
> do I get comfortable with the tools of the trade in software development".
>
> That's not something that the Gnu Radio community can economically address.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> ___
> 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] Help me help myself

[Marcus D. Leech]

On 12/22/2014 06:45 PM, Philip Balister wrote:

On 12/22/2014 06:42 PM, Marcus D. Leech wrote:

I'm not as smart as Marcus, so I googled "branchless clip",

http://stackoverflow.com/questions/427477/fastest-way-to-clamp-a-real-fixed-floating-point-value

Philip
I think that at the end of the day, questions like this boil down to 
"how do I get comfortable with the tools of the trade in software 
development".


That's not something that the Gnu Radio community can economically address.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] Help me help myself

[Philip Balister]

On 12/22/2014 06:42 PM, Marcus D. Leech wrote:
> On 12/22/2014 06:37 PM, Richard Bell wrote:
>> Hi all,
>>
>> The goal of this email is to learn how to find answers using available
>> resources on my own in the future. To do this, I will explain what
>> I've done to try and find the answer and then I hope someone can tell
>> me how to finish the process so that next time I can do it on my own.
>>
>> I'm working through the details of the MM Timing Recovery block. In
>> the process of doing this I've come across the following line in source:
>>
>> d_omega = d_omega_mid + gr::branchless_clip(d_omega-d_omega_mid,
>> d_omega_lim);
>>
>> I don't know what gr::branchless_clip does, so I started looking for
>> answers on google and the gnuradio API manual. In the manual, I find
>> this:
>>
>> http://gnuradio.org/doc/doxygen/namespacegr.html#ace35e8c3e3ad45a5100217d2b6826e1b
>>
>>
>> but that doesn't tell me what it does. I can't find anymore reference
>> to branchless_clip then this.
>>
>> From the source code, I don't know how to track down the reference.
>> I've searched my laptop for branchless_clip, but I get no returns.
>>
>> So the question is, how do I find what branchless_clip does in the MM
>> Timing Recovery block? I care more about the "how do I find" part of
>> the question then the actual answer, though I do want the actual answer.
>>
> I used the following "find" command:
> 
> find gnuradio -name "*.*" -exec grep -H branchless_clip '{}' ';'
> 
> And found the definition in:
> 
> gnuradio/gnuradio-runtime/include/gnuradio/math.h: 
> branchless_clip(float x, float clip)

I'm not as smart as Marcus, so I googled "branchless clip",

http://stackoverflow.com/questions/427477/fastest-way-to-clamp-a-real-fixed-floating-point-value

Philip

> 
> 
> 
> 



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

Re: [Discuss-gnuradio] Help me help myself

[Marcus D. Leech]

On 12/22/2014 06:37 PM, Richard Bell wrote:

Hi all,

The goal of this email is to learn how to find answers using available 
resources on my own in the future. To do this, I will explain what 
I've done to try and find the answer and then I hope someone can tell 
me how to finish the process so that next time I can do it on my own.


I'm working through the details of the MM Timing Recovery block. In 
the process of doing this I've come across the following line in source:


d_omega = d_omega_mid + gr::branchless_clip(d_omega-d_omega_mid, 
d_omega_lim);


I don't know what gr::branchless_clip does, so I started looking for 
answers on google and the gnuradio API manual. In the manual, I find this:


http://gnuradio.org/doc/doxygen/namespacegr.html#ace35e8c3e3ad45a5100217d2b6826e1b

but that doesn't tell me what it does. I can't find anymore reference 
to branchless_clip then this.


From the source code, I don't know how to track down the reference. 
I've searched my laptop for branchless_clip, but I get no returns.


So the question is, how do I find what branchless_clip does in the MM 
Timing Recovery block? I care more about the "how do I find" part of 
the question then the actual answer, though I do want the actual answer.



I used the following "find" command:

find gnuradio -name "*.*" -exec grep -H branchless_clip '{}' ';'

And found the definition in:

gnuradio/gnuradio-runtime/include/gnuradio/math.h:  
branchless_clip(float x, float clip)





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

[Discuss-gnuradio] Help me help myself

[Richard Bell]

Hi all,

The goal of this email is to learn how to find answers using available
resources on my own in the future. To do this, I will explain what I've
done to try and find the answer and then I hope someone can tell me how to
finish the process so that next time I can do it on my own.

I'm working through the details of the MM Timing Recovery block. In the
process of doing this I've come across the following line in source:

d_omega = d_omega_mid + gr::branchless_clip(d_omega-d_omega_mid,
d_omega_lim);

I don't know what gr::branchless_clip does, so I started looking for
answers on google and the gnuradio API manual. In the manual, I find this:

http://gnuradio.org/doc/doxygen/namespacegr.html#ace35e8c3e3ad45a5100217d2b6826e1b

but that doesn't tell me what it does. I can't find anymore reference to
branchless_clip then this.

>From the source code, I don't know how to track down the reference. I've
searched my laptop for branchless_clip, but I get no returns.

So the question is, how do I find what branchless_clip does in the MM
Timing Recovery block? I care more about the "how do I find" part of the
question then the actual answer, though I do want the actual answer.

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

Re: [Discuss-gnuradio] Running a GNU Radio Companion generated code

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Daniel,

> OK I have a code, generated with Gnu radio companion that i want
> to run over the command line to follow with GDB. I was under the
> impression that if I simply got the code generated in the
> ~/.grc_gnuradio, add the
This folder usually only contains 'hier_blocks'. Executable flowgraph
pythons files are usually created in the same folder your .grc file is
located in.

> 
> 
> 
> |def main(): """ go, go, go """ top_block = [CLASS]() 
> top_block.run()
Did you replace a class by [Class]? According to the Tutorial it
expects an object of type gr.top_block in this line.

> 
> if __name__ == "__main__": print 'Blocked waiting for GDB attach
> (pid = %d)' % (os.getpid(),) raw_input ('Press Enter to continue:
> ') main()  |
> 
> as stated at 
> https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging
>
> 
it would run to attach GDB. However, i am getting the following error:
> 
> --- Traceback (most recent call last): File "ieee802_15_4_phy.py",
> line 120, in  main() File "ieee802_15_4_phy.py", line 115,
> in main top_block.run() File 
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
>
> 
line 53, in __getattr__
> return getattr(self._hb, name) AttributeError: 'hier_block2_sptr'
> object has no attribute 'run'
You try to call run on a 'hier_block'. 'run' is a member of
'gr.top_block'. top_block contains the scheduler and takes care of
correct initialization etc. So it is essentially the flowgraph.

I hope I could give you some hints on what might go wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUmDfBAAoJEO7fmkDsqywMbyoQAKyANgElQ64/Ox81/gwl4TOY
k3NCr9Stj8CEUG65bYBPo4eDoVT5+xyA7e4HYTYrKMlHT+J2c/iG3ckH9sK7khoO
1jpFOtQn688tih6uBRhlVgNKWH26B2Hia8U4zIzavDcnt+B3aIRm+MG19Zlg6Ggg
XLD9KeJ6A5nfgrx+jsylAZGWmp4u6ZFupAVjuTA0vHab/3BOjCuJq2IOveWtSfhg
gPoHowIvWFwuiR/owJjwHhSGyCmZU1/Iz3yGT0TLdOZ8odlP0z9braIOt2bT3x9V
OQzgpQFBVuEEdSRJETZkWw0Lr4Jwl/Bko9pHi3tj6MGEcq8U6fP4Ml8dhiG1IE9q
UZ9XdSNJqDBNylfRxsyBm1oBmUV/gF6mXpD3851lQLdTNvP3R2QD7QrFP9UxRPKj
c300eaCsRhucDT7ApQmqTguPeL8ds+z6eN8BZ41BtD9etBPjbJDjoV+hfk4z16jF
gHEjVTAKti2OCiyya19xb67XJoufNz3Fjn09idG7YDAYRG7Qvn3XZCUpLAzO79pg
axceRvfxgMqws21NgTEDiEndDxjEeJm0mh1jcNUwoM6vlRar/JbEwRxPSCuvfUdx
GQac8LmkYJsROja1UgADE06fTEJZtLWUEQqBXhKlBlQz6sx1OA42XU8PPDm5c3SY
AQfwe85pgdf1nQY19UEv
=wYmS
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Running a GNU Radio Companion generated code

[Daniel Camara]

Hi people,

  Sorry for the dummy question, but I didn't find a simple and direct
answer searching around for this. (Not need to say also that I am just
starting with GNU Radio... :)

  OK I have a code, generated with Gnu radio companion that i want to run
over the command line to follow with GDB. I was under the impression that
if I simply got the code generated in the ~/.grc_gnuradio, add the



def main():
""" go, go, go """
top_block = [CLASS]()
top_block.run()
if __name__ == "__main__":
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
main()


as stated at
https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging it
would run to attach GDB. However, i am getting the following error:

---
Traceback (most recent call last):
  File "ieee802_15_4_phy.py", line 120, in 
main()
  File "ieee802_15_4_phy.py", line 115, in main
top_block.run()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 53, in __getattr__
return getattr(self._hb, name)
AttributeError: 'hier_block2_sptr' object has no attribute 'run'
---

The code runs correctly on Gnuradio companion! No problem whatsoever!
Which would be the correct way to run the code auto-generated by gnuradio
companion in a stand alone way?

  Thanks in advance...

   Daniel


-- 
Best regards...

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

Re: [Discuss-gnuradio] Doppler simulator

[Marcus Müller]

Yes and no. The signal source just uses the information "sampling rate" to 
calculate the length of one period in samples. Other than that, nothing in GNU 
radio cares about sampling rate - that's a real world concept that only applies 
to real world devices (such as the USRP sink) but not to the digital signal 
processing. You should make sure to use the same nominal sampling rate that you 
used to generate the files with the signal in. For example, if you calculated 
the satellite signal based on a nominal rate of 1MS/s, and play it back at 
5MS/s, everything will be frequency scaled with a factor of five.
Greetings,
Marcus

On December 22, 2014 11:51:34 AM CET, Carlos Alberto Ruiz Naranjo 
 wrote:
>Ok. Signal and sine must have the same sample rate (5 MS/s), right?
>
>2014-12-22 11:46 GMT+01:00 Marcus Müller :
>
>>  Yes and no: the shifting is done right; however, you should make
>sure to
>> use a consistent sampling rate throughout the block.
>> The USRP sink interprets the samples that come into it as having a
>sample
>> rate of 5MS/s, whereas the nominal sampling rate in the signal
>sources is
>> set to 2MS/s.
>>
>>
>>
>> On 12/22/2014 10:45 AM, Saul E. wrote:
>>
>>  First of all, I want to thank you for your answer.
>>
>>  Then, It is correct? (for a simple simulation of 1k, 2k and 3k Hz of
>> doppler shift)
>>
>>
>>
>> ​
>>
>> Thank you.
>>
>> Saul E.
>>
>>
>>
>> 2014-12-22 10:26 GMT+01:00 Marcus Müller :
>>
>>>  Hi Saul,
>>>
>>> a doppler shift is, mathematically speaking, nothing more than a
>>> multiplication with a complex sine, so use a multiply block and a
>signal
>>> source per simulated sattelite.
>>>
>>> Now, you might want to update your doppler shift according to a
>simulated
>>> sattelite's position. I recommend having a look at PyEphem[1], which
>offers
>>> you calculational routines for such things, and writing your own
>python
>>> block[2] to generate the complex sine.
>>>
>>> Greetings,
>>> Marcus
>>>
>>> [1] http://rhodesmill.org/pyephem/
>>> [2]
>http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>> ; go through tutorials 1, 2, 3
>>>
>>>
>>> On 12/22/2014 10:14 AM, Saul E. wrote:
>>>
>>>Hi all!!
>>>
>>> I am developing a SDR receiver and want to simulate the doppler of
>signal
>>> from several satellites.
>>> Any suggestions?
>>>
>>>  Signal1, signal2 and signal3 are BPSK signals and I use a USRP
>N200.
>>>
>>>
>>>  ​
>>>
>>>
>>>  Thank you very much in advance.
>>>  Saul E.
>>>
>>>
>>>
>>>  ___
>>> Discuss-gnuradio mailing
>listDiscuss-gnuradio@gnu.orghttps://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
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Doppler simulator

[Carlos Alberto Ruiz Naranjo]

Ok. Signal and sine must have the same sample rate (5 MS/s), right?

2014-12-22 11:46 GMT+01:00 Marcus Müller :

>  Yes and no: the shifting is done right; however, you should make sure to
> use a consistent sampling rate throughout the block.
> The USRP sink interprets the samples that come into it as having a sample
> rate of 5MS/s, whereas the nominal sampling rate in the signal sources is
> set to 2MS/s.
>
>
>
> On 12/22/2014 10:45 AM, Saul E. wrote:
>
>  First of all, I want to thank you for your answer.
>
>  Then, It is correct? (for a simple simulation of 1k, 2k and 3k Hz of
> doppler shift)
>
>
>
> ​
>
> Thank you.
>
> Saul E.
>
>
>
> 2014-12-22 10:26 GMT+01:00 Marcus Müller :
>
>>  Hi Saul,
>>
>> a doppler shift is, mathematically speaking, nothing more than a
>> multiplication with a complex sine, so use a multiply block and a signal
>> source per simulated sattelite.
>>
>> Now, you might want to update your doppler shift according to a simulated
>> sattelite's position. I recommend having a look at PyEphem[1], which offers
>> you calculational routines for such things, and writing your own python
>> block[2] to generate the complex sine.
>>
>> Greetings,
>> Marcus
>>
>> [1] http://rhodesmill.org/pyephem/
>> [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>> ; go through tutorials 1, 2, 3
>>
>>
>> On 12/22/2014 10:14 AM, Saul E. wrote:
>>
>>Hi all!!
>>
>> I am developing a SDR receiver and want to simulate the doppler of signal
>> from several satellites.
>> Any suggestions?
>>
>>  Signal1, signal2 and signal3 are BPSK signals and I use a USRP N200.
>>
>>
>>  ​
>>
>>
>>  Thank you very much in advance.
>>  Saul E.
>>
>>
>>
>>  ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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] Doppler simulator

[Marcus Müller]

Yes and no: the shifting is done right; however, you should make sure to
use a consistent sampling rate throughout the block.
The USRP sink interprets the samples that come into it as having a
sample rate of 5MS/s, whereas the nominal sampling rate in the signal
sources is set to 2MS/s.


On 12/22/2014 10:45 AM, Saul E. wrote:
> First of all, I want to thank you for your answer.
>
> Then, It is correct? (for a simple simulation of 1k, 2k and 3k Hz of
> doppler shift)
>
>
>
> ​
> Thank you.
> Saul E.
>
>
> 2014-12-22 10:26 GMT+01:00 Marcus Müller  >:
>
> Hi Saul,
>
> a doppler shift is, mathematically speaking, nothing more than a
> multiplication with a complex sine, so use a multiply block and a
> signal source per simulated sattelite.
>
> Now, you might want to update your doppler shift according to a
> simulated sattelite's position. I recommend having a look at
> PyEphem[1], which offers you calculational routines for such
> things, and writing your own python block[2] to generate the
> complex sine.
>
> Greetings,
> Marcus
>
> [1] http://rhodesmill.org/pyephem/
> [2]
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials ;
> go through tutorials 1, 2, 3
>
>
> On 12/22/2014 10:14 AM, Saul E. wrote:
>> Hi all!!
>>
>> I am developing a SDR receiver and want to simulate the doppler
>> of signal from several satellites.
>> Any suggestions?
>>
>> Signal1, signal2 and signal3 are BPSK signals and I use a USRP N200.
>>
>>
>> ​
>>
>>
>> Thank you very much in advance.
>> Saul E.
>>
>>
>>
>> ___
>> 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] Doppler simulator

[Saul E.]

First of all, I want to thank you for your answer.

Then, It is correct? (for a simple simulation of 1k, 2k and 3k Hz of
doppler shift)



​

Thank you.

Saul E.



2014-12-22 10:26 GMT+01:00 Marcus Müller :

>  Hi Saul,
>
> a doppler shift is, mathematically speaking, nothing more than a
> multiplication with a complex sine, so use a multiply block and a signal
> source per simulated sattelite.
>
> Now, you might want to update your doppler shift according to a simulated
> sattelite's position. I recommend having a look at PyEphem[1], which offers
> you calculational routines for such things, and writing your own python
> block[2] to generate the complex sine.
>
> Greetings,
> Marcus
>
> [1] http://rhodesmill.org/pyephem/
> [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials ;
> go through tutorials 1, 2, 3
>
>
> On 12/22/2014 10:14 AM, Saul E. wrote:
>
>   Hi all!!
>
> I am developing a SDR receiver and want to simulate the doppler of signal
> from several satellites.
> Any suggestions?
>
>  Signal1, signal2 and signal3 are BPSK signals and I use a USRP N200.
>
>
>  ​
>
>
>  Thank you very much in advance.
>  Saul E.
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] Doppler simulator

[Marcus Müller]

Hi Saul,

a doppler shift is, mathematically speaking, nothing more than a
multiplication with a complex sine, so use a multiply block and a signal
source per simulated sattelite.

Now, you might want to update your doppler shift according to a
simulated sattelite's position. I recommend having a look at PyEphem[1],
which offers you calculational routines for such things, and writing
your own python block[2] to generate the complex sine.

Greetings,
Marcus

[1] http://rhodesmill.org/pyephem/
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
; go through tutorials 1, 2, 3

On 12/22/2014 10:14 AM, Saul E. wrote:
> Hi all!!
>
> I am developing a SDR receiver and want to simulate the doppler of
> signal from several satellites.
> Any suggestions?
>
> Signal1, signal2 and signal3 are BPSK signals and I use a USRP N200.
>
>
> ​
>
>
> Thank you very much in advance.
> Saul E.
>
>
>
> ___
> 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] Doppler simulator

[Saul E.]

Hi all!!

I am developing a SDR receiver and want to simulate the doppler of signal
from several satellites.
Any suggestions?

Signal1, signal2 and signal3 are BPSK signals and I use a USRP N200.


​


Thank you very much in advance.
Saul E.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio