Talk:Eb/N0

From Wikipedia, the free encyclopedia

WP:TEL This article is within the scope of WikiProject Telecommunications, an attempt to build a comprehensive and detailed guide to telecommunications on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project as a "full time member" and/or contribute to the discussion.

The noise spectral density in the denominator of this term should in fact be capital-N, subscript-zero. JanCeuleers 13:08, 25 May 2006 (UTC)

Added redirects for correct spelling Dimawik 21:49, 29 October 2006 (UTC)

Contents

[edit] overrevised

Man, this stub sucks. The older, conversational piece was much more informative for people who are actually doing work with this parameter, and it clearly referenced its confusing nature. Wikipedia isn't meant to get choked for style. —Preceding unsigned comment added by 128.171.103.5 (talk)

The previous version was a copyright violation. –Mysid(t) 07:05, 4 August 2006 (UTC)

[edit] some changes

I made some changes. I changed occurrences of CNR (carrier to noise ratio) to the more correct SNR (signal to noise ratio), since not all signals have carriers, and carriers don't convey information; I noted that Eb/N0 is useful in spread spectrum systems, which are generally power limited; and I noted that the "cutoff rate" is now largely obsolete given the discovery of turbo codes that closely approach the Shannon bound. Karn 05:19, 5 June 2007 (UTC)

[edit] Bit/s/Hz

The link bit/s/Hz was removed and once again changed to the home-made unit (bit/s)/Hz, with the comment that bit/s/Hz is ambiguous.

For a list several hundreds books using bit/s/Hz or bits/s/Hz, see [1] and [2]. See also the discussion in Talk:Spectral_efficiency#Bits/s/Hz.

I don't understand why (bit/s)/Hz would be less ambiguous. I have never seen it in literature. So I assume it is okay to put the bit/s/Hz link back?

Mange01 (talk) 22:16, 13 April 2008 (UTC)

The unit bit/s/Hz can mean either (bit/s)/Hz or bit/(s/Hz). Just because others use an ambiguous form is not a good reason for doing so here. I can see no harm in including a link though. Thunderbird2 (talk) 23:23, 13 April 2008 (UTC)
Hmm. Have you ever had a calculator claiming that 20/10/2 is 4? Or that 20 - 10 - 2 is 12? According to the Order of operations article, division and subtraction should be evaluated from the left. I believe you have lots of brilliant novel ideas for improved terminology, but I think it might be a wise idea to stick to established terminology at Wikipedia. :)

Mange01 (talk) 23:37, 13 April 2008 (UTC)

The bit per second (symbol bit/s) is an established unit of data transfer rate. The hertz (symbol Hz) is an established unit of bandwidth. Therefore (bit/s)/Hz can be used as an unambiguous unit of data rate per unit bandwidth. I will request further opinions from WP:MOSNUM. Thunderbird2 (talk) 06:16, 14 April 2008 (UTC)
We generally say that units shouldn't have multiple division operators (/) in them, because it introduces this sort of ambiguity. if what's meant it (bit/s)/Hz, then formally it ought to be bit/s•Hz (that might not be the right dot, but you get the idea). SamBC(talk) 09:59, 14 April 2008 (UTC)
SamBC, did you mean bit/(s·Hz)? That is formally the correct symbol, but it seems somehow less intuitive than (bit/s)/Hz, and in the end means the same thing. What do others think? Thunderbird2 (talk) 11:53, 14 April 2008 (UTC)
I didn't mean to have the parentheses, although that's the sort of dot I meant. I have a feeling that the parentheses are unnecessary by convention as there's usually only one division operator; certainly, that's the format that was used for complex units when I was studying physics: all of the units in the numerator first (with or without dots), solidus, and then all the units in the denominator. SamBC(talk) 14:24, 14 April 2008 (UTC)
The NIST Guide to SI says "to avoid ambiguity, the solidus must not be repeated on the same line unless parentheses are used." I agree; although I can eventually work out what compound symbols with two or more soliduses mean, it slows me down. --Gerry Ashton (talk) 13:49, 14 April 2008 (UTC)
To answer Thunderbird2 more specifically, the parentheses remove the ambiguity: either bit/(s·Hz) or (bit/s)/Hz are unambiguous (note the "unless" part of SP811 rule pointed out by Gerry). Another option is to use exponent notation: bit s−1 Hz−1 or bit·s−1·Hz−1. While there may be consistency issues within an article, or individual preferences that other contributors can agree to, I see no reason to overspecify it as a general rule.
There is good reason for the conventional usage and we shouldn't change the units involved in it; otherwise we could simplify it and not have to worry about one or two divisions, by multiplying out 1 s·Hz = 1, so 1 bit/(s·Hz) = 1 bit. Gene Nygaard (talk) 16:35, 14 April 2008 (UTC)

