Re: [Discuss-gnuradio] GRC FFT Plot

[Gerome Jan L]

Actually, you were right at first madengr. My transmitter is USRP1 with WBX 50-2200 while my receiver is USRP N200 with TVRX2 and spectrum analyzer. Can you give me suggestions on how I can match the amplitude on both the spectrum analyzer and the USRP's? Attached is a screenshot of my experiment on our lab.

Using just the GRC Signal Source and Noise Source, I was able to display the desired power amplitude in dBW with less than 10 dB loss by varying the amplitude of each block. For the Signal Source block, the amplitude was 6.31 exp -8 (-144 dBW). For the Noise Source block, the amplitude was 2 exp -8 (-154 dBW). GRC FFT produces -137 dB and -159 dB respectively. Therefore I can say that these dB values in the FFT plot are in dBW. 

Best,

Gerome Jan M. Llames 

Engineering Research and Development for Technology (ERDT) Scholar

University of San Carlos - Technological Campus

Nasipit Talamban, Cebu City, Philippines, 6000

Mobile: +639271525124

Email: address@hidden

"Design is not just what it looks like and feels like. Design is how it works."  - Steve Jobs

On Tue, Aug 4, 2015 at 10:26 PM, <address@hidden> wrote:

Send Discuss-gnuradio mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: FFT plot unit (Marcus D. Leech)
   2. Re: FFT plot unit (Martin Braun)
   3. Re: FFT plot unit (Marcus D. Leech)
   4. Re: GRC FFT Plot (madengr)
   5. Re: FFT plot unit (John Ackermann N8UR)
   6. Re: Blocks handling vectors (Martin Braun)
   7. Re: GRC FFT Plot (madengr)
   8. Free IEEE tutorial (Gregory W. Ratcliff)
   9. Re: FFT plot unit (Marcus D. Leech)
  10. Re: Request regarding Channel Estimator Block (Martin Braun)
  11. Trouble creating simple custom Sink (Python): Unable to
      coerce endpoint (address@hidden)
  12. Re: Trouble creating simple custom Sink (Python): Unable to
      coerce endpoint (Marcus M?ller)
  13. State Machine that drops samples (Problems with return and
      consume_each in general_work) (Felipe Domingues)
  14. Re: State Machine that drops samples (Problems with return
      and consume_each in general_work) (Felipe Domingues)
  15. Re: Communication problems between 2 USRP's (John Garrick)
  16. pybombs difficulty (Mike Markowski)
  17. Re: pybombs difficulty (address@hidden)
  18. GLError 1285 (Marcus D. Leech)
  19. Re: pybombs difficulty (West, Nathan)
  20. Re: pybombs difficulty (Mike Markowski)
  21. Re: pybombs difficulty (Washbourne, Logan)
  22. Re: how to choose tune_delay? (fquitin)
  23. Fwd: Re: Trouble creating simple custom Sink (Python): Unable
      to coerce endpoint (ma4l0v)
  24. Re: pybombs difficulty (West, Nathan)
  25. Re: GLError 1285 (Sylvain Munaut)
  26. ControlPort 3.7.8rc1 (bob wole)
  27. Re: ControlPort 3.7.8rc1 (Jeon)
  28. Re: ControlPort 3.7.8rc1 (Volker Schroer)
  29. Re: how to choose tune_delay? (Marcus M?ller)
  30. pybombs with latest gnuradio 3.7.8. version (Iluta V)
  31. Re: pybombs with latest gnuradio 3.7.8. version (West, Nathan)
  32. TX and RX synchronization to control latency (Daniele Nicolodi)
  33. Strange behaviour (Simon Olvhammar)
  34. Re: Strange behaviour (Johannes Demel)
  35. Re: pybombs difficulty (Washbourne, Logan)


----------------------------------------------------------------------

Message: 1
Date: Mon, 03 Aug 2015 12:04:14 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] FFT plot unit
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 08/03/2015 09:36 AM, Sylvain Munaut wrote:
> Hi,
>
>> I was able to gather results, and I am really confused with it. I generated
>> a -30 dB signal based on the fft plot shown and transmitted it using a usrp.
>> My spectrum analyzer received a signal at -50 dBm (-80 dB) and my receiver
>> which also uses a usrp received the signal and plotted it at -30 dB. My
>> question is, what is the unit of the fft plot? Is it dB or dBm?
> They're dBFS  or dB Full Scale ...
>
> So they're just relative to the "full scale" range defined in GR as -1.0 ... 1.0
>
> USRP are not calibrated instruments, so you can't map this to dBm or
> any absolute power measurement. Only relative measurements are valid.
>
>
>
> Cheers,
>
>     Sylvain
>
> _______________________________________________
>
In order for Gnu Radio to display calibrated power units, it would need
to have a very vigorously-defined interface to each and every piece of
hardware so
   that power levels displayed in the FFTs are in calibrated convenient
power units, like dBm.   This in turn, would require that every piece of
hardware that
   connects to Gnu Radio be vigorously calibrated over their entire
operating parameter space, including sample-rate, tuning frequency, and
gain setting.
   This isn't, as you might imagine, practical.

So, what Gnu Radio receives are digitized voltage samples that are
mostly-linearly-proportional to the voltage received at the antenna
terminals
   of the device.  These are in turn, for purposes of convenience and
generality, converted into a floating-point number in the range {-1.0,+1.0}
   within a flow-graph.  But without calibration on the part of the
end-user, they are "unitless", and you have to determine the proportionality
   in the context of your own application.





------------------------------

Message: 2
Date: Mon, 03 Aug 2015 09:24:12 -0700
From: Martin Braun <address@hidden>
To: "Marcus D. Leech" <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] FFT plot unit
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

This pops up a lot, and hence earned a spot on the FAQ a while back:

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-know-the-exact-voltagepower-of-my-received-input-signal

...although that section could surely be expanded.

M

On 03.08.2015 09:04, Marcus D. Leech wrote:
> On 08/03/2015 09:36 AM, Sylvain Munaut wrote:
>> Hi,
>>
>>> I was able to gather results, and I am really confused with it. I
>>> generated
>>> a -30 dB signal based on the fft plot shown and transmitted it using
>>> a usrp.
>>> My spectrum analyzer received a signal at -50 dBm (-80 dB) and my
>>> receiver
>>> which also uses a usrp received the signal and plotted it at -30 dB. My
>>> question is, what is the unit of the fft plot? Is it dB or dBm?
>> They're dBFS  or dB Full Scale ...
>>
>> So they're just relative to the "full scale" range defined in GR as
>> -1.0 ... 1.0
>>
>> USRP are not calibrated instruments, so you can't map this to dBm or
>> any absolute power measurement. Only relative measurements are valid.
>>
>>
>>
>> Cheers,
>>
>>     Sylvain
>>
>> _______________________________________________
>>
> In order for Gnu Radio to display calibrated power units, it would need
> to have a very vigorously-defined interface to each and every piece of
> hardware so
>   that power levels displayed in the FFTs are in calibrated convenient
> power units, like dBm.   This in turn, would require that every piece of
> hardware that
>   connects to Gnu Radio be vigorously calibrated over their entire
> operating parameter space, including sample-rate, tuning frequency, and
> gain setting.
>   This isn't, as you might imagine, practical.
>
> So, what Gnu Radio receives are digitized voltage samples that are
> mostly-linearly-proportional to the voltage received at the antenna
> terminals
>   of the device.  These are in turn, for purposes of convenience and
> generality, converted into a floating-point number in the range {-1.0,+1.0}
>   within a flow-graph.  But without calibration on the part of the
> end-user, they are "unitless", and you have to determine the
> proportionality
>   in the context of your own application.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




------------------------------

Message: 3
Date: Mon, 03 Aug 2015 12:27:50 -0400
From: "Marcus D. Leech" <address@hidden>
To: Martin Braun <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] FFT plot unit
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 08/03/2015 12:24 PM, Martin Braun wrote:
> This pops up a lot, and hence earned a spot on the FAQ a while back:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-know-the-exact-voltagepower-of-my-received-input-signal
>
> ...although that section could surely be expanded.
>
> M
I just did so :)


