Coder Social home page Coder Social logo

jgaeddert / liquid-dsp Goto Github PK

View Code? Open in Web Editor NEW
1.8K 130.0 420.0 24.81 MB

digital signal processing library for software-defined radios

Home Page: http://liquidsdr.org

License: MIT License

C 88.35% Shell 0.24% C++ 9.91% Python 0.23% MATLAB 0.46% Assembly 0.01% M4 0.80%

liquid-dsp's Introduction

liquid-dsp

Software-Defined Radio Digital Signal Processing Library - https://liquidsdr.org

Core CI codecov MIT License Packaging status

liquid-dsp is a free and open-source digital signal processing (DSP) library designed specifically for software-defined radios on embedded platforms. The aim is to provide a lightweight DSP library that does not rely on a myriad of external dependencies or proprietary and otherwise cumbersome frameworks. All signal processing elements are designed to be flexible, scalable, and dynamic, including filters, filter design, oscillators, modems, synchronizers, complex mathematical operations, and much more.

// get in, manipulate data, get out
#include <liquid/liquid.h>
int main() {
    unsigned int M  = 4;     // interpolation factor
    unsigned int m  = 12;    // filter delay [symbols]
    float        As = 60.0f; // filter stop-band attenuation [dB]

    // create interpolator from prototype
    firinterp_crcf interp = firinterp_crcf_create_kaiser(M,m,As);
    float complex x = 1.0f;  // input sample
    float complex y[M];      // interpolated output buffer

    // repeat on input sample data as needed
    {
        firinterp_crcf_execute(interp, x, y);
    }

    // destroy interpolator object
    firinterp_crcf_destroy(interp);
    return 0;
}

For more information, please refer to the documentation online.

Installation and Dependencies

liquid-dsp only relies on libc and libm (standard C and math) libraries to run; however liquid will take advantage of other libraries (such as FFTW) if they are available.

If you build from the Git repository you will also need to install autotools for generating the configure.sh script (e.g. brew install autoconf automake on macOS, sudo apt-get install automake autoconf on Debian variants).

Installation

The recommended way to obtain the source code is to clone the entire repository from GitHub:

git clone git://github.com/jgaeddert/liquid-dsp.git

Building and installing the main library is a simple as

./bootstrap.sh
./configure
make
sudo make install

If you are installing on Linux for the first time, you will also need to rebind your dynamic libraries with sudo ldconfig to make the shared object available. This is not necessary on macOS.

If you decide that you want to remove the installed DSP library, simply run

sudo make uninstall

Seriously, I won't be offended.

Run all test scripts

Source code validation is a critical step in any software library, particularly for verifying the portability of code to different processors and platforms. Packaged with liquid-dsp are a number of automatic test scripts to validate the correctness of the source code. The test scripts are located under each module's tests/ directory and take the form of a C source file. liquid includes a framework for compiling, linking, and running the tests, and can be invoked with the make target check, viz.

make check

There are currently more than 110,000 checks to verify functional correctness. Drop me a line if these aren't running on your platform.

Testing Code Coverage

In addition to the full test suite, you can configure gcc to export symbol files to check for code coverage and then use gcovr to generate a full report of precisely which lines are covered in the autotests. These symbol files aren't generated by default and need to be enabled at compile-time through a configure flag:

./configure --enable-coverage

Running the tests and generating the report through gcovr can be invoked with the coverage make target:

make coverage

Examples

Nearly all signal processing elements have a corresponding example in the examples/ directory. Most example scripts generate an output .m file for plotting with GNU octave All examples are built as stand-alone programs and can be compiled with the make target examples:

make examples

Sometimes, however, it is useful to build one example individually. This can be accomplished by directly targeting its binary (e.g. make examples/modem_example). The example then can be run at the command line, viz. ./examples/modem_example.

Benchmarking tool

Packaged with liquid are benchmarks to determine the speed each signal processing element can run on your machine. Initially the tool provides an estimate of the processor's clock frequency and will then estimate the number of trials so that each benchmark will take between 50 and 500 ms to run. You can build and run the benchmark program with the following command:

make bench

C++

Compiling and linking to C++ programs is straightforward. Just include <complex> before <liquid/liquid.h> and use std::complex<float> in favor of float complex. Here is the same example as the one above but in C++ instead of C:

// get in, manipulate data, get out
#include <complex>
#include <liquid/liquid.h>
int main() {
    unsigned int M  = 4;     // interpolation factor
    unsigned int m  = 12;    // filter delay [symbols]
    float        As = 60.0f; // filter stop-band attenuation [dB]

    // create interpolator from prototype
    firinterp_crcf interp = firinterp_crcf_create_kaiser(M,m,As);
    std::complex<float> x = 1.0f;   // input sample
    std::complex<float> y[M];       // interpolated output buffer

    // repeat on input sample data as needed
    {
        firinterp_crcf_execute(interp, x, y);
    }

    // destroy interpolator object
    firinterp_crcf_destroy(interp);
    return 0;
}

PlatformIO

Install platformio (brew install platformio on macOS, sudo -H python3 -m pip install -U platformio on Linux). Add liquid-dsp to your platform.io list of dependencies:

[env:native]
platform = native
lib_deps = https://github.com/jgaeddert/liquid-dsp.git

