Re: LF: Bugfix for ebnaut_ifft utility

[Markus Vester <markusvester@aol.com>]

Hi Stefan,

this is not easy to say as it depends on a number of circumstances. In your local test, the difference was quite large (EbN0 = 40.25 dB vs 41.57 dB), but this is because the lack of external noise emphasized the relatively small artifact on the signal. In a more realistic scenario the individual symbols are buried in the noise. Considering an EbNaut sequence with e.g. N=1000 symbols, the signal energy is quasi-randomly spread over 1000 frequency bins. Only one of these bins would be affected or "lost", suggesting an SNR loss on the order of 0.1% power or  0.004 dB.

Best 73,
Markus

-----Ursprüngliche Mitteilung-----
Von: DK7FC <selberdenken@posteo.de>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org>
Verschickt: Mi, 7. Jun 2017 18:49
Betreff: Re: LF: Bugfix for ebnaut_ifft utility

Thanks Markus,

What does minor SNR degradation mean, in dB, and on what does this value depend? (e.g. transmission time, symbol length, etc).

73, Stefan

Am 07.06.2017 17:59, schrieb Markus Vester:

Dear EbNauteers,

I recently stumbled upon a bug in my ebnaut_ifft3a utility, which is used to convert SpecLab FFT export files to IQ wav files. The first step of the inverse FFT is to take the complex conjugate of the data array. Due to the bug, the respective loop was executed only N-1 times, leaving a sign error in the imaginary part of a single bin next to the center frequency. When fed with a high-SNR signal close to SpecLab's center frequency, this can produce strange undulation patterns in the phase display and a minor SNR degradation for the decoder.

The bug has been fixed in version 3b, available on
 http://df6nm.bplaced.net/VLF/fec_tests/ebnaut_ifft3b.zip

Best regards,
Markus (DF6NM)