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

[Gilad Beeri (ApolloShield)]

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):
[image: pasted1]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building simulation of basic turbo code

[Achilleas Anastasopoulos]

Adrian,

your scattered questions indicate you have a long way to go before you can
do anything useful with gnuradio on your own.

I suggest you "study" these examples carefully: you'll discover that many
people have put a lot of time and love into this and have provided
documentation to answer most if not all your questions.
Try to read the documentation of gr-trellis explaining how you can build
any arbitrary fsm.
Then read the documentation and code for the siso modules.
Then read the documentation and code for sccc/pccc etc.
As the folder name suggests these are only EXAMPLES but this is also open
source so all the code is there for you to read/change.

If the documentation does not answer your questions then please post a
specific question on the list. Even better, provide your own grc draft
design so people can comment on something concrete.
I am willing to help you with gr-trellis if you decide to take it seriously.

best
Achilleas
___
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]

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] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Fons Adriaensen]

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

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

[Benny Alexandar]

>>It can, even if the data stream has irregular timing. That's why there
>>is a DLL there. See the links posted before for how it works.

Suppose if I have an audio hardware where I can set the ppm drift and the 
hardware adjusts the sampling frequency based on the ppm drift, then no need of 
the resampler and delay caused by resampler, but I need to measure the ppm 
drift. I was reading your paper on adaptive resampling. For example in case of 
broadcast receiver there is no feedback path from transmitter or any other 
sources. 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 and do I need the DLL if my hardware supports programing the ppm 
for adjusting the sampling frequency ? I can adjust it after every block of 
audio samples being rendered, which may be too frequent, instead average over 
few seconds and adjust it.

-ben


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

Mac setup has v3.0.10. I upgraded on the Linux setup from 3.0.8, but it didn't 
make a difference. Good thought, though. 

My intuition is saying it is something with the fact that the viterbi call is a 
templated function. Either I'm not calling it quite right or SWIG isn't 
wrapping it correctly. 

Paul Garver


> On Nov 12, 2016, at 10:17 PM, Cinaed Simson  wrote:
> 
> Maybe the version of swig?
> 
> On Debian Jessie, it's
> 
>  swig2.0 -version
> 
> which generates
> 
>  SWIG Version 2.0.12
> 
> -- Cinaed
> 
> 
>> On 11/12/2016 06:47 PM, Garver, Paul W wrote:
>> I've isolated the issue further. I have a viterbi_algorithm_combined()
>> call [1] in a work function in one of the blocks in the OOT module.
>> Here's the snippet.
>> 
>> 
>> // Call Viterbi decoder on the input
>> 
>> trellis::viterbi_algorithm_combined(d_fsm->I(),d_fsm->S(),d_fsm->O(),
>> 
>> d_fsm->NS(),d_fsm->OS(),d_fsm->PS(),d_fsm->PI(),22,-1,-1,8,
>> 
>> d_constellation,digital::TRELLIS_EUCLIDEAN,soft_decisions,&(bits[0]));
>> 
>> If I comment this out, all functions show up as expected in the python
>> module. With the function, none of the SWIG wrappers appear. BUT, OSX
>> has no problem with it. Strange! I don't know if SWIG is mangling this
>> because it is a template function or if it is something totally different.
>> 
>> Here are the two setups:
>> 
>> "Linux Setup"
>> OS: Ubuntu 16.04.1 LTS
>> GR: v3.7.10.1-144-g7b0dfd80
>> 
>> g++ 5.4.0
>> 
>> 
>> "Mac Setup"
>> 
>> OS: OSX 10.10.4
>> 
>> GR: v3.7-MacPorts-devel-git-e10637b(20160809)
>> 
>> clang --version Apple LLVM version 6.1.0 (clang-602.0.53)
>> 
>> 
>> Not sure what other details are relevant. Anyone have any ideas?
>> 
>> 
>> 
>> 
>> 
>> [1]
>> http://gnuradio.org/doc/doxygen/namespacegr_1_1trellis.html#aac3ff175700850a652cf80fb44b436eb
>> 
>> 
>> 
>> 
>> *From:* Discuss-gnuradio
>>  on behalf of
>> Daniel P. Martin 
>> *Sent:* Saturday, November 12, 2016 9:27 PM
>> *To:* discuss-gnuradio@gnu.org
>> *Subject:* Re: [Discuss-gnuradio] Linking gr-digital in OOT Module
>> (Success on OSX, fails on Linux)
>> 
>> Just today I had a problem like this in an OOT module on Ubuntu. I'd
>> added a callback method to allow gnuradio-companion to set a changed
>> parameter. I'm not sure if this is the way it's supposed to work, but I
>> had to go back to the build directory and do a "cmake ../" to get swig
>> to discover the change and build a python wrapper for the method. So:
>> make clean, cmake ../, make, sudo make install, sudo ldconfig. Good luck!
>> 
>> Dan
>> 
>> 
>>> On 11/12/16 2:55 PM, Garver, Paul W wrote:
>>> I’ve got an out-of-tree module which uses gr-trellis and gr-digital. In the 
>>> root OOT module directory’s CMakeLists.txt I’ve added:
>>> 
>>> set(GR_REQUIRED_COMPONENTS RUNTIME TRELLIS DIGITAL)
>>> 
>>> I’ve got a Mac OS X and Linux setup. On the MAC setup ( GR 
>>> v3.7-MacPorts-devel-git-e106376b(20160809)), the OOT module compiles and 
>>> executes as expected. However, on the Linux setup (GR 
>>> v3.7.10.1-144-g7b0dfd80) I get the "AttributeError:’module’ object has no 
>>> attribute” error.
>>> 
>>> Running a Python session on Linux, importing the OOT module, and doing 
>>> dir() yields none of the functions in the OOT module.
>>> 
>>> The odd thing is that the OS X compilation is clearly linking 
>>> libgnuradio-digital as found by
>>> # otool -L
>>> 
>>> BUT using ldd on the Linux compiled version does NOT show linking to 
>>> libgnuradio-digital
>>> 
>>> I’m thinking that not linking gr-digital is causing this issue. It is the 
>>> exact same code. My understanding is that adding DIGITAL as shown above is 
>>> sufficient for correct linkage, but it isn’t linking in Linux. Is there any 
>>> reason I would need to explicitly add the digital library to CMakeLists in 
>>> lib/?
>>> 
>>> PWG
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> -- 
>> Dr. Daniel Martin
>> Acadia Controls, LLC
>> 110 Gateway Commons Dr
>> Gorham, ME
>> 207 838-6465 mobile
>> 207 839-6303 fax, office
>> www.acadiacontrols.com 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> Discuss-gnuradio Info Page - lists.gnu.org
>> 
>> lists.gnu.org
>> To see the collection of prior postings to the list, visit the
>> Discuss-gnuradio Archives. Using Discuss-gnuradio: To post a message to
>> all the list ...
>> 
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>>