Re: [Discuss-gnuradio] VOLK: fast way to log10()?

2015-09-15 Thread Brian Padalino 
On a side note, this is extremely impressive and I wish I knew about it sooner:

  https://software.intel.com/sites/landingpage/IntrinsicsGuide/

There's a few different log10_ps (packed single) functions in there.

Brian

On Wed, Sep 16, 2015 at 12:24 AM, Dennis Glatting  wrote:
> On Tue, 2015-09-15 at 23:35 -0400, Marcus D. Leech wrote:
>> On 09/15/2015 11:15 PM, Dennis Glatting wrote:
>> > With the VOLK library, is there a way to compute the log10() of
>> > each
>> > 32f in a buffer?
>> >
>> > That is:
>> >
>> >   for( int i = 0; i < num; ++i )
>> > buf[i] = std::log10( buf[i]);
>> >
>> > I only see log2() in the library but don't know if there is an easy
>> > way
>> > to compute log10().
>> >
>> >
>> > Thanks.
>> Define "fast".
>>
>
> Faster than the code fragment above.
>
> I see log2(), pow(), sin(), and other kernels in the library and
> /assumed/ there must be some way of log10() if only through a
> combination of kernel calls.
>
>
>> Ordinarily, one does a log10 to convert into engineering units at the
>> back of, for example, a power-measurement chain.
>>
>> There's usually no reason to do that in the middle of a flow-graph,
>> where things can stay in linear units.
>>
>
> 1) Working with VOLK to learn VOLK.
> 2) Having fun with vectors.
> 3) Generating power data points for plotting across a selected
>set of samples.
>
>
>>
>>
>> ___
>> 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] AttributeError: 'module' object has no attribute 'ofdm_chanest_MMSE_vcvc'

2015-09-15 Thread monika bansal 
Hii

I have added a new block and it is available in the block list of gnuradio.
I am using it in the flow graph. When i run it, it shows the error :


*self.Channel_Estimation_ofdm_chanest_MMSE_vcvc_0 =
Channel_Estimation.ofdm_chanest_MMSE_vcvc((sync_word1), (sync_word2), 8, 0,
-1, False,  0.1)*
*AttributeError: 'module' object has no attribute 'ofdm_chanest_MMSE_vcvc'*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building with cmake

2015-09-15 Thread Martin Braun 
On 15.09.2015 17:40, Robert Durkacz wrote:
> Certainly gnuradio is not too large a project to maintain by the make
> utility. I hope Marcus will confirm that for the benefit of people who
> never use make directly. It is for reasons of portability that you
> need a 'meta-make', right? A meta-make is something that generates a
> make system or ideally might translate one from one environment to
> another. If I follow Marcus, a meta-make should leave a decent make
> system behind and you do not expect it to leave lots of traces of
> itself behind like cmake does.
> 
> I hope to spend some time on gnuradio and the next thing I will do is
> put a simple build system in place for my own use. I don't see a
> problem. SDR is the main aim but I am interested in cooperating with
> anyone who wants to get the most out of make.

Robert,

- cmake doesn't leave any traces except for a build/ dir. Most of us can
live with that.
- GNU Radio most certainly is big enough to warrant usage of CMake over
raw make. The maintenance load for such a build system would be
incredible, and I really don't know how you'd enable stuff like
ENABLE_GR_FOO and 'allow bad boost' with pure make.
- CMake also generates other things we care about such as Visual Studio
projects.

I'm not discouraging you to try and fiddle with make, but GNU Radio
isn't going to move away from CMake any time soon. But the make system
won't be 'simple', and I don't see the advantage.

As I said, it's your time -- but I would like to close this thread &
discussion on this mailing list. We've argued over build systems in the
past, and at this point it's not helping anyone.
Thanks, everyone!

M


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

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

2015-09-15 Thread Dennis Glatting 
On Tue, 2015-09-15 at 23:35 -0400, Marcus D. Leech wrote:
> On 09/15/2015 11:15 PM, Dennis Glatting wrote:
> > With the VOLK library, is there a way to compute the log10() of
> > each
> > 32f in a buffer?
> > 
> > That is:
> > 
> >   for( int i = 0; i < num; ++i )
> > buf[i] = std::log10( buf[i]);
> > 
> > I only see log2() in the library but don't know if there is an easy
> > way
> > to compute log10().
> > 
> > 
> > Thanks.
> Define "fast".
> 

Faster than the code fragment above.

I see log2(), pow(), sin(), and other kernels in the library and
/assumed/ there must be some way of log10() if only through a
combination of kernel calls.


> Ordinarily, one does a log10 to convert into engineering units at the
> back of, for example, a power-measurement chain.
> 
> There's usually no reason to do that in the middle of a flow-graph, 
> where things can stay in linear units.
> 

1) Working with VOLK to learn VOLK.
2) Having fun with vectors.
3) Generating power data points for plotting across a selected 
   set of samples.


> 
> 
> ___
> 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] VOLK: fast way to log10()?

2015-09-15 Thread Brian Padalino 
On Wed, Sep 16, 2015 at 12:24 AM, Dennis Glatting  wrote:
>
> 1) Working with VOLK to learn VOLK.
> 2) Having fun with vectors.
> 3) Generating power data points for plotting across a selected
>set of samples.

Lastly, another alternative, if you wanted to utilize what is already
there in VOLK, if you wanted to do something like 10*log10(x), you can
also think of it as 10*log2(x)/log2(10) - rewritten to put the
constants together - 10*log2(10)*log2(x), where 10*log2(10) is
3.01029995664.

So convert a vector of floats into log2 then multiply a vector by a
const that is equal to 10*log2(10) to get them to their final value.
Not as efficient, potentially, but still an option if you want to
learn VOLK.

Brian

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

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

2015-09-15 Thread Marcus D. Leech 

On 09/15/2015 11:15 PM, Dennis Glatting wrote:

With the VOLK library, is there a way to compute the log10() of each
32f in a buffer?

That is:

  for( int i = 0; i < num; ++i )
buf[i] = std::log10( buf[i]);

I only see log2() in the library but don't know if there is an easy way
to compute log10().


Thanks.

Define "fast".

Ordinarily, one does a log10 to convert into engineering units at the 
back of, for example, a power-measurement chain.


There's usually no reason to do that in the middle of a flow-graph, 
where things can stay in linear units.




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

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

