Talk:Manchester code/Archive 1

Archive 1

Hz per bit/second

There is nothing dubious about this unit; it is simply the reciprocal of spectral efficiency. Spectral efficiency is measured (typically) in bit/s/Hz, i.e. bit/s per Hz. Crudely put, it is the ratio of the bit-rate vs. the spectral bandwidth used by the coding/modulation scheme. The higher this figure, the better, as it means that you're getting a higher information-rate for the same bandwidth.

The reciprocal of spectral efficiency is in units of Hz per bit/s; clearly the lower this figure is, the better. It describes, crudely, the amount of bandwidth required to transmit a given information rate.

Hz per bit, as was proposed as an alternative, is meaningless (in this context, at least). As a unit, it would imply that the bandwidth is related to the total number of bits transmitted.

This is basic comms theory and maths; so consequently, I've removed the dubious tags.

If you're still not happy, then we can re-write that section to talk about spectral efficiency rather than its reciprocal, because I admit that's not a commonly-used dimension. Oli Filth 01:46, 21 April 2007 (UTC)

The generic nature of Manchester code

It's useful in editing to remember that Manchester code is abstract from the means used to encode and decode it. It is often generated and decoded by software, so we should avoid suggesting (for example) that the decoder is "hardware" (or even that it's necessarily part of an electronic system). Mike Shepherd 11:36, 12 July 2007 (UTC)

Fourier components

Regarding the recent edit with the comment "by definition, a Fourier component is constant", we should distinguish between the "constant" results (the Fourier coefficients) of analysing a given segment of signal and the (typically different) results from analysis of another segment. A communication system exists precisely because these are different. It is in this sense that we might speak of the Fourier components changing in time. Thus (colloquially), we say "the DC component is constant" when we might say (more formally) that "the DC component is the same for any long segment of the signal". But let's remember that there's little point to an article which would satisfy a pure mathematician but which almost no-one else understands.Mike Shepherd 08:16, 25 August 2007 (UTC)

I see your point! However, might I suggest something along the lines of the following as a rewrite, so as to keep "everyone" happy (changes marked in bold):

"The DC component of the encoded signal is not dependent on the data and therefore carries no information, allowing the signal to be conveyed conveniently by media (e.g. radio) that usually do not convey a DC component."

Incidentally, I'm not convinced that radio is the best example here, as it's highly unlikely that anyone would ever try to transmit a baseband signal directly over radio. Any thoughts on this? Oli Filth 10:52, 25 August 2007 (UTC)

I'm easy with either version. I think I was being pedantic when I said that radio does not "usually" convey a DC component. Radio is a good example, but probably we should remove the word "usually". To me, the change from "which" to "that" makes the style colloquial (perhaps because I'm more familiar with British English), so I would never use the second form myself in a formal document. But I think either is OK, particularly if it's OK in American English.Mike Shepherd 14:33, 26 August 2007 (UTC)

Where does the name "Manchester Code" come from?

Does anybody know where the name "Manchester Code" comes from? I have heard several explanantions but none of them did convince me. —The preceding unsigned comment was added by 87.165.10.155 (talk) 20:29, 21 February 2007 (UTC).

Could it be something to do with the Manchester Mark I? Bastie 19:27, 27 February 2007 (UTC)

It's a back-derivation from "Manchester Encoding". (They were English in Manchester). See: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=892877 or the December 2000 IEE ES&E journal —Preceding unsigned comment added by 203.206.162.148 (talk) 02:04, 5 October 2009 (UTC)

Sloppy use of terminology in shortcomings section

Firstly bandwidth is used incorrectly - the bandwidth of a Manchester coded signal is identical to the equivalent baseband signal. The frequency range on a baseband signal goes from DC to the baud rate. The maximum frequency on a Manchester coded line is twice the baud rate (which has implications for cabling, drive circuitry and attenuation), but the minimum frequency is the baud rate itself. The bandwidth is identical - equal to the baud rate in both situations.

Similarly "asynchronous communications" does not relate exclusively to carrier-less transmission standards - other standards may be used such as FSK. For example a 120 baud modem has a bandwidth of 1200 baud or 10 Hz/bit-second since the minimum frequency is 1200 Hz and the maximum 2400 Hz. It is still asynchronous in nature. Crispmuncher (talk) 19:40, 5 May 2010 (UTC)

If by "baseband signal" you mean the signal before line coding, then no, the spectral occupation of Manchester coding is approximately double. Oli Filth^{(talk|contribs)} 17:23, 7 May 2010 (UTC)

The maximum frequency component is double that before coding, but the low frequency components have now gone, leaving approximately the same bandwidth. In principle several manchester coded channels could be frequency multiplexed together making use of this fact, but I doubt that is ever done. The whole purpose of manchester coding is to move the spectrum away from the dead space at the bottom transmission channel which cannot pass DC (or even long strings of 1s or 0s). The half of the spectrum that manchester code is not using remains unusable for anything else so for all practical purposes the bandwidth is doubled. SpinningSpark 18:19, 7 May 2010 (UTC)

Whilst it introduces a null at DC, it's not as simple as simply shifting the PSD along the frequency axis (as I'm sure you appreciate). I haven't got access to any graphing stuff at the moment so I can't check my beliefs, but I'm pretty sure that however you look at it (e.g. 3dB bandwidth, etc.), Manchester coding occupies twice the spectrum of NRZ. Oli Filth^{(talk|contribs)} 18:55, 7 May 2010 (UTC)

Surely there is not much going on below half clock frequency? This is the lowest steady frequency manchester code can produce (string of 101010...). Anything else will introduce shorter, half-width pulses with a correspondingly higher frequency content. SpinningSpark 22:22, 7 May 2010 (UTC)

