Bug in BLE performance simulation

I think there could be a bug in and around these two lines of this Matlab sim.

codeRate = 1/2;

snrVec = EbNo + 10*log10(codeRate) - 10*log10(sps);

The well-known formula mapping EbNo to SNR is SNR = EbNo + 10*log10(fs/B), where fb = information bit rate and B = receiver noise bandwidth, both in Hz. The ratio fb/B can be viewed as a code rate if redundancy is used. The problem is that the code rate is incorrect for the 125 kbps PHY. It's 1 for the 1 Mbps and 2 Mbps version of the PHY, which I think is correct, and 1/2 is correct for the 500 kbps PHY, but it should be 1/8 for the 125 kbps PHY.

Does anyone disagree? If not, I think it's important for someone from the MathWorks team to fix this issue and update this post. Otherwise, because this is publicly viewable on the internet, folks (like me) are going to come to the wrong conclusion about how the 125 kbps PHY should perform!

Answer 1

[Deepak@Mathworks]

Hi Gary,

I don't understand how are you reaching to the conclusion of 125kbps Phy will have a coderate of 1/8

% For Coded PHY's (LE500K and LE125K), the code rate factor is included
% in SNR calculation as 1/2 rate FEC encoder is used.

These lines in the example make it clear that for 500 kbps and 125kbps data rates, we are using a 1/2 FEC which means that if you have x input bits then you are going to add x redundant bits to it for better error rate performance so doesn't matter what data rates you use, your code rate is still going to be 1/2 (input_bits/output_bits = x/2x).

Hope this makes it clear.

Cheers,

Deepak

Answer 2

[Gary Sugar]

Hi Deepak -

The correct formula mapping Eb/N0 to SNR doesn't depend on the code rate per se. It depends on the ratio R of the information rate fb to the channel bandwidth B, i.e., R = fb/B - just like what's stated on the Wiki site. In the case of the 125 kbps PHY, even though rate 1/2 FEC is used, there is also a 4-to-1 pattern mapper that spreads the FEC encoder output by a factor of 4, by mapping each output bit from the FEC encoder onto groups of 4 bits, yielding a 1 Mbps stream that's presented to the FSK modulator. So for the 125 kbps PHY, fb is of course 125 kbps, and because of the pattern mapper, B = 1 MHz, yielding R = 1/8. For the 500 kbps PHY, since there is rate 1/2 FEC but no 4-to-1 pattern mapper, R = 1/2.

Make sense?

Gary

[Deepak@Mathworks]

Gary, in the example, spread factor is defined by sps. Hence the formula is updated to:

snrVec = EbNo - 10*log10(sps); for No FEC case and

snrVec = EbNo + 10*log10(codeRate) - 10*log10(sps); for FEC case.

From my understanding, i think there are two confusions.

1. You want coderate = fb/B but in the example coderate/sps = fb/B
2. You are assuming that it's only happening for 125kbps but not for 500kbps case?

But as you can see in the example sps is defined for both coded as well as non-coded transmissions, hence sps is kept seperate from coderate. Otherwise we will be having a coderate of 1/4 for even non-coded cases which seems wrong.

[Deepak@Mathworks]

Code rate is defined for FEC only: Wikipedia_Link and not for the time diversity which is introduced by the repeatition of bits.

Answer 3

[Gary Sugar]

I'm OK with the way you're handling sps (samples per symbol) in your simulation. You're using it to lower the SNR by 10*log(sps) dB to account for the fact that the receiver will increase the SNR by the same amount using a 1 MHz wide lowpass filter before demodulating the bits. And it's just a constant in the simulation that affects each modulation rate in the same way. It's fine (and correct).

What's not fine, in my opinion, is your formula

snrVec = EbNo + 10*log10(codeRate) - 10*log10(sps);

I think you should re-do it like this:

snrVec = EbNo + 10*log10(fb/B) - 10*log10(sps);

where fb = [2e6 1e6 500e3 125e3], B = 1e6, and sps = 4. If you do it this way, you'll see that your formula(s) and mine will produce exactly the same results for snrVec for all cases except 125 kbps. In that specific case, your formula becomes

snrVec = EbNo + 10*log10(1/2) - 10*log10(sps);

and mine becomes

snrVec = EbNo + 10*log10(1/8) - 10*log10(sps);

So I think your simulatiion is making the 125 kbps performance look 6 dB better than it really is.

You buying it now?

Answer 4

[Alekhya Parisha]

Hi Gary,

Here is a quick mathematical equation for snr

SNR=E/(1 chip*No)*chips/bit*bits/symbol*symbols/sample

= E/(1 chip*No)*spreading factor*log2(M)/sps

We know that Eb = Ec*spreadingFactor then the equation deduces to

=E/(1 bit*No)*log2(M)/sps

For Uncoded modes, SNR = Eb/No -10*log10(sps)

For Coded modes, SNR = Eb/No + 10*log10(k) -10*log10(sps) [Here k is the code rate which is ½ ]

Here Eb/No refers to uncoded Eb/No.

If we consider Ec/No as the simulation parameter then we would have included spreadingFactor but as Eb/No is considered then there is no need to consider spreading factor.

Hope this clarifies your concern.

-Alekhya.

Answer 5

[Gary Sugar]

What does "E" refer to in your formula?

I think we're in agreement on what Eb/No means - it's a commonly used term in digital communications that refers to the received energy per information bit (i.e., without coding or spreading) divided by the noise power spectral density at the receiver.

Answer 6

[Gary Sugar]

One other way for us to try to converge on this is for me to ask this: where did you come up with the formula

snrVec = EbNo + 10*log10(codeRate) - 10*log10(sps) ?

Can you derive it from a commonly used or accepted source? Because I don't think you can. My formula

snrVec = EbNo + 10*log10(fb/B) - 10*log10(sps)

comes directly from the first equation on the Wikipedia site on Eb/No and is written about in many textbooks. The last term is the term you guys added (correctly) to map SNR in the Nyquist bandwidth of the simulation to SNR in the receiver's noise bandwidth.

I'm not going to stop arguing on this until you guys either (1) admit that you have a bug and correct the simulation, or (2) convince me that I'm wrong, which I'm happy to be convinced of. The reason I'm so passionate about this is that many folks are looking at your simulation online and taking it as the gospel on how the BT receiver should perform at various data rates. I keep getting into arguments with folks on other websites about it!

Gary

[Gary Sugar]

Where'd you guys go? Just curious where your heads are on this issue.

[Alekhya Parisha]

Hello Gary,

For repetition coding with repetition length of L, we get a coding gain of 10log10(Rc*dmin) = 10log10( 1/L · L) = 0 dB. Repetition coding does not result in a coding gain, because the minimum distance(dmin) is the same as the code rate(1/L).

For LE125Kbps, the repetition length in the standard is four (L=4) coding gain is 0dB.

snrVec = EbNo + 10*log10(codeRate) - 10*log10(sps)

Here we considered codeRate which corresponds to coding gain i.e.,1/2 same for LE 500 and LE 125 Kbps so we haven't considered 1/4 factor as there won't be any coding gain.

For LE125 Kbps spreading factor(4) needs to be included in the snr calculation.

Hence, snrVec = EbNo + 10*log10(1/8)- 10*log10(sps)

Hope this clarifies you.

[Gary Sugar]

"For LE125 Kbps spreading factor(4) needs to be included in the snr calculation. Hence, snrVec = EbNo + 10*log10(1/8)- 10*log10(sps)"

If you think this is true for LE125 kbps, then it sounds like I've convinced you that you have a bug in your simulation at LE125 kbps. Yes? Because the simulation is using 1/2 in the log10() as it's currently written.