2015-09-15 Thread Brian Padalino 
It sounded like a fun and interesting question, so apparently there is
a little post from 2007 about a new implementation in C licensed under
GPLv2:

  https://sourceware.org/ml/libc-alpha/2007-06/msg00124.html

It would be interesting to compare and see if the results are
beneficial even if no VOLK is involved.

Brian

On Tue, Sep 15, 2015 at 11:15 PM, Dennis Glatting  wrote:
> With the VOLK library, is there a way to compute the log10() of each
> 32f in a buffer?
>
> That is:
>
>  for( int i = 0; i < num; ++i )
>buf[i] = std::log10( buf[i]);
>
> I only see log2() in the library but don't know if there is an easy way
> to compute log10().
>
>
> Thanks.
>
>
>
>
> ___
> 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] VOLK: fast way to log10()?

2015-09-15 Thread Dennis Glatting 
On Wed, 2015-09-16 at 00:32 -0400, Brian Padalino wrote:
> On a side note, this is extremely impressive and I wish I knew about
> it sooner:
> 
>   https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> 
> There's a few different log10_ps (packed single) functions in there.
> 

That's really interesting Thanks. I recently purchased two MICs for
learning but still awaiting parts for my server. I see KNC listed.


> Brian
> 
> On Wed, Sep 16, 2015 at 12:24 AM, Dennis Glatting 
> wrote:
> > On Tue, 2015-09-15 at 23:35 -0400, Marcus D. Leech wrote:
> > > On 09/15/2015 11:15 PM, Dennis Glatting wrote:
> > > > With the VOLK library, is there a way to compute the log10() of
> > > > each
> > > > 32f in a buffer?
> > > > 
> > > > That is:
> > > > 
> > > >   for( int i = 0; i < num; ++i )
> > > > buf[i] = std::log10( buf[i]);
> > > > 
> > > > I only see log2() in the library but don't know if there is an
> > > > easy
> > > > way
> > > > to compute log10().
> > > > 
> > > > 
> > > > Thanks.
> > > Define "fast".
> > > 
> > 
> > Faster than the code fragment above.
> > 
> > I see log2(), pow(), sin(), and other kernels in the library and
> > /assumed/ there must be some way of log10() if only through a
> > combination of kernel calls.
> > 
> > 
> > > Ordinarily, one does a log10 to convert into engineering units at
> > > the
> > > back of, for example, a power-measurement chain.
> > > 
> > > There's usually no reason to do that in the middle of a flow
> > > -graph,
> > > where things can stay in linear units.
> > > 
> > 
> > 1) Working with VOLK to learn VOLK.
> > 2) Having fun with vectors.
> > 3) Generating power data points for plotting across a selected
> >set of samples.
> > 
> > 
> > > 
> > > 
> > > ___
> > > 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

Re: [Discuss-gnuradio] building with cmake

2015-09-15 Thread Robert Durkacz 
Marcus Leech writes "When a project blooms in portability, size,
dependencies, and "reach", the use of a meta-make scheme of some sort
actually makes those kinds of project practical."

Certainly gnuradio is not too large a project to maintain by the make
utility. I hope Marcus will confirm that for the benefit of people who
never use make directly. It is for reasons of portability that you
need a 'meta-make', right? A meta-make is something that generates a
make system or ideally might translate one from one environment to
another. If I follow Marcus, a meta-make should leave a decent make
system behind and you do not expect it to leave lots of traces of
itself behind like cmake does.

I hope to spend some time on gnuradio and the next thing I will do is
put a simple build system in place for my own use. I don't see a
problem. SDR is the main aim but I am interested in cooperating with
anyone who wants to get the most out of make.

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

[Discuss-gnuradio] VOLK: fast way to log10()?

2015-09-15 Thread Dennis Glatting 
With the VOLK library, is there a way to compute the log10() of each
32f in a buffer?

That is:

 for( int i = 0; i < num; ++i )
   buf[i] = std::log10( buf[i]);

I only see log2() in the library but don't know if there is an easy way
to compute log10().


Thanks.




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

Re: [Discuss-gnuradio] Transmission error

2015-09-15 Thread Rama V 
Please kindly help with the above error

Thanks,
Dave
On Sep 14, 2015 5:02 PM, "Rama V"  wrote:

> Hey all,
> I have a small doubt regarding the reception of data packets. I am
> attaching a small figure of the command 'uhd_fft' where I mentioned the
> frequency and the sampling rate as 250k. The command I have given for this
> was
>
> ./benchmark_tx.py -m qpsk -M 2 --discontinuous -f 2.435G
>
> I tried to run this and I see an 'U' in the middle of transmission. Is
> this why I was not able to receive the packets because I get
>
> ok = False pktno = 53034 n_rcvd = 1 n_right = 0
>
> My PC is Dell Inspiron 15R 5537 and I think it's somewhat a new version.
> Do I need to mention any sample rate in the command of benchmark. And also
> when I set the sample rate to 250k in my benchmark command, my laptop
> freezes and I need to restart it again. Do I need to give a low value?
> Please help and excuse for my brevity.
>
> Thanks,
> Dave
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building with cmake

2015-09-15 Thread Marcus D. Leech 

On 09/15/2015 08:40 PM, Robert Durkacz wrote:

Marcus Leech writes "When a project blooms in portability, size,
dependencies, and "reach", the use of a meta-make scheme of some sort
actually makes those kinds of project practical."

Certainly gnuradio is not too large a project to maintain by the make
utility. I hope Marcus will confirm that for the benefit of people who
never use make directly. It is for reasons of portability that you
need a 'meta-make', right? A meta-make is something that generates a
make system or ideally might translate one from one environment to
another. If I follow Marcus, a meta-make should leave a decent make
system behind and you do not expect it to leave lots of traces of
itself behind like cmake does.

I hope to spend some time on gnuradio and the next thing I will do is
put a simple build system in place for my own use. I don't see a
problem. SDR is the main aim but I am interested in cooperating with
anyone who wants to get the most out of make.
You can put "system dependencies goo" inside every Makefile you author, 
but my experience is that exercise becomes
  "stand on your head while rubbing your tummy counterclockwise"-ish 
pretty quickly.


With meta-make systems, the Makefiles are interstitial artifacts, like 
.o files an the like.


