csdr 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 :

...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

Jun 15 '18 14:06 UgoPoddine

Ugo,

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

Andras

Jun 15 '18 14:06 ha7ilm

Thank-you Andreas. I will do.

Regards Ugo

----- Messaggio originale ----- Da: "András Retzler" [email protected] Inviato: ‎15/‎06/‎2018 16:58 A: "simonyiszk/csdr" [email protected] Cc: "UgoPoddine" [email protected]; "Author" [email protected] 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.

Jun 15 '18 15:06 UgoPoddine

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 [email protected] 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 https://github.com/simonyiszk/csdr/issues/37#issuecomment-397648584, or mute the thread https://github.com/notifications/unsubscribe-auth/Aj7dKAEYlwGhsfnZhqgXOKEemjdSj_WEks5t88t3gaJpZM4Upr3p .

Jun 15 '18 16:06 ki7oxa

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" :

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 ;

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 [email protected]:

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 [email protected] 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 https://github.com/simonyiszk/csdr/issues/37#issuecomment-397648584, 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 https://github.com/simonyiszk/csdr/issues/37#issuecomment-397671000, or mute the thread https://github.com/notifications/unsubscribe-auth/AL2bJyQQRSp6ov6KyJYTCXrqEEiRq3hQks5t893PgaJpZM4Upr3p .

Jun 16 '18 18:06 UgoPoddine

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.

Jan 03 '22 23:01 k8wu

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

Jan 04 '22 10:01 ha7ilm

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:

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:

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

Jan 04 '22 12:01 k8wu

Is there a considerable difference between the two?

Jan 04 '22 19:01 ha7ilm

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_on

Benchmark off: 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.

Jan 05 '22 03:01 k8wu