Available Modules

  • agc: automatic gain control, received signal strength
  • audio: source audio encoders/decoders: cvsd, filterbanks
  • buffer: internal buffering, circular/static, ports (threaded)
  • channel: additive noise, multi-path fading, carrier phase/frequency offsets, timing phase/rate offsets
  • dotprod: inner dot products (real, complex), vector sum of squares
  • equalization: adaptive equalizers: least mean-squares, recursive least squares, semi-blind
  • fec: basic forward error correction codes including several Hamming codes, single error correction/double error detection, Golay block code, as well as several checksums and cyclic redundancy checks, interleaving, soft decoding
  • fft: fast Fourier transforms (arbitrary length), discrete sin/cos transforms
  • filter: finite/infinite impulse response, polyphase, hilbert, interpolation, decimation, filter design, resampling, symbol timing recovery
  • framing: flexible framing structures for amazingly easy packet software radio; dynamically adjust modulation and coding on the fly with single- and multi-carrier framing structures
  • math: transcendental functions not in the C standard library (gamma, besseli, etc.), polynomial operations (curve-fitting, root-finding, etc.)
  • matrix: basic math, LU/QR/Cholesky factorization, inversion, Gauss elimination, Gram-Schmidt decomposition, linear solver, sparse matrix representation
  • modem: modulate, demodulate, PSK, differential PSK, QAM, optimal QAM, as well as analog and non-linear digital modulations GMSK)
  • multichannel: filterbank channelizers, OFDM
  • nco: numerically-controlled oscillator: mixing, frequency synthesis, phase-locked loops
  • optim: (non-linear optimization) Newton-Raphson, evoluationary algorithms, gradient descent, line search
  • quantization: analog/digital converters, compression/expansion
  • random: (random number generators) uniform, exponential, gamma, Nakagami-m, Gauss, Rice-K, Weibull
  • sequence: linear feedback shift registers, complementary codes, maximal-length sequences
  • utility: useful miscellany, mostly bit manipulation (shifting, packing, and unpacking of arrays)
  • vector: generic vector operations

License