>
> On 03.08.2015 09:04, Marcus D. Leech wrote:
>> On 08/03/2015 09:36 AM, Sylvain Munaut wrote:
>>> Hi,
>>>
>>>> I was able to gather results, and I am really confused with it. I
>>>> generated
>>>> a -30 dB signal based on the fft plot shown and transmitted it using
>>>> a usrp.
>>>> My spectrum analyzer received a signal at -50 dBm (-80 dB) and my
>>>> receiver
>>>> which also uses a usrp received the signal and plotted it at -30 dB. My
>>>> question is, what is the unit of the fft plot? Is it dB or dBm?
>>> They're dBFS  or dB Full Scale ...
>>>
>>> So they're just relative to the "full scale" range defined in GR as
>>> -1.0 ... 1.0
>>>
>>> USRP are not calibrated instruments, so you can't map this to dBm or
>>> any absolute power measurement. Only relative measurements are valid.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>      Sylvain
>>>
>>> _______________________________________________
>>>
>> In order for Gnu Radio to display calibrated power units, it would need
>> to have a very vigorously-defined interface to each and every piece of
>> hardware so
>>    that power levels displayed in the FFTs are in calibrated convenient
>> power units, like dBm.   This in turn, would require that every piece of
>> hardware that
>>    connects to Gnu Radio be vigorously calibrated over their entire
>> operating parameter space, including sample-rate, tuning frequency, and
>> gain setting.
>>    This isn't, as you might imagine, practical.
>>
>> So, what Gnu Radio receives are digitized voltage samples that are
>> mostly-linearly-proportional to the voltage received at the antenna
>> terminals
>>    of the device.  These are in turn, for purposes of convenience and
>> generality, converted into a floating-point number in the range {-1.0,+1.0}
>>    within a flow-graph.  But without calibration on the part of the
>> end-user, they are "unitless", and you have to determine the
>> proportionality
>>    in the context of your own application.
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




------------------------------

Message: 4
Date: Mon, 3 Aug 2015 09:04:14 -0700 (MST)
From: madengr <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GRC FFT Plot
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

1) Send in a CW tone from a signal generator of known power (dBm)
2) Read the level from GR FFT (dB)
3) Figure out the amount you need to offset (dB)
4) Multiply your samples by a constant value of 10**(offset_dB/20.0)
5) The GR FFT will now be calibrated to an absolute power (dBm).

Note if you change any settings, technically you would have to go through
this again.

Lou



Jan wrote
> Hi guys,
>
> I transmitted this -30 dB signal (Image 1) using a usrp: The spectrum
> analyzer displays -50 dBm (Image 2) as its reading. My receiver end picked
> up the signal with the same peak power at -30 dB (Image 3). I'm confused.
> How
> do I convert the dB power in the GRC to the received signal of the
> spectrum
> analyzer in dBm? How do I convert the Power (dB) of the FFT to dBW or dBm?
>
> Best,
>
> *Gerome Jan M. Llames *





--
View this message in context: http://gnuradio.4.n7.nabble.com/GRC-FFT-Plot-tp55210p55217.html
Sent from the GnuRadio mailing list archive at Nabble.com.



------------------------------

Message: 5
Date: Mon, 03 Aug 2015 12:35:06 -0400
From: John Ackermann N8UR <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] FFT plot unit
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

It might be helpful to clarify that since this is a voltage ratio, it's
20log rather than the 10log used for power (e.g., doubling voltage is
6dB, doubling power is 3dB), so the scaling will look different than a
typical spectrum analyzer.  (It would be nice if the instrumentation
blocks could have an option to select voltage, or power into 50 or 75
ohms...)

On 8/3/2015 12:27 PM, Marcus D. Leech wrote:
> On 08/03/2015 12:24 PM, Martin Braun wrote:
>> This pops up a lot, and hence earned a spot on the FAQ a while back:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-know-the-exact-voltagepower-of-my-received-input-signal
>>
>>
>> ...although that section could surely be expanded.
>>
>> M
> I just did so :)



------------------------------

Message: 6
Date: Mon, 03 Aug 2015 09:37:22 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Blocks handling vectors
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

On 03.08.2015 00:18, Galiero Casay Gabriele wrote:
> - The io signatures would be defined like this:
>         gr::io_signature::make(1,  1,  pkt_len*sizeof(float)),
>         gr::io_signature::make(1, 1, sizeof(float) * (sync_word_len +
> pkt_len)))
>  To clarify a bit what I want is to add a predefined preamble of length
> sync_word, which I define in the constructor and cannot be accessible.
>  Now, one of my questions was, is the most suitable block that I have to
> use a general one? or is it possible to use a decimator?\

In this case, you can use a sync block, because you have 1 output items
per 1 input item. However, you're packaging entire packets as vectors --
not sure if that's your intention.

If you want to handle this on an item-by-item basis, you need a general
block, because the relative rate is (sync_len+pkt_len)/pkt_len, and
that's (most likely) non-integer. This approach can be convenient if
your packets are very large, or if your packet length (with or without
sync word) is an annoying size and doesn't fit into page boundaries.

>   int
>     add_sync_impl::general_work (int noutput_items,
>                        gr_vector_int &ninput_items,
>                        gr_vector_const_void_star &input_items,
>                        gr_vector_void_star &output_items)
>     {
>         const float *in = (const float *) input_items[0];
>         float *out = (float *) output_items[0];
>
>         // Do <+signal processing+>
>         for (int i = 0; i < noutput_items; i++) {
>             std::memcpy(&out[0], &d_sync_word[0], sizeof(float) *
> d_sync_word_len);
>             std::memcpy(&out[d_sync_word_len], &in[0], sizeof(float) *
> d_pkt_len);
>         }
>         // Tell runtime system how many input items we consumed on
>         // each input stream.
>         consume_each (d_pkt_len);

Nope, you've consumed noutput_items.

>         // Tell runtime system how many output items we produced.
>         return noutput_items;
>     }
>
>  But when I try to connect the blocks to test them with python it gives
> me error:
>   File "<stdin>", line 1, in <module>
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 48, in wrapped
>     raise ValueError("Unable to coerce endpoint")
> ValueError: Unable to coerce endpoint


Well, we can't see what you're connecting this too, but it probably
doesn't have pkt_len or pkt_len+sync_word vector lengths.

M



------------------------------

Message: 7
Date: Mon, 3 Aug 2015 09:13:51 -0700 (MST)
From: madengr <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GRC FFT Plot
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

I misread you question and thought you were receiving with the USRP.  Same
procedure, just don't let the transmitted signal go past +/- 1.0 or you will
clip the DAC.  In practice keep it backed off 6 dB or more to allow for
crest factor.

Lou



madengr wrote
> 1) Send in a CW tone from a signal generator of known power (dBm)
> 2) Read the level from GR FFT (dB)
> 3) Figure out the amount you need to offset (dB)
> 4) Multiply your samples by a constant value of 10**(offset_dB/20.0)
> 5) The GR FFT will now be calibrated to an absolute power (dBm).
>
> Note if you change any settings, technically you would have to go through
> this again.
>
> Lou
>
>
> Jan wrote
>> Hi guys,
>>
>> I transmitted this -30 dB signal (Image 1) using a usrp: The spectrum
>> analyzer displays -50 dBm (Image 2) as its reading. My receiver end
>> picked
>> up the signal with the same peak power at -30 dB (Image 3). I'm confused.
>> How
>> do I convert the dB power in the GRC to the received signal of the
>> spectrum
>> analyzer in dBm? How do I convert the Power (dB) of the FFT to dBW or
>> dBm?
>>
>> Best,
>>
>> *Gerome Jan M. Llames *





--
View this message in context: http://gnuradio.4.n7.nabble.com/GRC-FFT-Plot-tp55210p55220.html
Sent from the GnuRadio mailing list archive at Nabble.com.



------------------------------

Message: 8
Date: Mon, 3 Aug 2015 16:42:39 +0000 (UTC)
From: "Gregory W. Ratcliff" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Free IEEE tutorial
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

Below is a free (to IEEE members) tutorial on wide bandwidth signal analysis.?
Let me know If you guys consider this kind of thing spam and but me being curious always appreciate a few diversions from time to time.
We all could learn something from this I expect.

Greg
Gregory W. Ratcliff

*******************http://event.on24.com/r.htm?e=1026616&s=1&k=64D655E7978210FA93FA3793C48A82E7



| Error Vector Magnitude measurements fit for 5G |
|
DESCRIPTION: Error vector magnitude, EVM, measurements have been the mainstay of modulation performance analysis for more than twenty years. Each new technology has defined a specific measurement to suit the characteristics of the physical layer signal. The interest in signals for 5G that are much wider bandwidth, operating at much higher frequencies means it?s time to draw a comparison between the different waveforms and the impact on the measurement of EVM. This presentation reviews what an EVM measurement is and what it can tell us about the device being measured. A combination of real life and simulated examples are used, with single and multi-carrier waveforms having bandwidths of 20 MHz ? 2 GHz, to demonstrate the impact of a variety of signal impairments, including broadband noise and phase noise. The examples will show how to make measurements that give the expected, and consistent results. |




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/4c0f3254/attachment.html>

------------------------------

Message: 9
Date: Mon, 03 Aug 2015 12:42:54 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] FFT plot unit
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 08/03/2015 12:35 PM, John Ackermann N8UR wrote:
> It might be helpful to clarify that since this is a voltage ratio,
> it's 20log rather than the 10log used for power (e.g., doubling
> voltage is 6dB, doubling power is 3dB), so the scaling will look
> different than a typical spectrum analyzer.  (It would be nice if the
> instrumentation blocks could have an option to select voltage, or
> power into 50 or 75 ohms...)
Yes, and we need 50 ohm and 75 ohm terminator blocks in GRC..... :) :)