Thanks everyone for your contributions. To summarise, the main options appear to be

  1. the original bit/s/Hz
  2. (bit/s)/Hz
  3. bit/s·Hz or bit/(s·Hz)
  4. bit·s−1·Hz−1
  5. or just bit

Any preference? Thunderbird2 (talk) 17:07, 14 April 2008 (UTC)

[edit] Discussion

I consider bit/s·Hz to be wrong. Using the conventional order of operations, it is equivalent to (bit/s)Hz. People who already understand the subject thoroughly will probably understand what is meant, but encyclopedias are not written for people who already understand the subject thoroughly. --Gerry Ashton (talk) 17:13, 14 April 2008 (UTC)
bit/s·Hz is just as ambiguous (if not worse, following standard precedence rules). (bit/s)/Hz and bit/(s·Hz) are technically correct, but just look weird, probably because I've never seen them used in practice (can you cite an example?). However, I appreciate that this is what the NIST guidelines would appear to recommend/mandate. bit·s−1·Hz−1 looks less weird, but is a handful to type. Just bit is wrong because "cancelling" the dimensions disguises the meaning of the unit (it would be a bit like cancelling amp hour to a number of coulombs).
The original bit/s/Hz would be my vote, because it's the de facto standard (as per the refs Mange01 cited). However, because it would appear to violate the recommendations at WP:MOSNUM, I would go for bit·s−1·Hz−1 as the next best alternative. Oli Filth(talk) 19:01, 14 April 2008 (UTC)
The ambiguous bit/s/Hz seems by far the most common. Of the unambiguous forms I could only find this, which seems to use #4. Thunderbird2 (talk) 22:47, 14 April 2008 (UTC)
What gets even worse is that in the spectral efficiency there are some three solidi monstrosities. In any case, only #1 or #4 get my vote in the order given by Oli and for the same reasons. Caerwine Caer’s whines 23:33, 14 April 2008 (UTC)
In that case I propose bit·s−1·Hz−1 as the most acceptable of the unambiguouos alternatives. Any objections? Thunderbird2 (talk) 06:12, 15 April 2008 (UTC)
bit·s−1·Hz−1 is occurring in the literature, albeit really seldom. I don't like it because it is not very intuitive, and that it solves a non-problem. Bit/s/Hz is not ambiguous in any way. The unit Bit/sHz would be ambiguous, since it might mistakenly be written as Bit/s·Hz, which is not the same thing. This discussion has already taken place among digital transmission researchers over the whole world. The fact that Google gives 6 hits for "bit s-1 Hz-1" and thousands of hits for "bit/s/Hz" indicates the outcome of the discussion. Mange01 (talk) 07:48, 15 April 2008 (UTC)
Your option 3 includes one acceptable choice, one unacceptable one with a different meaning in standard rules for order of operation (1 bit/s·Hz = 1 bit·Hz/s, with hertz ending up in the numerator rather than denominator). Thus totally unacceptable, invalidating not only that choice, but making any meaningful interpretation of the whole range of options invalid.
OTOH, I don't know how Mange01 gets his Google to distinguish between any combinations which include parentheses somewhere and which do not contain parentheses, and any single search trying to find superscripts in only going to find a part of them, because of the various ways superscripts are written, because the minus sign can be done with several different characters, probably none of which are indexed by Google--but some or all of them do affect Google's word boundaries and exact-phrase determination. Gene Nygaard (talk) 13:17, 15 April 2008 (UTC)
Google books results
For a list several hundreds books using (bit/s}/Hz or (bits/s)/Hz, see [3] and [4].
Actually it is zero.
Notes.
  1. All I did was to add parentheses to the searches Mange01 used in his original posting in this section, copying his sentence down here with the updated links
  2. Same number of hits in either case: 465 and 372 respectively
  3. Obviously, Mange01's searches are of no utility whatsoever in telling us whether "bit/s/Hz" or "(bit/s)/Hz" or any of dozens of other combinations of spaces, parentheses, and other unsearched-for punctuation are included in those hits.
Gene Nygaard (talk) 13:51, 15 April 2008 (UTC)
Note further that you'd still get the very same results if the search term were "bit·s·Hz" and "bits·s·hz" (case insensitive as well as not caring what sort of punctuation separates the "words"). Gene Nygaard (talk) 13:59, 15 April 2008 (UTC)
Come an friends. We can use our eyes and good judgement. Never trust Google hit rates without occular observation of the search results. Actually, I did not see (bit/s)/Hz in any of the above hits, but maybe I gave up too early? Mange01 (talk) 07:00, 16 April 2008 (UTC)