The danger with "rolling your own build system for Gnu Radio" that 
*doesn't* include all the CMake stuff, is that you'll fall out of step
  fairly quickly, and the maint exercise of converting the way Gnu 
Radio builds itself to your own purely-Make based scheme will

  become burdensome.

I'm about as olde-skool as they come in this community, and even I could 
see the benefit of migrating from a meta-make scheme
  like autotools, to CMake, and CMake is more portable--one of the 
desires of the CMake migration was to make Windows builds
  easier, but there hasn't been much "steam" in that direction, in 
practice.





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

[Discuss-gnuradio] Possibly ways to help contribute

2015-09-15 Thread Tom Rondeau 
Hello GNU Radio dev community! I wanted to pass on some information for you
that might be a good way for you to help contribute to our project. Thanks
to Pete Mathys during out GRCon15 Hackfest, we now have a list of blocks
with minimal or no documentation. I've put together a Google spreadsheet
that lists all of the blocks in question. For anyone looking to help us fix
the documentation, this would be a good place to start.

One of the issues is that many of these blocks are Python-based as
hierarchical blocks. Some have full documentation that is not properly
getting exported into GRC. So it might not be a case of documentation but
helping identify how to get that information out there.

https://docs.google.com/spreadsheets/d/1Tb4nRjz8ruhzq-TlpkKFsByWI92fsON2cqR5HOolIwE/edit?usp=sharing

Another area to contribute is to help us identify areas where we can better
apply VOLK. Another spreadsheet that I've created lists all of the public
classes in GNU Radio. We wish to identify which classes/blocks could be
redone using VOLK. And if so, what VOLK kernels should we use as well as an
indicator for if the use of VOLK is done in that block. This can hopefully
serve as a checklist for the project in general and a good way for people
to contribute and help get our code moving faster.

https://docs.google.com/spreadsheets/d/1zKBi3xmihD2Tv7ME0qsKOzC6QjV5FtzIk6mqpHbNlCI/edit?usp=sharing

Thanks!

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

[Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

2015-09-15 Thread Jeon 
I've measured time taken by convolutional decoding in gr-ieee802-11. The
module is using Punctured Convolutional Code class from IT++ library (
http://itpp.sourceforge.net/4.3.0/classitpp_1_1Punctured__Convolutional__Code.html
)

I've used chrono (chrono.h, chrono) to measure time taken. You can see how
I made it from the following page (
https://gist.github.com/gsongsong/7c4081f44e88a7f4407a#file-ofdm_decode_mac-cc-L252-L257
)

I've measure time with a loopback flow graph (w/o USRP;
examples/wifi_loopback.grc)

The result says that it takes from 5,000 to 30,000 us, which is 5 to 30 ms
to decode a signal with a length of 9,000 samples (samples are either 1 or
-1.)

* Test environment: Ubuntu 14.04 on VMWare, 2 CPUs and 4 GB RAM allocated
* Host environmetn: Windows 7 with i7-3770 3.7 GHz

Since I am not familiar with error correcting codes, I have no idea how
large the order of time taken is. But I think that one of the most
efficient decoding algorithm is Viterbi and that IT++ must use it.'

Then I  can deduce that CC decoding takes a quite long time even though the
algorithm (Viterbi) is very efficient. And is it a natural limitation of
software decoding and SDR?

Another question comes that, the commercial off the shelf (COTS) Wi-Fi
device achieves really high throughput and that must be based on super
faster CC decoding. Is that because COTS is using heaviliy optimized FPGA
and dedicated decoding chips?

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

Re: [Discuss-gnuradio] Simple FIR Filter

2015-09-15 Thread Richard Bell 
Thanks Doug. I ended up implementing my own solution using a volk call. I 
hadn't realized the built in filters were wrappers for volk, thank you for 
pointing that out. Glad to know I did it in a gnuradio centric way. 

Rich

Sent from my iPhone

> On Sep 15, 2015, at 8:14 AM, Douglas Geiger  
> wrote:
> 
> Rich,
>  If you look in gr-filter/lib/fir_filter.cc you'll see all the filter kernel 
> implementations. Since it looks like you're only interested in floats (and 
> therefore, I assume real - not complex - signals and taps), if you look at 
> fir_filter_fff::filter(const float input[]) you can see that it really is 
> just a wrapper for the volk_32f_x2_dot_prod_32f kernel from VOLK. Note that 
> this call is the inner kernel, which gets called either by filterN (for the 
> non-decimating case) or filterNdec (for the decimating case) inside the 
> work(...) function by the corresponding block (i.e. fir_filter_fff_impl.cc 
> for the all-floats case). If you are interested in complex signals/taps, 
> fir_filter.cc has all the other variants as well, but you'll notice that 
> pretty much all the filter(...) calls are just wrappers for VOLK functions 
> (e.g. volk_32fc_x2_dot_prod_32fc for the all complex float case). All the 
> rest of the code relating to the FIR filters has to do with setup and things 
> like updating taps, so if all you need is a simple dot product function for 
> implementing your own FIR filter, I highly recommend looking through the VOLK 
> documentation. Note that if you have lots of taps, it becomes desirable at 
> some point to move into the Fourier domain, and do a simple element-wise 
> multiply rather than a time domain convolution. I'll leave walking through 
> fft_filter.cc as an exercise for the reader...
> 
>  Regards,
>   Doug
> 
>> On Mon, Sep 14, 2015 at 1:24 AM, Richard Bell  
>> wrote:
>> Hi all,
>> 
>> I'm not sure how to implement a simple FIR filter within C++ code that does 
>> not act directly on the OOT blocks input array. I would appreciate it if 
>> someone would demonstrate a simple example of how to use fir_filter_fff 
>> assuming the following:
>> 
>> float[N] my_input_array = {N float values};   < This is not the OOT 
>> modules input port array
>> float[M] taps = {my taps};
>> float[N+M-1] my_output_array = {N+M-1 float values}; < This is not the 
>> OOT modules output port
>> 
>> What is the code that will convolve my_input_array with taps and store it in 
>> my_output_array using gnuradio builtins? I've tried this myself but can't 
>> get it to work. I'm not interested in writing my own convolution code when 
>> gnuradio has optimized implementations.
>> 
>> Thanks,
>> Rich
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> -- 
> Doug Geiger
> doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis

2015-09-15 Thread Nowlan, Sean 
Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 
with my particular CPFSK parameters.