But, seriously, one can always prefix any instrumentation block with a
scaling function in the ax + b form with a multiplier and adder to
achieve whatever
   pleasant-and-convenient scaling one wants.


>
> On 8/3/2015 12:27 PM, Marcus D. Leech wrote:
>> On 08/03/2015 12:24 PM, Martin Braun wrote:
>>> This pops up a lot, and hence earned a spot on the FAQ a while back:
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-know-the-exact-voltagepower-of-my-received-input-signal
>>>
>>>
>>>
>>> ...although that section could surely be expanded.
>>>
>>> M
>> I just did so :)
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




------------------------------

Message: 10
Date: Mon, 03 Aug 2015 09:58:17 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Request regarding Channel Estimator
        Block
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

On 02.08.2015 11:32, Gaddam Yamuna wrote:
> Hello,
>
> I am unable to understand the *max-carr-offset* parameter in *Channel
> Estimator block. *How this parameter help in order to receive

It effectively limits the search range, and it's specified in multiples
of integer carrier offsets. The channel model simply takes an arbitrary
frequency to offset your signal.

M




------------------------------

Message: 11
Date: Mon, 03 Aug 2015 18:05:37 +0000
From: address@hidden
To: address@hidden
Subject: [Discuss-gnuradio] Trouble creating simple custom Sink
        (Python): Unable to coerce endpoint
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed

I'd like to implement a simple custom sink block in Python.

AFAIK, a sink is a 1:0 basic block, with one input port, and no output
port.

I define it as a class:

class MySink(gr.basic_block):
     def __init__(self, src_block):
     gr.basic_block.__init__(self, name='MySink', in_sig=[numpy.float32],
out_sig=None)
     gr.top_block().connect(src_block, self)

Then, in the top block constructor:
     # ....
     self.gsm_fcch_detector_0 = grgsm.fcch_detector(4)
     # Line bellow raises an 'Unable to coerce endpoint' exception
     self.my_sink = MySink(self.gsm_fcch_detector_0)

As you may already have guessed, I'm a newcomer here, and I'm sure I
miss something obvious.
I thought the connect line should wire the FCCH detector output port to
my custom sink input port, but instead it raises an exception.

I will really appreciate any direction, as I'm a bit stuck here: could
someone point me toward what I clearly misunderstand ?

Thanks in advance.



------------------------------

Message: 12
Date: Mon, 03 Aug 2015 20:15:26 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Trouble creating simple custom Sink
        (Python): Unable to coerce endpoint
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

Hi M4RL0V,

a sink is typically built as a sync block, simply because it's easier
(and still works), since you don't have to implement a general_work (and
a forecast).

So your problem here is that logically, connecting happens in the
top_block, not in the block itself; have a look at python code that the
GNU Radio Companion generates when connecting two blocks. It simply
happens outside any constructor as tb.connect(source,sink).

Generally, I don't know whether that actually is the problem here. You
forgot to actually include information on what goes wrong, and any
relevant errors (if any). It's hard to help you like this :) Here's a
link having a few tips on how to ask good questions on the mailing list:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors

Best regards,
Marcus

On 08/03/2015 08:05 PM, address@hidden wrote:
> I'd like to implement a simple custom sink block in Python.
>
> AFAIK, a sink is a 1:0 basic block, with one input port, and no output
> port.
>
> I define it as a class:
>
> class MySink(gr.basic_block):
>     def __init__(self, src_block):
>     gr.basic_block.__init__(self, name='MySink',
> in_sig=[numpy.float32], out_sig=None)
>     gr.top_block().connect(src_block, self)
>
> Then, in the top block constructor:
>     # ....
>     self.gsm_fcch_detector_0 = grgsm.fcch_detector(4)
>     # Line bellow raises an 'Unable to coerce endpoint' exception
>     self.my_sink = MySink(self.gsm_fcch_detector_0)
>
> As you may already have guessed, I'm a newcomer here, and I'm sure I
> miss something obvious.
> I thought the connect line should wire the FCCH detector output port
> to my custom sink input port, but instead it raises an exception.
>
> I will really appreciate any direction, as I'm a bit stuck here: could
> someone point me toward what I clearly misunderstand ?
>
> Thanks in advance.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




------------------------------

Message: 13
Date: Mon, 3 Aug 2015 20:17:32 +0100
From: Felipe Domingues <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] State Machine that drops samples (Problems
        with return and consume_each in general_work)
Message-ID:
        <CAOkiim+af4hfJ=address@hidden>
Content-Type: text/plain; charset="utf-8"

Dear all,

I'm trying to implement a simple state machine to receive bursty data and
write it in a file.

To accomplish this I have created a general block that accepts complex
samples and has two states:

0 - Just drops data. If one of the samples is 0, go to state 1.

1 - Copy inputs to outputs. If one of the samples is 1, go to state 0.

I will use this block in the future to wrap another more complex signal
processing block that will generate a proper parameter for state transition.

However I'm failing to make even this simple one work. Here's my
general_work:

--------------------------------------------------------------------------------------------------

        for (int i = 0; i < noutput_items; i++) {

          currentState = nextState;

          if(in[i] == std::complex<float> (0,0)){

            if(currentState == 0){
              nextState = 1;
              consume_each(i);
              return 0;

            }

            if(currentState == 1){
              for (int j = 0; j < i; j++) {
                out[j] = in[j];
              }
              nextState = 0;
              consume_each(i);
              return i;
            }

          }

        }

        if (currentState == 0){
          consume_each (noutput_items);
          return 0;
        }

        if (currentState == 1){
          for (int j = 0; j < noutput_items; j++) {
            out[j] = in[j];
          }
          consume_each (noutput_items);
          return noutput_items;
        }

--------------------------------------------------------------------------------------------------


Here's what it does:

1) Receive new state

2) Checks for state transition condition. If true:

2A) If it's in state 0: Change state to 1, consume all inputs processed so
far (which makes non-processed inputs to go back to the queue in the next
call of general_work, correct?) and returns 0 (which is equivalent to not
generating outputs, right?)

2B) If it's in state 1: Same as 2A, but copy ( i ) inputs to the output
(number of samples before state transition happens) and returns i samples.


3) If the loop ends without any state transition, the same thing that
happened in 2A) and 2B) is executed, however noutput_items are
processed/consumed/returned instead.

I'm testing this block in the attached flow graph, however the generated
file is blank. Both nextState and currentState are private attributes of
the block and are initialized in the constructor with 0.

My questions are:

1) Am I misunderstanding the way consume_each and return works?

2) What should I do with the forecast() function? I cannot guarantee that
any numbers of inputs will actually produce an output.

3) Is this really the best way to accomplish what I want?


Thank you all for your assistance,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/fc590c70/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fg.png
Type: image/png
Size: 20911 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/fc590c70/attachment.png>

------------------------------

Message: 14
Date: Mon, 3 Aug 2015 21:23:53 +0100
From: Felipe Domingues <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] State Machine that drops samples
        (Problems with return and consume_each in general_work)
Message-ID:
        <CAOkiim+B=82tC7X1g=SRi93E6+32Da7fA9w3=address@hidden>
Content-Type: text/plain; charset="utf-8"

Dear all,

I was able to fix the problem.

Fist I had forecast set to a big number and vector sink was unable to
provide such amount of inputs. I changed that to ninput_items_required[0]=
noutput_items, not sure if it's the correct relation thought. But the block
still didn't work.

Apparently I was not consuming the item responsible for the state
transition, so general_work was in an infinite loop. Changing
consume_each(i) to consume_each(i+1) did the trick.

Finally, for some reason I had to delete the blank file generated by past
iterations of the program manually and a correct one was created. Now I
don't need to do that any more, but watch out if you are using Ubuntu 14.04.

Here is the (apparently) working code:

        for (int i = 0; i < noutput_items; i++) {

          currentState = nextState;
          std::cout << noutput_items << std::endl;
          std::cout << "\nin[i]: " << in[i] << std::endl;


          if(in[i] == std::complex<float> (0,0)){

            if(currentState == 0){
              std::cout << "\nstatezero" << std::endl;
              nextState = 1;
              consume_each(i+1);
              return 0;

            }

            if(currentState == 1){
              std::cout << "\nstateone" << std::endl;
              for (int j = 0; j < i; j++) {
                out[j] = in[j];
              }
              nextState = 0;
              consume_each(i+1);
              return i;
            }

          }

        }

        if (currentState == 0){
          std::cout << "\nFinishing loop in state zero" << std::endl;
          consume_each (noutput_items);
          return 0;
        }

        if (currentState == 1){

          for (int j = 0; j < noutput_items; j++) {
            out[j] = in[j];
          }
          consume_each (noutput_items);
          std::cout << "\nnFinishing loop in state one" << std::endl;
          return noutput_items;
        }