liquid projects are released under the X11/MIT license. By default, this project will try to link to FFTW if it is available on your build platform. Because FFTW starting with version 1.3 is licensed under the GNU General Public License v2 this unfortunately means that (and I'm clearly not a lawyer, here) you cannot distribute liquid-dsp without also distributing the source code if you link to FFTW. This is a similar situation with the classic libfec which uses the GNU Lesser GPL. Finally, liquid-dsp makes extensive use of GNU autoconf, automake, and related tools. These are fantastic libraires with amazing functionality and their authors should be lauded for their efforts. In a similar vain, much the software I write for a living I give away for free; however I believe in more permissive licenses to allow individuals the flexibility to use software with fewer limitations. If these restrictions are not acceptible, liquid-dsp can be compiled and run without use of these external libraries, albeit a bit slower and with limited functionality.

Short version: this code is copyrighted to me (Joseph D. Gaeddert), I give you full permission to do whatever you want with it except remove my name from the credits. Seriously, go nuts! but take caution when linking to other libraries with different licenses. See the license for specific terms.

liquid-dsp's People

Contributors

andreasbombe avatar andrewvoznytsa avatar artempisarenko avatar atsampson avatar brian-armstrong avatar dajuro avatar dforsi avatar fsheikh avatar garbagetrash avatar glv2 avatar guruofquality avatar gwbres avatar jgaeddert avatar lejafar avatar michelp avatar mnhauke avatar muellermartin avatar nowls avatar osh avatar r4d10n avatar rstarkov avatar taylorgibb avatar tpetazzoni avatar vankxr avatar viraptor avatar z80asmc0der avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

liquid-dsp's Issues

Segfault when calling destroy on symsync

I am current working the latest build from the master branch.

I recently discovered that a segfault occurs when I call symsync_crcf_destroy from my class destructor. The cause of the segfault is an attempt to free heap memory that was never allocated. I did not investigate the issue in-depth, but briefly looking at the source it looks like it has to do with how the symsync filter module is initializing its IIR filter.

mmx related target specific option mismatch

This might be related to other things that are already reported and being worked on, but I wasn't really sure so I opened a new bug here.

x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/equalization/s
rc/equalizer_rrrf.o src/equalization/src/equalizer_rrrf.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/crc.o 
src/fec/src/crc.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec.o 
src/fec/src/fec.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv.o src/fec/src/fec_conv.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv_poly.o src/fec/src/fec_conv_poly.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv_pmatrix.o src/fec/src/fec_conv_pmatrix.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_conv_punctured.o src/fec/src/fec_conv_punctured.c
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
src/dotprod/src/dotprod_rrrf.mmx.c: In function ‘dotprod_rrrf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_rrrf.mmx.c:203:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_rrrf.mmx.c:204:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
make: *** [<builtin>: src/dotprod/src/dotprod_rrrf.mmx.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
 _mm_addsub_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
         s = _mm_addsub_ps( ci, cq );
           ^
make: *** [<builtin>: src/dotprod/src/dotprod_cccf.mmx.o] Error 1
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
src/dotprod/src/sumsq.mmx.c: In function ‘liquid_sumsqf’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/sumsq.mmx.c:85:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/sumsq.mmx.c:86:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
make: *** [<builtin>: src/dotprod/src/sumsq.mmx.o] Error 1

Broken Altivec support

Trying to compile Liquid for modern PPC targets with the NXP SDK:

user@host:~/dev/liquid-dsp$ make
powerpc-fsl-linux-gcc  -m32 -mhard-float -mcpu=e6500 --sysroot=/opt/fsl-qoriq/2.0/sysroots/ppce6500-fsl-linux  -O2 -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -O2 -pipe -g -feliminate-unused-debug-types  -fno-common -faltivec   -c -o src/libliquid.o src/libliquid.c
powerpc-fsl-linux-gcc: error: unrecognized command line option '-faltivec'
<builtin>: recipe for target 'src/libliquid.o' failed
make: *** [src/libliquid.o] Error 1

Perhaps -faltivec is a Mac thing. It appears that GCC uses -maltivec -mabi=altivec. I know autoconfigure has the ability to discover the correct flags, because FFTW does so. I changed the makefile and was able to continue with the compilation. However, it failed at the dotprod module thus:

powerpc-fsl-linux-gcc  -m32 -mhard-float -mcpu=e6500 --sysroot=/opt/fsl-qoriq/2.0/sysroots/ppce6500-fsl-linux  -O2 -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -O2 -pipe -g -feliminate-unused-debug-types  -fno-common -maltivec -mabi=altivec   -c -o src/dotprod/src/dotprod_rrrf.av.o src/dotprod/src/dotprod_rrrf.av.c
src/dotprod/src/dotprod_rrrf.av.c: In function 'dotprod_rrrf_execute':
src/dotprod/src/dotprod_rrrf.av.c:176:5: error: can't convert between vector values of different size
     s0 = s1 = s2 = s3 = (vector float)(0);
     ^
src/dotprod/src/dotprod_rrrf.av.c:178:9: warning: implicit declaration of function 'vec_madd' [-Wimplicit-function-declaration]
         s0 = vec_madd(ar[nblocks-1],d[nblocks-1],s0);
         ^
src/dotprod/src/dotprod_rrrf.av.c:178:9: error: AltiVec argument passed to unprototyped function
src/dotprod/src/dotprod_rrrf.av.c:179:9: error: AltiVec argument passed to unprototyped function
         s1 = vec_madd(ar[nblocks-2],d[nblocks-2],s1);
         ^
src/dotprod/src/dotprod_rrrf.av.c:180:9: error: AltiVec argument passed to unprototyped function
         s2 = vec_madd(ar[nblocks-3],d[nblocks-3],s2);
         ^
src/dotprod/src/dotprod_rrrf.av.c:181:9: error: AltiVec argument passed to unprototyped function
         s3 = vec_madd(ar[nblocks-4],d[nblocks-4],s3);
         ^
src/dotprod/src/dotprod_rrrf.av.c:186:5: warning: implicit declaration of function 'vec_add' [-Wimplicit-function-declaration]
     s0 = vec_add(s0,s1);    // s0 = s0+s1
     ^
src/dotprod/src/dotprod_rrrf.av.c:186:5: error: AltiVec argument passed to unprototyped function
src/dotprod/src/dotprod_rrrf.av.c:187:5: error: AltiVec argument passed to unprototyped function
     s2 = vec_add(s2,s3);    // s2 = s2+s3
     ^
src/dotprod/src/dotprod_rrrf.av.c:188:5: error: AltiVec argument passed to unprototyped function
     s0 = vec_add(s0,s2);    // s0 = s0+s2
     ^
src/dotprod/src/dotprod_rrrf.av.c:192:9: error: AltiVec argument passed to unprototyped function
         s0 = vec_madd(ar[nblocks],d[nblocks],s0);
         ^
src/dotprod/src/dotprod_rrrf.av.c:197:5: error: can't convert between vector values of different size
     s.v = vec_add(s0,(vector float)(0));
     ^
src/dotprod/src/dotprod_rrrf.av.c:197:5: error: AltiVec argument passed to unprototyped function
<builtin>: recipe for target 'src/dotprod/src/dotprod_rrrf.av.o' failed
make: *** [src/dotprod/src/dotprod_rrrf.av.o] Error 1

This code doesn't even have #include "altivec.h". Not sure how that was expected to work...
Anyway I added that but a few of the errors remain.

I am currently working on fixing the code, I will offer a pull request if I get it working.

One more question:

Why is LIQUID_IIRFILT_USE_DOTPROD defined as 0 in iirfilt? If I can use SIMD acceleration for my filters, I'd like to do that.

thanks.

some functions lost!

The following function can not find in liquiddsp,why?
spgramcf_create_kaiser
spgramcf_accumulate_psd
spgramcf_write_accumulation

Build fails on Mac OS X Mavericks due to AVX instructions

Despite the known fact that liquid-dsp does not build with LLVM/Clang (documented in the troubleshooting section), building liquid-dsp on a specific version of Mac OS X does fail with multiple errors like:

{standard input}:25:no such instruction: `vmovss LC1(%rip), %xmm2'

Currently the full error log available at: http://bot.brew.sh/job/Homebrew%20Core%20Pull%20Requests/4200/version=mavericks/testReport/junit/brew-test-bot/mavericks/install_liquid_dsp/

I don't know why this only happens on Mavericks (10.9.x) while building on Yosemite (10.10.x) and El Capitan (10.11.x) does work flawlessly when building with GCC instead of LLVM/Clang.

Possible fix:
By adding the compiler flag -Wa,-q this issue can be resolved while it also works on newer versions of Mac OS X. This was suggested as a solution for a similar issue OP2/PyOP2#471 and this thread on StackOverflow.

Note:
I came across this bug while submitting a package for Homebrew (third party package manager for OS X). The corresponding pull request is Homebrew/homebrew-core#2664

Update: This only affects version liquid-dsp 1.2.0 when building with GCC instead of LLVM/Clang

Multi-stage resampler

I'm attempting to use the multi stage resampler to resample an input waveform to an arbitrary rate. Unfortunately, I'm not getting the results I would expect. I've looked at the example and am trying to adapt it to my particular use case...

My setup is the following:
Input rate: 37777.0
Output rate: 5540.0
R ~ 0.14665007808984304
As = 120 (i know this is excessive, the problem is present at lower (80) attenuation as well)

My test waveform is a complex tone, amplitude 1, with frequency 55.40 Hz, it has 6819 samples. This should produce ten cycles at the end sample rate and 1000 samples.
(6819*5540/37777) =1000.0068..
For the most part, this is what happens. However, the start and endpoints don't look as "nice" as I had hoped. for example, at different "R"s I may get an overshoot of as much as 0.1. Clearly, some is to be expected, I just wanted to verify that this is correct and that I am not doing something wrong.

My code performs three executes, at first, I only push filter delay worth of samples into the resampler. Then I push the remaining input data. This way, I can throw away the useless samples. Lastly I push a set of zeroes (size of delay) into the filter to get out the remaining samples. Then I truncate the output buffer and I'm all done. At this point I have the delay compensated output. Here is the execute portion of the code for reference.

    size_t output_size = std::floor(input_data.size() * _r);
    //allocate some buffer space, it will be truncated later, lots of extra space here
    _output_data->resize(output_size + 2 * _delay + std::ceil(_r));
    unsigned int ny = 0;
    size_t written = 0;
    float frac_delay = msresamp_crcf_get_delay(_resamp);
    int delay = std::ceil(frac_delay);
    std::vector<std::complex<float> > shifter;
    shifter.resize(delay, std::complex<float>(0, 0));
    //push the first delay samples through the resampler, we will overwrite the results
    msresamp_crcf_execute(_resamp, input_data.data(), delay, _output_data->data(), &ny);
    //now push the remaining samples through the filter, start at index 0 of the output data
    msresamp_crcf_execute(_resamp, &input_data.at(delay), input_data.size() - delay, _output_data->data(), &ny);
    //lastly, push an array of zeroes with delay size through the filter to get the rest of the samples
    msresamp_crcf_execute(_resamp, shifter.data(), shifter.size(), &_output_data->at(ny), &ny);
    //truncate our output data to only contain the delay compensated result
    _output_data->resize(output_size);

Link to some plots:
http://imgur.com/a/k3gwL
Notice that the first sample of the output data seems incorrect. Should it not be 1?

My question is quite simple, is this procedure functionally correct? If not, where did I slip up? Thank you for any insight.

Also there is a typo in the documentation: for the multistage resampler interface documentation:
http://liquidsdr.org/doc/msresamp/
The call is: msresamp_crcf_execute(q,*x,nx,*y,*ny), not msresamp_crcf_filter_execute(q,*x,nx,*y,*ny)

cheers,
dominik

discussion about using liquid-dsp for BTLE packet capturing in Raspberry Pi 3

https://github.com/drtyhlpr/ble_dump

I have tried this on Raspberry Pi 3. The processing speed does not seem fast enough to capture a packet since it keeps emitting "OOOOOO" message. Similarly I tried FM radio receiver on Raspberry Pi 3 and it had similar problems.

Is it doable of implementing a BLE, WIFI, GSM, LTE scanner using liquid-dsp to be deployed in Raspberry Pi 3? At this stage I am mainly interested in BLE. The output should be able to be displayed using wireshark.

The output of the above repository on ubuntu is good enough at this stage.

Compile Breaks at dotprod_cccf.mmx.c

I'm running through the build of CubicSDR from CJ Cliffe's project https://github.com/cjcliffe/CubicSDR/wiki/Build-Linux. I'm having a problem building liquid-dsp by pulling from

git clone https://github.com/jgaeddert/liquid-dsp
liquid-dsp$ cd liquid-dsp
liquid-dsp$ ./bootstrap.sh
liquid-dsp$ ./configure --enable-fftoverride
liquid-dsp$ make -j4

The make output is posted below. I have two laptops sitting side by side with the same error in the same location of the build. Both are i386 machines with Debian. One is running Jessie and has an AMD dual core and the other is running Sid and has an Intel dual core.

I can pull the source code http://liquidsdr.org/downloads/liquid-dsp-1.2.0.tar.gz and compile and install on both machines with no issues. However, this does not seem to bode well for CubicSDR, CubicSDR fails to build and complains about liquid-dsp. cjcliffe/CubicSDR#393

Any help would be appreciated. And thanks for all the time and effort you've put into the project.

Here's the breakpoint

$ make -j4 gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/libliquid.o src/libliquid.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/agc/src/agc_crcf.o src/agc/src/agc_crcf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/agc/src/agc_rrrf.o src/agc/src/agc_rrrf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/buffer/src/bufferf.o src/buffer/src/bufferf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/buffer/src/buffercf.o src/buffer/src/buffercf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/channel/src/channel_cccf.o src/channel/src/channel_cccf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’: /usr/lib/gcc/i686-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: /usr/lib/gcc/i686-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ <builtin>: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1 make: *** Waiting for unfinished jobs....

double precision

It would be great if you could add support for double precision.

Thank you

Regard
Linus

Internal version bump

If you could bump the 1.2.x version on feature commits it'd be helpful during compilation so that it can detect whether things new things like FSK modem are available and provide an out-of-date warning.

Thanks!

Windows users

I would like to use the library under windows on an STM32F7 (GCC_Eclipse).
any help??

cross compilation fails when generating tables

Hi,
I tried to cross-compile liquid-dsp library using PTXDIST.
Everything works as expected until the build process want's to execute reverse_byte_gentab.
The executeable is build for the target architecture, but tries to run on my host architecture.
So the reverse_byte_gentab executeable need so be compiled by the host compiler.
I'm not familar enough with autotools so i don't know how i may change this behaviour.

Greetings,
Florian

Debian Error Help!

Iam trying to install on debian jessie armhf cant get pass "make comand"
ERROR:
root@/liquid-dsp# make
gcc -I . -I include -Wall -fPIC -g -O2 -ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon -c -o src/libliquid.o src/libliquid.c
In file included from /usr/include/features.h:398:0,
from /usr/include/complex.h:25,
from include/liquid.h:78,
from src/libliquid.c:27:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory

include <gnu/stubs-soft.h>

                         ^

compilation terminated.
: recipe for target 'src/libliquid.o' failed
make: *** [src/libliquid.o] Error 1

Valgring SSE4

Hi i need to compile library with -m32 flag and then valgrind:
`vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==19838== valgrind: Unrecognised instruction at address 0x8050599.
==19838== at 0x8050599: fft_create_plan_mixed_radix (fft_mixed_radix.c:105)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)

==19838== Your program just tried to execute an instruction that Valgrind
==19838== did not recognise. There are two possible reasons for this.
==19838== 1. Your program has a bug and erroneously jumped to a non-code
==19838== location. If you are running Memcheck and you just saw a
==19838== warning about a bad jump, it's probably your program's fault.
==19838== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19838== i.e. it's Valgrind's fault. If you think this is the case or
==19838== you are not sure, please let us know and we'll try to fix it.
==19838== Either way, Valgrind will now raise a SIGILL signal which will
==19838== probably kill your program.
`
It's probably connected with SSE4 (http://stackoverflow.com/questions/7875485/valgrind-unhandled-instruction-bytes-error). Can I turn it off and how, I try to change config.h but it's ineffective.

Best way to access "derrors" integer from decode_rs_char()?

I noticed that the number of errors detected in the example programs all were in reference to the original data. Where we don't have the original data, it would be really nice to have "derrors" available either through direct access to the struct, or through some sort of helper function on the fec_s struct.

Thoughts?

Integrating 4FSK in Framing module

Hi,
I know that 4FSK is in experimental stage right now and is not available as modulation type in framing module. Is it possible that I may add it to framing easily? What all steps are required ?
Thanks

Building liquid-dsp 1.2.0 on Mac OS X with LLVM/Clang

Building the release tarball of version 1.2.0 of liquid-dsp fails when using LLVM/Clang on Mac OS X (documented in troubleshooting section of manual/website). Currently the suggested fix is to use GCC instead (related issue #48), but this is not favored by Homebrew's maintainers (see isse Homebrew/homebrew-core#2664). Therefore I tried to build the latest release with LLVM/Clang and the only issues seems to be the configure script checks for malloc, realloc, free, memset, memmove in libc and sinf, cosf, expf, cargf, cexpf, crealf, cimagf, sqrtf in libm:

checking for malloc, realloc, free, memset, memmove in -lc... no
configure: error: Need standard c library!

and

checking for sinf, cosf, expf, cargf, cexpf, crealf, cimagf, sqrtf in -lm... no
configure: error: Need standard (complex) math library!

Possible fixes:

  • Release current master if applicable
  • Patch release for liquid-dsp e.g. 1.2.1 using the relevant changes from master

The patch could simply replace lines 160 to 166 in configure.ac with the corresponding lines in the master branch.

If this patch is applied building with LLVM/Clang succeeds and make check passes (PASSED ALL 42373 CHECKS with WARNINGS : 34).

firpfb behavior

I just noticed an odd result when performing the same filtering operation through firdecim and firpfb.
I wanted to be able to adjust the output phase using a timing estimate from my signal, so first I tested the output of firpfb with a fixed phase (0).
From my understanding the output signals should be the same (as a polyphase filter is just a more efficient implementation of FIR filtering + decimation/interpolation). Then I noticed that the current implementation just subsamples the filter coefficients to form M filters and each output sample only uses 1 of them.
Am i missing something? Is this behavior unintended? If so, I can help here.
Keep up the good work!

firpfbch2_crcf toggle channels on/off?

Channelizer is working perfectly for my purposes so far, but it would be helpful (if it improves CPU usage) to be able to toggle unused channels. Often what I want is in just one or two or may span two (reconstruct) and it seems wasteful if the unused channel data is still consuming cycles.

Thanks, Cheers!

gcc -Wall -O2 -pthread -lm -lc -lliquid -o benchmark_threaded benchmark_threaded.c

I am trying this file:

http://liquidsdr.org/blog/raspberry-pi3-benchmarks/benchmark_threaded.c

cpchung:temp$ gcc -Wall -O2 -pthread -lm -lc -lliquid -o benchmark_threaded benchmark_threaded.c
/tmp/ccLGDpmH.o: In function process_worker': benchmark_threaded.c:(.text+0x2d): undefined reference to firfilt_crcf_execute_block'
/tmp/ccLGDpmH.o: In function process_create': benchmark_threaded.c:(.text+0x25d): undefined reference to firfilt_crcf_create_kaiser'
benchmark_threaded.c:(.text+0x271): undefined reference to firfilt_crcf_set_scale' benchmark_threaded.c:(.text+0x29b): undefined reference to randnf'
benchmark_threaded.c:(.text+0x2b5): undefined reference to randnf' /tmp/ccLGDpmH.o: In function process_destroy':
benchmark_threaded.c:(.text+0x305): undefined reference to firfilt_crcf_destroy' /tmp/ccLGDpmH.o: In function benchmark':
benchmark_threaded.c:(.text+0x453): undefined reference to roundf' /tmp/ccLGDpmH.o: In function main':
benchmark_threaded.c:(.text.startup+0x332): undefined reference to `ceilf'
collect2: error: ld returned 1 exit status
cpchung:temp$ locate liquid.h
/home/cpchung/liquid-dsp/include/liquid.h
/usr/local/include/liquid/liquid.h

Linker issues when compiling for ARM target + FEC detection question

I'm a Linux dev for a university CubeSat team, and we hope to use your frontend to apply Reed-Solomon encoding to our radio transmissions for FEC.

  1. How can we detect the number of bit errors if we don't have the original message present on the receiving end? All of the example programs simply use the original message to do this, but I thought Reed-Solomon has some sort of built in "parity checking" that you can use to gauge if you're past the number of correctable errors.

  2. We're compiling libfec for the MitySOM335x and are seeing the following errors:

checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... no
checking fec.h usability... no
checking fec.h presence... no
checking for fec.h... no
checking fftw3.h usability... no
checking fftw3.h presence... no
checking for fftw3.h... no
checking for fftwf_plan_dft_1d in -lfftw3f... no
configure: WARNING: fftw3 library useful but not required
checking for create_viterbi27 in -lfec... no
configure: WARNING: fec library useful but not required

Related to not finding malloc:

src/audio/src/cvsd.c: In function 'cvsd_create':
src/audio/src/cvsd.c:74:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_golay2412.c: In function 'fec_golay2412_create':
src/fec/src/fec_golay2412.c:240:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming74.c: In function 'fec_hamming74_create':
src/fec/src/fec_hamming74.c:60:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming84.c: In function 'fec_hamming84_create':
src/fec/src/fec_hamming84.c:76:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming128.c: In function 'fec_hamming128_create':
src/fec/src/fec_hamming128.c:146:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_pass.c: In function 'fec_pass_create':
src/fec/src/fec_pass.c:34:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_rep3.c: In function 'fec_rep3_create':
src/fec/src/fec_rep3.c:35:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_rep5.c: In function 'fec_rep5_create':
src/fec/src/fec_rep5.c:35:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded2216.c: In function 'fec_secded2216_create':
src/fec/src/fec_secded2216.c:200:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded3932.c: In function 'fec_secded3932_create':
src/fec/src/fec_secded3932.c:216:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded7264.c: In function 'fec_secded7264_create':
src/fec/src/fec_secded7264.c:219:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/interleaver.c: In function 'interleaver_create':
src/fec/src/interleaver.c:81:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/packetizer.c: In function 'packetizer_create':
src/fec/src/packetizer.c:98:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/packetizer.c: In function 'packetizer_realloc_buffers':
src/fec/src/packetizer.c:419:5: warning: implicit declaration of function 'rpl_realloc'
src/filter/src/firdespm.c: In function 'firdespm_create':
src/filter/src/firdespm.c:249:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketgen.c: In function 'bpacketgen_create':
src/framing/src/bpacketgen.c:85:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketgen.c: In function 'bpacketgen_recreate':
src/framing/src/bpacketgen.c:160:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/bpacketsync.c: In function 'bpacketsync_create':
src/framing/src/bpacketsync.c:103:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketsync.c: In function 'bpacketsync_reconfig':
src/framing/src/bpacketsync.c:449:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/detector_cccf.c: In function 'detector_cccf_create':
src/framing/src/detector_cccf.c:124:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/framegen64.c: In function 'framegen64_create':
src/framing/src/framegen64.c:53:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/framesync64.c: In function 'framesync64_create':
src/framing/src/framesync64.c:125:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframegen.c: In function 'flexframegen_create':
src/framing/src/flexframegen.c:104:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframegen.c: In function 'flexframegen_reconfigure':
src/framing/src/flexframegen.c:390:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/flexframesync.c: In function 'flexframesync_create':
src/framing/src/flexframesync.c:147:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframesync.c: In function 'flexframesync_decode_header':
src/framing/src/flexframesync.c:632:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/gmskframegen.c: In function 'gmskframegen_create':
src/framing/src/gmskframegen.c:92:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/gmskframegen.c: In function 'gmskframegen_assemble':
src/framing/src/gmskframegen.c:241:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/gmskframesync.c: In function 'gmskframesync_create':
src/framing/src/gmskframesync.c:160:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/gmskframesync.c: In function 'gmskframesync_decode_header':
src/framing/src/gmskframesync.c:832:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/ofdmflexframegen.c: In function 'ofdmflexframegen_create':
src/framing/src/ofdmflexframegen.c:155:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/ofdmflexframegen.c: In function 'ofdmflexframegen_reconfigure':
src/framing/src/ofdmflexframegen.c:441:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/ofdmflexframesync.c: In function 'ofdmflexframesync_create':
src/framing/src/ofdmflexframesync.c:141:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/ofdmflexframesync.c: In function 'ofdmflexframesync_decode_header':
src/framing/src/ofdmflexframesync.c:571:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/qdetector_cccf.c: In function 'qdetector_cccf_create':
src/framing/src/qdetector_cccf.c:96:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpacketmodem.c: In function 'qpacketmodem_create':
src/framing/src/qpacketmodem.c:55:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpacketmodem.c: In function 'qpacketmodem_configure':
src/framing/src/qpacketmodem.c:148:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/qpilotgen.c: In function 'qpilotgen_create':
src/framing/src/qpilotgen.c:63:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpilotsync.c: In function 'qpilotsync_create':
src/framing/src/qpilotsync.c:74:5: warning: implicit declaration of function 'rpl_malloc'
In file included from src/matrix/src/smatrixb.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixb_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixb_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
In file included from src/matrix/src/smatrixf.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixf_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixf_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
In file included from src/matrix/src/smatrixi.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixi_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixi_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
src/modem/src/ampmodem.c: In function 'ampmodem_create':
src/modem/src/ampmodem.c:78:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/cpfskdem.c: In function 'cpfskdem_create':
src/modem/src/cpfskdem.c:156:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/cpfskmod.c: In function 'cpfskmod_create':
src/modem/src/cpfskmod.c:100:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/fskdem.c: In function 'fskdem_create':
src/modem/src/fskdem.c:81:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/fskmod.c: In function 'fskmod_create':
src/modem/src/fskmod.c:70:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/gmskdem.c: In function 'gmskdem_create':
src/modem/src/gmskdem.c:88:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/gmskmod.c: In function 'gmskmod_create':
src/modem/src/gmskmod.c:67:5: warning: implicit declaration of function 'rpl_malloc'
src/multichannel/src/ofdmframegen.c: In function 'ofdmframegen_create':
src/multichannel/src/ofdmframegen.c:105:5: warning: implicit declaration of function 'rpl_malloc'
src/multichannel/src/ofdmframesync.c: In function 'ofdmframesync_create':
src/multichannel/src/ofdmframesync.c:147:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/chromosome.c: In function 'chromosome_create':
src/optim/src/chromosome.c:43:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/gasearch.c: In function 'gasearch_create_advanced':
src/optim/src/gasearch.c:72:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/gasearch.c: In function 'gasearch_set_population_size':
src/optim/src/gasearch.c:181:5: warning: implicit declaration of function 'rpl_realloc'
src/optim/src/gradsearch.c: In function 'gradsearch_create':
src/optim/src/gradsearch.c:59:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/qnsearch.c: In function 'qnsearch_create':
src/optim/src/qnsearch.c:37:5: warning: implicit declaration of function 'rpl_malloc'
src/sequence/src/bsequence.c: In function 'bsequence_create':
src/sequence/src/bsequence.c:51:5: warning: implicit declaration of function 'rpl_malloc'
src/sequence/src/msequence.c: In function 'msequence_create':
src/sequence/src/msequence.c:77:5: warning: implicit declaration of function 'rpl_malloc'
src/utility/src/shift_array.c: In function 'liquid_lcircshift':
src/utility/src/shift_array.c:101:5: warning: implicit declaration of function 'rpl_malloc'
arm-arago-linux-gnueabi-ar: creating libliquid.a

Everything compiles and works fine natively, so it's possible that our CMake setup is not passing options appropriately to autoconf. Here's what we're using to pull in your project:

    ExternalProject_Add(${LIQUID_NAME}
        DEPENDS fec
        PREFIX ${LIQUID_NAME}
        GIT_REPOSITORY https://github.com/jgaeddert/liquid-dsp.git
        INSTALL_COMMAND ${CDH_SUDO} ${MAKE} install # ${CDH_INSTALL_CMD}
        INSTALL_DIR ${CDH_INSTALL_DIR}
        CMAKE_ARGS
            -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CDH_CMAKE_ARGS}
        UPDATE_COMMAND ${LIQUID_LIB_BUILD_DIR}/bootstrap.sh
        CONFIGURE_COMMAND ${LIQUID_LIB_BUILD_DIR}/configure --prefix=<INSTALL_DIR> ${CDH_AUTOCONF_HOST} ${CDH_AUTOCONF_BUILD}
        BUILD_COMMAND ${MAKE}
    ##    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${LIQUID_LIB_PREFIX_DIR}
    ##    CMAKE_GENERATOR ${CMAKE_GENERATOR}
         BUILD_IN_SOURCE 1
    ##    INSTALL_COMMAND ""
    #    UPDATE_COMMAND ""
        )