The PSD of a linear modulation scheme (which Manchester coding is) is that of the underlying pulse shape (assuming random data). So one needs to compare the Fourier transform of a rectangular pulse with that of a pair of consecutive half-width rectangular pulses of opposite polarity. As I mentioned, I haven't currently got access to Excel or Matlab so I can't produce a comparative log-domain graph today; however there's a linear-domain comparative graph on page 39 of this. Clearly, the half-power (3dB) bandwidth of Manchester coding is at least double that of NRZ. Oli Filth^{(talk|contribs)} 09:01, 8 May 2010 (UTC)

Yes, maybe I'm running my mouth without engaging brain. Manchester code can be viewed as phase modulation, and a simplistic rule of thumb for the bandwidth of that is frequency deviation plus twice baseband. So I will now admit I'm wrong and shut up. SpinningSpark 15:01, 8 May 2010 (UTC)

I agree that "asynchronous communications" is an unclear comparison point. Perhaps "non-return-to-zero" (NRZ) should be used instead. Oli Filth^{(talk|contribs)} 09:11, 8 May 2010 (UTC)

Relation with inversion list

I find this to have some similarities with the inversion lists' property of not handling the data, but the transition of the data bits. — Preceding unsigned comment added by 109.50.70.79 (talk) 23:19, 23 February 2012 (UTC)

False statement

The statement "... the encoding of each data bit has at least one transition and occupies the same time. It therefore has no DC component..." (an edit by 203.206.162.148 at 05:37, 2 February 2010‎) is false. Zero DC component requires more than these constraints. An obvious counterexample is a signal which is high for a short time, then low for the rest of the information bit time, this pattern repeated.Mike Shepherd (talk)

 Fixed. I agree that zero DC component requires more than than the constraints you quoted. Feel free to make further improvements. --DavidCary (talk) 05:21, 25 November 2015 (UTC)

Marking data

I have been using Manchester encoding since the mid 70's (1970's, not 1870's as some people in my office claim). There is one piece of information that I did not see anywhere in the article.

Since the Manchester code requires a transition in the middle of a bit, the code can be "broken" by removing this transition for one bit time. This places a data "Mark" in the bit stream. This mark can be either Low or High. A series of marks and bits is used as a header to identify data type and specify the start of the bit stream that follows.

In the day, we referred to this as "Bi-Phase Mark encoding", referring to the use of the mark in the Manchester code. Today, Manchester encoding is still used to transfer data. I currently use it for RFID cards. Hankpollinger (talk) 15:20, 4 June 2015 (UTC)

I agree that information on the system you describe belongs somewhere in Wikipedia.

However, I suspect that it would be better to put information on that system in the biphase mark code article rather than this Manchester code article.

What specific RFID card standard uses that encoding?

Hankpollinger, do you have any WP: reliable sources that describe "Bi-Phase Mark encoding" or similar line codes, or their use in RFID or other applications? --DavidCary (talk) 05:21, 25 November 2015 (UTC)

Aliases

Manchester code is commonly refered to as Bi-phase-level or split phase in telemetry documentation including the Range Commanders Council document IRIG 106. I belive it would be constructive to include these as my search from bi-phase-level did not produce any results. --138.64.8.53 14:09, 30 January 2007 (UTC)Thad Sterling

We have a lot of redirects to here that include biphase but that term is not mentioned in the article. Biphase does appear in Differential Manchester encoding. It is not perfectly clear to me in IRIG 106 that Bi-phase-level is the same as Manchester. ~Kvng (talk) 13:29, 26 March 2020 (UTC)

Manchester code = bi-phase mark code ?

Several articles that I read (perhaps originating from the same source) use bi-phase code and Manchester code as two equivalent terms for the same encoding. The description of "Biphase Mark Coding" here on Wikipedia (http://en.wikipedia.org/wiki/Biphase_Mark_Code) seems to confirm this. A link "see also ..." on this page might be useful (or an explanation where the difference lies).

Thiadmer Riemersma

---

I think the Manchester graph is wrong. The correct bits or drawing should be opposite depending on how you look at it. In Manchester Encoding, a 1-bit transits from negative to positive and vice versa for 0-bit.

SA DIP 25 Swl

Actually there are two types of bit representations and the page explains that. To avoid ambiguity, I have specified the type of encoding displayed on the image. Natrij 23:59, 1 February 2006 (UTC)

---

I think it's important to note here somewhere that the bi-phase mark (and bi-phase space) are commonly referred to in some industries as FM1 and FM0, respectively. It's an important distinction as FM1 or FM0 (bi-phase mark or space) are easily decoded without reference to (absolute) phase at all. This simplicity exists since a transition occurs at the beginning of each bit period. This stands in contrast to Manchester encoded data where the (absolute) change of phase direction must be noted. FM0 and FM1 as common terms probably came about since they don't imply phase sensitity.

Gene Gajewski 11-Mar-2006 71.32.73.216 04:08, 12 March 2006 (UTC)

There is an article on Differential_Manchester_encoding as well as one on BMC. That information would probably be more appropriate there. Though I think this article needs a tad more detail about the differential variation and more obvious link -- maybe it's worth putting this nomenclature there as well. I'd advocate the mention of them here in reference to BMC. I believe differential manchester is subtly different again. Maybe we should merge them all into Biphase Encoding or something?--Ktims 22:24, 31 March 2006 (UTC)

We definitely should have Biphase encoding and Biphase code lead somewhere. Perhaps some merging is in order. Without further study, I'm not clear on the relationship between biphase, Manchester and Differential Manchester. ~Kvng (talk) 13:33, 26 March 2020 (UTC)