BTW there was a typo in my original email, both state transitions use the
same condition.

Thank you very much for your attention,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/db77dee3/attachment.html>

------------------------------

Message: 15
Date: Mon, 03 Aug 2015 23:09:02 +0200
From: John Garrick <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Communication problems between 2
        USRP's
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8

Hi Tom,
I have actually added a jpg file which shows the output when given the
command of uhd_fft. Actually,my experiment is to transmit different data
packets to the receiver with minimized errors with ./benchmark_tx.py -f
2.435G and ./benchmark_rx.py -f 2.435G as commands . May I please know
of how can to set the gain in this picture and also how this picture is
useful for the reception of data packets. Please help as I am new to
using GNU Radio and USRP. Thank you.

Regards,
John

Attachments:
http://www.ruby-forum.com/attachment/10951/Screenshot_from_2015-08-03_16_03_15.png


--
Posted via http://www.ruby-forum.com/.



------------------------------

Message: 16
Date: Mon, 3 Aug 2015 17:39:43 -0400
From: Mike Markowski <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

I use gentoo at home and have no difficulty keeping gnuradio up to date.

At work we're on a standalone network (no internet) so occasionally bring
computers home to update them.  Lately, I've been having trouble with
pybombs.  Using a freshly installed ubuntu 15.04, then doing an

  apt-get update
  apt-get upgrade [not sure the update was necessary]

I first used

  apt-get install gnuradio

Thinking better of it, I ran

  apt-get remove gnuradio
  apt-get autoremove

Then went with pybombs

  git clone git://github.com/pybombs/pybombs
  cd pybombs
  ./pybombs config [use install path /usr/local/gnuradio]
  ./pybombs install gnuradio

And after several tries continue to receive this error:

[...many lines of install...]
Unpacking liblog4cpp5-dev (1.0-4) ...
Setting up liblog4cpp5-dev (1.0-4) ...
installation ok via: deb
Installing from source: gnuradio
Cloning into 'gnuradio'...
Checking connectivity... done.
Cloning into 'volk'...
remote: Counting objects: 5450, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
Resolving deltas: 100% (3918/3918), done.
Checking connectivity... done.

    CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF

Configuring: (100%)
[==========================================================]
Configuration failed. Re-trying with higher verbosity.
make: *** No targets specified and no makefile found.  Stop.
Build failed. See output above for error messages.

Any hints as to what is going wrong?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/e7b7f706/attachment.html>

------------------------------

Message: 17
Date: Mon, 03 Aug 2015 17:49:04 -0500
From: address@hidden
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

Mike,

When I ran into this problem, I had to reinstall pybombs. I think the problem lies in changing the installation prefix after installing pybombs.

I'm sure there is another way to fix this, I just don't know what it is.

When I reinstalled pybombs, I defined the installation prefix when the several prompts are asked at the beginning.

Sent from my Cyanogen phone

On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden> wrote:
>
> I use gentoo at home and have no difficulty keeping gnuradio up to date.
>
> At work we're on a standalone network (no internet) so occasionally bring computers home to update them.? Lately, I've been having trouble with pybombs.? Using a freshly installed ubuntu 15.04, then doing an
>
> ? apt-get update
> ? apt-get upgrade [not sure the update was necessary]
>
> I first used
>
> ? apt-get install gnuradio
>
> Thinking better of it, I ran
>
> ? apt-get remove gnuradio
> ? apt-get autoremove
>
> Then went with pybombs
>
> ? git clone git://github.com/pybombs/pybombs
> ? cd pybombs
> ? ./pybombs config [use install path /usr/local/gnuradio]
> ? ./pybombs install gnuradio
>
> And after several tries continue to receive this error:
>
> [...many lines of install...]
> Unpacking liblog4cpp5-dev (1.0-4) ...
> Setting up liblog4cpp5-dev (1.0-4) ...
> installation ok via: deb
> Installing from source: gnuradio
> Cloning into 'gnuradio'...
> Checking connectivity... done.
> Cloning into 'volk'...
> remote: Counting objects: 5450, done.
> remote: Compressing objects: 100% (10/10), done.
> remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
> Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
> Resolving deltas: 100% (3918/3918), done.
> Checking connectivity... done.
> ?
> ??? CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio? -DENABLE_DOXYGEN=OFF
>
> Configuring: (100%) [==========================================================]
> Configuration failed. Re-trying with higher verbosity.
> make: *** No targets specified and no makefile found.? Stop.
> Build failed. See output above for error messages.
>
> Any hints as to what is going wrong?
>
> Thanks,
> Mike

------------------------------

Message: 18
Date: Mon, 03 Aug 2015 20:17:01 -0400
From: "Marcus D. Leech" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] GLError 1285
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

I have users of my simple_ra application complaining of this:

Traceback (most recent call last):
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 209, in _on_paint
     for fcn in self._draw_fcns: fcn[1]()
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 65, in draw
     GL.glCallList(self._grid_compiled_list_id)
   File "errorchecker.pyx", line 53, in
OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError
(src/errorchecker.c:1218)
OpenGL.error.GLError: GLError(
     err = 1285,
     baseOperation = glCallList,
     cArguments = (1L,)
)

After running for an hour or two.

This is on F22, but on F20, there's no such issue.  So, it appears that
there's a memory leak somewhere, but not sure where.





------------------------------

Message: 19
Date: Mon, 3 Aug 2015 20:38:21 -0400
From: "West, Nathan" <address@hidden>
To: "address@hidden" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

Logan,

For your case deleting inventory.dat would do the trick of effectively
resetting pybombs state (and if your done with an install rm the prefix)

Mike,

Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
Radio. Try running pybombs again with -v -v

On Monday, August 3, 2015, <address@hidden> wrote:

> Mike,
>
> When I ran into this problem, I had to reinstall pybombs. I think the
> problem lies in changing the installation prefix after installing pybombs.
>
> I'm sure there is another way to fix this, I just don't know what it is.
>
> When I reinstalled pybombs, I defined the installation prefix when the
> several prompts are asked at the beginning.
>
> Sent from my Cyanogen phone
>
> On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden
> <_javascript_:;>> wrote:
> >
> > I use gentoo at home and have no difficulty keeping gnuradio up to date.
> >
> > At work we're on a standalone network (no internet) so occasionally
> bring computers home to update them.  Lately, I've been having trouble with
> pybombs.  Using a freshly installed ubuntu 15.04, then doing an
> >
> >   apt-get update
> >   apt-get upgrade [not sure the update was necessary]
> >
> > I first used
> >
> >   apt-get install gnuradio
> >
> > Thinking better of it, I ran
> >
> >   apt-get remove gnuradio
> >   apt-get autoremove
> >
> > Then went with pybombs
> >
> >   git clone git://github.com/pybombs/pybombs
> >   cd pybombs
> >   ./pybombs config [use install path /usr/local/gnuradio]
> >   ./pybombs install gnuradio
> >
> > And after several tries continue to receive this error:
> >
> > [...many lines of install...]
> > Unpacking liblog4cpp5-dev (1.0-4) ...
> > Setting up liblog4cpp5-dev (1.0-4) ...
> > installation ok via: deb
> > Installing from source: gnuradio
> > Cloning into 'gnuradio'...
> > Checking connectivity... done.
> > Cloning into 'volk'...
> > remote: Counting objects: 5450, done.
> > remote: Compressing objects: 100% (10/10), done.
> > remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
> > Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
> > Resolving deltas: 100% (3918/3918), done.
> > Checking connectivity... done.
> >
> >     CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
> >
> > Configuring: (100%)
> [==========================================================]
> > Configuration failed. Re-trying with higher verbosity.
> > make: *** No targets specified and no makefile found.  Stop.
> > Build failed. See output above for error messages.
> >
> > Any hints as to what is going wrong?
> >
> > Thanks,
> > Mike
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <_javascript_:;>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/0de56ba1/attachment.html>

------------------------------

Message: 20
Date: Mon, 3 Aug 2015 21:11:47 -0400
From: Mike Markowski <address@hidden>
To: address@hidden
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <CANq1pf=vBYHwY5HUpdiLQwNVYZVtC=address@hidden>
Content-Type: text/plain; charset="utf-8"

Thanks, Nathan, and all who replied publicly and privately,

The problem seems to be that I had installed Anaconda (from Continuum
Analytics) which does not include Cheetah by default.  It does exist,
however, in the python tree installed by ubuntu, and that seemed to confuse
things.  I installed Cheetah within the anaconda tree and I believe all is
well.  I can say for sure when compiling completes!

Thanks for the speedy and helpful replies,
Mike

On Mon, Aug 3, 2015 at 8:38 PM, West, Nathan <address@hidden>
wrote:

