The seleae logic analyser did a good job of decoding this because if you can see, the variation between long and short pulses in some cases are well outside most algorithms to decode, the MLX90109 data sheet says how the built in manchester decoder will make this easy, all you have to do is check for a 50% duty cycle clock and clock the binary on the positive clock pulse.

To save you doing this I have two working circuits none of which produce anything like a 50% duty cycle, in fact the clock signal is just a mirror of the manchester data at twice the frequency. so what is going wrong?

The data sheet is very poor on this and to prove it works I’ve ordered the MLX90109 development kit, hopefully using this I should have some more positive news next time.

Of course I’m only getting snatches of times between work and sleep to do this so I am not giving it the full attention it deserves. The other option of course is to write a more fuzzy manchester decoder and ignore the built in decoder and this may be what I will do if I dont make any progress on finding the problem with the decoder.

Above is the 64 bit raw Manchester Encoded data stream coming out of the data pin on the MLX90109 decoder of the Mobile terminal board. I have captured it using the Saleae Logic analyser which conveniently has a Manchester decoding option. (If you havent got one of these analysers I seriously recommend buying one.)

If you download the EM4100 RFID chip technical manual you will see you can get it in 3 options, Manchester encoding, BiPhase Encoding and Phase shift encoding. All the cheap RFID tags out there I have seen are Manchester encoded so for my particular device I will concentrate on this. (though the principles are identical for the others)

Before you bring an RFID tag into the proximity of the mobile systems RFID coil, the data line will either contain no data or random gibberish. Once it begins decoding something similar to the above data stream will emerge.

The tag I am decoding has the number 0007666343 printed on it so how do I get from the above gibberish to 0007666343?

There are already some very good write ups on this, but there is no harm in repeating them again. The diagram below is a copy of the one in the EM4100 technical document and if you got here via google, you’ve probably seen it on several sites.

The data stream is read from top to bottom and from left to right. So the 64 bits are made up of 9 logic ‘1’s as a preamble, followed by 2 even parity hex characters with the manufacturer version, followed by 8 even parity hex characters with the tags number, then the 4 column parity bits and finally a stop ‘0’ bit.

The pre-amble is important in two ways:

1. Firstly in manchester encoding it generates our lowest bit rate square wave which allows our decoding mpu to sample and deterime the bit rate.
2. Secondly, the nine  ‘1’s are unique in the data stream and allow us to determine where the data starts. * (See last point below)

The second line D00, D01, D02, D03 deocdes into a hex character which in the above case is %0001, because only one bit is set, and we are even parity, P0 is therefore set to a 1. Ignoring the pre-amble and putting all our bits from above into the above table we get:

The Version Number of the Tag is therefore 0x12 and the Unique ID of the tag is 0x0074FAA7 which when converted to base 10 (Decimal) is 0007666343 which is the number that is printed on the tag. Note we always convert to 10 digits and include the leading zeros.

The column parity column works the same as the row parity so on column 1 we have 00001110 which is 3 ‘1’s set so we add a ‘1’ in the parity column to make it ‘4’ an even number.

the last bit is always ‘0’ and the stream the repeats the sequence without a break (hence the need to find the pre-amble!).

Note that we do not require the version number of the tag and it is normally not printed on the tag, technically there could be the same number from two different manufacturers, but practically you have more chances of winning the lottery than this happening.

Hopefully it helps someone.

* Note the observant amongst you may have noticed that the series of zeros in the middle of the data stream look like they could be mistaken for the pre-amble so how do you know if it is or not?

The most simple way for an MPU to decode manchester is to split each data bit into two.

When we get a transition from low to high we have a logic ‘1’ so the bitstream will be ’01’

When we get a transition from high to low we have a logic ‘0’ so the bitstream will be ’10’

If you see ’00’ or ’11’ in the bitstream you have an invalid combination and you have probably got your waveform sampling 180 degrees out of phase (you chose poorly) to fix you just move the sample window forward by a bit length and try again.

Now to write some code…