ha7ilm / csdr

A simple DSP library and command-line tool for Software Defined Radio.

Hi! I'm András.

I'm a researcher at UGent.

I was the original author of the open-source CSDR and OpenWebRX packages for Software Defined Radio.

csdr's Issues

Bandpass fails to stop every now and then, hanging the rest of OpenWebRX

On very rare occassions, OpenWebRX fails to show connecting user the waterfall, while the background services continue running. The analysis of the situation with GDB has shown the following:

1. SDR source fails to start for the user because of modificationLock taken by a previous attempt to stop this same SDR source.

2. The previous SDR stop is being caused by the scheduler shutting down an FT8 service.

3. Tracking down where it hangs shows the following:

(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/csdr/chain/__init__.py", line 139, in stop
    w.stop()
  File "/usr/lib/python3/dist-packages/csdr/chain/__init__.py", line 139, in stop
    w.stop()
  File "/usr/lib/python3/dist-packages/owrx/service/__init__.py", line 106, in stopServices
    service.stop()
  File "/usr/lib/python3/dist-packages/owrx/service/__init__.py", line 76, in onStateChange
    self.stopServices()
  File "/usr/lib/python3/dist-packages/owrx/source/__init__.py", line 579, in setState
    c.onStateChange(state)
  File "/usr/lib/python3/dist-packages/owrx/source/__init__.py", line 474, in stop
    self.setState(SdrSourceState.STOPPING)
  File "/usr/lib/python3/dist-packages/owrx/source/connector.py", line 66, in stop
    super().stop()
  File "/usr/lib/python3/dist-packages/owrx/source/__init__.py", line 539, in checkStatus
    self.stop()
  File "/usr/lib/python3/dist-packages/owrx/service/schedule.py", line 293, in _setCurrentEntry
    self.source.checkStatus()
  File "/usr/lib/python3/dist-packages/owrx/service/schedule.py", line 306, in selectProfile

4. The native code where it hangs is inside CSDR:

#4  0x0000ffffa13e32a0 in std::thread::join() () from /lib/aarch64-linux-gnu/libstdc++.so.6
#5  0x0000ffffa15a385c in Csdr::AsyncRunner::stop() () from /lib/aarch64-linux-gnu/libcsdr++.so.0.18

5. And the hanging module is Bandpass, that is inside Selector, that is inside ServiceSelectorChain for FT8:

(gdb) py-print w
local 'w' = <pycsdr.modules.Bandpass at remote 0xffffa0b7ad30>

Csdr (or Gnuradio) interfacing to RPITX

Hello group,

I'm more and more bit confused regarding interfacing of GnuRadio with Evariste's RPITX, and I hope you can help.
I have used several test SSB flowgraph or CSDR tfor modulating in USB audio files and transmitting them over RPITX.
The situation is the following :

I'm using RPITX "standard version" (not the new one) installed on a RaspberryPI2 with Stretch (Linux 4.14.49+ #11201 armv6l GNU/Linux)
Test trasmission over RPITX on USB of sampleaudio.wav test file, modulated using the Evariste's modulation program pissb is successful over 10 m band
I made a test flowgraph on GnuRadio on Windows that reads the "modulated" (by pissb) wav file and send it to the RaspberryPI via UDP sink : this allows an RPITX correct transmission, but only if I use the following receaving statement :
nc -u -l 8011 | sudo rpitx -i - -m IQ -a 14 -f $FREQUENCY

Gnuradio reads in FLOAT format and send it to UDPsink in FLOAT format (not in COMPLEX)

If I start modulating the sampleaudio.wav using different USB TX flowgraph (I can share them, for example the one of oz9aec or of ha7ilm) or also CSDR and I send the modulated output (correct, checking FFT scope...) to RPITX using again UDP sink, the result is a noise transmission (both setting RPITX in IQ or IQFLOAT format, both transmitting float or complex data flow over UDP sink.
Worst, the "correctly running" output of PISSB utility can be played o using any kind of playing audio tool, while the modulated output of the different flowgraphs (being IQ) should not.
I'm consequently a bit confused : what is the real data format accepted as input from RPITX, and which the correct way for interfacing it with Gnuradio and csdr ? (I guess that UDP or TCP sink - now deprecated - is not the issue...)

Any help appreciated
Regards, 73
Ugo

can't make for mac osx

make                                
cat: /proc/cpuinfo: No such file or directory
cat: /proc/cpuinfo: No such file or directory
cat: /proc/cpuinfo: No such file or directory
cat: /proc/cpuinfo: No such file or directory
NOTE: you may have to manually edit Makefile to optimize for your CPU (especially if you compile on ARM, please edit PARAMS_NEON).
Auto-detected optimization parameters: -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS

rm -f dumpvect*.vect
gcc -std=gnu99 -O3 -ffast-math -fdump-tree-vect-details -dumpbase dumpvect -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS fft_fftw.c libcsdr_wrapper.c  -g -lm -lrt -lfftw3f -DUSE_FFTW -DLIBCSDR_GPL -DUSE_IMA_ADPCM -Wno-unused-result -fpic -shared -o libcsdr.so
clang: error: unknown argument: '-fdump-tree-vect-details'
clang: error: unknown argument: '-mvectorize-with-neon-quad'
clang: error: no such file or directory: 'dumpvect'
make: *** [libcsdr.so] Error 1

Install on RPI Zero

Hello all
I try to install on RPI zero (not a programmer I just follow instruction !)
All seems go ok but when launch i get : Illegal instruction error

I need to configure "NEON" ? but how ?

Thank you

Add support for FFT integration

Could you add the support of FFT integration, aka, averaging x number of FFTs?

This has numerous uses, including better power measurements and smaller FFT files (used in radar and radio-astronomy applications).

Thanks!

Bug in fir_decimate_cc NEON implementation at higher decimation rates

I encountered this issue when trying to run OpenWebRX on an Odroid-U3. When running at a sample rate of 0.25 Msps everything works fine, while at a sample rate of 2.048 Msps the audio would drop out, even though the CPU usage was very low.

After some investigation this seems to be an issue with fir_decimate_cc, it started outputting zeros with higher decimation rates (185 at 2.048 Msps) after about 1 second of operation while it works fine with lower rates (22 at 0.25 Msps). When not using the NEON optimized implementation of fir_decimate_cc by removing -DNEON_OPTS in PARAMS_NEON this issue does not arise.

Without the optimized implementation the Odroid-U3 uses 22% CPU when sampling at 2.048 Msps with 1 client connected, so this workaround is (pretty much) usable.

This issue could of course be specific to the Odroid-U3, please report if anyone has the current NEON-implementation working using another board/cpu with NEON FPU, then the solution is to use the workaround when using an Odroid-U3. :)

Compiling on RPi - armv6

Hi,

i'm trying to compile on an old RPi with armv6. Tried with the flags below but still getting an Illegal Instruction on nmux. Any clues?

PARAMS_NEON = -mfloat-abi=hard -march=armv6 -mtune=arm6 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS

Thanks in advance
Dominic

root@pi:~/csdr# rtl_sdr -s 250000 -f 145525000 -p 0 -g 5 -| nmux --bufsize 65536 --bufcnt 763 --port 4951
nmux: listening on 127.0.0.1:4951
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
Sampling at 250000 S/s.
Tuned to 145525000 Hz.
Tuner gain set to 3.70 dB.
Reading samples in async mode...
Signal caught, exiting!
Short write, samples lost, exiting!
User cancel, exiting...
Illegal instruction


root@pi:~/csdr# nmux --bufsize 65536 --port 4951 --address 127.0.0.1
nmux: listening on 127.0.0.1:4951
Illegal instruction


root@pi:~/csdr# cat /proc/cpuinfo 
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7
Hardware	: BCM2835
Revision	: 000f

compile csdr on openwrt platform with error

error message:
`NOTE: you may have to manually edit Makefile to optimize for your CPU (especially if you compile on ARM, please edit PARAMS_NEON).
Auto-detected optimization parameters: -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4 -mfpmath=sse

rm -f dumpvect*.vect
gcc -I /home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/api -L /home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/.libs -std=gnu99 -O3 -ffast-math -fdump-tree-vect-details -dumpbase dumpvect -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4 -mfpmath=sse fft_fftw.c libcsdr_wrapper.c -g -lm -lrt -lfftw3f -DUSE_FFTW -DLIBCSDR_GPL -DUSE_IMA_ADPCM -Wno-unused-result -fpic -shared -Wl,-soname,libcsdr.so.0.15 -o libcsdr.so.0.15
/usr/bin/ld: skipping incompatible /home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/.libs/libfftw3f.so when searching for -lfftw3f
/usr/bin/ld: skipping incompatible /home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/.libs/libfftw3f.a when searching for -lfftw3f
/usr/bin/ld: cannot find -lfftw3f
collect2: error: ld returned 1 exit status
Makefile:54: recipe for target 'libcsdr.so' failed
make[4]: *** [libcsdr.so] Error 1
make[4]: Leaving directory '/home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/csdr-0.1'
Makefile:81: recipe for target '/home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/csdr-0.1/.built' failed
make[3]: *** [/home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/csdr-0.1/.built] Error 2
make[3]: Leaving directory '/home/openwrt/csdr.openwrt'
time: package/csdr/compile#2.57#0.12#2.80
package/Makefile:111: recipe for target 'package/csdr/compile' failed
make[2]: *** [package/csdr/compile] Error 2
make[2]: Leaving directory '/home/openwrt/openwrt'
package/Makefile:107: recipe for target '/home/openwrt/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.package_compile' failed
make[1]: *** [/home/openwrt/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/openwrt/openwrt'
/home/openwrt/openwrt/include/toplevel.mk:216: recipe for target 'world' failed
make: *** [world] Error 2
`

when I compile csdr on openwrt playform , and the hardware cpu is MediaTek Ralink MIPS (MT7621), the fftw3 module is also compilie from openwrt original package source.

and I checked the libfftw3f.so is elf32-little :
`objdump -p /home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/.libs/libfftw3f.so

/home/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/fftw3-single/fftw-3.3.7/.libs/libfftw3f.so: file format elf32-little`

Rewrite iof()s and qof()s to more easily understandable form

iof(a,b) == a[b].i

octave output plots to PDF/PS/PNG instead of display

I'm trying to get the fft plots working with the command as shown.

rtl_sdr -s 2400000 -f 104300000 -g 20 - | csdr convert_u8_f | csdr fft_cc 1024 1200000 HAMMING --octave | octave -i > /dev/null

For some strange reason, octave output plots do not show up when connecting remotely to a Raspberry Pi with an rtl-sdr dongle.

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
octave-gui: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
panic: Aborted -- stopping myself...

Likely this is an octave specific x11 authentication issue as other X11 windows show up correctly. I have never used octave but is it possible to send the output directly to a pdf (or ps or png) by modifying the above command without the octave gui.

Feature request: Add support for CS16

Just making my request 'official'. :) Happy to help/donate where I can, but unfortunately not a programmer. This change could help reduce overall CPU usage of all csdr processes, not to mention also whichever tool is used to provide the I/Q data, i.e., rtl_sdr, rx_sdr or hackrf_transfer. (Where supported, obviously. I can confirm rx_sdr supports this as long as the device backed by SoapySDR also does.)

