gr-fosphor depends on libpng 1.6, here's a diff to update the png
recipe. before i update it and break something, here's your chance to
test and discuss.
diff --git a/libpng.lwr b/libpng.lwr
index f986478..4489dac 100644
--- a/libpng.lwr
+++ b/libpng.lwr
@@ -19,7 +19,7 @@
category: baseline
dep
On Wed, Nov 11, 2015 at 8:32 AM, Stefan Wunsch <
stefan.wun...@student.kit.edu> wrote:
> Aaaah I solved it. Never ever write in a VOLK kernel to your input
> buffer! This throws no errors but it fails during the ctest. So I
> suppose the first test compares the output and the second one the input
On Wed, Nov 11, 2015 at 4:40 PM, Johnathan Corgan
wrote:
> On Wed, Nov 11, 2015 at 10:47 AM, Martin Braun
> wrote:
>
>
>> Since you're not the copyright holder of the original code, you have no
>> way of transferring said copyright to the FSF.
>>
>> I'm not sure what the correct way to do this i
On Wed, 11 Nov 2015 13:42:35 -0800
Johnathan Corgan wrote:
> On Wed, Nov 11, 2015 at 6:07 AM, Frederick E. Stevens > wrote:
>
>
> > As I recall, this behavior has cropped up in 3.6 and 3.7 of gnuradio for
> > me but it wasn't much of an issue at the time.
> >
This afternoon, I had some time t
On Wed, Nov 11, 2015 at 6:07 AM, Frederick E. Stevens wrote:
> As I recall, this behavior has cropped up in 3.6 and 3.7 of gnuradio for
> me but it wasn't much of an issue at the time.
>
It turns out this is a long-standing bug in GRC that has been around since
its inception. Sebastian has fix
On Wed, Nov 11, 2015 at 10:47 AM, Martin Braun
wrote:
> Since you're not the copyright holder of the original code, you have no
> way of transferring said copyright to the FSF.
>
> I'm not sure what the correct way to do this is. An out-of-tree approach
> will definitely work, since the licenses
On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell
wrote:
> John, did you mean this four step process, otherwise stop before wait
> doesn't let anything happen:
>
> tb.start()
> tb.wait()
> tb.stop()
> tb.wait()
>
> Like that? If so, why don't the auto-generated top_blocks have to do that?
>
To cla
Well, you could simply use a FSK receiver, and send a specific sequence
of symbols for 1 and the inverse sequence for 0, and just correlate
against that sequence.
Best regards,
Marcus
On 11/11/2015 09:41 PM, abhinav narain wrote:
> Hi Marcus,
>
>
> So, maybe we should take a step back
Hi Marcus,
>
> So, maybe we should take a step back and ask: *what* is the *data* you're
> trying to transmit? Transmitting a single bit at a time sounds so unlikely.
>
> You are right, my research requires the exact thing - to transmit a single
bit sparingly as it is unlikely to think that was a
The point is that what you're effectively doing is using the front 11 as
a kind of preamble, and 01 or 10 being the symbol you send.
That doesn't sound like much. To be honest, PPM in an environment like
that without lots of redundancy simply sounds unstable -- you just miss
one of your preamble sy
Hi Stefan,
great work! As Martin said, the copyright is the actual issue. Have you
tried to contact the authors? The fact that they seem to be working at a
university rather than a company is at least promising.
Cheers
Andre
On 11.11.2015 19:47, Martin Braun wrote:
> Stefan,
>
> **THIS IS N
Hi Marcus,
Will be really great if you could look at the last part of my mail.
My specific questions is -
Lets say I transmit two PPM frames... 1100 and 1101
say: *1100**1101*
The number of non-bold zeros are what I am filling in between the
information frames at transmitter.
But at receiv
John, did you mean this four step process, otherwise stop before wait
doesn't let anything happen:
tb.start()
tb.wait()
tb.stop()
tb.wait()
Like that? If so, why don't the auto-generated top_blocks have to do that?
Rich
On Tue, Nov 10, 2015 at 7:24 PM, Johnathan Corgan
wrote:
> tb.stop(), the
Stefan,
**THIS IS NOT LEGAL ADVICE ETC.
the license isn't the issue, but the copyright. Code that goes into GNU
Radio is copyrighted by the FSF (that's why you signed that CLA). This
is becoming a more and more common thing, btw, see the recent
discussions on the LLVM project.
Since
On 11.11.2015 01:14, w xd wrote:
> I have look at the api, and find 4 class about the ofdm equalizer，
>
> ofdm_equalizer_1d_pilots,
> ofdm_equalizer_base,ofdm_equalizer_simpledfe,ofdm_equalizer_static.
These are different implementations, and are dropped into the actual
equalizer block (a
Hi Nathan,
> I think it's more of a testament to how good Intel (and modern)
> processors are at branching.
wow!
> An adventurous soul is welcome to try putting that table lookup in to
> an avx2 protokernel with the new gather instructions.
I am adventurous, but that sounds like a hard beer, since
Hi,
I'm running modified Slackware64-14.1 on my laptops and desktop
computers. I just built 3.7.8.1 using the gnuradio.SlackBuild provided
by slackbuilds.org. I am observing the same behavior on all my
machines. One is intel based and the other two are AMD64 based. I have
not upgraded gcc
Hi!
I have implemented a SIMD accelerated Mersenne-Twister as a VOLK kernel.
The performance is pretty good with up to 350% performance increase
compared to a conventional Mersenne-Twister (used is the boost.random
implementation with O3 compiler flag).
Now the problem: The code isn't completely
Aaaah I solved it. Never ever write in a VOLK kernel to your input
buffer! This throws no errors but it fails during the ctest. So I
suppose the first test compares the output and the second one the input
buffers?
Greetings
Stefan
On 11/11/2015 01:45 PM, Stefan Wunsch wrote:
> Hi!
>
> I have som
Hi!
I have some issues with the (understanding of the) behaviour of the VOLK
test-cases (defined in kernel_tests.h).
Each test defined in kernel_tests.h runs two times. Now I have the
problem that the first one succeeds but the second one fails.
I do not understand why the icompare function (the
Hi,
Thank you in advance.
I have look at the api, and find 4 class about the ofdm equalizer，
ofdm_equalizer_1d_pilots,
ofdm_equalizer_base,ofdm_equalizer_simpledfe,ofdm_equalizer_static.
1.Can someone tell their difference and relation.
2.I look at the ofdm_frame_equalizer_vcv
Hi,
Thank you so much for your kindly reply and patience.
But I want to confirm my option whether it's right or wrong.
The detection of the sync burst have delayed fft_len-1 because of
the filters in the sync block.
You have dalayed the signal fft_len+cp_len.And the c
22 matches
Mail list logo
