Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Garver, Paul W]

Yes, gr-pwg is the OOT module.


nm on libpwg.so yields:


 nm libgnuradio-pwg.so | grep -i 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_
 U 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_

It is undefined in libgnuradio-pwg, but libgnuradio-pwg links with 
libgnuradio-trellis, which provides the implementation as we saw before. I 
don't see an issue with this. What am I missing?

In lib/, the target_link_libraries looks like:
target_link_libraries(gnuradio-pwg ${Boost_LIBRARIES} ${GNURADIO_ALL_LIBRARIES})

GNURADIO_ALL_LIBRARIES=/usr/local/lib/libgnuradio-runtime.so/usr/local/lib/libgnuradio-pmt.so/usr/local/lib/libgnuradio-digital.so/usr/local/lib/libgnuradio-trellis.so

It does appear that GR_REQUIRED_COMPONENTS is properly updating cmake since 
gr-trellis lib is in the directive.

I grep'd through the entire gnuradio source tree and I can't find another 
instance (except gr-trellis in the viterbi_algorithm_combined blocks) calling 
viterbi_algorithm_combined().

Thanks for the suggestions. Still trying to track this one down; it has been 
very elusive!
PWG



From: Discuss-gnuradio  on 
behalf of Marcus Müller 
Sent: Monday, November 14, 2016 5:16:13 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on 
OSX, fails on Linux)

Good spotting, Cinaed!

judging from his initials, I'd guess gr-pwg is Paul's OOT module. Point
is that libgnuradio-pwg contains a reference to, but no implementation
of, the missing symbol, which is
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_

or to put it more "readable" (ha, ha.) in C++ terms:

void gr::trellis::viterbi_algorithm_combined(int, int, 
int, std::vector const&, std::vector const&, std::vector, std::allocator > > const&, 
std::vector, 
std::allocator > > const&, int, int, 
int, int, std::vector const&, 
gr::digital::trellis_metric_type_t, float const*, unsigned char*)

or omitting standard template arguments and trying to format things:

void
gr::trellis::viterbi_algorithm_combined  (
int,
int,
int,
std::vector const&,
std::vector const&,
std::vector< std::vector > const&,
std::vector< std::vector > const&,
int,
int,
int,
int,
std::vector const&,
gr::digital::trellis_metric_type_t,
float const*,
unsigned char*)


Anyway, the question is why linking doesn't look like it should.
Just to get this out of the way: Paul, what does your
lib/CMakeLists.txt's "target_link_libraries" directive look like, exactly?

Best regards,
Marcus

On 14.11.2016 22:38, Cinaed Simson wrote:
> On 11/14/2016 06:34 AM, Garver, Paul W wrote:
>> objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0
> Isn't this a different library from the previous error message, namely
>
>> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0:
> undefined symbol:
>
> On Linux, I don't have the library libgnuradio-pwg - should I?
>
> I have libgnuradio-trellis.
>
> -- Cinaed
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] How to generate digital modulated signal using USRP B200mini on Android?

[Charlie Von]

Hello everyone,

Could I spare a few minutes to consult more questions? I would be greatly 
appreciated if you can reply them.



The important question is how to generate digital modulated signal using USRP 
B200mini on Android.



My teammate and I have already realize the function of receive data from USRP 
B200mini on Android based on Mr. Tom Rondeau's instruction on 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Android



Recently we studied how to generate digital modulated signal via Android NDK 
using USRP B200mini connected with Android mobile.

We followed an example which from Mr. Tom Rondeau's ppt（An Approach to Digital 
Demodulation  http://www.trondeau.com/） to create a flowgraph on GRC. The 
flowgraph contains four main blocks: Random Source,PSK Mod,Multiply Const and 
UHD USRP Sink. We can find the corresponding the header files of Random Source 
Multiply Const and UHD USRP Sink.  But we could not find the corresponding the 
header file of PSK Mod. We are confused about this.If we can find out all 
the header files, then we can connect all the block's pointer to create a 
flowgraph in Android NDK.



Thank you so much!



Sincerely Charlie



2016 1115


发送自 Windows 10 版邮件应用

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

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Marcus Müller]

Good spotting, Cinaed!

judging from his initials, I'd guess gr-pwg is Paul's OOT module. Point
is that libgnuradio-pwg contains a reference to, but no implementation
of, the missing symbol, which is
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_

or to put it more "readable" (ha, ha.) in C++ terms:

void gr::trellis::viterbi_algorithm_combined(int, int, 
int, std::vector const&, std::vector const&, std::vector, std::allocator > > const&, 
std::vector, 
std::allocator > > const&, int, int, 
int, int, std::vector const&, 
gr::digital::trellis_metric_type_t, float const*, unsigned char*) 

or omitting standard template arguments and trying to format things:

void
gr::trellis::viterbi_algorithm_combined  (
int,
int,
int,
std::vector const&,
std::vector const&,
std::vector< std::vector > const&,
std::vector< std::vector > const&,
int,
int,
int,
int,
std::vector const&,
gr::digital::trellis_metric_type_t,
float const*,
unsigned char*) 


Anyway, the question is why linking doesn't look like it should.
Just to get this out of the way: Paul, what does your
lib/CMakeLists.txt's "target_link_libraries" directive look like, exactly?

Best regards,
Marcus

On 14.11.2016 22:38, Cinaed Simson wrote:
> On 11/14/2016 06:34 AM, Garver, Paul W wrote:
>> objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0
> Isn't this a different library from the previous error message, namely
>
>> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0:
> undefined symbol:
>
> On Linux, I don't have the library libgnuradio-pwg - should I?
>
> I have libgnuradio-trellis.
>
> -- Cinaed
>
> ___
> 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] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Cinaed Simson]

On 11/14/2016 06:34 AM, Garver, Paul W wrote:
> objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0

Isn't this a different library from the previous error message, namely

> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0:
undefined symbol:

On Linux, I don't have the library libgnuradio-pwg - should I?

I have libgnuradio-trellis.

-- Cinaed

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

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Fons Adriaensen]

On Mon, Nov 14, 2016 at 04:59:24PM +, Benny Alexandar wrote:

> I have some questions regarding it.
> How many blocks of audio the internal buffer  need to store ?

Enough to keep feeding samples to the audio HW until the sink's 
work() is called again. 

> When does the copy from gr buffer to internal buffer happens ? Is it
> during the audio hardware driver call back or during gr scheduling
> the audio sink ?

When gr calls the sink's work().

> Before copying to the internal buffer the audio block has to be played
> to prevent overwrite of data. In a way it has to do the same check
> what the gr buffers do, space is available to copy etc.

The sink's work() will block until all input data is transferred
to the internal buffer.

> Why not handle this with gr buffer ? Audio sink can query the
> available data in its input queue.

I don't understand what exactly you mean. If you mean that the
internal buffer isn't needed and that the gr buffer can take 
its role, that's not going to work. 
 
> I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
> ( The thin (blue) line is the exact mapping we want. Note
> that in this example the real sample frequency is
> slightly lower that the nominal — the thin line
> is lagging the grid as time advances.)
> 
> In an ideal case the thin blue line should intersect all the grid points.
> Why the real sample frequency is slightly lower than nominal ?
 
It's just an example, illustrating what happens in that case.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)


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

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons,

Thanks for the detailed explanation.

I have some questions regarding it.
How many blocks of audio the internal buffer  need to store ?
When does the copy from gr buffer to internal buffer happens ? Is it
during the audio hardware driver call back or during gr scheduling the
audio sink ?
Before copying to the internal buffer the audio block has to be played
to prevent overwrite of data. In a way it has to do the same check
what the gr buffers do, space is available to copy etc.
Why not handle this with gr buffer ? Audio sink can query the
available data in its input queue.

I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
( The thin (blue) line is the exact mapping we want. Note
that in this example the real sample frequency is
slightly lower that the nominal — the thin line
is lagging the grid as time advances.)

In an ideal case the thin blue line should intersect all the grid points.
Why the real sample frequency is slightly lower than nominal ?

-ben



From: Fons Adriaensen 
Sent: Sunday, November 13, 2016 9:47:48 PM
To: Benny Alexandar
Cc: Marcus Müller; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Sun, Nov 13, 2016 at 02:46:57PM +, Benny Alexandar wrote:

[ Please use the  key to limit the lenght of your text lines ]

> Only the receiver has to measure the drift and adjust to the incoming
> rate.
> ...
> So my problem is how to measure the ppm drift using timestamps from
> only the audio sink

You do not need to measure the rate error, at least not explicitly.
That is not how it works.

There will be some buffer between whatever provides the audio stream
(receiver, network, ...) and whatever consumes it (resampler or hardware
with adjustable sample rate).

If the rates are matched, then the *average* number of samples in that
buffer will be constant. Whenever it is greater than some target value
you increase the hardware sample rate. When it is lower you decrease
the hardware sample rate.

