Advise in piping sound stream to RPITX #37
Comments
|
Ugo, I don't know. You should test the DSP chain manually, part by part. Andras |
|
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.
|
|
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>
.
|
|
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>
.
|
|
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. |
|
I see. What happens if you recompile the code with benchmarking off? |
|
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). |
|
Is there a considerable difference between the two? |
|
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. |
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
The text was updated successfully, but these errors were encountered: