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 th
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(),
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 th
The other interesting thing is that dir() on the module returns practically
nothing.
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__']
However, the functions are there in the modulename_swig.py script, and symbols
related to the functions can be found with nm on _
Hi Michael,
Thanks for the tip. I've done this to no avail. Is there a way to get some more
useful error output? Seems like a SWIG thing, and I don't know too much about
how it works other than it wraps c/c++ functions.
Paul Garver
> On Nov 12, 2016, at 4:48 PM, Michael Dickens wrote:
>
>
Hi Paul - You are correct that adding "DIGITAL" as you write should add
that component in for headers and library linking. Did you clean the
build directory after changing this setting? Sometimes CMake won't redo
the linkage internally, and one just has to "rm -rf" the whole build
directory and sta
Hello again,
sorry for that i just saw some views and hoped for a response . I totally
understand your point and hope there is gonna be someone that is more into
GnuRadio companion than me.
However since i spent some time on more research I got into stuff there:
-not sure what kind of data type i
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
This can also happen if the OOT isn't linked properly. That is, some
necessary library is missing.
Ron
On 11/12/2016 09:42 AM, Tom Early wrote:
Yes Nicolas, thanks. I did do that.
I have still been working on it and still haven't solved it.
On 11/12/2016 11:10 AM, Nicolas Cuervo wrote:
Hi
Yes Nicolas, thanks. I did do that.
I have still been working on it and still haven't solved it.
On 11/12/2016 11:10 AM, Nicolas Cuervo wrote:
Hi Tom,
Did you, after you install your OOT module, run the following in your
terminal?:
sudo ldconfig
Cheers,
- Nicolas
On Fri, Nov 11, 201
Adrian
Don't bump your own thread within a couple of hours. Noone here is getting paid
to react to email during the weekend within hours. Your project is complex, and
the fact that you'll need to wait half a day or two for a qualified answer
hopefully won't devastate your timeline.
GNU Radio is
Hi Adrian,
in gr-trellis/examples/grc
there are two examples of a sccc and a pccc
best,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Tom,
Did you, after you install your OOT module, run the following in your
terminal?:
sudo ldconfig
Cheers,
- Nicolas
On Fri, Nov 11, 2016 at 9:43 PM, Tom Early wrote:
> Sorry, me again.
>
> Recently did a fresh install of ubuntu 16.10 and did a apt install of
> gnuradio.
>
> A few da
On Mon, Nov 07, 2016 at 12:48:18AM +0100, Marcus Müller wrote:
> Well it doesn't have any negative effect, and it allows you to just
> return the number of items you consumed (sink) or produced (source), and
> you write a work() instead of a general_work(), so that's why we do it.
Good news: I've
Anyone ?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Building-simulation-of-basic-turbo-code-tp61978p61982.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Sat, Nov 12, 2016 at 01:41:40PM +, Benny Alexandar wrote:
> Yes, but the input rate cannot be measured,
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.
> But the codec can use the time stamp of the input
Thanks Ben for the answer.
Regarding the last question, I want to clarify a bit what I meant.
Regular polyphase channelizer have oversample_rate option that lets you
set oversampling so you can get output sample rates:
input_samp_rate/number_of_channels * oversample_rate
where oversample_rate =
Hi Fons,
>> codec -> [ buffer -> resampler ] -> audio HW.
>>where [...] is the audio sink block. The buffer is *an internal part*
>>of the audio sink, and *not* the one that gr provides to connect codec
>>and audio sink.
So, there is an internal buffer in audio sink, which should at least be
Hello there,
I'm new GnuRadioCompanion user as my engineering project consists of turbo
codes description and their performance in simulation. My main concern is
that i've got no idea how to build such thing here and i would like to ask
for some help.
Since i've done some research list of things t
Hi,
>> Once you authorize someone to use sudo, he _is_root for all intents
>> and purposes, you realize that right ?
>
> In general that's not true, you can just allow some specific
> commands via sudo.
True, but "allow specific commands" is _really_ hard if you don't
understand _everything_ abo
On Sat, Nov 12, 2016 at 07:27:04AM +0100, Sylvain Munaut wrote:
> Once you authorize someone to use sudo, he _is_root for all intents
> and purposes, you realize that right ?
In general that's not true, you can just allow some specific
commands via sudo.
But of course, in this case it's true si
21 matches
Mail list logo
