Post by thread:Manchester Data Encoding

>Greetings: > >Does anyone have any info on manchester encoding and decoding. I have Andy >Warren's "psudo code" from his FFE site, and I found a link that appears to be >"dead" at: http://hobbes.king.ac.uk/matt/pic/manchest.html. > >I want to manchester encode a data stream using 16C84's for a radio link and >any *more* help or pointers would be greatly appreciated. I was obviously >hoping someone has some code they could share <g>. > I don't have any PIC code for you, but you sure brought back some memories for me! That gray matter is very wierd stuff! Manchester Coding There is a transition at the middle of each bit period The transition serves a clocking mechanism and also as data A low to high represents a 1 A high to low transition represents a 0 Widely used in LANs, and open-reel data tape drives A simple diagram of how a byte is encoded: www.optimized.com/tech_cmp/manchest.html see also: www.erg.abdn.ac.uk/users/gorry/eg3561/phy-pages/man.html and this one: http://knuth.sirti.org/~clark/cs333/Exam1_s97_key.html (and Exam2) The last referance above is VERY good for people who want to know more about physical data encoding! The objective is to mark all changes in bit values, not the actual values of the bits. But, they put a spin on it to avoid a contant tone in the event of a string of 1's or 0's. This much is called NRZ, "non-return-to-zero" coding. To save on the number of cycles, they use a half-cycle of the main tone as their standard period - this is where their brains came in! The reason it's used is to allow you to transmit twice as much data as FSK for a given bandwidth. If you use 1200 hz as your main frequency, you can actually send data at 2400 baud. But, your bandwidth will exceed 1200 hz in the real world (the math gets heavy). It's became popular for use with data tape drives, since it is somewhat tolerant of WOW and flutter induced timing skews. The first use that I saw of Manchester coding was in the "Don Tarbell" cassette interface for S-100 computers, circa 1979 or 1980. Of course, it was used earlier in mainframe tape drives. Both Ethernet and Token Ring networks also use Manchester - again, because of concern about timing skews. Another concern is that they don't have enough time to decode more advanced encoded signals. Manchester gives you twice as much data as FSK, along with the same timing tolerance as FSK. To get mode data into the same bandwidth, you can opt for GCR - Group code recording. Most disk drives use GCR, because disk drives don't have the same WOW and Flutter problems as tapes. Many hackers like myself who wanted to read "protected" floppy disks on the Apple 2 had to learn about GCR encoding. They called it "nybble encoding", and the good copy programs like LockSmith were called "nybble copy" programs. The book "Beneath Apple DOS" explained the coding in detail. To really pack data, you can use quadrature encoding, as in 9600 baud modems (I think 2400 baud modems use Manchester?). A quarter of a sine wave is used to hold 2 bits of data, I believe. Once you go above 9600, the math gets way over my head! For work over radio waves, the newest coding methods include "feed-forward" error-correcting codes (similar to hamming codes). These extra bits allow for error-correction at the other end without the need to retransmit the data. You pay about 20% extra in overhead, but it can be worth it because you save the "turn-around" latency that modern transceivers have. On the HF bands, CLOVER is the best protocol going! It's totally remarkable - it can dig down below the noise level to read the data. I think they even have a Clover+ out now. On VHF and higher, you don't need sophisticated coding methods because there's much less interferance. Simple FSK is the easiest if you can tolerate low speed, or if you have lots of bandwidth. For highest speed and lowest bandwidth, use real modem chips, as is done with ham radio "packet" protocols. Modem chips are usually far better than anything us hardware hackers can do, short of DSP (Clover uses advanced DSP methods). But, the newest modem chips all use DSP now, too! Eric Engler, KC8YB

