Manchester Encode/Decode in Hardware (not FPGA) - Page 1
Forum section: electronics / projects

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 12:12:01 am
content: Someone was discussing a use for a simple circuit to convey data at around 10-20 Mbps and was adding framing for every bit and then the bit and the bit inverted to maintain zero DC! I realized that this was way overkill, but he wants to keep the circuit simple.I remember working with Manchester encoding that adds no overhead bits as such, it simply sends the data and the data inverted by xoring with the clock. Recovery gives data and clock by a fairly simple means. But it was many years ago that I worked on this and I'm not sure the methods we used were robust.I think the encoding can be done easily with a 2x clock, so the clock and data can be xored and sampled so as to be glitch free. The decode we used involved a timing of 3/4 bit, triggered on an edge of the Manchester data, locking out reclocking and also sampling the data. I don't recall just how the clock was recovered, but it was probably just this lockout signal.I think another way is to sample the Manchester at at least 4x the data rate, and performing the obvious logic. As long as the signal stream is sampled at more than 4x (2x the clock), the logic should work. The clock won't be nice and even, but the data can be resampled if that is important I suppose.Any other ideas? I actually found little in a Google search. I think this is done internally in devices rather than with discrete logic solutions these days.

author: nctnico
author_rank: Super Contributor
timestamp: August 04, 2022, 12:15:31 am
content: 'simple manchester decoder' gives lots of hits with Google.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 04, 2022, 12:22:09 am
content: Yeah:https://www.allaboutcircuits.com/technical-articles/how-to-decode-manchester-encoded-data-using-hardware/

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 01:15:58 am
content: Quote from: nctnico on August 04, 2022, 12:15:31 amYes, lots of hits, not much value in what I saw.

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 02:24:06 am
content: Quote from: SiliconWizard on August 04, 2022, 12:22:09 amYes, I already saw this. I don't see useful circuits on that site. They have a page both for coder and decoder. One of the decoder circuits uses internal hardware from an MCU.Thanks

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2022, 05:22:11 am
content: Quote from: gnuarm on August 04, 2022, 02:24:06 amId say the cypress circuit from that site is exactly what you want for a discrete logic implementation. All you need to provide is a clock signal to allow the circuit to sense time, this is easily done in any number of ways, even a 555 timer. Encoder is the same thing, use the same clock circuit to instead feed a XOR gate to encode into manchester.Some form of timing circuitry will always be needed in manchester since clock recovery has to be done in some way. These simple circuits appear to mostly use the blanking method to pick out the correct edge, so your transmitters clock has to be about +/- 25% tolerance for it to decode correctly. This sort of accuracy is easy even for the most basic of RC oscillators.Framing can be the more complicated part. The easiest robust way is likely to use a long series of 0s as a frame delimiter. Say for example 9 bits of 0s is start/end of frame while a data segment is 8bits and 1bit that is always 1. That way you guarantee the 9 sequential 0 bits never happen in an actual data stream. If you are clever you could even use that 9th bit as a parity bit and use odd parity that way the bit will be 1 whenever you have 0x00 as input. This will likely also require the frame start to be 18 bits of 0s instead (in case you send 0x80 0x00)

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 05:41:38 am
content: Quote from: Berni on August 04, 2022, 05:22:11 amExcept that it is using logic delays to guarantee setup time at the FFs. The problem with that is while logic has specified maximum delays, the minimum delays are often not specified, or are very far from the maximum. I've worked on machines before where we had to replace expensive chips until we found one with the right timing. I would need to find another way of implementing that part of the circuit. I think I'd prefer to just sample the data at 4x through a 4 stage shift register (a single chip) and use logic to sort out the outputs. I'd need to work on that a bit as the logic might not be so simple.QuoteYes, I'm aware of that, but this "clock" can be an RC delay. Yeah, I know, linking RCs with digital is bad form, but with CMOS you at least have high input impedance and can use a differential input if required. Not saying that's what I'd do, but I prefer something like that to creating race conditions.QuoteWhat frame??? Just data. They are talking about adding two "frame" bits to EVERYbitsent as a nibble, 1 0 b /b. That requires zeros in the data to sync up, and I realized offers no advantage at all to Manchester.

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2022, 06:07:35 am
content: Quote from: gnuarm on August 04, 2022, 05:41:38 amYep a lot of digital circuitry tends to use those tricks because it makes for less gates to do the same thing. You can still add some picofarads of RC in places to get more margin on the timings.Quote from: gnuarm on August 04, 2022, 05:41:38 amI am talking more about more how to frame bytes/messages so that you can tell where the first and last bit in a packet is.The easy way is to just stop the manchester clock and start it back up on the beginning of each message, but this messes up the AC coupling, likely garbling the first few bits that are sent. So it is preferred to keep the manchester link constantly transmitting, but place a framing protocol on top that can differentiate between a idle bus and actual data being sent. Also in the event of interference on the bus you need some way to sync back up after loosing bits. This long stretch of 0s is what is used for framing on the CAN bus and is very reliable (except that they use bit stuffing to avoid false positives).Framing every 1 bit if information into a 4 bit frame is indeed very inefficient.The proper way is things like 8b/10b encoding, but you indeed wouldn't want to implement that form 74xx logic chips.