Check fir_decimate_cc NEON performance improvement

Reported to have only 1.12 speedup on Odroid-C1

FT8 decoding with Airspy HF+ Discovery

FT8 decoding works well with RTL-SDR V3 Dongle:

$ ~/librtlsdr/src/rtl_sdr -s 1000000 -f 14074000 -g 20 -O dm=4:dm=20E6 - | csdr convert_u8_f | csdr fir_decimate_cc 250 0.00166665 HAMMING > /tmp/ft8_14074000.c2

$ ./ft8d backup/ft8_14074000.c2 
 00   2.6  -9 -0.15 14074124 VU3CER VU3FOE MK68   MK68
 00   3.8  -6 -0.15 14074424 VU3CER VU3FOE MK68   MK68
 00   3.1  -5 -0.15 14074523 VU3CER VU3FOE MK68   MK68
 00   3.3   3 -0.14 14074623 VU3CER VU3FOE MK68   MK68
 00   3.8  12 -0.13 14074723 VU3CER VU3FOE MK68   MK68

The ft8d binary comes from https://github.com/pavel-demin/ft8d project.

Next, I tried using Airspy HF+ Discovery instead of the RTL-SDR V3 Dongle.

$ airspyhf_rx -r /dev/stdout -a 384000 -f 14.074000 -g on -m on - | csdr fir_decimate_cc 80 0.00166665 HAMMING > /tmp/ft8_14074000.c2"

$ ./ft8d backup/ft8_14074000.c2
<no decodes>