The important bit is the ${CDH_AUTOCONF_HOST} and ${CDH_AUTOCONF_BUILD} variables, which have respective values of --host=arm-arago-linux-gnueabi and --build=i386-pc-linux-gnu

I think this has something to do with the include directories used by cmake not being properly passed into autoconf, though that's just a guess. Have you all successfully built this library for ARM targets before?

Many compilation errors (debian 8.0)

src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’: src/dotprod/src/dotprod_cccf.mmx.c:225:12: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi] __m128 sum = _mm_setzero_ps(); // load zeros into sum register ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:115:1: error: inlining failed in call to always_inline ‘_mm_setzero_ps’: target specific option mismatch _mm_setzero_ps (void) ^ src/dotprod/src/dotprod_cccf.mmx.c:225:12: error: called from here __m128 sum = _mm_setzero_ps(); // load zeros into sum register ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:929:1: error: inlining failed in call to always_inline ‘_mm_loadu_ps’: target specific option mismatch _mm_loadu_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:240:11: error: called from here v = _mm_loadu_ps(&x[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:922:1: error: inlining failed in call to always_inline ‘_mm_load_ps’: target specific option mismatch _mm_load_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:243:12: error: called from here hi = _mm_load_ps(&_q->hi[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:922:1: error: inlining failed in call to always_inline ‘_mm_load_ps’: target specific option mismatch _mm_load_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:244:12: error: called from here hq = _mm_load_ps(&_q->hq[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:193:1: error: inlining failed in call to always_inline ‘_mm_mul_ps’: target specific option mismatch _mm_mul_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:247:12: error: called from here ci = _mm_mul_ps(v, hi); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:193:1: error: inlining failed in call to always_inline ‘_mm_mul_ps’: target specific option mismatch _mm_mul_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:248:12: error: called from here cq = _mm_mul_ps(v, hq); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:741:1: error: inlining failed in call to always_inline ‘_mm_shuffle_ps’: target specific option mismatch _mm_shuffle_ps (__m128 __A, __m128 __B, int const __mask) ^ src/dotprod/src/dotprod_cccf.mmx.c:251:12: error: called from here cq = _mm_shuffle_ps( cq, cq, _MM_SHUFFLE(2,3,0,1) ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:181:1: error: inlining failed in call to always_inline ‘_mm_add_ps’: target specific option mismatch _mm_add_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:258:13: error: called from here sum = _mm_add_ps(sum, s); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:971:1: error: inlining failed in call to always_inline ‘_mm_store_ps’: target specific option mismatch _mm_store_ps (float *__P, __m128 __A) ^ src/dotprod/src/dotprod_cccf.mmx.c:276:5: error: called from here _mm_store_ps(w, sum);