From: Achilleas Anastasopoulos [mailto:anas...@umich.edu]
Sent: Saturday, September 12, 2015 1:21 PM
To: Nowlan, Sean 
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,
I guess there was a missing normalization of the pulse.
Please add the line

p=p/sum(p)*Q/2.0;
just after the definition of the p pulse

p = numpy.ones(L*Q)


In addition, make sure you increase the Q (samples per symbol) considerably, ie 
make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for 
this constellation so it has to be appropriately samples in order to be 
represented accurately.

let me know how it goes
Achilleas



On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean 
> wrote:
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the 
format now, and I managed to build the gr-trellis documentation, which does 
spell out answers for a lot of what I asked.

I’ve abandoned making my own FSM since I can just use the CPM utilities in 
gr-trellis. However, I’m getting unexpected BER and PER when running 
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and 
L=1.

Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f

$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]

As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The 
construction of the phase response, q, looks correct to me. Any idea what might 
be going wrong?

Thanks,
Sean

From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
 On Behalf Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,

I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor 
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more 
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
  See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number 
of states is always = M^{L-1} * P (where M is the cardinality of the input 
alphabet),
so in your case you'll have a trellis with 3 states as the previous email 
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.


Now you can always drop all the above and design your FSM and signals from 
scratch. You can create the FSM from a file (this is explained in the 
gr-trellis documentaion--which is generated from gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF  THE FSM 
DEFINITION but part of the modulation definition as explained very extensively 
in the gr-trellis documentation.

let me know if you have any further questions,
Achilleas





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

Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis

2015-09-15 Thread Dan CaJacob 
Hi Sean,

Any chance you can share your work?

On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean 
wrote:

> Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB
> Es/N0 with my particular CPFSK parameters.
>
>
>
> *From:* Achilleas Anastasopoulos [mailto:anas...@umich.edu]
> *Sent:* Saturday, September 12, 2015 1:21 PM
> *To:* Nowlan, Sean 
> *Cc:* Discuss-gnuradio@gnu.org
>
>
> *Subject:* Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi
> algorithm using gr-trellis
>
>
>
> Sean,
>
> I guess there was a missing normalization of the pulse.
>
> Please add the line
>
> p=p/sum(p)*Q/2.0;
>
> just after the definition of the p pulse
>
> p = numpy.ones(L*Q)
>
>
> In addition, make sure you increase the Q (samples per symbol)
> considerably, ie make it 16 or more. The reason is that h=25/3 results in a
> BIG bandwidth for this constellation so it has to be appropriately samples
> in order to be represented accurately.
>
>
>
> let me know how it goes
>
> Achilleas
>
>
>
>
>
>
>
> On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean 
> wrote:
>
> Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
> format now, and I managed to build the gr-trellis documentation, which does
> spell out answers for a lot of what I asked.
>
>
>
> I’ve abandoned making my own FSM since I can just use the CPM utilities in
> gr-trellis. However, I’m getting unexpected BER and PER when running
> gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3
> and L=1.
>
>
>
> Diff of test_cpm.py with my simple modifications:
>
> https://gist.github.com/nowls/5b2bc2aada87dc197e3f
>
>
>
> $ python test_cpm.py
>
> Using Volk machine: avx_64_mmx_orc
>
> 100 16868 100 0.16868 1.0
>
> 200 33852 200 0.16926 1.0
>
> 300 50786 300 0.16928667 1.0
>
> 400 67667 400 0.1691675 1.0
>
> […]
>
>
>
> As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
> construction of the phase response, q, looks correct to me. Any idea what
> might be going wrong?
>
>
>
> Thanks,
>
> Sean
>
>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On
> Behalf Of *Achilleas Anastasopoulos
> *Sent:* Thursday, September 10, 2015 1:28 PM
> *To:* Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi
> algorithm using gr-trellis
>
>
>
> Sean,
>
> I just wanted to add to the previous answer:
>
> Indeed gr-trellis (and the fsm class specifically) has a built in
> constructor for generating the FSM corresponding to ANY CPM scheme.
>
> It only requires three parameters as explained in the comments
>
> in the file fsm.cc
>
> The constructed FSM is NOT based on Proakis decomposition, but on the more
> elegant decomposition by:
> "A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
>   See also my own notes at
> http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
>
> for all the details.
>
> In this case for h=K/P, it does not matter whether K is even or odd, the
> number of states is always = M^{L-1} * P (where M is the cardinality of the
> input alphabet),
>
> so in your case you'll have a trellis with 3 states as the previous email
> suggested.
>
> You may also find useful the python utility
>
> make_cpm_signals(K,P,M,L,q,frac)
>
> that can be found in gr-trellis/python
>
> that generates the signal space for you.
>
> (please see the above references for more info).
>
> Finally, you can take a look at the example "test_cpm.py"
>
> in the gr-trellis/examples/python
>
> and make appropriate changes for your CPFSK signal.
>
>
> 
>
> Now you can always drop all the above and design your FSM and signals from
> scratch. You can create the FSM from a file (this is explained in the
> gr-trellis documentaion--which is generated from
> gr-trellis/doc/gr-trellis.xml).
>
> The ouput symbol mapping is defined EXACTLY as you suggested in your email:
>
> every line corresponds to the current state and every column to an input.
>
> The entry is a number from 0 to I-1 (where I is the input cardinality).
>
> How this index is translated to an actual signal IS NOT PART OF  THE FSM
> DEFINITION but part of the modulation definition as explained very
> extensively in the gr-trellis documentation.
>
>
>
> let me know if you have any further questions,
>
> Achilleas
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] N210 & WBX for sale

2015-09-15 Thread Alexander Huemer 
On Mon, Sep 14, 2015 at 08:05:31PM +0200, James Kitchen wrote: 
> I'm not using my N210 neither my WBX any longer and i wonder if someone
> might be interested in buying them. They have been used very little. If
> someone is interested, please send me a private message.

In case somebody would like to buy the N210 alone, I'd be interested in 
the WBX, in case the price is reasonable.

Kind regards,
-Alex


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

Re: [Discuss-gnuradio] No tests were found!!!

2015-09-15 Thread Marcus Müller 
Hi Monika,

man 

often gives instructions on how to use a program.

man ctest

yields something like the following:

>-R , --tests-regex 
>   Run tests matching regular expression.
>
>   This option tells ctest to run only the tests whose
> names match the given regular expression.