> Logan,
>
> For your case deleting inventory.dat would do the trick of effectively
> resetting pybombs state (and if your done with an install rm the prefix)
>
> Mike,
>
> Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
> Radio. Try running pybombs again with -v -v
>
>
> On Monday, August 3, 2015, <address@hidden> wrote:
>
>> Mike,
>>
>> When I ran into this problem, I had to reinstall pybombs. I think the
>> problem lies in changing the installation prefix after installing pybombs.
>>
>> I'm sure there is another way to fix this, I just don't know what it is.
>>
>> When I reinstalled pybombs, I defined the installation prefix when the
>> several prompts are asked at the beginning.
>>
>> Sent from my Cyanogen phone
>>
>> On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden> wrote:
>> >
>> > I use gentoo at home and have no difficulty keeping gnuradio up to date.
>> >
>> > At work we're on a standalone network (no internet) so occasionally
>> bring computers home to update them.  Lately, I've been having trouble with
>> pybombs.  Using a freshly installed ubuntu 15.04, then doing an
>> >
>> >   apt-get update
>> >   apt-get upgrade [not sure the update was necessary]
>> >
>> > I first used
>> >
>> >   apt-get install gnuradio
>> >
>> > Thinking better of it, I ran
>> >
>> >   apt-get remove gnuradio
>> >   apt-get autoremove
>> >
>> > Then went with pybombs
>> >
>> >   git clone git://github.com/pybombs/pybombs
>> >   cd pybombs
>> >   ./pybombs config [use install path /usr/local/gnuradio]
>> >   ./pybombs install gnuradio
>> >
>> > And after several tries continue to receive this error:
>> >
>> > [...many lines of install...]
>> > Unpacking liblog4cpp5-dev (1.0-4) ...
>> > Setting up liblog4cpp5-dev (1.0-4) ...
>> > installation ok via: deb
>> > Installing from source: gnuradio
>> > Cloning into 'gnuradio'...
>> > Checking connectivity... done.
>> > Cloning into 'volk'...
>> > remote: Counting objects: 5450, done.
>> > remote: Compressing objects: 100% (10/10), done.
>> > remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
>> > Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
>> > Resolving deltas: 100% (3918/3918), done.
>> > Checking connectivity... done.
>> >
>> >     CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
>> >
>> > Configuring: (100%)
>> [==========================================================]
>> > Configuration failed. Re-trying with higher verbosity.
>> > make: *** No targets specified and no makefile found.  Stop.
>> > Build failed. See output above for error messages.
>> >
>> > Any hints as to what is going wrong?
>> >
>> > Thanks,
>> > Mike
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/4efc6027/attachment.html>

------------------------------

Message: 21
Date: Mon, 3 Aug 2015 20:15:00 -0500
From: "Washbourne, Logan" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

Thanks Nathan. Should I have to use sudo when using pybomb commands, now
that the installation prefix is outside of my home directory(because I now
I have to use sudo when using pybomb commands)?


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan <address@hidden>
wrote:

> Logan,
>
> For your case deleting inventory.dat would do the trick of effectively
> resetting pybombs state (and if your done with an install rm the prefix)
>
> Mike,
>
> Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
> Radio. Try running pybombs again with -v -v
>
>
> On Monday, August 3, 2015, <address@hidden> wrote:
>
>> Mike,
>>
>> When I ran into this problem, I had to reinstall pybombs. I think the
>> problem lies in changing the installation prefix after installing pybombs.
>>
>> I'm sure there is another way to fix this, I just don't know what it is.
>>
>> When I reinstalled pybombs, I defined the installation prefix when the
>> several prompts are asked at the beginning.
>>
>> Sent from my Cyanogen phone
>>
>> On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden> wrote:
>> >
>> > I use gentoo at home and have no difficulty keeping gnuradio up to date.
>> >
>> > At work we're on a standalone network (no internet) so occasionally
>> bring computers home to update them.  Lately, I've been having trouble with
>> pybombs.  Using a freshly installed ubuntu 15.04, then doing an
>> >
>> >   apt-get update
>> >   apt-get upgrade [not sure the update was necessary]
>> >
>> > I first used
>> >
>> >   apt-get install gnuradio
>> >
>> > Thinking better of it, I ran
>> >
>> >   apt-get remove gnuradio
>> >   apt-get autoremove
>> >
>> > Then went with pybombs
>> >
>> >   git clone git://github.com/pybombs/pybombs
>> >   cd pybombs
>> >   ./pybombs config [use install path /usr/local/gnuradio]
>> >   ./pybombs install gnuradio
>> >
>> > And after several tries continue to receive this error:
>> >
>> > [...many lines of install...]
>> > Unpacking liblog4cpp5-dev (1.0-4) ...
>> > Setting up liblog4cpp5-dev (1.0-4) ...
>> > installation ok via: deb
>> > Installing from source: gnuradio
>> > Cloning into 'gnuradio'...
>> > Checking connectivity... done.
>> > Cloning into 'volk'...
>> > remote: Counting objects: 5450, done.
>> > remote: Compressing objects: 100% (10/10), done.
>> > remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
>> > Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
>> > Resolving deltas: 100% (3918/3918), done.
>> > Checking connectivity... done.
>> >
>> >     CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
>> >
>> > Configuring: (100%)
>> [==========================================================]
>> > Configuration failed. Re-trying with higher verbosity.
>> > make: *** No targets specified and no makefile found.  Stop.
>> > Build failed. See output above for error messages.
>> >
>> > Any hints as to what is going wrong?
>> >
>> > Thanks,
>> > Mike
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/f8d4c679/attachment.html>

------------------------------

Message: 22
Date: Tue, 04 Aug 2015 03:21:25 +0200
From: fquitin <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] how to choose tune_delay?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Marcus,

Thanks for your comments, as usual, you're being a life-saver (I wasn't
aware of the existence of set_command_time/clear_command_time functions,
these will be immensely helpfull). From your suggestions, I understand
that the USRP will always re-attach a rx_time tag after being re-tuned?

Thanks,
Francois


On 03.08.2015 11:26, Marcus M?ller wrote:
> Hi Francois,
>
>  yes, that seems rather high; but maybe you're seeing the effects of
> the DC offset removal filter. You can try to use use
> set_auto_dc_offset(False) to make that faster [1].
>
>  However, usrp_spectrum_sense is pretty old, and hence can't even make
> use of stream tags on the GNU Radio side and timed commands on the
> USRP side, so the lower boundary for delay is the two-way latency
> between host and device -- which can easily be in the order of tens of
> milliseconds.
>
>  I'd personally recommend just going ahead and reimplementing this:
>  * Use the USRP source as usual
>  ? * use set_time_now (if you don't have a time/PPS source),
> set_start_time
>  ? * issue two or three timed tuning commands right at the start
> (set_command_time, set_rx_freq, clear_command_time)
>  * write a python block that waits for rx_time tags (which
> automatically get added by the USRP source nowadays)
>  ?* that block would, upon detection of such a tag, issue "the next
> tune request in line" (set_command_time(rx_time+delay), set_rx_freq,
> clear_command_time)
>  ?* that block would, after detection of such a tag, first discard a
> few samples and then calculate your metrics based on the following N
> samples
>
>  Best regards,
>  Marcus
>
>  [1]
> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
> [2]
>
> On 03.08.2015 11:11, Francois Quitin wrote:
>
>> Hi all,
>>
>> ?
>>
>> I want to retune the frequency of my USRP in Python during runtime.
>> I understand from usrp_spectrum_sense.py that I can just retune the
>> USRP during runtime, and that I need to allow for some tune_delay to
>> make sure that the samples corresponding to the old center frequency
>> are discarded.
>>
>> ?
>>
>> Is there any way to get a good estimate of tune_delay value? I want
>> to keep this as short as possible? (btw I?m using a USRP-N210
>> with WBX daughterboard) Some trial and error gave me values around
>> 50ms, but this seems rather high compared to what I?ve read
>> online.
>>
>> ?
>>
>> Any hints are welcome!
>>
>> Thanks,
>>
>> Francois
>>
>> ?
>>
>> --
>>
>> ?
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
>
>
>
> Links:
> ------
> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> [2]
> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



------------------------------

Message: 23
Date: Tue, 04 Aug 2015 03:40:36 +0200
From: ma4l0v <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Fwd: Re: Trouble creating simple custom
        Sink (Python): Unable to coerce endpoint
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8


Marcus, Thank you for your answer.

> a sink is typically built as a sync block, simply because it's easier
> (and still works), since you don't have to implement a general_work (and
> a forecast).

Actually, I do not override general_work() neither forecast(), but only
work(), with signature:
work(self, input_items, output_items)