configure syntax error

Trying to configure and build liquid-dsp. When I run configure I get

./configure: line 4571: syntax error near unexpected token no,,' ./configure: line 4571:AX_GCC_ARCHFLAG(no,,)'

As I am relatively inexperienced with this script I cant figure out what the syntax should be.
I an using Ubuntu of x86 64 bit

fskmod/dem missing in documentation

It seems that fskmod and similar modules (cpfsk*) are missing from the documentation.

I was wondering if this was a mishap, or if the documentation is still under development?

Hard limit? "error: msresamp2_crcf_create(), number of stages should not exceed 10"

I was wondering if this is a soft limit just for sanity or if it's possible to uncap it.. Or should I really be doing something different like another fixed resampler stage before it?

It happens now when my input bandwidth is 3.2M and I'm attempting to resample to ~1.5khz or lower. It isn't much of a problem at the moment since the usable bandwidth for devices is below the 10 stage limit -- but I'm about to add support for devices that may go as high as 8M - 10M input bandwidth and it will become a much bigger issue.

build fail: isnan not defined for complex numbers

With gcc 5.3.0, I get:

In file included from src/math/src/polyc.c:43:0:
src/math/src/poly.findroots.c: In function ‘polyc_findroots_bairstow_recursion’:
src/math/src/poly.findroots.c:305:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
         if (isnan(du) || isnan(dv)) {
         ^

isnan doesn't work for T == double complex (works fine in clang though)

This applies to current master (f6a33a6)

liquiddsp and LLVM libc++

There is a small issue with the following code from liquid.h when using it with Clang and libc++ (http://libcxx.llvm.org):

#if LIQUID_USE_COMPLEX_H==1
#   include <complex.h>
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef R _Complex C
#elif defined _GLIBCXX_COMPLEX
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef std::complex<R> C
#else
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef struct {R real; R imag;} C;
#endif
//#   define LIQUID_DEFINE_COMPLEX(R,C) typedef R C[2]

_GLIBCXX_COMPLEX is not defined under libc++, which instead defines _LIBCPP_COMPLEX. The following small change is therefore suggested.

#if LIQUID_USE_COMPLEX_H==1
#   include <complex.h>
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef R _Complex C
#elif defined _GLIBCXX_COMPLEX || defined _LIBCPP_COMPLEX
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef std::complex<R> C
#else
#   define LIQUID_DEFINE_COMPLEX(R,C) typedef struct {R real; R imag;} C;
#endif
//#   define LIQUID_DEFINE_COMPLEX(R,C) typedef R C[2]

./configure fails while "checking whether mmx is supported"

Exact output was:
checking whether mmx is supported... ./configure: line 4843: 0xunknown: value too great for base (error token is "0xunknown")

I'm running this on x86_64 Arch Linux. No other previous errors/warnings were given. I've gone through this process on Ubuntu and Fedora with success, but I haven't run into this problem before. Any clues as to what's going on and what to do? Thanks in advance!

Just to clarify: this error results in no Makefile being generated, so running make returns with make: *** No targets specified and no makefile found. Stop.

Problem using ./configure under Cygwin or Ubuntu 15.10

Hi,

I am having the following problem when running ./configure under Cygwin:

./configure: line 4571: syntax error near unexpected token `no,,'
./configure: line 4571: `AX_GCC_ARCHFLAG(no,,)'

Can you please advise?

Thanks,
-Mihai

PS: I'm getting the same on Ubuntu 15.10.

ARM support

Tried to build it for BeagleBoneBlack which has Cortex A8 and NEON support.

Currently https://github.com/jgaeddert/liquid-dsp/blob/master/configure.ac has such hardcoded configuration for ARM:

arm*)
    # TODO: check for Neon availability

    # ARM architecture : use neon extensions
    MLIBS_DOTPROD="src/dotprod/src/dotprod_cccf.neon.o \
                   src/dotprod/src/dotprod_crcf.neon.o \
                   src/dotprod/src/dotprod_rrrf.neon.o \
                   src/dotprod/src/sumsq.o"
    # TODO: check these flags
    ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon";;
*)