https://github.com/airspy/airspyhf/blob/master/tools/src/airspyhf_rx.c <-- I am using this to grab the IQ samples. I am guessing that the output format is CF32 which is directly supported by csdr tools. I could be totally wrong here.

No luck here!

Next, I tried using the Airspy HF+ Discover with rx_tools.

$ rx_sdr -s 384000 -f 14074000 -I CF32 -F CF32 - | csdr fir_decimate_cc 80 0.00166665 HAMMING > /tmp/ft8_14074000.c2

$ ./ft8d backup/ft8_14074000.c2
<no decodes>

No luck here either.

To ensure that FT8 traffic in always on the air, I use my https://github.com/kholia/Easy-Digital-Beacons-v1 project to generate such test FT8 traffic.

I am trying to understand where the bug is. Am I using csdr correctly? Or is airspyhf_rx subtly different in its behavior compared to rtl_sdr?

Note: All software versions are freshly built from git repos.

Thanks for the help.

Support for ARMv8

Looks like some of the ASM changed, I tried fixing but have never done any ASM, let alone ARM.

/tmp/ccyqVRJR.s: Assembler messages:
/tmp/ccyqVRJR.s:1390: Error: unknown mnemonic vmov.f32' --vmov.f32 q4,#0.0'
/tmp/ccyqVRJR.s:1391: Error: unknown mnemonic vmov.f32' --vmov.f32 q5,#0.0'
/tmp/ccyqVRJR.s:1392: Error: unknown mnemonic vld2.32' --vld2.32 {q0-q1},[x6]!'
/tmp/ccyqVRJR.s:1393: Error: unknown mnemonic vld1.32' --vld1.32 {q2},[x7]!'
/tmp/ccyqVRJR.s:1394: Error: unknown mnemonic vmla.f32' --vmla.f32 q4,q0,q2'
/tmp/ccyqVRJR.s:1395: Error: unknown mnemonic vmla.f32' --vmla.f32 q5,q1,q2'
/tmp/ccyqVRJR.s:1398: Error: unknown mnemonic vst1.32' --vst1.32 {q4},[x10]'
/tmp/ccyqVRJR.s:1399: Error: unknown mnemonic vst1.32' --vst1.32 {q5},[x11]'
Makefile:47: recipe for target 'all' failed

Build is on a pine64 with A64 (cortex-a53) on ubuntu 16.04.

Make error

Hi:
When i try to do a make it gives me this error
error at code quality check: badsyntax() used in csdr.c without return.
Makefile:106: recipe for target 'codequality' failed
make: *** [codequality] Error 1

Thanks
Xarbot

`shift_addfast_cc` is never used in OpenWebRX yet; add `shift_cc` that would autodetect the fastest available shift function.

[Feature request] 24 bit integer and 32 bit float support

Hi!
Is it possible to add the support for 24 bit integers and 32 bit float as input data types?
That would be really great! (i'm using a professional receiver...not an rtl-sdr).
Many many many many thanks!
Best regards

Michele

Poor WFM decoding performance with homepage example

Hello,
I am playing around with SDR with my newly bought RTL-SDR and I tried some of the examples given on the homepage (https://github.com/simonyiszk/csdr).

However, I could not manage to make any good quality demodulation of a standard WFM commercial broadcast using csdr. I applied the "Demodulate WFM: Advanced" command line almost as-it:
rtl_sdr -s 2400000 -f 97700000 -g 20 - | ./csdr convert_u8_f | ./csdr shift_addition_cc -0.085 | ./csdr fir_decimate_cc 10 0.05 HAMMING | ./csdr fmdemod_quadri_cf | ./csdr fractional_decimator_ff 5 | ./csdr deemphasis_wfm_ff 48000 50e-6 | ./csdr convert_f_s16 > csdr_decode.raw

but all I could get was a very noisy decoded sound. Here is a short audio clip after converting the raw to wav: Link to WAV file

This is surprising since I can get a much better output in GNU Radio using the very same sequence as csdr:

And then, on the same channel, only a few seconds apart, the output is really good: Link to WAV file

Am I missing something? Are these two doing something different?

--
felixzero

nmux crash (+fix)

Just came across this while deploying OpenWebRx on Arch Linux x86_64. The first client connects to nmux, then disconnects, the second client connects and then I get a 100% reproducible crash:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fd653522fcd in __memmove_ssse3 () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007fd653522fcd in __memmove_ssse3 () from /usr/lib/libc.so.6
#1  0x00005562be082fac in std::__copy_move<true, true, std::random_access_iterator_tag>::__copy_m<tsmthread_s*> (__result=<optimized out>,
    __last=<optimized out>, __first=<optimized out>) at /usr/include/c++/8.2.0/bits/stl_algobase.h:479
#2  std::__copy_move_a<true, tsmthread_s**, tsmthread_s**> (__result=<optimized out>, __last=<optimized out>, __first=<optimized out>)
    at /usr/include/c++/8.2.0/bits/stl_algobase.h:386
#3  std::__copy_move_a2<true, __gnu_cxx::__normal_iterator<tsmthread_s**, std::vector<tsmthread_s*, std::allocator<tsmthread_s*> > >, __gnu_cxx::__normal_iterator<tsmthread_s**, std::vector<tsmthread_s*, std::allocator<tsmthread_s*> > > > (__result=..., __last=..., __first=...)
    at /usr/include/c++/8.2.0/bits/stl_algobase.h:422
#4  std::move<__gnu_cxx::__normal_iterator<tsmthread_s**, std::vector<tsmthread_s*, std::allocator<tsmthread_s*> > >, __gnu_cxx::__normal_iterator<tsmthread_s**, std::vector<tsmthread_s*, std::allocator<tsmthread_s*> > > > (__result=..., __last=..., __first=...) at /usr/include/c++/8.2.0/bits/stl_algobase.h:487
#5  std::vector<tsmthread_s*, std::allocator<tsmthread_s*> >::_M_erase (__position=..., this=0x5562be48c1a0) at /usr/include/c++/8.2.0/bits/vector.tcc:163
#6  std::vector<tsmthread_s*, std::allocator<tsmthread_s*> >::erase (__position=..., this=0x5562be48c1a0) at /usr/include/c++/8.2.0/bits/stl_vector.h:1318
#7  tsmpool::remove_thread (this=0x5562be48c1a0, thread=0x5562be48c250) at tsmpool.cpp:52
#8  0x00005562be082873 in main (argc=<optimized out>, argv=<optimized out>) at nmux.cpp:206

This might be a clue:

tsmpool.cpp: In member function ‘int tsmpool::remove_thread(tsmthread_t*)’:
tsmpool.cpp:56:1: warning: no return statement in function returning non-void [-Wreturn-type]
 }

Indeed, I changed int tsmpool::remove_thread to void and voila, no more crashes.

Help editing Makefile

Hi!
Can someone help me modifing the Makefile for Raspberry?
Have not understood how should i change it...
Many thanks!
Michele

Support for AARCH64 (aka 64bit ARM)

I saw that the Makefile already tries to detect running on ARMv6, but not ARMv7/v8 or even AARCH64, so it would be a nice addition to support those.

Since on my device /proc/cpuinfo looks like

processor       : 0
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

It would be better to change the detection to use uname -m anyway, to at least detect the platform properly.

#11 could also apply here though, I'll see how far I get

Edit: According to https://stackoverflow.com/a/29891469 the following PARAMS should be enough for AARCH64 on a Raspberry Pi 3+:
PARAMS_RASPI = -mcpu=cortex-a53 -mtune=cortex-a53 -funsafe-math-optimizations -Wformat=0

Edit2:

cat /proc/device-tree/model 
Raspberry Pi 3 Model B Plus Rev 1.3

That's another good detection method, just search for "Raspberry Pi" and then differ by architecture (and maybe also derive the cortex by that information)

README.md has Broken Examples

The python math calculation used within one of the examples is broken. The python print command now requires an additional set of parenthesis around the entire python print argument, after a recent python version release.

Also, mplayer incantation doesn't work here using ALSA, so I'm readily suspecting mplayer will not also work with other recent Linux distributions using pulseaudio for the past many years.  I'm thinking, probably best relying upon rarely changing simplistic software tools, or boring and stable tools such as either ALSA aplay or sox software tools for the examples.  Albeit, mplayer and mpv are great multi tools, myself using mpv more often.  Regardless, aplay is easy and simplistic, and when dealing with sound file manipulation, always find sox performs well.

So far, the below modified examples currently works for me.  Note, the previously mentioned bugs have been fixed within the incantations below:

# fm demodulation
$ airspyhf_rx -z -d -r stdout -f 105.5 | ./csdr fir_decimate_cc 2 0.25 HAMMING | ./csdr fmdemod_quadri_cf | ./csdr fractional_decimator_ff 8 | ./csdr deemphasis_wfm_ff 48000 50e-6 | ./csdr convert_f_s16 |  play -t s16 -r 48000 -

# am demodulation
airspyhf_rx -z -d -r stdout -f 0.970 |  csdr convert_u8_f | csdr shift_addition_cc `python -c "print (float(145000000-144400000)/2400000)"` | csdr fir_decimate_cc 50 0.005 HAMMING | csdr amdemod_cf | csdr fastdcblock_ff | csdr agc_ff | csdr limit_ff | csdr convert_f_s16 |  play -t s16 -r 48000 -

Since I'm relatively new to airspyhf_rx and csdr, there maybe errors.  airspyhf hardware suggests always using AGC on (or set to low) setting.

Pocsag chain: rtl_tcp -> cdr -> multimon-ng

Hi,

i am trying to build a chain for POCSAG decoding.

ALready used rtl_fm & multimon - works like a charm.

Now i am trying to use rtl_tcp and csdr for fm decoding.
In my understanding, the deemphasis_nfm_ff is not useable as the BW is too narrow.

Tried this chain:
(Incoming IQ - BW 1024000, Output SR 22050)

'csdr convert_u8_f |'+
'csdr shift_addition_cc 0.126953125 |'+
'csdr fir_decimate_cc 46 0.0010869565217391304 BLACKMAN |'+
'csdr fmdemod_quadri_cf |'+
'csdr limit_ff |'+
'csdr deemphasis_wfm_ff 22050 50e-6 |'+
'csdr fastagc_ff 1024 |'+
'csdr convert_f_s16'

But result is just garbage

Whitch screws i have to turn?

Please use a SONAME for libcsdr

Hi,

To make it easier for others to build software using libcsdr, please use a SONAME to allow for tracking of the API/ABI.

"A shared object was identified in a library directory (a directory in the standard linker path) which doesn't have a SONAME. This is usually an error.

SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this."

Thanks,

using csdr encode_ima_adpcm and decode_ima_adpcm_u8_i16

Hi, about the IMA ADPCM encode and decode, I am trying to chain and play using pipes. In my first attempt use play
nc -l -u 7355 | csdr encode_ima_adpcm_i16_u8 | play -tima -r8k -

The input source has a 8kHz sample rate and the input format is signed short to encode_ima_adpcm but the sound is a bit distorted after decoded (using play), so my question here is: does the input source need a particular sample rate to use with csdr encode_ima_adpcm_i16_u8 ?

In the othe side if I want to use csdr encode and csdr decode which player do you recommend (play, mplayer) and how would be the parameters?, . It is something li ke this:
nc -l -u 7355 | csdr encode_ima_adpcm_i16_u8 | csdr decode_ima_adpcm_u8_i16 | mplayer...

Thanks and regards

Adding two signals

Hi,

I'm willing to add two signals. One baseband (say 500 KHz wide) I/Q stream coming from a rtl-sdr dongle and another signal, locally created, carrying some arbitrary modulation. The resulting baseband can be used to modulate using SSB an output signal.

Main purpose is to implement a linear transponder and adding some local telemetry channel.

I've been exploring the functions of csdr but found no function that can be used as a linear sum of two signals with proper alignment of sample rates.

¿Any idea?

73 de Pedro, LU7DID

Compile on OSX

Any advice how to compile on OSX?

convert_i16_f adds a portional of original data to the end

Thank you for this useful DSP tool which I am hoping to use. But I notice something strange when converting data types.

I recorded a 1 second IQ sine wave at 48kHz, and used csdr convert_i16_f to convert to a float file. The int16 file is 185.k where as the float32 file is 176k, which is 1k bigger than the expected 187.5*2.

Using python to read the int16 data to array yy and the float32 data to zz.
The beginnings are the same
yy[:5] = array([ 0.+250.j, -812.+134.j, -824. +18.j, -818. -98.j, -800.-213.j])
np.round(zz[:5]*(1<<15))
array([ 0.+250.j, -812.+134.j, -824. +18.j, -818. -98.j, -800.-213.j], dtype=complex64)

The end of the int16 data is
yy[-5:] = array([ 298.+834.j, 195.+868.j, 88.+885.j, -19.+889.j, -129.+876.j])