Bits per cycle has been suggested as an alternative below; I would have to disagree with this. Whilst it's true that the units of bit/s/Hz do cancel to this, there are two problems. Firstly, a Google search in the context of spectral efficiency results in only 8 hits (similarly low numbers for other permutations e.g. "bits/cycle"). Secondly, it isn't at all clear what is meant by "cycle" in this context; it's certainly not cycles of the carrier. Oli Filth(talk) 18:58, 17 April 2008 (UTC)

Reference supporting (bit/s)/Hz
After searching for a while I have now found one references supporting (bit/s)/Hz. See L. Becouarn, G. Vareille, P. Pecci, J.F. Marcerou, “3Tbit/s Transmission (301 DPSK channels at 10.709Gb/s) over 10270km with a record efficiency of 0.65(bit/s)/Hz”, in proc. ECOC (2004), post deadline, pp. 62-63. But I think we need a better source as reference if we are going to adopt this notation. Have you found more? Mange01 (talk) 07:48, 18 April 2008 (UTC)

[edit] Survey

I guess it amounts to a question of whether we should make an exception to our own rules here, on the grounds that the double solidus is so widespread. I propose a show of hands for the two main options. Please vote for your preferred option, with brief explanation. The discussion can continue in the above section.

[edit] I prefer bit/s/Hz

  1. It is the established unit in the literature. Wikipedia is not the place to define new unused units. The unit we vote for need support by references. Bit/s/Hz and similar forms (b/s/Hz, bits/s/Hz) together gives about 55000 hits in Google. This unit is not ambigous, since according to the Order of operations article, division and multiplication operators on a line (not under each other) should be evaluated from left to right. Mange01 (talk) 07:08, 18 April 2008 (UTC)
  2. <your signature here>

[edit] I prefer bit·s−1·Hz−1

# The alternative bit/s/Hz is ambiguous (or at best confusing to a non-expert) Thunderbird2 (talk) 08:04, 15 April 2008 (UTC)

  1. Attempts by specialized groups to impose their jargon on the general population should be resisted. --Gerry Ashton (talk) 13:16, 15 April 2008 (UTC)
  2. <your signature here>

[edit] I prefer (bit/s)/Hz

  1. Use (bit/s)/Hz. Brief explanation:
    • That is used in books; the Google searches above don't distinguish those using the parentheses from those not using them.
    • The parentheses really make it clear to everyone. This number is arrived at by dividing a rate expressed in bit/s by a frequency expressed in Hz.
    • It retains the same order, but does so unambiguously.
    • The negative superscripts notation is far less familiar than a slash for division.
    • We've only scratched the surface so far; what about the even more confusion three-solidus combinations of this with a length parameter (m or mi or km or whatever), such as bit/s/Hz/mi? Gene Nygaard (talk) 13:45, 15 April 2008 (UTC)
  2. I agree. Most of the literature on this, like anything, is by experts for experts, for whom there's no question of ambiguity. The parentheses allow unfamiliar readers to see the unit in an unambiguous, pre-parsed, easy-to-digest form, yet the unit is still so similar to the (more standard) parentheses-free version that anyone who knows it one way will immediately recongnize it the other way. :-) --Steve (talk) 17:51, 16 April 2008 (UTC)
  3. The alternative bit/s/Hz is ambiguous (or at best confusing to a non-expert) Thunderbird2 (talk) 06:06, 17 April 2008 (UTC)
  4. I find this to be absolutely unambiguous and quite legitimate. Greg L (talk) 07:25, 19 April 2008 (UTC)
  5. <your signature here>

[edit] I prefer bps/Hz

  1. bps/Hz has 12,800 Google hits. It is more explicit than just "bits" and makes clear that it is a ratio of bandwidth to frequency. —Ben FrantzDale (talk) 19:26, 16 April 2008 (UTC)

[edit] I prefer bits per cycle

  1. Bits per cycle. But we need to mention all the forms that are used. Probably starting with an SI-standard form and then listing the various things that it is called would be good. Dicklyon (talk) 15:12, 17 April 2008 (UTC)

[edit] I prefer a different option (please specify)

  1. <your signature here>

[edit] Inconsequent and complicated notation

  • Section 1 and 2 talks about C/N. Section 3 talks about S/N. I suppose it is the same thing here. The SNR of a modulated passband signal is often denoted CNR. We should go for one of them. From my point of view, it does not matter which.
  • Section 1 talks about fb (channel data rate = gross bit rate). Section 3 talks about R = information rate. I suppose the latter is the useful bit rate exclusive FEC. Then, can you really compare them?
  • I don't understand why the "Shannon limit" section includes a division by two in one equation, and a multiplication by two in another. These factors cancel each other. It makes things complicated. If you remove the division by 2 in the difinition of R_l, you will get the spectral efficiency, which is a common measure, sometimes denoted η. Okay, I know that N0/2 instead of N0 is often used in equations about equivelent baseband models, maybe that is part of the explanation.
S/N=E_b/N_0\cdot\frac{f_b}{B}