I forgot to mention an important part of Manchester coding in my last message. The encoding of the data is very simple, but the decoding is not as easy. The problem arises because you are NOT guaranteed a signal transition at the main clock frequency (FSK does guarantee this transition, and so it is easier to code). The rest of this discussion is about decoding Manchester data. Sometimes it takes a half of one clock to get a transition, and other times it takes 1, or even 1 and a half clocks before you get a signal transition. This makes it difficult to recover the clock that you need to decode the data. There are 4 ways to get the real clock back: 1) Analog Phase-Locked Loop (PLL) 2) Digital PLL 3) one-shot multivibrator-based circuit (Don Tarbell) 4) a digital algorithm to simulate the one-shot circuit Number 1 above is very good, and provides for quicker re-sync after you lose a bit. This is easier to understand if you look at a Manchester signal on a spectrum analyzer - you will see 3 discrete "carrier" frequencies. If your main frequency (which is half the data rate) is 1200 hz, then the other 2 freq's are 600hz and 400hz. Your PLL can simply lock onto the 1200 hz signal. Take the output of that and feed it into a zero-crossing detector, and then your get your data clock: 2400 hz. Number 2 above is just a digital algorithm that does the same thing as the Analog PLL circuit. This method is used by Ethernet chips. People who can code a PIC to do this definitely have my respect! Number 3 above is what made such a big splash with the Tarbell Cassette interface - Don made a very simple "one-shot" circuit hooked up to a couple Flip Flops to detect the location where the missing clock pulses would be. It was so awesome that Byte magazine published the circuit and an explanation. James Electronics (now Jameco) had a big run on the Signetics 8T20 chip (which mysteriously went up in price around that time), which was the one-shot with built-in flip-flops. Every electronics hacker wanted to build one of those circuits! Number 4 is a no-brainer now that every circuit has some kind of micro-controller built-in. You just set up a rather complex set of nested timing loops. The hardest part is to re-sync after losing one or more bits. With a special digital bit pattern, that I can't remember right now :-( , it is possible to guarantee re-sync within a certain number of clocks. The part of this decoding circuit that you need to do in external components is the front-end amp/limiter and zero-crossing detector (ZCD). This ZCD is NOT the same as the one mentioned in Number 1. This Zero-Crossing Detector puts out a short digital pulse on every transition of the input signal through the 0v level (assuming plus and minus swings). That digital pulse is the only input to the PIC. Along with that pulse, you will use the internal PIC timer heavily. End of discussion on Manchester coding. ------ Other clarifications: Group Code Recording (GCR) can be used 2 ways: to improve timing margins OR to improve throughput within a given bandwidth. One method of GCR (published in one of the IEEE journals circa 1980-1981) gives you a change in the frequency spectrum of the encoded signal, such that it improves your timing margins over Manchester. Instead of 1200, 600, and 400 hz, it gives you 1200, 600, and 300 hz. That is a whole octave between "carrier" frequencies - a much improved story for timing margins. This type of GCR has the same approximate throughput as the Manchester code, but is more reliable if your transport medium may introduce slight timing variations (like WOW and flutter of a tape drive). Most GCR methods are used to improve data throughput, since timing margins are not such a big deal with hard disk drives and Microwave radio links. I won't give an example of GCR encoding because it is a difficult subject to explain. I'll just say that it's based on keeping the ability to recover the clock, while also reducing the number of signal transitions. Manchester guarantees a signal transition at least once every 1.5 periods of your main frequency. GCR normally expands that time lag between transitions - often to 2 or 3 periods. Extended periods mean you can raise the data rate while keeping the same general bandwidth. The data itself can not be directly coded - instead you need a lookup table and a translation of "m encoded bits" for "n data bits", where m is always greater than n. This extra baggage comes in bec. of the need to keep the clock syncronized - but the data throughput goes up anyway. Of course, GCR is much harder to encode and decode than Manchester, and should not be used in typical "casual" circuits because of it's complexity. Also, recovering from errors (dropped bits) is almost impossible. On a hard disk, you'll likely lose the entire track's worth of data if you lose just one bit on the track. ---- I think the "feed-forward" error codes I referred to are actually called "FEC" - Forward Error Correction codes. There are several types of these used now, but the idea is the same: make you carry extra bytes with each data packet that can be used (if needed) to automatically correct errors at the distant end. Think of them as being an extension of the "parity" concept. Eric Engler, KC8YB

On Fri, 9 Jan 1998 01:15:30 -0700 "Eric W. Engler" <spam_OUTenglereTakeThisOuTSWCP.COM> writes: > >The encoding of the data is very simple, but the decoding is not >as easy. The problem arises because you are NOT guaranteed a >signal transition at the main clock frequency (FSK does guarantee >this transition, and so it is easier to code). > >The rest of this discussion is about decoding Manchester data. > >Sometimes it takes a half of one clock to get a transition, and >other times it takes 1, or even 1 and a half clocks before you get a >signal transition. This makes it difficult to recover the clock >that you need to decode the data. This is not Manchester data then. In your earlier post, you said correctly that "manchester data has a transition in the center of each bit". There is either 1/2 or one full bit time between transitions. However, special sequences which violate the protocol (missing a required transition) are often used for sync marker bits. The decoder would need extra logic to detect these. It is easier for me to think of the guaranteed transition being at the start of each bit, with an optional transition in the center if needed to set up for the next bit. The simplest possible decoder detects a transition and waits 3/4 of a bit time, ignoring any other transition during this time. Once the decoder gets in sync by receiving a signal with a full bit time between transitions (which occurs when the sequence 01 or 10 is transmitted), the transition detector will be certain to fire only at the start of each bit. The data line can then be sampled at a known point in the bits and correct data decoded. This decoder doesn't work really well in the presence of noise. For recording on disks or tapes or sending over cable, noise is not usually a major problem. The entire block must be re-sent if noise destroys even one bit, so the decoder's ability to re-sync in the middle of the block is not useful. The FM (single-density disk) format is very similar, having one transition per bit for one value of data and two transitions per bit for the other value of data. The same 3/4 bit time timer can be used, but it is necessary to take 2 samples during each bit to determine if a transition occurred in the center. The advantage of this format is that it is not sensitive to inverting the polarity of the signal during recording or transmission. Of course placing a NRZI encoder/decoder around a Manchester system has the same effect. It was realized that a lot of the transitions in FM are not necessary to convey data, so MFM was developed. If a 1 data bit was defined as having 2 transitions, the transition at the start of a 1 is deleted. So a 0 has a transition at the start, and a 1 has a transition in the middle. Additionally, if a 0 follows a 1, it has no transition at all. This guarantees a full bit time minimum betweeen transitions, with a possibility of 1, 1.5 or 2 bit times before the next transition. The minimum and maximum transition intervals are now twice as long, so the same hardware can record data twice as fast. Thus it is called "double density". "High density" disks use the same MFM format, but with better heads and disk materials that can handle twice again the data rate. Simple one-shot decoders do not work for MFM because there is not a guaranteed transition at the start of each bit. In fact, a long string of ones looks exactly like a long string of zeros: a transition each bit time. But the phase of the transitions is different. The decoder typically uses a PLL operating at twice the bit rate, and logic to remember the last bit state and the time since the last transition. Observe that the MFM standard breaks the data to the disk into basic time units of 1/2 the bit time. Each basic time unit may contain a single transition, however the basic time unit which follows one containing a transition is guaranteed to not contain one. Using shorter basic time units, but longer guarantees of nonrepeated transitions allows more data to be recorded on the disk, by more precisely controlling the phase of the data signal. This is the basis of RLL encoding. It uses a basic time unit of 1/3 bit time, with a guarantee of at least 2 but not more than 7 basic time units with no transition after each transition. Conforming to these rules, it is possible to store 8 bits every 16 basic time units. To record on the same hardware that previously used MFM, every 3 basic time units is equivalent to 1 MFM bit. Thus the overall bit rate is 1.5 times that possible from MFM. This format is used on nearly all modern hard disks as well as CD-ROMs (On CD, 17 basic time units store 8 bits. The extra time is supposedly used to "reduce DC content").

Excuse me? I thought one major reason that Manchester encoding was (is?) popular is that it is self clocking, that is, it is easy to decode since the clock and the data are "combined". Manchester is RZ (return to zero) encoding, unlike the familiar serial protocol, which is NRZ (non-return to zero), which means that decoding manchester needs none of the "framing" overhead of the serial protocol, such as start and stop bits. Neither does it require particularly accurate decoder timing, it can tolerate fairly gross timing discrepancies from "nominal", which would render RS232 useless since an FF byte or a 00 byte has no transitions at all, and rely on matched XTAL timing to determine the bit boundaries. I remember some Manchester backup hardware for the ancient Sinclair (or Timex) ZX-81 which used 3 or 4 simple logic IC's to recover the data from a plain old audio cassette recorder (and 3 or for more to encode the data in the first place). Seems to me this should be easy to implement in a PIC. CIAO - Martin. On Fri, 9 Jan 1998 01:15:30 -0700, "Eric W. Engler" <.....englereKILLspam@spam@SWCP.COM> wrote: {Quote hidden}>I forgot to mention an important part of Manchester coding in >my last message. > >The encoding of the data is very simple, but the decoding is not >as easy. The problem arises because you are NOT guaranteed a >signal transition at the main clock frequency (FSK does guarantee >this transition, and so it is easier to code). > >The rest of this discussion is about decoding Manchester data. > >Sometimes it takes a half of one clock to get a transition, and >other times it takes 1, or even 1 and a half clocks before you get a >signal transition. This makes it difficult to recover the clock >that you need to decode the data. > >There are 4 ways to get the real clock back: > > 1) Analog Phase-Locked Loop (PLL) > 2) Digital PLL > 3) one-shot multivibrator-based circuit (Don Tarbell) > 4) a digital algorithm to simulate the one-shot circuit > >Number 1 above is very good, and provides for quicker re-sync >after you lose a bit. This is easier to understand if you look >at a Manchester signal on a spectrum analyzer - you will see 3 >discrete "carrier" frequencies. If your main frequency (which is >half the data rate) is 1200 hz, then the other 2 freq's are 600hz >and 400hz. Your PLL can simply lock onto the 1200 hz signal. >Take the output of that and feed it into a zero-crossing detector, >and then your get your data clock: 2400 hz. > >Number 2 above is just a digital algorithm that does the same >thing as the Analog PLL circuit. This method is used by Ethernet >chips. People who can code a PIC to do this definitely have >my respect! > >Number 3 above is what made such a big splash with the Tarbell >Cassette interface - Don made a very simple "one-shot" circuit >hooked up to a couple Flip Flops to detect the location where >the missing clock pulses would be. It was so awesome that Byte >magazine published the circuit and an explanation. James >Electronics (now Jameco) had a big run on the Signetics 8T20 chip >(which mysteriously went up in price around that time), which was >the one-shot with built-in flip-flops. Every electronics >hacker wanted to build one of those circuits! > >Number 4 is a no-brainer now that every circuit has some kind >of micro-controller built-in. You just set up a rather complex >set of nested timing loops. The hardest part is to re-sync after >losing one or more bits. With a special digital bit pattern, that >I can't remember right now :-( , it is possible to guarantee >re-sync within a certain number of clocks. > >The part of this decoding circuit that you need to do in external >components is the front-end amp/limiter and zero-crossing >detector (ZCD). This ZCD is NOT the same as the one mentioned >in Number 1. This Zero-Crossing Detector puts out a short digital >pulse on every transition of the input signal through >the 0v level (assuming plus and minus swings). That digital >pulse is the only input to the PIC. Along with that pulse, >you will use the internal PIC timer heavily. > >End of discussion on Manchester coding. > >------ > >Other clarifications: > >Group Code Recording (GCR) can be used 2 ways: to improve timing >margins OR to improve throughput within a given bandwidth. > >One method of GCR (published in one of the IEEE journals circa >1980-1981) gives you a change in the frequency spectrum of the >encoded signal, such that it improves your timing margins over >Manchester. Instead of 1200, 600, and 400 hz, it gives you 1200, >600, and 300 hz. That is a whole octave between "carrier" >frequencies - a much improved story for timing margins. This >type of GCR has the same approximate throughput as the Manchester >code, but is more reliable if your transport medium may introduce >slight timing variations (like WOW and flutter of a tape drive). > >Most GCR methods are used to improve data throughput, since timing >margins are not such a big deal with hard disk drives and Microwave >radio links. > >I won't give an example of GCR encoding because it is a difficult >subject to explain. I'll just say that it's based on keeping the >ability to recover the clock, while also reducing the number of >signal transitions. Manchester guarantees a signal transition at >least once every 1.5 periods of your main frequency. GCR normally >expands that time lag between transitions - often to 2 or 3 periods. >Extended periods mean you can raise the data rate while keeping the >same general bandwidth. > >The data itself can not be directly coded - instead you need a >lookup table and a translation of "m encoded bits" for "n data bits", >where m is always greater than n. This extra baggage comes in bec. >of the need to keep the clock syncronized - but the data throughput >goes up anyway. > >Of course, GCR is much harder to encode and decode than Manchester, >and should not be used in typical "casual" circuits because of >it's complexity. Also, recovering from errors (dropped bits) is >almost impossible. On a hard disk, you'll likely lose the entire >track's worth of data if you lose just one bit on the track. > >---- > >I think the "feed-forward" error codes I referred to are actually >called "FEC" - Forward Error Correction codes. There are several >types of these used now, but the idea is the same: make you carry >extra bytes with each data packet that can be used (if needed) to >automatically correct errors at the distant end. Think of them as >being an extension of the "parity" concept. > > >Eric Engler, KC8YB Martin R. Green elimarKILLspamNOSPAMbigfoot.com To reply, remove the NOSPAM from the return address. Stamp out SPAM everywhere!!!

> Excuse me? I thought one major reason that Manchester encoding was > (is?) popular is that it is self clocking, that is, it is easy to > decode since the clock and the data are "combined". Manchester is RZ > (return to zero) encoding, unlike the familiar serial protocol, which > is NRZ (non-return to zero), which means that decoding manchester > needs none of the "framing" overhead of the serial protocol, such as > start and stop bits. Neither does it require particularly accurate > decoder timing, it can tolerate fairly gross timing discrepancies from > "nominal", which would render RS232 useless since an FF byte or a 00 > byte has no transitions at all, and rely on matched XTAL timing to > determine the bit boundaries. Manchester coding uses two lengths of pulse: long and short. Within valid data, short pulses always occur in pairs. Consequently, it is fairly easy to design a manchester decoder which can adapt relatively quickly to changes in data rate, and the "paired short pulse" requirement adds a little bit of error detection. Linear time code readers for videotape can often read data written at 2400bps nominal when the tape is moved anywhere from 1/10 to 10x normal speed (they can also go both forward and backward--kinda neat!) In some other long/short coding schemes, the lengths of long/short pulses differ in a non-2:1 ratio. I2of5 barcodes code each decimal digit as either 2 wide and 3 narrow bars, or 2 wide and 3 narrow spaces; the wide parts are 2.5x as wide as the narrow. Schemes like Manchester coding are easier to encode in hardware than those which use variable or fractional width pulses, but decoding of corruptible signals may be more reliable with variable-width techniques.

Ok, I think we are getting confused here. Manchester encoding is not based on pulse width, but on the direction of the level transition in the middle of each bit. There are synchronous schemes that do depend on pulse width, and which are also fairly immune to speed mismatches between encoder and decoder, but they are not Manchester. I also remember another type of Manchester encoding (a quick search of the web reveals this is called "differential Manchester") in which one logic level is represented by a level change at the beginning of a bit boundary followed by an opposite level change in either direction at the middle of the bit, and the other logic level is coded a NO level change at the beginning of the bit, but again, a change in either direction in the middle of the bit. Effectively, the only real difference between regular and differential Manchester is the location of the "intelligence" in the bit stream. With one it is at the start of the bit boundary, with the other it is in the middle. CIAO - Martin. On Fri, 9 Jan 1998 13:31:13 -0600, John Payson <.....supercatKILLspam.....MCS.NET> wrote: {Quote hidden}>> Excuse me? I thought one major reason that Manchester encoding was >> (is?) popular is that it is self clocking, that is, it is easy to >> decode since the clock and the data are "combined". Manchester is RZ >> (return to zero) encoding, unlike the familiar serial protocol, which >> is NRZ (non-return to zero), which means that decoding manchester >> needs none of the "framing" overhead of the serial protocol, such as >> start and stop bits. Neither does it require particularly accurate >> decoder timing, it can tolerate fairly gross timing discrepancies from >> "nominal", which would render RS232 useless since an FF byte or a 00 >> byte has no transitions at all, and rely on matched XTAL timing to >> determine the bit boundaries. > >Manchester coding uses two lengths of pulse: long and short. Within valid >data, short pulses always occur in pairs. Consequently, it is fairly easy >to design a manchester decoder which can adapt relatively quickly to changes >in data rate, and the "paired short pulse" requirement adds a little bit of >error detection. Linear time code readers for videotape can often read data >written at 2400bps nominal when the tape is moved anywhere from 1/10 to 10x >normal speed (they can also go both forward and backward--kinda neat!) > >In some other long/short coding schemes, the lengths of long/short pulses >differ in a non-2:1 ratio. I2of5 barcodes code each decimal digit as >either 2 wide and 3 narrow bars, or 2 wide and 3 narrow spaces; the wide >parts are 2.5x as wide as the narrow. Schemes like Manchester coding >are easier to encode in hardware than those which use variable or fractional >width pulses, but decoding of corruptible signals may be more reliable >with variable-width techniques. Martin R. Green EraseMEelimarspam_OUTTakeThisOuTNOSPAMbigfoot.com To reply, remove the NOSPAM from the return address. Stamp out SPAM everywhere!!!

>>Sometimes it takes a half of one clock to get a transition, and >>other times it takes 1, or even 1 and a half clocks before you get a >>signal transition. This makes it difficult to recover the clock >>that you need to decode the data. > >This is not Manchester data then. In your earlier post, you said >correctly that "manchester data has a transition in the center of each >bit". There is either 1/2 or one full bit time between transitions. >However, special sequences which violate the protocol (missing a required >transition) are often used for sync marker bits. The decoder would need >extra logic to detect these. You're correct. I got it confused with MFM. I believe MFM is the one I described regarding the 3 carrier freq's. I remember playing around with it, but the terminology is not fresh in my mind. >This is the basis of RLL encoding. It uses a basic time unit of 1/3 bit >time, with a guarantee of at least 2 but not more than 7 basic time units >with no transition after each transition. Conforming to these rules, it >is possible to store 8 bits every 16 basic time units. To record on the >same hardware that previously used MFM, every 3 basic time units is >equivalent to 1 MFM bit. Thus the overall bit rate is 1.5 times that >possible from MFM. This format is used on nearly all modern hard disks >as well as CD-ROMs (On CD, 17 basic time units store 8 bits. The extra >time is supposedly used to "reduce DC content"). Indeed, RLL is one type of Group Code Recording. The lookup tables ensure that you will never have too many 0's or 1's in a row. I'll try to come up with a better explanation of GCR. As others have noted, Manchester itself is not so hard to decode. You are guaranteed one transition for each bit of data. That must be why it's used on TV remotes - not necessarily because it's efficient, but just because it's easy to work with. Eric Engler

At 05:55 PM 1/9/98 GMT, you wrote: >One doubt: > >Still referring to my tones via phone lines problem, will I get any benefit >by using Manchester encoding in my transmission ? > >I understand the advantages of a synchronous approach when you are recording >the data on a cassette, but how about phone line transmission ? > Phone lines are a little different in their frequency spectrum. They don't do good with 300 hz tones, so MFM is not a reasonable method. However, Manchester is still fine, but not optimum. It would give you two tones an octave apart. The biggest concern with phone lines is "Group delay distortion". This is basically a inconsistant phase shift throuhout the frequency range. To minimize this type of distortion, your tones should be closer together. For example, if you're using 1200 hz with Manchester, the low tone is 600 hz. Both tones are well within the passband, but the delay of 600 hz will likely be different than the delay of 1200 hz. For ease of use and good performance, it's best to use real modem chips. Some of them are even good enough to automatically compensate for group delay distortion. Only the absolute lowest cost designs should use Manchester, or FSK, over a phone line. It will work, but it's easier and fairly cheap to use real modem chips. One popular one was from TI - I think it was only a 1200 baud chip, but it was easy to interface to and cheap. I've heard that it may not be available any more - I can't remember the part number. Does anyone know of some inexpensive modem chips? Please give us some part numbers. Eric Engler

Martin, I also recall that Manchester's popularity was the self clocking and another advantage was there was always a bit level change which we took advantage of in the early 80's with an IR system. With NRZ we could'nt drive the IR LEDs as hard. I was trying to find the encoder/decoder chips we used. I think it was from Harris but I have their recent data book set and I could'nt find it. I think it was HD3<something>. I thought that I still had a pair but I still have old surface mount 54 series TTL from the 60's and 1702's... This has'nt made it to my current inventory data base ;-) With Manchester code, the 1's change at the leading half of the time slot and the 0's change in the trailing half of the time slot. Another related scheme is Bi-Phase (the chips we used did both). In this case, 1's are at the middle of the time slot and 0's occupy the full time slot. Basically, the 1's occur at the clock rate and the 0's occur at 1/2 the clock rate. - Tom At 04:55 PM 1/9/98 GMT, you wrote: {Quote hidden}>Excuse me? I thought one major reason that Manchester encoding was >(is?) popular is that it is self clocking, that is, it is easy to >decode since the clock and the data are "combined". Manchester is RZ >(return to zero) encoding, unlike the familiar serial protocol, which >is NRZ (non-return to zero), which means that decoding manchester >needs none of the "framing" overhead of the serial protocol, such as >start and stop bits. Neither does it require particularly accurate >decoder timing, it can tolerate fairly gross timing discrepancies from >"nominal", which would render RS232 useless since an FF byte or a 00 >byte has no transitions at all, and rely on matched XTAL timing to >determine the bit boundaries. > >I remember some Manchester backup hardware for the ancient Sinclair >(or Timex) ZX-81 which used 3 or 4 simple logic IC's to recover the >data from a plain old audio cassette recorder (and 3 or for more to >encode the data in the first place). > >Seems to me this should be easy to implement in a PIC. > >CIAO - Martin. > >On Fri, 9 Jan 1998 01:15:30 -0700, "Eric W. Engler" <KILLspamenglereKILLspamSWCP.COM> >wrote: > >>I forgot to mention an important part of Manchester coding in >>my last message. >> >>The encoding of the data is very simple, but the decoding is not >>as easy. The problem arises because you are NOT guaranteed a >>signal transition at the main clock frequency (FSK does guarantee >>this transition, and so it is easier to code). >> >>The rest of this discussion is about decoding Manchester data. >> >>Sometimes it takes a half of one clock to get a transition, and >>other times it takes 1, or even 1 and a half clocks before you get a >>signal transition. This makes it difficult to recover the clock >>that you need to decode the data. >> >>There are 4 ways to get the real clock back: >> >> 1) Analog Phase-Locked Loop (PLL) >> 2) Digital PLL >> 3) one-shot multivibrator-based circuit (Don Tarbell) >> 4) a digital algorithm to simulate the one-shot circuit >> >>Number 1 above is very good, and provides for quicker re-sync >>after you lose a bit. This is easier to understand if you look >>at a Manchester signal on a spectrum analyzer - you will see 3 >>discrete "carrier" frequencies. If your main frequency (which is >>half the data rate) is 1200 hz, then the other 2 freq's are 600hz >>and 400hz. Your PLL can simply lock onto the 1200 hz signal. >>Take the output of that and feed it into a zero-crossing detector, >>and then your get your data clock: 2400 hz. >> >>Number 2 above is just a digital algorithm that does the same >>thing as the Analog PLL circuit. This method is used by Ethernet >>chips. People who can code a PIC to do this definitely have >>my respect! >> >>Number 3 above is what made such a big splash with the Tarbell >>Cassette interface - Don made a very simple "one-shot" circuit >>hooked up to a couple Flip Flops to detect the location where >>the missing clock pulses would be. It was so awesome that Byte >>magazine published the circuit and an explanation. James >>Electronics (now Jameco) had a big run on the Signetics 8T20 chip >>(which mysteriously went up in price around that time), which was >>the one-shot with built-in flip-flops. Every electronics >>hacker wanted to build one of those circuits! >> >>Number 4 is a no-brainer now that every circuit has some kind >>of micro-controller built-in. You just set up a rather complex >>set of nested timing loops. The hardest part is to re-sync after >>losing one or more bits. With a special digital bit pattern, that >>I can't remember right now :-( , it is possible to guarantee >>re-sync within a certain number of clocks. >> >>The part of this decoding circuit that you need to do in external >>components is the front-end amp/limiter and zero-crossing >>detector (ZCD). This ZCD is NOT the same as the one mentioned >>in Number 1. This Zero-Crossing Detector puts out a short digital >>pulse on every transition of the input signal through >>the 0v level (assuming plus and minus swings). That digital >>pulse is the only input to the PIC. Along with that pulse, >>you will use the internal PIC timer heavily. >> >>End of discussion on Manchester coding. >> >>------ >> >>Other clarifications: >> >>Group Code Recording (GCR) can be used 2 ways: to improve timing >>margins OR to improve throughput within a given bandwidth. >> >>One method of GCR (published in one of the IEEE journals circa >>1980-1981) gives you a change in the frequency spectrum of the >>encoded signal, such that it improves your timing margins over >>Manchester. Instead of 1200, 600, and 400 hz, it gives you 1200, >>600, and 300 hz. That is a whole octave between "carrier" >>frequencies - a much improved story for timing margins. This >>type of GCR has the same approximate throughput as the Manchester >>code, but is more reliable if your transport medium may introduce >>slight timing variations (like WOW and flutter of a tape drive). >> >>Most GCR methods are used to improve data throughput, since timing >>margins are not such a big deal with hard disk drives and Microwave >>radio links. >> >>I won't give an example of GCR encoding because it is a difficult >>subject to explain. I'll just say that it's based on keeping the >>ability to recover the clock, while also reducing the number of >>signal transitions. Manchester guarantees a signal transition at >>least once every 1.5 periods of your main frequency. GCR normally >>expands that time lag between transitions - often to 2 or 3 periods. >>Extended periods mean you can raise the data rate while keeping the >>same general bandwidth. >> >>The data itself can not be directly coded - instead you need a >>lookup table and a translation of "m encoded bits" for "n data bits", >>where m is always greater than n. This extra baggage comes in bec. >>of the need to keep the clock syncronized - but the data throughput >>goes up anyway. >> >>Of course, GCR is much harder to encode and decode than Manchester, >>and should not be used in typical "casual" circuits because of >>it's complexity. Also, recovering from errors (dropped bits) is >>almost impossible. On a hard disk, you'll likely lose the entire >>track's worth of data if you lose just one bit on the track. >> >>---- >> >>I think the "feed-forward" error codes I referred to are actually >>called "FEC" - Forward Error Correction codes. There are several >>types of these used now, but the idea is the same: make you carry >>extra bytes with each data packet that can be used (if needed) to >>automatically correct errors at the distant end. Think of them as >>being an extension of the "parity" concept. >> >> >>Eric Engler, KC8YB > > >Martin R. Green >RemoveMEelimarTakeThisOuTNOSPAMbigfoot.com > >To reply, remove the NOSPAM from the return address. >Stamp out SPAM everywhere!!! > >