now, you ran "ctest -V -R square"; ctest only ran the tests that have
"square" in their name (as you explicitly asked it to), and since there
were no tests with square in their name, none could be run.

Best regards,
Marcus

On 15.09.2015 10:19, monika bansal wrote:
> Hi Martin,
> I run *ctest -V -R qa_ofdm_chanest_MMSE_vcvc* 
> It is giving the test results.
>
> So, do we need to give the QA test file name in place of square ?
>
> Thanks.
>
> On Mon, Sep 14, 2015 at 10:38 PM, Martin Braun  > wrote:
>
> On 11.09.2015 21:51, monika bansal wrote:
> > When i am running * ctest -V -R square, output* is :
> >
> > Constructing a list of tests
> > Done constructing a list of tests
> > Checking test dependency graph...
> > Checking test dependency graph end
> > No tests were found!!!
>
> Is there a test call 'square'?
>
> M
>
>
> ___
> 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

Re: [Discuss-gnuradio] No tests were found!!!

2015-09-15 Thread monika bansal 
Hi Martin,
I run *ctest -V -R qa_ofdm_chanest_MMSE_vcvc*
It is giving the test results.

So, do we need to give the QA test file name in place of square ?

Thanks.

On Mon, Sep 14, 2015 at 10:38 PM, Martin Braun 
wrote:

> On 11.09.2015 21:51, monika bansal wrote:
> > When i am running * ctest -V -R square, output* is :
> >
> > Constructing a list of tests
> > Done constructing a list of tests
> > Checking test dependency graph...
> > Checking test dependency graph end
> > No tests were found!!!
>
> Is there a test call 'square'?
>
> M
>
>
> ___
> 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] On the convolutional code performance of gr-ieee802-11

2015-09-15 Thread Ron Economos 
Made a mistake. The DVB-T receiver is not part of the 3.7.8 release. 
It's a recent commit on the master branch (3.7.9git).


Ron

On 09/15/2015 01:31 AM, Ron Economos wrote:
The author of gr-dvbt looked at this issue when he developed the DVB-T 
receiver. Here's a blog entry on his findings.


http://yo3iiu.ro/blog/?p=1393

He benchmarked the IT++ decoder in last place.

IT++ = 2-3 Mbps
gr-trellis = 5 Mbps
Karn C = 7-8 Mbps
gr-dvbt = 39-40 Mbps

The gr-dvbt receiver is now part of GNU Radio as of the last release, 
3.7.8. The SSE2 viterbi decoder module is here:


https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbt/dvbt_viterbi_decoder_impl.cc

In addition, I believe there's another decoder in gr-fec. I'm not very 
familiar with it, so maybe someone else can comment on it. Looks like 
it's in this module:


https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_decoder_impl.cc

Ron

On 09/15/2015 12:47 AM, Jeon wrote:
I've measured time taken by convolutional decoding in gr-ieee802-11. 
The module is using Punctured Convolutional Code class from IT++ 
library 
(http://itpp.sourceforge.net/4.3.0/classitpp_1_1Punctured__Convolutional__Code.html)


I've used chrono (chrono.h, chrono) to measure time taken. You can 
see how I made it from the following page 
(https://gist.github.com/gsongsong/7c4081f44e88a7f4407a#file-ofdm_decode_mac-cc-L252-L257)


I've measure time with a loopback flow graph (w/o USRP; 
examples/wifi_loopback.grc)


The result says that it takes from 5,000 to 30,000 us, which is 5 to 
30 ms to decode a signal with a length of 9,000 samples (samples are 
either 1 or -1.)


* Test environment: Ubuntu 14.04 on VMWare, 2 CPUs and 4 GB RAM allocated
* Host environmetn: Windows 7 with i7-3770 3.7 GHz

Since I am not familiar with error correcting codes, I have no idea 
how large the order of time taken is. But I think that one of the 
most efficient decoding algorithm is Viterbi and that IT++ must use it.'


Then I  can deduce that CC decoding takes a quite long time even 
though the algorithm (Viterbi) is very efficient. And is it a natural 
limitation of software decoding and SDR?


Another question comes that, the commercial off the shelf (COTS) 
Wi-Fi device achieves really high throughput and that must be based 
on super faster CC decoding. Is that because COTS is using heaviliy 
optimized FPGA and dedicated decoding chips?


Regards,
Jeon.



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

Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

2015-09-15 Thread Ron Economos 
The author of gr-dvbt looked at this issue when he developed the DVB-T 
receiver. Here's a blog entry on his findings.


http://yo3iiu.ro/blog/?p=1393

He benchmarked the IT++ decoder in last place.

IT++ = 2-3 Mbps
gr-trellis = 5 Mbps
Karn C = 7-8 Mbps
gr-dvbt = 39-40 Mbps

The gr-dvbt receiver is now part of GNU Radio as of the last release, 
3.7.8. The SSE2 viterbi decoder module is here:


https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbt/dvbt_viterbi_decoder_impl.cc

In addition, I believe there's another decoder in gr-fec. I'm not very 
familiar with it, so maybe someone else can comment on it. Looks like 
it's in this module:


https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_decoder_impl.cc

Ron

On 09/15/2015 12:47 AM, Jeon wrote:
I've measured time taken by convolutional decoding in gr-ieee802-11. 
The module is using Punctured Convolutional Code class from IT++ 
library 
(http://itpp.sourceforge.net/4.3.0/classitpp_1_1Punctured__Convolutional__Code.html)


I've used chrono (chrono.h, chrono) to measure time taken. You can see 
how I made it from the following page 
(https://gist.github.com/gsongsong/7c4081f44e88a7f4407a#file-ofdm_decode_mac-cc-L252-L257)


I've measure time with a loopback flow graph (w/o USRP; 
examples/wifi_loopback.grc)


The result says that it takes from 5,000 to 30,000 us, which is 5 to 
30 ms to decode a signal with a length of 9,000 samples (samples are 
either 1 or -1.)


* Test environment: Ubuntu 14.04 on VMWare, 2 CPUs and 4 GB RAM allocated
* Host environmetn: Windows 7 with i7-3770 3.7 GHz

Since I am not familiar with error correcting codes, I have no idea 
how large the order of time taken is. But I think that one of the most 
efficient decoding algorithm is Viterbi and that IT++ must use it.'


Then I  can deduce that CC decoding takes a quite long time even 
though the algorithm (Viterbi) is very efficient. And is it a natural 
limitation of software decoding and SDR?


Another question comes that, the commercial off the shelf (COTS) Wi-Fi 
device achieves really high throughput and that must be based on super 
faster CC decoding. Is that because COTS is using heaviliy optimized 
FPGA and dedicated decoding chips?


Regards,
Jeon.


___
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] No tests were found!!!

2015-09-15 Thread monika bansal 
* Thanks Marcus ...

On Tue, Sep 15, 2015 at 2:24 PM, monika bansal 
wrote:

> Thanks Martin for the nice explanation...
>
> On Tue, Sep 15, 2015 at 1:59 PM, Marcus Müller 
> wrote:
>
>> Hi Monika,
>>
>> man 
>>
>> often gives instructions on how to use a program.
>>
>> man ctest
>>
>> yields something like the following:
>>
>>-R , --tests-regex 
>>   Run tests matching regular expression.
>>
>>   This option tells ctest to run only the tests whose names
>> match the given regular expression.
>>
>>
>> now, you ran "ctest -V -R square"; ctest only ran the tests that have
>> "square" in their name (as you explicitly asked it to), and since there
>> were no tests with square in their name, none could be run.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 15.09.2015 10:19, monika bansal wrote:
>>
>> Hi Martin,
>> I run *ctest -V -R qa_ofdm_chanest_MMSE_vcvc*
>> It is giving the test results.
>>
>> So, do we need to give the QA test file name in place of square ?
>>
>> Thanks.
>>
>> On Mon, Sep 14, 2015 at 10:38 PM, Martin Braun 
>> wrote:
>>
>>> On 11.09.2015 21:51, monika bansal wrote:
>>> > When i am running * ctest -V -R square, output* is :
>>> >
>>> > Constructing a list of tests
>>> > Done constructing a list of tests
>>> > Checking test dependency graph...
>>> > Checking test dependency graph end
>>> > No tests were found!!!
>>>
>>> Is there a test call 'square'?
>>>
>>> M
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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

Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

2015-09-15 Thread Marcus Müller 
Hi Jeon,

speed depends on your hardware and the implementation of the decoder.
As a rule of thumb: the more "generally applicable" a decoder is, the
slower it gets.
Jan wrote a set of highly SIMD-optimized decoders, but these are (pretty
common) special cases, so they don't cover all the cases that gr-trellis
works in, or even more general, the ITPP decoders application range. I'd
assume you could get a significant speed boost if you replaced the IT++
implementation with your own, highly specialized decoder if you know
what you're doing, but honestly, implementing, leave alone optimizing,
decoders is a non-trivial task and one should definitely not start a
project like gr-ieee802-11 trying to write one's own decoder if there's
an existing decoder out there that's usable (IT++ can be a pain to use,
still).