While the float32 data extends 128 samples beyond sample 48,000
np.round(zz[-131:-126]*(1<<15))
array([ 88.+885.j, -19.+889.j, -129.+876.j, -564.-658.j, -478.-730.j], dtype=complex64)

So the last sample in the int16 data, shown in bold, is at sample [-129] which corresponds to the expected 48000 th sample of the float32. But there are 128 more samples after 48000.

Then, by scanning through the int data, I found the start of the 128 sample extension to be sample 512 from the end of the original
yy[-513:-508].
array([-637.-573.j, -564.-658.j, -478.-730.j, -389.-789.j, -290.-837.j])
np.round(zz[-129:-124]*(1<<15))
array([-129.+876.j, -564.-658.j, -478.-730.j, -389.-789.j, -290.-837.j], dtype=complex64)

In summary the converted data is 128 samples longer than the original with the added data being a 128 sample section taken 512 samples from the end of the original data. I suspect some buffer under/over run but cannot see where this might occur.

Help in understanding and fixing this would be appreciated. R

PS this is running on a raspberry pi using the branch recommended in the QTCSDR installation instructions.

./parsevect

When running Makefile:

./parsevect dumpvect*.vect
/bin/sh: 1: ./parsevect: not found
Makefile:47: recipe for target 'all' failed

Needed to chmod +x parsevect

Hope that helps.

Add WFM stereo decoding

Block diagram:

csdr-wfm-stereo-svg.zip

Compiling Issue: Raspberry Pi 3 + Raspbian Buster

Hello,

This is what I get when I make the master branch in a Raspberry Pi 3 + Raspbian Buster. Although it seems to work, with OpenwebRX, I'm getting a lot of audio underruns:

`NOTE: you may have to manually edit Makefile to optimize for your CPU (especially if you compile on ARM, please edit PARAMS_NEON).
Auto-detected optimization parameters: -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS

rm -f dumpvect*.vect
gcc -std=gnu99 -O3 -ffast-math -fdump-tree-vect-details -dumpbase dumpvect -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS fft_fftw.c libcsdr_wrapper.c -g -lm -lrt -lfftw3f -DUSE_FFTW -DLIBCSDR_GPL -DUSE_IMA_ADPCM -Wno-unused-result -fpic -shared -Wl,-soname,libcsdr.so.0.15 -o libcsdr.so.0.15
In file included from libcsdr_wrapper.c:1:
libcsdr.c:320:9: note: #pragma message: Manual NEON optimizations are ON: we have a faster shift_addfast_cc now.
#pragma message "Manual NEON optimizations are ON: we have a faster shift_addfast_cc now."
^~~~~~~
In file included from libcsdr_wrapper.c:1:
libcsdr.c:468:9: note: #pragma message: Manual NEON optimizations are ON: we have a faster fir_decimate_cc now.
#pragma message "Manual NEON optimizations are ON: we have a faster fir_decimate_cc now."
^~~~~~~
./parsevect dumpvect*.vect

Auto-vectorization built into gcc can increase the execution speed of algorithms with automatic
generation of SIMD instructions if the CPU is capable.
We parse the output of the vectorizer to analyze which loops could be optimized (thus speeded up) this way.
Warning! The result may be different on different CPU architectures...

Colors:

• can't be vectorized
• successfully vectorized
• not intended to be vectorized (not important)

libcsdr.c:123:5: note: LOOP VECTORIZED normalize_fir_f: normalize pass 2
libcsdr.c:121:5: note: LOOP VECTORIZED normalize_fir_f: normalize pass 1
libcsdr.c:136:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed firdes_lowpass_f: calculate taps
libcsdr.c:156:5: note: not vectorized: multiple nested loops. firdes_bandpass_c
libcsdr.c:162:14: note: not vectorized: number of iterations cannot be computed. firdes_bandpass_c
libcsdr.c:161:14: note: not vectorized: number of iterations cannot be computed. firdes_bandpass_c
libcsdr.c:193:5: note: not vectorized: multiple nested loops. shift_math_cc
libcsdr.c:204:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase
libcsdr.c:203:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase
libcsdr.c:217:5: note: not vectorized: relevant stmt not supported: _34 = __builtin_sinf (_30);
libcsdr.c:217:5: note: not vectorized: relevant stmt not supported: _34 = __builtin_sinf (_30);
libcsdr.c:237:5: note: not vectorized: multiple nested loops. shift_math_cc
libcsdr.c:262:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase
libcsdr.c:261:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase
libcsdr.c:276:5: note: not vectorized: multiple nested loops.
libcsdr.c:280:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:279:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:303:10: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:302:10: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:294:5: note: LOOP VECTORIZED shift_unroll_cc
libcsdr.c:311:5: note: not vectorized: unsupported data-type complex float
libcsdr.c:311:5: note: not vectorized: unsupported data-type complex float
libcsdr.c:392:10: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:391:10: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:327:5: note: LOOP VECTORIZED
libcsdr.c:484:9: note: not vectorized: control flow in loop.
libcsdr.c:590:9: note: not vectorized: multiple nested loops.
libcsdr.c:590:9: note: not vectorized: multiple nested loops.
libcsdr.c:597:13: note: not vectorized: number of iterations cannot be computed. fir_interpolate_cc: i loop
libcsdr.c:596:13: note: not vectorized: number of iterations cannot be computed. fir_interpolate_cc: i loop
libcsdr.c:618:15: note: not vectorized: control flow in loop.
libcsdr.c:624:9: note: LOOP VECTORIZED rational_resampler_ff (inner loop)
libcsdr.c:678:5: note: LOOP VECTORIZED fir_one_pass_ff
libcsdr.c:699:5: note: not vectorized: multiple nested loops. fractional_decimator_ff
libcsdr.c:678:5: note: LOOP VECTORIZED fir_one_pass_ff
libcsdr.c:678:5: note: LOOP VECTORIZED fir_one_pass_ff
libcsdr.c:678:5: note: LOOP VECTORIZED fir_one_pass_ff
libcsdr.c:727:5: note: not vectorized: control flow in loop.
libcsdr.c:730:9: note: not vectorized: control flow in loop.
libcsdr.c:763:5: note: not vectorized: multiple nested loops. fractional_decimator_ff
libcsdr.c:784:9: note: not vectorized: relevant stmt not supported: _47 = _43 / _46;
libcsdr.c:784:9: note: not vectorized: relevant stmt not supported: _47 = _43 / _46;
libcsdr.c:774:9: note: not vectorized: control flow in loop.
libcsdr.c:777:13: note: not vectorized: control flow in loop.
libcsdr.c:769:13: note: not vectorized: control flow in loop.
libcsdr.c:678:5: note: LOOP VECTORIZED fir_one_pass_ff
libcsdr.c:771:13: note: LOOP VECTORIZED
libcsdr.c:843:5: note: LOOP VECTORIZED apply_fir_fft_cc: add overlap
libcsdr.c:837:5: note: LOOP VECTORIZED apply_fir_fft_cc: normalize by fft_size
libcsdr.c:825:5: note: LOOP VECTORIZED apply_fir_fft_cc: multiplication
libcsdr.c:869:5: note: not vectorized: relevant stmt not supported: _17 = __builtin_sqrtf (_16); amdemod: sqrt
libcsdr.c:869:5: note: not vectorized: relevant stmt not supported: _17 = __builtin_sqrtf (_16); amdemod: sqrt
libcsdr.c:864:5: note: LOOP VECTORIZED amdemod: ii+qq
libcsdr.c:888:5: note: LOOP VECTORIZED amdemod_estimator
libcsdr.c:911:5: note: not vectorized, possible dependence between data-refs *_14 and *_17 dcblock_f
libcsdr.c:911:5: note: not vectorized, possible dependence between data-refs *_14 and *_17 dcblock_f
libcsdr.c:935:5: note: LOOP VECTORIZED fastdcblock_ff: remove DC component
libcsdr.c:927:5: note: LOOP VECTORIZED fastdcblock_ff: calculate block average
libcsdr.c:975:5: note: not vectorized: unsupported data-type double fastagc_ff: apply gain
libcsdr.c:975:5: note: not vectorized: unsupported data-type double fastagc_ff: apply gain
libcsdr.c:959:5: note: LOOP VECTORIZED fastagc_ff: peak search
libcsdr.c:1009:5: note: not vectorized: unsupported use in stmt. fmdemod_atan_novect
libcsdr.c:1009:5: note: not vectorized: no grouped stores in basic block. fmdemod_atan_novect
libcsdr.c:1027:5: note: not vectorized: unsupported data-type double fmdemod_quadri_novect_cf
libcsdr.c:1027:5: note: not vectorized: unsupported data-type double fmdemod_quadri_novect_cf
libcsdr.c:1065:5: note: not vectorized: unsupported data-type double fmdemod_quadri_cf: output division
libcsdr.c:1065:5: note: not vectorized: unsupported data-type double fmdemod_quadri_cf: output division
libcsdr.c:1065:5: note: not vectorized: no grouped stores in basic block. fmdemod_quadri_cf: output division
libcsdr.c:1061:5: note: LOOP VECTORIZED fmdemod_quadri_cf: output denomiator
libcsdr.c:1057:5: note: LOOP VECTORIZED fmdemod_quadri_cf: output numerator
libcsdr.c:1052:5: note: LOOP VECTORIZED fmdemod_quadri_cf: di
libcsdr.c:1046:5: note: LOOP VECTORIZED fmdemod_quadri_cf: dq
libcsdr.c:1094:5: note: not vectorized, possible dependence between data-refs *_16 and *_19 deemphasis_wfm_ff
libcsdr.c:1094:5: note: not vectorized, possible dependence between data-refs *_16 and *_19 deemphasis_wfm_ff
libcsdr.c:1124:9: note: LOOP VECTORIZED deemphasis_nfm_ff: inner loop
libcsdr.c:1132:5: note: LOOP VECTORIZED limit_ff
libcsdr.c:1141:5: note: LOOP VECTORIZED gain_ff
libcsdr.c:1147:5: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1157:5: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1177:5: note: LOOP VECTORIZED
libcsdr.c:1176:5: note: LOOP VECTORIZED
libcsdr.c:1183:5: note: not vectorized: multiple nested loops.
libcsdr.c:1187:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1186:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1196:5: note: not vectorized: relevant stmt not supported: amplitude_now_22 = __builtin_sqrtf (_10);
libcsdr.c:1196:5: note: not vectorized: relevant stmt not supported: amplitude_now_22 = __builtin_sqrtf (_10);
libcsdr.c:1225:9: note: not vectorized: control flow in loop. log2n
libcsdr.c:1240:9: note: not vectorized: control flow in loop. next_pow2
libcsdr.c:1248:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed apply_window_c
libcsdr.c:1261:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed precalculate_window
libcsdr.c:1271:5: note: LOOP VECTORIZED apply_precalculated_window_c
libcsdr.c:1280:2: note: LOOP VECTORIZED apply_precalculated_window_f
libcsdr.c:1289:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed apply_window_f
libcsdr.c:1302:5: note: LOOP VECTORIZED logpower_cf: pass 3
libcsdr.c:1300:5: note: not vectorized: relevant stmt not supported: _17 = __builtin_log10f (_16); logpower_cf: pass 2
libcsdr.c:1300:5: note: not vectorized: relevant stmt not supported: _17 = __builtin_log10f (_16); logpower_cf: pass 2
libcsdr.c:1298:5: note: LOOP VECTORIZED logpower_cf: pass 1
libcsdr.c:1307:5: note: LOOP VECTORIZED logpower_cf: pass 1
libcsdr.c:1313:5: note: LOOP VECTORIZED logpower_cf: pass 3
libcsdr.c:1311:5: note: not vectorized: relevant stmt not supported: _6 = __builtin_log10f (_4); logpower_cf: pass 2
libcsdr.c:1311:5: note: not vectorized: relevant stmt not supported: _6 = __builtin_log10f (_4); logpower_cf: pass 2
libcsdr.c:1319:5: note: LOOP VECTORIZED
libcsdr.c:1544:9: note: not vectorized: control flow in loop.
libcsdr.c:1560:22: note: not vectorized: multiple nested loops.
libcsdr.c:1564:17: note: not vectorized: data ref analysis failed *_29 = 0;
libcsdr.c:1564:17: note: not vectorized: data ref analysis failed *_14 = iftmp.223_41;
libcsdr.c:1559:13: note: not vectorized: control flow in loop.
libcsdr.c:1618:9: note: not vectorized: control flow in loop.
libcsdr.c:1674:13: note: not vectorized: multiple nested loops.
libcsdr.c:1710:9: note: LOOP VECTORIZED
libcsdr.c:1690:9: note: not vectorized: control flow in loop.
libcsdr.c:1697:13: note: LOOP VECTORIZED
libcsdr.c:1676:35: note: not vectorized: control flow in loop.
libcsdr.c:1734:5: note: not vectorized: control flow in loop.
libcsdr.c:1737:13: note: not vectorized: control flow in loop.
libcsdr.c:1769:5: note: not vectorized: relevant stmt not supported: _5 = _4 > 0.0;
libcsdr.c:1769:5: note: not vectorized: relevant stmt not supported: _5 = _4 > 0.0;
libcsdr.c:1776:5: note: not vectorized: unsupported data-type complex float
libcsdr.c:1776:5: note: not vectorized: unsupported data-type complex float
libcsdr.c:1787:5: note: not vectorized: multiple nested loops.
libcsdr.c:1788:9: note: not vectorized: control flow in loop.
libcsdr.c:1789:13: note: LOOP VECTORIZED
libcsdr.c:1796:5: note: not vectorized: control flow in loop.
libcsdr.c:1798:9: note: not vectorized: unsupported data-type double
libcsdr.c:1798:9: note: not vectorized: unsupported data-type double
libcsdr.c:1812:5: note: LOOP VECTORIZED
libcsdr.c:1821:5: note: not vectorized: unsupported use in stmt.
libcsdr.c:1831:9: note: not vectorized: unsupported use in stmt.
libcsdr.c:1837:9: note: not vectorized: unsupported use in stmt.
libcsdr.c:1837:9: note: not vectorized: no grouped stores in basic block.
libcsdr.c:1878:9: note: not vectorized: multiple nested loops.
libcsdr.c:1905:18: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1904:18: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1890:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1889:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1880:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1879:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:1948:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1948:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1942:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1942:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1935:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1935:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1933:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1931:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:1924:5: note: LOOP VECTORIZED
libcsdr.c:1993:9: note: not vectorized: control flow in loop.
libcsdr.c:2110:5: note: not vectorized: multiple nested loops.
libcsdr.c:2140:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2139:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2125:22: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2205:5: note: not vectorized: complicated access pattern.
libcsdr.c:2253:9: note: LOOP VECTORIZED firdes_add_peak_c: normalize pass 2
libcsdr.c:2249:9: note: not vectorized: unsupported use in stmt. firdes_add_peak_c: normalize pass 1
libcsdr.c:2240:9: note: LOOP VECTORIZED
libcsdr.c:2227:5: note: not vectorized: multiple nested loops. firdes_add_peak_c: calculate taps
libcsdr.c:2235:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2234:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2264:5: note: not vectorized: control flow in loop.
libcsdr.c:2267:9: note: not vectorized: complicated access pattern.
libcsdr.c:2279:5: note: not vectorized: control flow in loop.
libcsdr.c:2282:9: note: LOOP VECTORIZED
libcsdr.c:2314:5: note: LOOP VECTORIZED
libcsdr.c:2297:5: note: not vectorized: unsupported use in stmt.
libcsdr.c:2297:5: note: not vectorized: no grouped stores in basic block.
libcsdr.c:2297:5: note: not vectorized: control flow in loop.
libcsdr.c:2322:5: note: not vectorized: multiple nested loops.
libcsdr.c:2328:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2327:14: note: not vectorized: number of iterations cannot be computed.
libcsdr.c:2338:5: note: not vectorized: control flow in loop.
libcsdr.c:2342:9: note: LOOP VECTORIZED
libcsdr.c:2365:5: note: not vectorized: unsupported data-type double convert_u8_f
libcsdr.c:2365:5: note: not vectorized: unsupported data-type double convert_u8_f
libcsdr.c:2370:5: note: LOOP VECTORIZED convert_s8_f
libcsdr.c:2375:5: note: LOOP VECTORIZED convert_s16_f
libcsdr.c:2380:5: note: not vectorized: unsupported data-type double convert_f_u8
libcsdr.c:2380:5: note: not vectorized: unsupported data-type double convert_f_u8
libcsdr.c:2387:5: note: LOOP VECTORIZED convert_f_s8
libcsdr.c:2397:5: note: LOOP VECTORIZED convert_f_s16
libcsdr.c:2406:19: note: not vectorized: relevant stmt not supported: _12 = BIT_FIELD_REF <_6, 8, 8>;
libcsdr.c:2406:19: note: not vectorized: relevant stmt not supported: _12 = BIT_FIELD_REF <_6, 8, 8>;
libcsdr.c:2414:10: note: not vectorized: relevant stmt not supported: _24 = BIT_FIELD_REF <_21, 8, 16>;
libcsdr.c:2414:10: note: not vectorized: relevant stmt not supported: _24 = BIT_FIELD_REF <_21, 8, 16>;
libcsdr.c:2427:19: note: LOOP VECTORIZED
libcsdr.c:2432:10: note: LOOP VECTORIZED
libcsdr.c:2448:5: note: LOOP VECTORIZED
libcsdr.c:2459:5: note: not vectorized: unsupported data-type double
libcsdr.c:2459:5: note: not vectorized: unsupported data-type double
libcsdr.c:2477:5: note: not vectorized: unsupported data-type double
libcsdr.c:2477:5: note: not vectorized: unsupported data-type double
libcsdr.c:2487:5: note: not vectorized: unsupported data-type complex double
libcsdr.c:2487:5: note: not vectorized: unsupported data-type complex double
libcsdr.c:2487:5: note: not vectorized: no grouped stores in basic block.
libcsdr.c:2501:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed
libcsdr.c:2520:5: note: LOOP VECTORIZED
libcsdr.c:2525:5: note: LOOP VECTORIZED
libcsdr.c:2536:5: note: LOOP VECTORIZED trivial_vectorize: should pass :-)
libcsdr_gpl.c:50:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:49:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:37:2: note: not vectorized: unsupported use in stmt. shift_addition_cc: work
libcsdr_gpl.c:77:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:76:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:64:2: note: not vectorized: unsupported use in stmt. shift_addition_cc: work
libcsdr_gpl.c:104:2: note: not vectorized: control flow in loop. shift_addition_cc: work
libcsdr_gpl.c:111:8: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize phase
libcsdr_gpl.c:158:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:157:7: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: normalize starting_phase
libcsdr_gpl.c:142:2: note: not vectorized: number of iterations cannot be computed. shift_addition_cc: work
libcsdr_gpl.c:198:2: note: not vectorized: unsupported use in stmt. agc_ff
libcsdr_gpl.c:198:2: note: not vectorized: no grouped stores in basic block. agc_ff
ima_adpcm.c:157:2: note: not vectorized: data ref analysis failed step_57 = _stepSizeTable[state$index_19];
ima_adpcm.c:157:2: note: not vectorized: no grouped stores in basic block.
ima_adpcm.c:168:2: note: not vectorized: data ref analysis failed step_55 = _stepSizeTable[state_17];
fastddc.c:50:8: note: not vectorized: number of iterations cannot be computed.
fastddc.c:42:20: note: not vectorized: control flow in loop.
fastddc.c:95:2: note: LOOP VECTORIZED
fastddc.c:154:2: note: LOOP VECTORIZED fastddc_inv_cc: normalize by size
fastddc.c:144:2: note: LOOP VECTORIZED
fastddc.c:126:2: note: not vectorized: data ref analysis failed _18 = *_17;
fastddc.c:116:2: note: LOOP VECTORIZED
gcc -std=gnu99 -O3 -ffast-math -fdump-tree-vect-details -dumpbase dumpvect -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS csdr.c -g -lm -lrt -lfftw3f -DUSE_FFTW -DLIBCSDR_GPL -DUSE_IMA_ADPCM -L. -lcsdr -Wno-unused-result -o csdr
In file included from /usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from csdr.c:34:
/usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]

warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"

^~~~~~~
csdr.c:163:6: warning: trigraph ??< ignored, use -trigraphs to enable [-Wtrigraphs]
" ??<jump_to_function_docs_on_github>\n"

g++ -O3 -ffast-math -fdump-tree-vect-details -dumpbase dumpvect -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS nmux.cpp tsmpool.cpp -g -lm -lrt -lfftw3f -DUSE_FFTW -DLIBCSDR_GPL -DUSE_IMA_ADPCM -L. -lcsdr -lpthread -Wno-unused-result -o nmux
`