author: jbb
author_rank: Super Contributor
timestamp: August 04, 2022, 09:10:05 am
content: HmmmTo throw a curveball into the discussion… Manchester codes etc. assume that the transmission path can only do 1 / 0.If you’re using a wire or something, could you try a DC correct line code like Alternate Mark Encoding (aargh mobile editor won’t paste so I can put link, sorry. Search Wikipedia Bipolar encoding)? Quite simple circuits, but your transmission path needs to handle +1/0/-1 (fine for wires and transformers).

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 12:32:19 pm
content: Quote from: jbb on August 04, 2022, 09:10:05 amYes, I've worked with AMI before, but that requires special hardware interfacing. The +1 and -1 have to be symmetrically balanced voltage and drive and the 0 state must be driven as well, not just tristate. Most importantly, it requires a protocol layer that insures a minimum number of transitions in order to provide a clock, such as B8ZS. I think this is a bit more complicated than what I can do. Sending both the bit and the bit complement, works fine for this data rate. Normally people want to push the data rate, but in this case it's not a problem.

author: gnuarm
author_rank: Super Contributor
timestamp: August 04, 2022, 12:37:33 pm
content: Quote from: Berni on August 04, 2022, 06:07:35 amYes, I know, but I don't play games that require logic as timing elements. I've seen too many sketchy designs that worked intermittently because of such games.QuoteWhat packet? You are assuming this is something that it isn't. It's just a stream of data at this level in the interface.QuoteThat would be needed if there were any idle bits.QuoteExactly. The "proper" way is trying to optimize bandwidth, and other aspects which are not important. So Manchester seems to be very adequate.

author: jonpaul
author_rank: Super Contributor
timestamp: August 04, 2022, 02:14:58 pm
content: Bonjour, See digital audio serial interfaces, SP/DIF, AES/EBU, AES3.Industry std since 1980s. very old problem.Many dedicated encoders/decoders/transcievers, serial stream with embedded clock to 24 bit stereo audio digital or visa versa.MFG: TI, AKM, Burr Brown, ST, Cirrus Logic.Jon

author: S57UUU
author_rank: Regular Contributor
timestamp: August 04, 2022, 02:29:50 pm
content: A manchester modem, that Matjaz S53MV developed for the Slovenian packet radio network is described here:http://lea.hamradio.si/~s53mv/dmostovi.pdfpage 86. Text is in Slovene, but the schematic should be understandable. This thing is well tested, hundreds built, most packet radio 20years ago in Slovenia, Croatia and Italy used this.There were later versions using a lower clock factor (I think 16X ?), but can't find them currently.Marko Cebokli

author: Benta
author_rank: Super Contributor
timestamp: August 05, 2022, 11:34:41 pm
content: I remember this from cassette tape storage (that were Manchester coded) from the very early personal computer years.IIRC, the Manchester decoder worked like tihs:The input signal was fed to an XOR gate, whose output clocked a non-retriggerable, edge-triggered monostable tuned at 3/4 (75%) of the bit time.The output of that clocked a D-FF, whose D input was also connected to the input signal. Its output was fed to the other input of the XOR.The output of the D-FF was the decoded bit stream.Simple and very effective.