Ideas
Follow


Martin Ryba

AWGN SNR calibration for band limited signals

Martin Ryba on 7 Nov 2023
Latest activity Reply by Jon on 12 Dec 2023

Seeing a colleague make this mistake (one I've had to fix multiple times in other's work too) makes me want to ask the community: would you like the awgn() function/blocks to give the option for creating a SNR at the bandwidth of the signal? Your typical flow is something like this:
  • Create a signal, usually at some nominal upsampling factor (e.g., 4) such that it's now nicely over sampled, especially if you're using a RRC or similar pulse shaping filter.
  • Potentially add a frequency offset (which might make the sample frequency even higher)
  • Add AWGN channel model for a desired SNR
  • Put this into your detector/receiver model
The problem is, when someone says, "I'm detecting XYZ at foo SNR," it should not magically improve as a function of the oversample. The problem isn't that awgn() generates white noise, that's what it's supposed to do and the typical receiver has noise across the entire band. The problem is that SNR is most properly defined as the signal power over the noise power spectral density times the signal's noise equivalent bandwidth. Now I looked and there's no handy function for computing NEBW for an input signal (there's just a function for assessing analysis windows). In practice it can get a bit tricky. The occupied bandwidth or HPBW are often close enough to the NEBW, we're usually not haggling over hundredths of a dB. So, in my not so humble opinion, the "measured" flag for awgn() should give an option for bandwidth matching or at least document the behavior better in the help page. All too often I'm seeing 3-6 (or worse) dB errors because people aren't taking the signal's bandwidth into account.

1 Comment

Jon
Jon on 12 Dec 2023
Yes

See Also

Tags