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. 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: >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" >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 >elimar@NOSPAMbigfoot.com > >To reply, remove the NOSPAM from the return address. >Stamp out SPAM everywhere!!! > >