Generally, I'd frown upon using a VM to benchmark decoders: Good
decoders might make substantial use advanced SIMD instructions, but
these might not be enabled in your virtualizer. Furthermore, if you want
to do real-world gr-ieee802-11 usage, *don't* work in a VM, unless
you're super knowledgable about how to configure VMs; latency and CPU
overhead is critical, so the default "NAT" network configuration will
not work well for network-attached USRPs, and USB3 support in VMs is
ranging between bad and horrible, so B2x0 aren't really the best thing
to be used in VMs, either.

Run "volk-config-info --avail-machines" and check whether the output
contains:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc;

If that's the case, your VMWare does allow AVX/SSE4 inside your VM.

Best regards,
Marcus

On 15.09.2015 09:47, Jeon wrote:
> I've measured time taken by convolutional decoding in gr-ieee802-11.
> The module is using Punctured Convolutional Code class from IT++
> library
> (http://itpp.sourceforge.net/4.3.0/classitpp_1_1Punctured__Convolutional__Code.html)
>
> I've used chrono (chrono.h, chrono) to measure time taken. You can see
> how I made it from the following page
> (https://gist.github.com/gsongsong/7c4081f44e88a7f4407a#file-ofdm_decode_mac-cc-L252-L257)
>
> I've measure time with a loopback flow graph (w/o USRP;
> examples/wifi_loopback.grc)
>
> The result says that it takes from 5,000 to 30,000 us, which is 5 to
> 30 ms to decode a signal with a length of 9,000 samples (samples are
> either 1 or -1.)
>
> * Test environment: Ubuntu 14.04 on VMWare, 2 CPUs and 4 GB RAM allocated
> * Host environmetn: Windows 7 with i7-3770 3.7 GHz
>
> Since I am not familiar with error correcting codes, I have no idea
> how large the order of time taken is. But I think that one of the most
> efficient decoding algorithm is Viterbi and that IT++ must use it.'
>
> Then I  can deduce that CC decoding takes a quite long time even
> though the algorithm (Viterbi) is very efficient. And is it a natural
> limitation of software decoding and SDR?
>
> Another question comes that, the commercial off the shelf (COTS) Wi-Fi
> device achieves really high throughput and that must be based on super
> faster CC decoding. Is that because COTS is using heaviliy optimized
> FPGA and dedicated decoding chips?
>
> Regards,
> Jeon.
>
>
> ___
> 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] No tests were found!!!

2015-09-15 Thread monika bansal 
Thanks Martin for the nice explanation...

On Tue, Sep 15, 2015 at 1:59 PM, Marcus Müller 
wrote:

> Hi Monika,
>
> man 
>
> often gives instructions on how to use a program.
>
> man ctest
>
> yields something like the following:
>
>-R , --tests-regex 
>   Run tests matching regular expression.
>
>   This option tells ctest to run only the tests whose names
> match the given regular expression.
>
>
> now, you ran "ctest -V -R square"; ctest only ran the tests that have
> "square" in their name (as you explicitly asked it to), and since there
> were no tests with square in their name, none could be run.
>
> Best regards,
> Marcus
>
>
> On 15.09.2015 10:19, monika bansal wrote:
>
> Hi Martin,
> I run *ctest -V -R qa_ofdm_chanest_MMSE_vcvc*
> It is giving the test results.
>
> So, do we need to give the QA test file name in place of square ?
>
> Thanks.
>
> On Mon, Sep 14, 2015 at 10:38 PM, Martin Braun 
> wrote:
>
>> On 11.09.2015 21:51, monika bansal wrote:
>> > When i am running * ctest -V -R square, output* is :
>> >
>> > Constructing a list of tests
>> > Done constructing a list of tests
>> > Checking test dependency graph...
>> > Checking test dependency graph end
>> > No tests were found!!!
>>
>> Is there a test call 'square'?
>>
>> M
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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