Decoding SSB with ELAD FDM-S2

Hi, can someone provide an example of demodulating LSB voice at an input samplerate of 192k 24 bit integer?
I find it quite difficult to build the string

I provide the input 192k i/ with this command:

elad_sdr_24 14248800 0

that output an infinite i/q stream at 192k on the frequency 14.248800kHz

Any help?

Pizero : Auto detect Raspberry platform improvement

Pizero CPU info :
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 900093

Maybe modify auto-detect using Hardware or feature ? For example
PARAMS_ARM = $(if $(call cpufeature,ARMv6,dummy-text),$(PARAMS_RASPI),$(PARAMS_NEON))

Help creating a working chain...

Hi!
I'm fighting with my receiver and csd for months...and cannot find a valid "chain" of commands to decode some audio...
My receiver outputs samples at a samplerate of 192khz 24 bit integer...
What i would like to do is: tune the receiver to a central frequency (for example 7070000) and decode an lsb audio signal at 7073000 (so +3 khz from the tuned freq) with a bandwidth of 2.7khz (standard ham audio bandwidth).
The output of the soundcard is 44.100 (i'm using a raspberry 3 with the classic 3.5mm jack).
The receiver outputs samples in this way:
elad_sdr_24 7070000 0 | csdr... (where frequency is 7070000 and 0 means infinite samples).

Can someone provide me the command to use?

Many thanks!

'73 de IU5HES

---

http://www.iu5hes.it

Decoding SSB with airspy

Using the example on the README I created a line to use airspy_rx and achieve a similar result:

airspy_rx -t 0 -r /dev/stdout -a 1 -f 434.253 -g 18 | csdr fir_decimate_cc 59 0.005 HAMMING | csdr bandpass_fir_fft_cc 0 0.1 0.05 | csdr realpart_cf | csdr agc_ff | csdr limit_ff | csdr convert_f_s16 | mplayer -ao jack:name=RTTY -cache 1024 -quiet -rawaudio samplesize=2:channels=1:rate=48000 -demuxer rawaudio -&

I don't really understand what each part is doing but signal sounds correct, however there are occasional pauses in the signal which make it really hard to decode. Is there anything in this command which could cause this.

Runnning on Raspberry Pi 3

Bug on Pi4-4GB + Odroid N2 4G "Buster" csdr jump 100% CPU usage on 20-30 seconds!

csdr run on 20-30sec to 100 % CPU on a "openwebrx" Setup with csdr preinstalled! if i start the openwebrx webinterface with waterfall. At Debian Stretch Release this does NOT happen, does anyone know why and whats changed between the OS Releases? both python 2.7, both compliled seemless!
Openwebrx -> csdr set Hz-filters ->start rtl_sdr ..
Every switch i press on the interface restart a command to csdr at backend, then csdr waits 20-30sec like hang/freeze the Audio, after 30 seconds the Sound runs and the Waterfall works too.
Tested varios Browsers, same issue. No logged Errors..
...make me nuts.. new hardware and lookups.. thanks for infos..

Advise in piping sound stream to RPITX

Hello,

I'm trying to pipe audio from ALSA_LOOPBACK to RPITX using csdr libraries, and to transmit it on USB, using the following statement :

arecord -c1 -r 48000 -D hw:Loopback,1,0 -f S16_LE - | csdr convert_s16_f | csdr dsb_fc | csdr bandpass_fir_fft_cc 0 0.1 0.01 | csdr gain_ff 2.0 | csdr shift_addition_cc 0.2 | sudo rpitx -i- -m IQ -f $FREQUENCY

...on Frequency 28150 KHz.

The effect is to trasmit noise.

Please consider :
A) that audio recorded from alsa_loopback after the "arecord -c1 -r 48000 -D hw:Loopback,1,0 -f S16_LE" statement is correct.
B) that test audio USB transmissions from RPITX on the same frequency using :

rpitx -m IQ -i /home/pi/pat/ssbIQ.wav -f $FREQUENCY -l

... after having created ssbIQ.wav with the RPITX pissb utility, are correctly transmitted over radio channel.

I'm probably making some mistake in using csdr : can you put me on the right way ?

Thank-you
73
Best regards
Ugo IU1IOB

Correct a sample rate from adc

Hello,

Sorry to post this here since it's not a problem but a question I don't know where to post it.
Is it possible to fix a quartz sampling clock fault of an adc in command line?
For example I have an I/Q stream of 384khz 16bits with an error of 5pps and whose receiver frequency is 50.500mhz.
In fact, it is not only a question of correcting the frequency offset but also the induced excursion.
If anyone has an answer?
Many thanks in advance

Please make a release

Hi,

The last release was a long time ago and there have been many commits since that release.

Are you planning to make one soon?

Thanks,