Though the default forecast() implementation (1 input -> 1 output) may
be wrong for me (as I don't have any output), and my work function does
not call consume(), I do not think this may cause the error, since the
ValueError("Unable to coerce endpoint") exception raises at:
self.connect((self.gsm_fcch_detector_0,0) , (self.my_sink, 0))

I assume self.gsm_fcch_detector_0 is properly initialized, as when I
substitute the code bellow, it works as expected:
self.connect((self.gsm_fcch_detector_0, 0), (self.blocks_tag_debug_0, 0))
where blocks_tag_debug_0 is of type gr.blocks.tag_debug.

Following your suggestion, I updated my code to inherit from sync_block
rather than basic_block:
class MySink(gr.sync_block):
    def __init__(self) gr.sync_block.__init__(self, name='MySink',
in_sig=[numpy.float32], out_sig=None)

In my understanding, this should define a sink block with a single input
port with item size float32, and no output port. But still the same error.

< So your problem here is that logically, connecting happens in the
< top_block, not in the block itself; have a look at python code that the
< GNU Radio Companion generates when connecting two blocks. It simply
< happens outside any constructor as tb.connect(source,sink).

I use GNU radio 3.7, and companion generates Python scripts which
initialize the whole flow graph in the top block constructor, that
contains sections for Parameters and Variables, then Blocks, and then
Connections. The main() function only instantiates and
starts/stops/waits the top block (no connection happen here for me).
I still tried to call connect() from the main() function rather than
from the top block constructor, the error is identical.

< Generally, I don't know whether that actually is the problem here. You
< forgot to actually include information on what goes wrong, and any
< relevant errors (if any). It's hard to help you like this :)

I'm not sure I can tell you more that this: connecting an input to my
stupid sink raises ValueError("Unable to coerce endpoint").
Bellow is the console output:

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
Opening nuand bladeRF with device identifier string: "*:instance=0"
 Serial # 23a1...fec4
 FW v1.8.0 FPGA v0.3.3
[INFO @ bladerf.c:648] Clamping bandwidth to 1500000Hz
Using Volk machine: avx_64_mmx_orc
Traceback (most recent call last):
  File "./fcch_block.py", line 101, in <module>
    tb = fcch_block(ppm=options.ppm, fc=options.fc)
  File "./fcch_block.py", line 65, in __init__
    self.connect((self.gsm_fcch_detector_0,0) , (self.my_sink, 0))
  File
"/rand/platform/gnuradio-3.7.7.1/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 48, in wrapped
    raise ValueError("Unable to coerce endpoint")
ValueError: Unable to coerce endpoint


I understand the runtime complains that the (self.my_sink,0) port is not
defined (can not be coerced), and thus can't connect to the source
output port, though I assumed providing the appropriate input I/O
signature to the sink block's constructor should achieve its input
port's "registration".

Thanks again for your kind help.




------------------------------

Message: 24
Date: Mon, 3 Aug 2015 23:06:48 -0400
From: "West, Nathan" <address@hidden>
To: "Washbourne, Logan" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

You only have to use sudo with pybombs if you don't have write permission
to your prefix. In general it's best to avoid using sudo and pybombs
together if possible (with the exception of when pybombs asks you for sudo
password when using apt-get install).  You can either set the prefix to
somewhere your user normally has write access to (typically your home
directory), or alter permissions of your prefix. As an example, if you were
setting your prefix to /opt/gnuradio/pybombs-v3.7.8  the least obtrusive
way to do this is
    sudo mkdir -p /opt/gnuradio/pybombs-v3.7.8 # assuming your user doesn't
have write access to /opt/gnuradio you need sudo to mkdir
    sudo chown myusername:mygroupname /opt/gnuradio/pybombs-v3.7.8
    ./pybombs install gnuradio

In practice I usually make a group on my machines called 'developer' and
add my user to it, then give the developer group ownership or write access
(depends on what I feel like when I set up a new machine) to /opt. That
lets me write whatever to /opt without sudo (don't forget you need to login
after adding your user to group for it to take effect). The same principle
can be used with /usr/local or any other directory, but IMHO you should at
least make your work an extra layer deep so you can just rm -rf the whole
prefix (without root!) and not have much to worry about damaging.

Cheers,
Nathan

On Mon, Aug 3, 2015 at 9:15 PM, Washbourne, Logan <
address@hidden> wrote:

> Thanks Nathan. Should I have to use sudo when using pybomb commands, now
> that the installation prefix is outside of my home directory(because I now
> I have to use sudo when using pybomb commands)?
>
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
> On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan <address@hidden>
> wrote:
>
>> Logan,
>>
>> For your case deleting inventory.dat would do the trick of effectively
>> resetting pybombs state (and if your done with an install rm the prefix)
>>
>> Mike,
>>
>> Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
>> Radio. Try running pybombs again with -v -v
>>
>>
>> On Monday, August 3, 2015, <address@hidden> wrote:
>>
>>> Mike,
>>>
>>> When I ran into this problem, I had to reinstall pybombs. I think the
>>> problem lies in changing the installation prefix after installing pybombs.
>>>
>>> I'm sure there is another way to fix this, I just don't know what it is.
>>>
>>> When I reinstalled pybombs, I defined the installation prefix when the
>>> several prompts are asked at the beginning.
>>>
>>> Sent from my Cyanogen phone
>>>
>>> On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden> wrote:
>>> >
>>> > I use gentoo at home and have no difficulty keeping gnuradio up to
>>> date.
>>> >
>>> > At work we're on a standalone network (no internet) so occasionally
>>> bring computers home to update them.  Lately, I've been having trouble with
>>> pybombs.  Using a freshly installed ubuntu 15.04, then doing an
>>> >
>>> >   apt-get update
>>> >   apt-get upgrade [not sure the update was necessary]
>>> >
>>> > I first used
>>> >
>>> >   apt-get install gnuradio
>>> >
>>> > Thinking better of it, I ran
>>> >
>>> >   apt-get remove gnuradio
>>> >   apt-get autoremove
>>> >
>>> > Then went with pybombs
>>> >
>>> >   git clone git://github.com/pybombs/pybombs
>>> >   cd pybombs
>>> >   ./pybombs config [use install path /usr/local/gnuradio]
>>> >   ./pybombs install gnuradio
>>> >
>>> > And after several tries continue to receive this error:
>>> >
>>> > [...many lines of install...]
>>> > Unpacking liblog4cpp5-dev (1.0-4) ...
>>> > Setting up liblog4cpp5-dev (1.0-4) ...
>>> > installation ok via: deb
>>> > Installing from source: gnuradio
>>> > Cloning into 'gnuradio'...
>>> > Checking connectivity... done.
>>> > Cloning into 'volk'...
>>> > remote: Counting objects: 5450, done.
>>> > remote: Compressing objects: 100% (10/10), done.
>>> > remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
>>> > Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
>>> > Resolving deltas: 100% (3918/3918), done.
>>> > Checking connectivity... done.
>>> >
>>> >     CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>> -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
>>> >
>>> > Configuring: (100%)
>>> [==========================================================]
>>> > Configuration failed. Re-trying with higher verbosity.
>>> > make: *** No targets specified and no makefile found.  Stop.
>>> > Build failed. See output above for error messages.
>>> >
>>> > Any hints as to what is going wrong?
>>> >
>>> > Thanks,
>>> > Mike
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150803/15fab19a/attachment.html>

------------------------------

Message: 25
Date: Tue, 4 Aug 2015 09:31:28 +0200
From: Sylvain Munaut <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] GLError 1285
Message-ID:
        <CAHL+j0_i2CkD6eSRRYLBdZA9ydHBEZr0gfcJ7rm8qR=address@hidden>
Content-Type: text/plain; charset=UTF-8

Hi,

> Traceback (most recent call last):
>   File
> "/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
> line 209, in _on_paint
>     for fcn in self._draw_fcns: fcn[1]()
>   File
> "/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
> line 65, in draw
>     GL.glCallList(self._grid_compiled_list_id)
>   File "errorchecker.pyx", line 53, in
> OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError
> (src/errorchecker.c:1218)
> OpenGL.error.GLError: GLError(
>     err = 1285,
>     baseOperation = glCallList,
>     cArguments = (1L,)
> )
>
> After running for an hour or two.
>
> This is on F22, but on F20, there's no such issue.  So, it appears that
> there's a memory leak somewhere, but not sure where.

I'd suspect the driver ...

What hardware are they running this on ? (which GL driver)

Cheers,

   Sylvain



------------------------------

Message: 26
Date: Tue, 4 Aug 2015 12:36:07 +0500
From: bob wole <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] ControlPort 3.7.8rc1
Message-ID:
        <CAGd3OzzcSuvarMfsF-t=address@hidden>
Content-Type: text/plain; charset="utf-8"

Ubuntu 14.04 64-bit

I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
fetched gnuradio using

git clone --recursive https://github.com/gnuradio/gnuradio.git


 Gnuradio enabled component shows

* gr-ctrlport
* * thrift

However, I do not see any *gr-ctrlport directory *inside the gnuradio
directory. Where is the source code for control port? Also there are no
examples for using control port.