So the remaining problem is to find the average number of samples in
the buffer (and not to measure the 'ppm drift').

This is done by timing both the arrival and consumption of samples,
i.e. the write and read operations to the buffer. For each block
that is written or read, you mark the time 't' (using the same clock
for both) and you also keep a sample count 'k'. So on both ends you
have a series of (t, k),  These provide a piecewise-linear function
k(t), mapping 't' to 'k'. A DLL is used to ensure this is a smooth
function (in other words, one that is stays close to a straight line).

Then the average number of samples is the difference of these two
functions evaluated at the same time. This is compared to the target
value and the smoothed difference is used to adjust the hardware
sample rate. Note that this is a feedback system, and you need to
ensure stability.

That's it, I don't think I can explain it more clearly.

Ciao,

--
FA


A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

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

[Discuss-gnuradio] Reg : Buffers in GNU Radio based receivers

[sumitstop]

Hello, 

I was wondering how GNU Radio implements receive buffer while receiving the
data from an SDR. 

Is it like a very long circular buffer. The UHD thread starts filling the
buffer from one end, meanwhile the receiver thread also starts processing
it.

The time when UHD thread reaches the end of circular buffer, it starts
writing again from the start of buffer. 

Could anyone explain how it actually happens in GNU Radio or in general for
any receiver ? 

Context : I am developing a Wifi receiver. It works pretty good in
simulation, but during real-time operation, it is missing the preambles most
of the times. I suspect because the preamble is gets spitted between the
short packets which UHD is putting into my buffer. 

*Apology if the post doesn't pertain to the mailing list :) 

Regards

Sumit  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Reg-Buffers-in-GNU-Radio-based-receivers-tp62008.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Garver, Paul W]

 Here's the result. I think the answer is "yes", but will need to read up on 
objdump output format.

objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0  | grep 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_

Returns:
00060aa0 l F .text 0775  
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_




From: Sylvain Munaut <246...@gmail.com>
Sent: Monday, November 14, 2016 9:28:53 AM
To: Garver, Paul W
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on 
OSX, fails on Linux)

> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0: undefined
> symbol:
> _ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_
>


If you check with objdump, is that symbol indeed in that lib ?


objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0  |
grep 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_


Cheers,

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

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Sylvain Munaut]

> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0: undefined
> symbol:
> _ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_
>


If you check with objdump, is that symbol indeed in that lib ?


objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0  |
grep 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_


Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Garver, Paul W]

Hi Sylvain,


Thanks for the debugging tip. With those changes, I get:


>>> import pwg
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pwg/__init__.py", line 32, in 

from pwg_swig import *
  File "/usr/local/lib/python2.7/dist-packages/pwg/pwg_swig.py", line 28, in 

_pwg_swig = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/pwg/pwg_swig.py", line 24, in 
swig_import_helper
_mod = imp.load_module('_pwg_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0: undefined 
symbol: 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_

This appears to be a linking error related to gr-trellis. It leads me to 
believe that simply adding TRELLIS to GR_REQUIRED_COMPONENTS in the OOT 
module's root CMake may not be sufficient. Somehow OSX and Clang handle this 
differently.


But an ldd on the OOT module's library clearly show gr-trellis is linked.


linux-vdso.so.1 =>  (0x7ffe5437b000)
libboost_system.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.55.0 (0x7f5df3fa)
libgnuradio-runtime-3.7.11git.so.0.0.0 => 
/usr/local/lib/libgnuradio-runtime-3.7.11git.so.0.0.0 (0x7f5df3cae000)
libgnuradio-pmt-3.7.11git.so.0.0.0 => 
/usr/local/lib/libgnuradio-pmt-3.7.11git.so.0.0.0 (0x7f5df3a5b000)
libgnuradio-trellis-3.7.11git.so.0.0.0 => 
/usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0 (0x7f5df379d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f5df348e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f5df3277000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5df2ead000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5df2c8f000)
libvolk.so.1.3 => /usr/local/lib/libvolk.so.1.3 (0x7f5df27cf000)
libboost_program_options.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.55.0 
(0x7f5df2559000)
libboost_filesystem.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.55.0 (0x7f5df2341000)
libboost_thread.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0 (0x7f5df2126000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7f5df1ee6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5df1cde000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5df19d5000)
/lib64/ld-linux-x86-64.so.2 (0x7f5df43df000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f5df17bb000)




From: Sylvain Munaut <246...@gmail.com>
Sent: Sunday, November 13, 2016 11:26:20 AM
To: Garver, Paul W
Cc: Cinaed Simson; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on 
OSX, fails on Linux)