Re: [Discuss-gnuradio] Simple FIR Filter

2015-09-15 Thread Douglas Geiger 
Rich,
 If you look in gr-filter/lib/fir_filter.cc you'll see all the filter
kernel implementations. Since it looks like you're only interested in
floats (and therefore, I assume real - not complex - signals and taps), if
you look at fir_filter_fff::filter(const float input[]) you can see that it
really is just a wrapper for the volk_32f_x2_dot_prod_32f kernel from VOLK.
Note that this call is the inner kernel, which gets called either by
filterN (for the non-decimating case) or filterNdec (for the decimating
case) inside the work(...) function by the corresponding block (i.e.
fir_filter_fff_impl.cc for the all-floats case). If you are interested in
complex signals/taps, fir_filter.cc has all the other variants as well, but
you'll notice that pretty much all the filter(...) calls are just wrappers
for VOLK functions (e.g. volk_32fc_x2_dot_prod_32fc for the all complex
float case). All the rest of the code relating to the FIR filters has to do
with setup and things like updating taps, so if all you need is a simple
dot product function for implementing your own FIR filter, I highly
recommend looking through the VOLK documentation. Note that if you have
lots of taps, it becomes desirable at some point to move into the Fourier
domain, and do a simple element-wise multiply rather than a time domain
convolution. I'll leave walking through fft_filter.cc as an exercise for
the reader...

 Regards,
  Doug

On Mon, Sep 14, 2015 at 1:24 AM, Richard Bell 
wrote:

> Hi all,
>
> I'm not sure how to implement a simple FIR filter within C++ code that
> does not act directly on the OOT blocks input array. I would appreciate it
> if someone would demonstrate a simple example of how to use fir_filter_fff
> assuming the following:
>
> float[N] my_input_array = {N float values};   < This is not the OOT
> modules input port array
> float[M] taps = {my taps};
> float[N+M-1] my_output_array = {N+M-1 float values}; < This is not the
> OOT modules output port
>
> What is the code that will convolve my_input_array with taps and store it
> in my_output_array using gnuradio builtins? I've tried this myself but
> can't get it to work. I'm not interested in writing my own convolution code
> when gnuradio has optimized implementations.
>
> Thanks,
> Rich
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sigidwiki

2015-09-15 Thread madengr 
Wow thanks.  That's awesome.  I think the 10 Bd Russian XPA signal stole some
riffs from Dream Theater.

http://www.sigidwiki.com/wiki/CIS_20-MFSK_XPA

Lou




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Sigidwiki-tp56045p56065.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

[Discuss-gnuradio] (no subject)

2015-09-15 Thread Gerome Jan L 
Hi guys,

What does the sampling rate in this usrp block does?i'm talking about the
uhd:usrp source block. Is this the one that samples the IF from my TVRX2
daughterboard? Or is this the bandwidth that is displayed on the QT Sink?
Or is this the bandwidth that needs to be sample. As far as I know,
sampling rate is fixed at 100 MSps by the ADC.
I'm asking this because whenver I set it to say 400 kHz in sampling rate,
it give me a bandwidth of 400 kHz. If I increase does, it increases the
bandwidth too. If this sets the sampling rate in the usrp, it should only
make the plot nicier, not increase its bandwidth. If I am not mistaken.
Thanks in advance.


-- 

Best,

*Gerome Jan M. Llames *
Aspiring Technopreneur | Tech Savvy | Curious
Mobile: +639271525124
Email: geromejanlla...@gmail.com

"*Because the people who are crazy enough to think they can change the
world, are the ones who do.*"  - Steve Jobs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD: USRP Source

2015-09-15 Thread Gerome Jan L 
Hi guys,

What does the sampling rate in this usrp block does?i'm talking about the
uhd:usrp source block. Is this the one that samples the IF from my TVRX2
daughterboard? Or is this the bandwidth that is displayed on the QT Sink?
Or is this the bandwidth that needs to be sample. As far as I know,
sampling rate is fixed at 100 MSps by the ADC.
I'm asking this because whenver I set it to say 400 kHz in sampling rate,
it give me a bandwidth of 400 kHz. If I increase does, it increases the
bandwidth too. If this sets the sampling rate in the usrp, it should only
make the plot nicier, not increase its bandwidth. If I am not mistaken.
Thanks in advance.


-- 

Best,

*Gerome Jan M. Llames *
Aspiring Technopreneur | Tech Savvy | Curious
Mobile: +639271525124
Email: geromejanlla...@gmail.com

"*Because the people who are crazy enough to think they can change the
world, are the ones who do.*"  - Steve Jobs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD: USRP Source

2015-09-15 Thread Martin Braun 
It sets the output sampling rate of the USRP, and hence the usable
bandwidth. Internally, it sets the DDC chain's decimation, so if you
request 1 Msps, it will decimate from 100 MHz sampling rate by a factor
of 100.

The rate at which the IF is sampled from the TVRX2 is, as you point out,
fixed to 100 MHz on the N200.

M

On 15.09.2015 09:11, Gerome Jan L wrote:
> Hi guys,
> 
> What does the sampling rate in this usrp block does?i'm talking about
> the uhd:usrp source block. Is this the one that samples the IF from my
> TVRX2 daughterboard? Or is this the bandwidth that is displayed on the
> QT Sink? Or is this the bandwidth that needs to be sample. As far as I
> know, sampling rate is fixed at 100 MSps by the ADC. 
> I'm asking this because whenver I set it to say 400 kHz in sampling
> rate, it give me a bandwidth of 400 kHz. If I increase does, it
> increases the bandwidth too. If this sets the sampling rate in the usrp,
> it should only make the plot nicier, not increase its bandwidth. If I am
> not mistaken.
> Thanks in advance.
> 
> 
> -- 
> 
> Best,
> 
> *Gerome Jan M. Llames *
> Aspiring Technopreneur | Tech Savvy | Curious
> Mobile: +639271525124 
> Email: geromejanlla...@gmail.com 
> 
> "/Because the people who are crazy enough to think they can change the
> world, are the ones who do./"  - Steve Jobs
> 
> 
> 
> 
> 
> ___
> 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] Demodulating CPFSK with Viterbi algorithm using gr-trellis