--
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/6f9b8d05/attachment.html>

------------------------------

Message: 27
Date: Tue, 4 Aug 2015 17:09:51 +0900
From: Jeon <address@hidden>
To: Discuss GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
Message-ID:
        <CACfn7v572B4TEpznsaFwjWa7oFC8jKB=address@hidden>
Content-Type: text/plain; charset="utf-8"

Dear Bob,

A few months ago, I've asked a similar question (
http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html)

and Tom gave me his paper in SIGCOMM.

Inspecting GNU Radio Applications with ControlPort and Performance Counters
Thomas Rondeau, Tim O?Shea, and Nathan Goergen

You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php

It does not fully describe how it can be used, though, through this you can
get a hint.

Regards,
Jeon.

2015-08-04 16:36 GMT+09:00 bob wole <address@hidden>:

> Ubuntu 14.04 64-bit
>
> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
> fetched gnuradio using
>
> git clone --recursive https://github.com/gnuradio/gnuradio.git
>
>
>  Gnuradio enabled component shows
>
> * gr-ctrlport
> * * thrift
>
> However, I do not see any *gr-ctrlport directory *inside the gnuradio
> directory. Where is the source code for control port? Also there are no
> examples for using control port.
>
> --
> Bob
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/3214d234/attachment.html>

------------------------------

Message: 28
Date: Tue, 4 Aug 2015 10:26:50 +0200
From: Volker Schroer <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

There is a directory
gnuradio-runtime/python/gnuradio/ctrlport


where you in controlport related stuff.

- - Volker

Am 04.08.2015 um 10:09 schrieb Jeon:
> Dear Bob,
>
> A few months ago, I've asked a similar question
> (http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html)
>
> and Tom gave me his paper in SIGCOMM.
>
> Inspecting GNU Radio Applications with ControlPort and Performance
> Counters
> Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>
> You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php
>
> It does not fully describe how it can be used, though, through this
> you can get a hint.
>
> Regards,
> Jeon.
>
> 2015-08-04 16:36 GMT+09:00 bob wole <address@hidden
> <mailto:address@hidden>>:
>
>     Ubuntu 14.04 64-bit
>
>     I just installed frest gnuradio 3.7.8rc1 with control port
>     enabled. I fetched gnuradio using
>
>     git clone --recursive https://github.com/gnuradio/gnuradio.git
>
>
>      Gnuradio enabled component shows
>
>     * gr-ctrlport
>     * * thrift
>
>     However, I do not see any *gr-ctrlport directory *inside the
>     gnuradio directory. Where is the source code for control port?
>     Also there are no examples for using control port.
>
>     --
>     Bob
>
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/2f409f7b/attachment.html>

------------------------------

Message: 29
Date: Tue, 4 Aug 2015 11:38:10 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] how to choose tune_delay?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

Hi Francois,

yes, N210 and later have timed commands abilities, which comes with the
feature of metadata containing time stamps; the GNU Radio USRP source is
able to evaluate that metadata coming from UHD, and adds stream tags at
the right position[1].

Greetings,
Marcus

[1]
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#a8ba918061af928ee7c01e7124580eb82

On 04.08.2015 03:21, fquitin wrote:
> Hi Marcus,
>
> Thanks for your comments, as usual, you're being a life-saver (I
> wasn't aware of the existence of set_command_time/clear_command_time
> functions, these will be immensely helpfull). From your suggestions, I
> understand that the USRP will always re-attach a rx_time tag after
> being re-tuned?
>
> Thanks,
> Francois
>
>
> On 03.08.2015 11:26, Marcus M?ller wrote:
>> Hi Francois,
>>
>>  yes, that seems rather high; but maybe you're seeing the effects of
>> the DC offset removal filter. You can try to use use
>> set_auto_dc_offset(False) to make that faster [1].
>>
>>  However, usrp_spectrum_sense is pretty old, and hence can't even make
>> use of stream tags on the GNU Radio side and timed commands on the
>> USRP side, so the lower boundary for delay is the two-way latency
>> between host and device -- which can easily be in the order of tens of
>> milliseconds.
>>
>>  I'd personally recommend just going ahead and reimplementing this:
>>  * Use the USRP source as usual
>>    * use set_time_now (if you don't have a time/PPS source),
>> set_start_time
>>    * issue two or three timed tuning commands right at the start
>> (set_command_time, set_rx_freq, clear_command_time)
>>  * write a python block that waits for rx_time tags (which
>> automatically get added by the USRP source nowadays)
>>   * that block would, upon detection of such a tag, issue "the next
>> tune request in line" (set_command_time(rx_time+delay), set_rx_freq,
>> clear_command_time)
>>   * that block would, after detection of such a tag, first discard a
>> few samples and then calculate your metrics based on the following N
>> samples
>>
>>  Best regards,
>>  Marcus
>>
>>  [1]
>> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
>>
>> [2]
>>
>> On 03.08.2015 11:11, Francois Quitin wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I want to retune the frequency of my USRP in Python during runtime.
>>> I understand from usrp_spectrum_sense.py that I can just retune the
>>> USRP during runtime, and that I need to allow for some tune_delay to
>>> make sure that the samples corresponding to the old center frequency
>>> are discarded.
>>>
>>>
>>>
>>> Is there any way to get a good estimate of tune_delay value? I want
>>> to keep this as short as possible? (btw I?m using a USRP-N210
>>> with WBX daughterboard) Some trial and error gave me values around
>>> 50ms, but this seems rather high compared to what I?ve read
>>> online.
>>>
>>>
>>>
>>> Any hints are welcome!
>>>
>>> Thanks,
>>>
>>> Francois
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
>>
>>
>>
>> Links:
>> ------
>> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> [2]
>> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




------------------------------

Message: 30
Date: Tue, 4 Aug 2015 15:12:29 +0300
From: Iluta V <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] pybombs with latest gnuradio 3.7.8.
        version
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

Would be nice to see the latest gnuradio version 3.7.8 also available on
pybombs. Currently there is 3.7.7.1-204 which I have just fetched from
there.

I would appreciate a response from anyone knowing more about it.

BR,

Iluta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/7d80c49d/attachment.html>

------------------------------

Message: 31
Date: Tue, 4 Aug 2015 08:19:16 -0400
From: "West, Nathan" <address@hidden>
To: Iluta V <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs with latest gnuradio 3.7.8.
        version
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

It hasn't been released yet. http://gnuradio.org/redmine/news/56

On Tuesday, August 4, 2015, Iluta V <address@hidden> wrote:

> Would be nice to see the latest gnuradio version 3.7.8 also available on
> pybombs. Currently there is 3.7.7.1-204 which I have just fetched from
> there.
>
> I would appreciate a response from anyone knowing more about it.
>
> BR,
>
> Iluta
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/3dd9cabe/attachment.html>

------------------------------

Message: 32
Date: Tue, 04 Aug 2015 14:43:59 +0200
From: Daniele Nicolodi <address@hidden>
To: GNURadio <address@hidden>
Subject: [Discuss-gnuradio] TX and RX synchronization to control
        latency
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

Hello,

the recommended way to control latency due to buffers both in software
and hardware is to synchronize the TX and RX streams, namely to have a
mechanism that emits samples only when samples are received, minus a
maximum latency.

My naive solution to implement that is this:

class synchronize(gr.hier_block2):
    def __init__(self, fs, delay):
        gr.hier_block2.__init__(self, self.__class__.__name__,
            gr.io_signature(2, 2, gr.sizeof_gr_complex),
            gr.io_signature(1, 1, gr.sizeof_gr_complex))

        delay = blocks.delay(gr.sizeof_gr_complex, int(fs * delay))
        multiply = blocks.multiply_const_cc(0)
        add = blocks.add_cc()
        self.connect((self, 0), (add, 0))
        self.connect((self, 1), delay, multiply, (add, 1))
        self.connect(add, self)

Which is simple enough, but also probably not the most efficient or
elegant way. There is a better way of doing it, other than writing a new
block, probably based on the delay block?

Cheers,
Daniele



------------------------------

Message: 33
Date: Tue, 4 Aug 2015 15:07:50 +0200
From: Simon Olvhammar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Strange behaviour
Message-ID:
        <CABcmisUKL=address@hidden>
Content-Type: text/plain; charset="utf-8"

Hi,

I'm seeing some strange behaviour in Gnuradio that i cannot explain.
Subtracting the same value from each other should return zero, If I'm not
mistaken. And why is there a dip in the center of my X310 stream? No signal
is connected to the USRP.

What am I missing?

Kind Regards
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/673c86c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: odd.png
Type: image/png
Size: 192033 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/673c86c3/attachment.png>

------------------------------

Message: 34
Date: Tue, 4 Aug 2015 15:21:15 +0200
From: Johannes Demel <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] Strange behaviour
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Simon,

I recommend using QT GUIs. WX GUI will be removed eventually.