Little tip in general:

in the python/  directory, look at the __init__.py file and remove the
try / except around the "from xxx_swig import *".

This will then actually _print_ the error preventing the SWIG import ...

Cheers,

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

Re: [Discuss-gnuradio] GNU Radio Tutorial Example Doesn't Work

[Marcus Müller]

Hi Gilad,

find something that actually produces a singing sine attached. Notice
that the waterfall sink display isn't "perfect" by means of being a
constant-height zig-zag line. But that was never to be expected – the
DFT simply produces higher amplitudes at frequencies that are actually
exactly "hit" by the signal, and since the signal frequency changes
continously, this can't be always the case.

I don't think I can salvage the example – it's really an illustration of
what not to do with a signal probe; if you want one signal to somehow
modulate the other, you'd always (and that's the whole idea behind GR)
combine the two sample streams, and not employ some inaccurate, hackish
python-function-probing mechanism. So please don't take the example from
the wiki as guideline for building modulators!

Best regards,
Marcus

On 14.11.2016 13:23, Marcus Müller wrote:
>
> Hi Gilad,
>
> yes, that's now my new not-favourite example, because it uses a signal
> probe where it shouldn't be using a signal probe. You're right, this
> *cannot* work reliably. (to explain: GNU Radio blocks always run as
> fast as possible. For example, the the signal probe just drops the
> signal as fast as possible, but "writes down" the last value every
> iteration; thus, the triangle-generating signal source runs as fast as
> it can, and probably produces 10s of millions of samples per second.
> Thus, the value seen by the function probe every roughly so and so
> many milliseconds is absolutely random. I wonder under which
> conditions this flowgraph used to work; in theory, we've tested them
> all :) ooops)
>
> I'll fix the example and let you know as soon as I have something
> better for you :)
>
> Best regards,
>
> Marcus
>
> On 14.11.2016 06:03, Gilad Beeri (ApolloShield) wrote:
>> Hi,
>> Going over tutorial
>> 2 http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC,
>> trying the last example (a triangle wave, prove signal and a sine
>> wave), which based on common sense and the image in the tutorial,
>> should result in a periodic triangle shape in the waterfall scope.
>>
>> I get a completely different result, see image attached.
>> My flowgraph seems to be accurate, also when running
>> tutorial_two_7.grc from the examples I get the same result.
>>
>> GNU Radio 3.7.10.1, mac OS 10.12.1.
>>
>> Do you have an idea why I don't get the expected shape?
>>
>> This is the image from the
>> tutorial: 
>> https://raw.githubusercontent.com/gnuradio/gr-tutorial/master/examples/tutorial2/images/singing_waterfall.png
>>
>> This is what I get (when running the example, not my own flowgraph):
>> pasted1
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



singing sine.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Tutorial Example Doesn't Work

[Marcus Müller]

Hi Gilad,

yes, that's now my new not-favourite example, because it uses a signal
probe where it shouldn't be using a signal probe. You're right, this
*cannot* work reliably. (to explain: GNU Radio blocks always run as fast
as possible. For example, the the signal probe just drops the signal as
fast as possible, but "writes down" the last value every iteration;
thus, the triangle-generating signal source runs as fast as it can, and
probably produces 10s of millions of samples per second. Thus, the value
seen by the function probe every roughly so and so many milliseconds is
absolutely random. I wonder under which conditions this flowgraph used
to work; in theory, we've tested them all :) ooops)

I'll fix the example and let you know as soon as I have something better
for you :)

Best regards,

Marcus

On 14.11.2016 06:03, Gilad Beeri (ApolloShield) wrote:
> Hi,
> Going over tutorial
> 2 http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC,
> trying the last example (a triangle wave, prove signal and a sine
> wave), which based on common sense and the image in the tutorial,
> should result in a periodic triangle shape in the waterfall scope.
>
> I get a completely different result, see image attached.
> My flowgraph seems to be accurate, also when running
> tutorial_two_7.grc from the examples I get the same result.
>
> GNU Radio 3.7.10.1, mac OS 10.12.1.
>
> Do you have an idea why I don't get the expected shape?
>
> This is the image from the
> tutorial: 
> https://raw.githubusercontent.com/gnuradio/gr-tutorial/master/examples/tutorial2/images/singing_waterfall.png
>
> This is what I get (when running the example, not my own flowgraph):
> pasted1
>
>
> ___
> 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