Advise in piping sound stream to RPITX

[UgoPoddine]

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

[ha7ilm]

Ugo,

I don't know. You should test the DSP chain manually, part by part.

Andras

[UgoPoddine]

Thank-you Andreas. I will do. Regards Ugo

…

----- Messaggio originale ----- Da: "András Retzler" <notifications@github.com> Inviato: ‎15/‎06/‎2018 16:58 A: "simonyiszk/csdr" <csdr@noreply.github.com> Cc: "UgoPoddine" <ugo.poddine@gmail.com>; "Author" <author@noreply.github.com> Oggetto: Re: [simonyiszk/csdr] Advise in piping sound stream to RPITX (#37) Ugo, I don't know. You should test the DSP chain manually, part by part. Andras — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ki7oxa]

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 if that is an exact copy and paste, I think your csdr chain is fine.... the problem is maybe" rpitx -i- " should be " rpitx -i - "... note the space after the i and the - for your input src... Let us know if thats all it is... 73 Ki7OXA

…

On Fri, Jun 15, 2018 at 7:57 AM, András Retzler ***@***.***> wrote: Ugo, I don't know. You should test the DSP chain manually, part by part. Andras — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aj7dKAEYlwGhsfnZhqgXOKEemjdSj_WEks5t88t3gaJpZM4Upr3p> .

[UgoPoddine]

Hello William, thank-you very much for your help. The copy of the script was exact. I made the modification that you suggested, and now the noise has been transformed in ... silence. I try to simplify the test script as follow (you can see the space added after the "i" : aplay -c1 -r 48000 -f s16_LE sampleaudio.wav - | 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 28150 Of course : aplay -c1 -r 48000 -f s16_LE sampleaudio.wav play the short rpitx test file without any issue on whatever audio alsa port (no pulseaudio !). ... but the silence is still there. I have remarked that, differently from the test script of RPITX, when the above listed chain is executed, RPITX stops (without crashing) at calibration step, as follow ; aplay -c1 -r 48000 -f s16_LE sampleaudio.wav - | 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 28150 csdr bandpass_fir_fft_cc: csdr shift_addition_cc: window = HAMMING csdr bandpass_fir_fft_cc: (fft_size = 1024) = (taps_length = 401) + (input_size = 624) - 1 (overlap_length = 400) = taps_length - 1 reinitialized to 0.2 Playing WAVE 'sampleaudio.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono rpitx Version 0.2 compiled Jun 4 2018 (F5OEO Evariste) running on Frequency=0.000000 SampleRate=48000 Master PLL = 1000000000 memory: 512 MB processor: Broadcom BCM2835 i2cDevice: /dev/i2c-1 model: Model B+ manufacturer: Sony pcb revision: 1 warranty void: no revision: 0010 peripheral base: 0x20000000 Jessie >>> Ok, I'm on Stretch.... Using mbox device /dev/vcio. 3616000 Size NUM PAGES 883 PAGE_SIZE 4096 MASH 3 Freq PLL# 6 csdr bandpass_fir_fft_cc: filter initialized, low_cut = 0, high_cut = 0.1 Calibrate : ppm=-7 DMA 159ns:1419ns ... no more ... using the test RPITX script we have some steps more : [....] MASH 3 Freq PLL# 6 Calibrate : ppm=-7 DMA 160ns:1361ns WaitNano=20833 F1=56357407.229048 TuneFrequency 56358000.000000 F2=56358182.668758 Initial Resolution(Hz)=775.439710 ResolutionPWMF 5.964921 NbStep=130 DELAYStep=8 ****** STARTING TRANSMIT ******** >> RF is issued Looping FileIn Looping FileIn END OF PiTx Any strongly appreciated suggestion ? Thank you Best regards (73) Ugo 2018-06-15 18:16 GMT+02:00 ki7oxa <notifications@github.com>:

…

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 if that is an exact copy and paste, I think your csdr chain is fine.... the problem is maybe" rpitx -i- " should be " rpitx -i - "... note the space after the i and the - for your input src... Let us know if thats all it is... 73 Ki7OXA On Fri, Jun 15, 2018 at 7:57 AM, András Retzler ***@***.***> wrote: > Ugo, > > I don't know. You should test the DSP chain manually, part by part. > > Andras > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#37 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ Aj7dKAEYlwGhsfnZhqgXOKEemjdSj_WEks5t88t3gaJpZM4Upr3p> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL2bJyQQRSp6ov6KyJYTCXrqEEiRq3hQks5t893PgaJpZM4Upr3p> .

[k8wu]

I found this open issue on a search. When you use the bandpass_fir_fft_cc method in CSDR, one of the things it does is to initialize four different FFT plans (one for taps, one for forward, and two for backward). The forward and backward FFT plans are all benchmarked on initialization. On just about any desktop/laptop PC with an Intel or AMD x86_64 processor, there will be no delay at all.

However, on the Raspberry Pi single board computers with ARM processors, that's where there is a huge delay. On a Raspberry Pi 4 with 4 GiB of memory running in 64 bit mode, it takes about 20 seconds for bandpass_fir_fft_cc to become ready and start processing data with a transition bandwidth of 0.01 * sample rate. During this time, RPiTX will transmit a dead carrier on the given frequency. If I increase this to 0.1 * sample rate, the delay of start drops to 5 seconds.

I haven't yet figured out a workaround for this, as removing the bandpass filter will result in both sidebands being transmitted.

[ha7ilm]

I see. What happens if you recompile the code with benchmarking off?

[k8wu]

Running this command with the unmodified csdr gives me this IQ file, which was later demodulated to provide the audio file with the benchmarking on:

cat wx.wav | sox - -t s16 -e signed-integer -b 16 -c 1 -r 48000 - bandpass 1.5k 2.4k | csdr convert_i16_f | csdr fastagc_ff | csdr dsb_fc | csdr bandpass_fir_fft_cc 0.01 0.1 0.001 | csdr shift_addition_cc 0.25 | csdr convert_f_i16 | sox -t s16 -e signed-integer -b 16 -c 2 -r 48000 - wx-benchmark-on.wav

Running this command with the version of csdr that I compiled with the benchmarking in bandpass_fir_fft_cc off gives me this IQ file, which was later demodulated to provide the audio file with the benchmarking off:

cat wx.wav | sox - -t s16 -e signed-integer -b 16 -c 1 -r 48000 - bandpass 1.5k 2.4k | csdr-dbg-no-bm convert_i16_f | csdr-dbg-no-bm fastagc_ff | csdr-dbg-no-bm dsb_fc | csdr-dbg-no-bm bandpass_fir_fft_cc 0.01 0.1 0.001 | csdr-dbg-no-bm shift_addition_cc 0.25 | csdr-dbg-no-bm convert_f_i16 | sox -t s16 -e signed-integer -b 16 -c 2 -r 48000 - wx-benchmark-off.wav

I will provide the demodulated output for both in the attached ZIP file. I did it this way so we can hear what it sounds like before being sent to RPiTX. The bandpass was tuned to try to better manage the SSB bandwidth. The reason there's noise is because it was a weather radio recording originally, and fastagc_ff also amplifies noise (as is expected if there is any).

wx-audio-demod.zip

[ha7ilm]

Is there a considerable difference between the two?

[k8wu]

I didn't notice any difference. Because I trust my eyes more than my ears, here are the frequency plots from both using Audacity's "Plot Spectrum":

Benchmark on:

Benchmark off:

I don't see much of a difference aside from a little bit of rolloff after 7 kHz, but by that point, that's -80 to -90 dBc.