'stream to streams' does not duplicate samples. In your case the first
sample goes to output 0 and the second sample goes to output 1.
<repeat pattern>

For AWGN you should observe another noise for in your FFT plot.

Your received signal is not a perfect AWGN signal. e.g. your dip is
probably some 1/f noise caused by some analog part in your USRP. Have
a look at the unprocessed samples form the USRP source.

happy hacking
Johannes

On 04.08.2015 15:07, Simon Olvhammar wrote:
> Hi,
>
> I'm seeing some strange behaviour in Gnuradio that i cannot
> explain. Subtracting the same value from each other should return
> zero, If I'm not mistaken. And why is there a dip in the center of
> my X310 stream? No signal is connected to the USRP.
>
> What am I missing?
>
> Kind Regards Simon
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVwLxLAAoJEO7fmkDsqywMVrwP/288Q8VoZT6jCe6IlZh26gZy
K7wfBEr0a5EpxjkPAE73ArI84WRzcrniiHT5nt5CMqX07nI3w6nCW63pwq8Xc4UU
0Ycw2YTo/r9x5IZvuhMEWyU1zmPmlpBLTcZquJZLmGY8pEKwJnzQQsJ+AyNjQs1V
C3cNnFJFW9h5wOBPJeO4G6eWNBET15E43+GxMZ3337AqVB9FTQEqiI/OstFKKZ7H
Q1zXtfVu5nqWmICtj42iF2DKGrNbz56NpIGsWCEjJIgg50k0nYYIYMfXaA2bgn/F
x/IAK+IEjAenK8zJtVAEoyGkEuRd4iPR0EObOYZWPgW4hKZtkBz3B6G2c95aM6PE
+r1oFAxPXsDaai+FtiGFJf+jbKoxe6B9wWVPi9GDBHbjBPDlO6sJJZBUE2fOPCQr
gfVx+lxbsAF6KMU1gjYyPTvDT7BvSXpJaSkR6smJrnexK4MupFJ7UAvNyS/PbWcN
DG2RMM76WYFvs2AjLfncwHlmBuvuLIMEFZDSEEklidnNFORkX2xeu+LIEEnAgEWt
uR4CapNeAOKq2HZ6f3o+HMJC/3goEzcCHRStcCak+RcDyweqq0DLE1bzcb5QVb+H
2mcaYb9lon/TLBdXo6xK0IPaAWrV1AaLektrrlRsrnDmE3zuOPNpJ0HxwF623S3c
BUjq/00BR3ct4Of7Tahf
=v33w
-----END PGP SIGNATURE-----



------------------------------

Message: 35
Date: Tue, 4 Aug 2015 09:25:59 -0500
From: "Washbourne, Logan" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] pybombs difficulty
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

So I changed the install prefix to /home/username/thesis/target and then
deleted the inventory.dat file and removed the previous install prefix
folder(this was usr/local, but it actually ended up in usr/local/share, I'm
thinking this was a problem because I think there are lingering files). I'm
having problems now, I can't remove or update any packages, it states that
there is not an inventory file so it creates an empty one and then states
there is nothing to do. Is there a way to have it generate a new inventory
file? I can't install any packages because they seem to still be in the
pybombs folder. Do you have any advice Nathan?

My initial reasoning for changing the install prefix to usr/local/ was to
enable me to create my own OOT modules and build the tutorial examples.
When pybomb's install prefix was in my home directory it kept throwing an
error about the CMake files. I tried to change the install prefix locations
within those CMake files but that didn't seem to fix my problems.

I'm really starting to learn that a little knowledge can be a pretty
dangerous thing haha.

I appreciate your time and help,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 3, 2015 at 10:06 PM, West, Nathan <address@hidden>
wrote:

> Password Alert! This message may contain a request for your password.
> NEVER SEND OR RESPOND TO E-MAIL REQUESTS FOR YOUR PASSWORD. For questions
> about this alert, please contact the IT HelpDesk at 405-744-4357 or email
> address@hidden.
> ------------------------------
> You only have to use sudo with pybombs if you don't have write permission
> to your prefix. In general it's best to avoid using sudo and pybombs
> together if possible (with the exception of when pybombs asks you for sudo
> password when using apt-get install).  You can either set the prefix to
> somewhere your user normally has write access to (typically your home
> directory), or alter permissions of your prefix. As an example, if you were
> setting your prefix to /opt/gnuradio/pybombs-v3.7.8  the least obtrusive
> way to do this is
>     sudo mkdir -p /opt/gnuradio/pybombs-v3.7.8 # assuming your user
> doesn't have write access to /opt/gnuradio you need sudo to mkdir
>     sudo chown myusername:mygroupname /opt/gnuradio/pybombs-v3.7.8
>     ./pybombs install gnuradio
>
> In practice I usually make a group on my machines called 'developer' and
> add my user to it, then give the developer group ownership or write access
> (depends on what I feel like when I set up a new machine) to /opt. That
> lets me write whatever to /opt without sudo (don't forget you need to login
> after adding your user to group for it to take effect). The same principle
> can be used with /usr/local or any other directory, but IMHO you should at
> least make your work an extra layer deep so you can just rm -rf the whole
> prefix (without root!) and not have much to worry about damaging.
>
> Cheers,
> Nathan
>
> On Mon, Aug 3, 2015 at 9:15 PM, Washbourne, Logan <
> address@hidden> wrote:
>
>> Thanks Nathan. Should I have to use sudo when using pybomb commands, now
>> that the installation prefix is outside of my home directory(because I now
>> I have to use sudo when using pybomb commands)?
>>
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan <address@hidden
>> > wrote:
>>
>>> Logan,
>>>
>>> For your case deleting inventory.dat would do the trick of effectively
>>> resetting pybombs state (and if your done with an install rm the prefix)
>>>
>>> Mike,
>>>
>>> Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
>>> Radio. Try running pybombs again with -v -v
>>>
>>>
>>> On Monday, August 3, 2015, <address@hidden> wrote:
>>>
>>>> Mike,
>>>>
>>>> When I ran into this problem, I had to reinstall pybombs. I think the
>>>> problem lies in changing the installation prefix after installing pybombs.
>>>>
>>>> I'm sure there is another way to fix this, I just don't know what it is.
>>>>
>>>> When I reinstalled pybombs, I defined the installation prefix when the
>>>> several prompts are asked at the beginning.
>>>>
>>>> Sent from my Cyanogen phone
>>>>
>>>> On Aug 3, 2015 4:39 PM, Mike Markowski <address@hidden> wrote:
>>>> >
>>>> > I use gentoo at home and have no difficulty keeping gnuradio up to
>>>> date.
>>>> >
>>>> > At work we're on a standalone network (no internet) so occasionally
>>>> bring computers home to update them.  Lately, I've been having trouble with
>>>> pybombs.  Using a freshly installed ubuntu 15.04, then doing an
>>>> >
>>>> >   apt-get update
>>>> >   apt-get upgrade [not sure the update was necessary]
>>>> >
>>>> > I first used
>>>> >
>>>> >   apt-get install gnuradio
>>>> >
>>>> > Thinking better of it, I ran
>>>> >
>>>> >   apt-get remove gnuradio
>>>> >   apt-get autoremove
>>>> >
>>>> > Then went with pybombs
>>>> >
>>>> >   git clone git://github.com/pybombs/pybombs
>>>> >   cd pybombs
>>>> >   ./pybombs config [use install path /usr/local/gnuradio]
>>>> >   ./pybombs install gnuradio
>>>> >
>>>> > And after several tries continue to receive this error:
>>>> >
>>>> > [...many lines of install...]
>>>> > Unpacking liblog4cpp5-dev (1.0-4) ...
>>>> > Setting up liblog4cpp5-dev (1.0-4) ...
>>>> > installation ok via: deb
>>>> > Installing from source: gnuradio
>>>> > Cloning into 'gnuradio'...
>>>> > Checking connectivity... done.
>>>> > Cloning into 'volk'...
>>>> > remote: Counting objects: 5450, done.
>>>> > remote: Compressing objects: 100% (10/10), done.
>>>> > remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
>>>> > Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
>>>> > Resolving deltas: 100% (3918/3918), done.
>>>> > Checking connectivity... done.
>>>> >
>>>> >     CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>>> -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
>>>> >
>>>> > Configuring: (100%)
>>>> [==========================================================]
>>>> > Configuration failed. Re-trying with higher verbosity.
>>>> > make: *** No targets specified and no makefile found.  Stop.
>>>> > Build failed. See output above for error messages.
>>>> >
>>>> > Any hints as to what is going wrong?
>>>> >
>>>> > Thanks,
>>>> > Mike
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150804/58a1f654/attachment.html>

------------------------------

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


End of Discuss-gnuradio Digest, Vol 153, Issue 8
************************************************

ISDBT Experiment Edited.jpg
Description: JPEG image