2015-09-15 Thread Nowlan, Sean 
Sure. Here was the pulse normalization fix Achilleas suggested:

https://github.com/gnuradio/gnuradio/pull/636

And this is a patch for CPFSK with modulation index h=25/3 (based off the PR 
above):

https://gist.github.com/nowls/8566d649e20ac0fa6d4e

Sean

From: Dan CaJacob [mailto:dan.caja...@gmail.com]
Sent: Tuesday, September 15, 2015 2:36 PM
To: Nowlan, Sean ; anas...@umich.edu
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Hi Sean,

Any chance you can share your work?

On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean 
> wrote:
Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 
with my particular CPFSK parameters.

From: Achilleas Anastasopoulos 
[mailto:anas...@umich.edu]
Sent: Saturday, September 12, 2015 1:21 PM
To: Nowlan, Sean 
>
Cc: Discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,
I guess there was a missing normalization of the pulse.
Please add the line

p=p/sum(p)*Q/2.0;
just after the definition of the p pulse

p = numpy.ones(L*Q)

In addition, make sure you increase the Q (samples per symbol) considerably, ie 
make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for 
this constellation so it has to be appropriately samples in order to be 
represented accurately.

let me know how it goes
Achilleas



On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean 
> wrote:
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the 
format now, and I managed to build the gr-trellis documentation, which does 
spell out answers for a lot of what I asked.

I’ve abandoned making my own FSM since I can just use the CPM utilities in 
gr-trellis. However, I’m getting unexpected BER and PER when running 
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and 
L=1.

Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f

$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]

As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The 
construction of the phase response, q, looks correct to me. Any idea what might 
be going wrong?

Thanks,
Sean

From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
 On Behalf Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,

I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor 
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more 
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
  See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number 
of states is always = M^{L-1} * P (where M is the cardinality of the input 
alphabet),
so in your case you'll have a trellis with 3 states as the previous email 
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.


Now you can always drop all the above and design your FSM and signals from 
scratch. You can create the FSM from a file (this is explained in the 
gr-trellis documentaion--which is generated from gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF  THE FSM 
DEFINITION but part of the modulation definition as explained very extensively 
in the gr-trellis documentation.

let me know if you have any further questions,

[Discuss-gnuradio] Printing values on the flowgraph.

2015-09-15 Thread Joe N 
Hi all,  I'm still trying to get used to things on Gnu Radio and i'm ready to
jump into making my own "tweaks".  I am trying to duplicate a scanner that I
saw on YouTube. ( https://www.youtube.com/watch?v=r9GtAFn5UlY ).  The
question that I have is regarding printing out of values.  For instance if
i'm parsing a tuning list that I can query from python, how can I display it
on the graph.  Or simply print out the frequency that I'm currently tuned
to.  Seems simple, but most things that I see online imply that I actually
have to create a new block to perform this type of functionality.  Is this
the case?  Can anyone point me to a good starting point to do this?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Printing-values-on-the-flowgraph-tp56075.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] Demodulating CPFSK with Viterbi algorithm using gr-trellis

2015-09-15 Thread Nowlan, Sean 
The BER and PER seem to be very sensitive to the oversampling factor (samples 
per symbol), Q.  For low Q, Achilleas’ point about needing more samples to get 
a better resolution on the symbol matched filters makes sense. However, I’m not 
sure why there’s a big jump in performance from Q=8 to Q=12, or why performance 
gets worse for Q>12. But based on this limited test, Q=12 looks like a good 
candidate.

QBERPER
4 1.040e-030.2344
8 1.095e-030.2455
12   2.637e-050.0068
16   3.340e-050.0084
24   3.867e-050.0098
32   3.359e-050.0086
48   4.238e-050.0108
> I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 with my particular CPFSK 
> parameters.
By the way, the above claim was with Q=48.

Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Tuesday, September 15, 2015 3:40 PM
To: Dan CaJacob ; anas...@umich.edu
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sure. Here was the pulse normalization fix Achilleas suggested:

https://github.com/gnuradio/gnuradio/pull/636

And this is a patch for CPFSK with modulation index h=25/3 (based off the PR 
above):

https://gist.github.com/nowls/8566d649e20ac0fa6d4e

Sean

From: Dan CaJacob [mailto:dan.caja...@gmail.com]
Sent: Tuesday, September 15, 2015 2:36 PM
To: Nowlan, Sean 
>; 
anas...@umich.edu
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Hi Sean,

Any chance you can share your work?

On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean 
> wrote:
Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 
with my particular CPFSK parameters.

From: Achilleas Anastasopoulos 
[mailto:anas...@umich.edu]
Sent: Saturday, September 12, 2015 1:21 PM
To: Nowlan, Sean 
>
Cc: Discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,
I guess there was a missing normalization of the pulse.
Please add the line

p=p/sum(p)*Q/2.0;
just after the definition of the p pulse

p = numpy.ones(L*Q)
In addition, make sure you increase the Q (samples per symbol) considerably, ie 
make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for 
this constellation so it has to be appropriately samples in order to be 
represented accurately.

let me know how it goes
Achilleas



On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean 
> wrote:
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the 
format now, and I managed to build the gr-trellis documentation, which does 
spell out answers for a lot of what I asked.

I’ve abandoned making my own FSM since I can just use the CPM utilities in 
gr-trellis. However, I’m getting unexpected BER and PER when running 
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and 
L=1.

Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f

$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]

As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The 
construction of the phase response, q, looks correct to me. Any idea what might 
be going wrong?

Thanks,
Sean

From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
 On Behalf Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using 
gr-trellis

Sean,

I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor 
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more 
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
  See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number 
of

Re: [Discuss-gnuradio] Sigidwiki

2015-09-15 Thread Francisco Albani 
This bears some resemblance to the idea we discussed in the Community
Working Group at GRCON15. Am I right?

:)

2015-09-14 17:33 GMT-03:00 Martin Braun :

> Hey,
>
> for those stragglers out there, who, like me, take a while to hear about
> new websites, this is interesting:
>
> http://www.sigidwiki.com/wiki/Signal_Identification_Guide
>
> Sigidwiki is a wiki page dedicated to identifying radio signals. Very
> interesting!
>
> Cheers,
> Martin
>
> ___
> 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