For BeagleBoneBlack

ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon";;

must be changed to

ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=hard -mfpu=neon";;

Not sure what is correct for new 4 core RaspberryPi. I got some hints that this should work with gcc >= 4.9

ARCH_OPTION="-ffast-math -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4";;

As comments are already saying, question is how to detect if NEON is supported and which neon flag to use, the same goes for mcpu flag.

Configure failure

Following the described procedure I get the following error running Configure and would appreciate any assistance. The target is a Raspberry Pi 2.

Thanks, Bob W9RAN

./configure: line 4571: syntax error near unexpected token no,,' ./configure: line 4571:AX_GCC_ARCHFLAG(no,,)'
root@raspberrypi:~/Downloads/liquid-dsp# make
make: *** No targets specified and no makefile found. Stop.

Build fails from tarball, gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1)

src/math/src/poly.findroots.c:287:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
if (isnan(du) || isnan(dv)) {
^
src/math/src/poly.findroots.c:287:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
: recipe for target 'src/math/src/polyc.o' failed
Thanks for the help

liquidsdr.org down

Just in case you didn't know, the site's been down for a few days now

configure does not add the right -march cflags

Tried to build on an old core2duo machine. configure did not add the right -march=core2 flag so SIMD extensions failed to build.

Had to do. export CFLAGS="-march=core2" before running configure. Then it built ok.

Build and install in one step with `make install`

Its somewhat expected behaviour to build and install with the command make install but this fails with the current lease version of liquid-dsp. This is because there is no dependency rule for the install command. I suggest to add all as dependency for the install rule to enable this behaviour.

Why does fft print so much stuff? How do I prevent fft_execute from printing?

I'm using an embedded application. I don't want all sorts of junk on the screen. Can anyone explain why I get so much junk printed to the screen when specifying anything other than -n 16 in the example code? Notice I'm using the -q flag. I've played with the code, and this is definitely coming from the fft_execute() function.

user@host:~/dev/liquid-dsp-1.3.0/examples$ ./fft_example -q -n 10
fft plan [forward], n=10, Cooley-Tukey
10, Cooley-Tukey mixed radix, Q=2, P=5
  2, DFT
  5, DFT
computing 5 DFTs of size 2
i=  0/  5
     45.000000   -45.000000
     -5.000000     5.000000
i=  1/  5
     10.388418    20.388418
     -6.624599     3.375402
i=  2/  5
      1.881910    11.881909
     -8.632713     1.367286
i=  3/  5
     -1.367286     8.632712
    -11.881909    -1.881909
i=  4/  5
     -3.375401     6.624599
    -20.388420   -10.388417
computing 5 DFTs of size 2
i=  0/  5
      0.000004     0.000000
     50.000004   -50.000000
i=  1/  5
      9.999996    -9.999998
     60.000004   -60.000008
i=  2/  5
     19.999996   -19.999996
     70.000000   -70.000000
i=  3/  5
     30.000000   -30.000000
     80.000000   -80.000000
i=  4/  5
     39.999996   -40.000000
     90.000000   -90.000000
rmse =   4.6398e-07
done.

Use sse3 should be optionally enabled when supported by the system

Hi,

Since b3ed2ff crosscompiling using OpenEmbedded fails.

| mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32 --sysroot=....  -Os -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -msse3 -Os -pipe -g -feliminate-unused-debug-types     -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c
| mipsel-oe-linux-gcc: error: unrecognized command line option '-msse3'

Is it possible to add a proper test in order to enable sse3 instead of hardcoding to CFLAGS?

E.g. http://www.gnu.org/software/autoconf-archive/ax_ext.html

make liquid-dsp with error

I run ./bootstrap.sh and ./configure , and they all succeed.

when run make, it shows:
andy@andy-Mac-Laptop:~/liquid-dsp$ make
gcc -I . -I include -Wall -fPIC -g -O2 -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed
make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1

libfec \o/

I see the docs (and the bench output) mention libfec, but I can't for the life of me find libfec — well, more precisely, I found a couple things that might be libfec.

I forked one from Google code, and the more likely one seems to be from ka9q.net … but it won't compile on my modern computer. Some of the preprocessor directives comment out too much code, which is fixable, but other linking issues come up too.

Is that the right one? I can probably fix it or is it the Google code one? Asking for a quick doc fix here, sortof along the lines of changing “libfec” to “libfec by so-and-so.”

More liberal license?

At my last job we were in awe of liquid DSP's completeness and documentation, but we were not legally/contractually allowed to use GPL code. Would you be open to release it under a more liberal license?

I also ask because I'm working on some DSP and communications code for the Julia language, which can directly call c libraries. I'd love to link to Liquid, but the Julia community prefers the MIT license, and is actively trying to migrate away from all its GPL dependencies.

I'm sorry if this is an offensive request, and will completely understand if you prefer sticking to GPL.

framing tutorial

Hi, I have a problem with framesync64_print(fs) function while compiling 3rd tutorial. It isn't printing details and properties. I am using eclipse environment but after compiling project under console and run it, it throws "Segmentation fault" message. I could not find the issue of this also I do not have an opportunity to check this program on other machine. Waiting for help.
-Martin

Ubuntu 16 - problem to install

I was following the Installation guide, but when I executed the make I had some issues.

Can anyone help me?

liquid-dsp$ make
gcc -I . -I include -Wall -fPIC -g -O2 -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed
make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.