Has someone some experience with RFID tags, in particular EM4100?
For me, this is the first time I approach RFID. I'm developing a U2270B-based reader. The output of U2270B is a generic input pin of a microcontroller (PIC from Microchip).
Now I'm writing the code to decode the protocol I see at the microcontroller input. The tag SHOULD be EM4100 type.
I read EM4100 tags has 64 bits code that is outputted continuously, bit after bit. Each bit is Manchester or Bi-Phase encoded and the bit length is usually 64 clock cycles, that is nominal 125kHz.
So the bit lenght is 512us (bitrate is about 1950bps) and the pulses should have a lenght of 256us or 512us (for example, with Manchester modulation, each bit is coded with a level transition in the middle of the bit period).
Why I see on the oscilloscope a signal output from U2270B with strange pulses length, when the tag is near the inductance? I can see pulses of
256us and 512us lenght, but I see also other strange durations, such as
340us that is at the middle!!! In this condition is very difficult to make a decent decoding.
Any help or similar experience? Could the tag be of different type?
As Jack indicated Manchester encoding has different pulse widths. I'm not sure you get three different widths though.
formatting link
The same is true for bi-phase encoding, just two pulse widths, a bit time and half a bit time.
Is it possible you are looking at a decoded bit stream? That would have arbitrarily long pulse widths, all a multiple of the bit time. But then your 340 us is not an exact multiple like 256 and 512 us.
How do you know what timing to expect? What is your source for this info? What is generating the signal?
I will say this, the coding schemes are intended to facilitate alignment to the transitions. Your decoding should allow for realignment if there is a gap in the data. Saying that, I can't say this is your problem though. The 340 us pulse is hard to explain. Can you provide a little more detail? When you say "pulse", do you also mean the space between the pulses? Do you see more than one oddly timed pulse or gap? Could you post an image or other means of showing the problem area of your pulse train in detail?
For me the pulse is the time the signal is high or low (the time between two *different* edge, rising-falling or falling-rising). So my pulses can be only 1 or 2 bit length, no other values are possible.
The strange pulse I measured (340us) is from a rising edge to the next falling edge, and this is very strange!
I think it could depend if the first edge is synchronized at the beginning of the bit time or at the middle, but I'm not sure.
After reading many times the U2270B datasheet e after many measures with oscilloscope, I found a good solution. I don't like it very much, but it works most of the time.
First step, search for two successive edges (rising-falling or falling-rising) measuring the distance. If it is in the range Tl1-Tl2, it's a long pulse so we are sure we are synchronized to the middle of the bit time so we can continue decoding. If it is in the range Ts1-Ts2, it's a short pulse so we have to continue searching a long pulse. Otherwise there's an error (transponder could be not present).
Now we are at the middle of a time bit. We wait for a Tnext time that is slightly greater than half of a bit time, and then monitor for the next edge. If this edge happens too early (before Ts1) or too late (later than Tl2), there's an error. Otherwise the bit is the signal level just after the edge. Now we are again synchronized at the middle of a bit time and we can continue waiting for Tnext and so on.
The problem is tuning Ts1, Ts2, Tl1, Tl2 and Tnext, that are very large ranges vaguely similar to the theorical values. After many measures with oscilloscope I found good values and now the decoding successes 9 times over 10.
We used to do this in hardware and it used *very* simple hardware. I'm not sure which protocol you are working with, bi-phase or Manchester, they are slightly different. One works with the level and the other adds a transition for one state and omits the transition for the other state. You just need one timing value to discriminate between the long timing and the short... but then we didn't have the third pulse width you are seeing. Once you are sync'd with the correct edge, you use the timing value to tell you if the next edge is the short or long and in one protocol ignore short edges, in the other use the presence of the short edge to set the bit value. Having a third pulse width means something is wrong.
Why not sharing this "hardware" with the newsgroup? :-)
Manchester.
Yes, this in theory. Indeed I started working with this simple logic, but it never worked.
I don't see just a third pulse width, I see that short and long widths are too much variable. The maximum short pulse width is very similar to the minimum long pulse width!
How did you decode the RF signal? I'm using U2270B from Temic (actually Atmel), maybe this is the problem. Indeed take a look at what I found in its datasheet:
--
Figure 9 shows the timing of the Manchester and bi-phase code
in an ideal situation. However, the timing of the code at the
decoder input is affected by various effects of modulation,
demodulation and noise in most applications. THERE IS A JITTER AT
THE RISING AND FALLING EDGE OF THE DATA SIGNAL. ADDITIONALLY, THE
CLOCKS OF THE TRANSPONDER SIGNAL AND THE DECODER SYSTEM ARE
ASYNCHRONOUS. The decoder should evaluate the reader output signal with
the method shown in figure 10 to achieve a maximum range and minimum errors.
Just open your eyes, it is easy to find using something called "Google". It was an RC timing value, a FF and an XOR gate, IIRC. This was my first job in electronics some 40 years ago, so I don't have the schematics.
That's the one where the polarity of the encoded signal after the "important" transition" is the value of the bit. The timeout value inhibits the unimportant edge when present and the direction of the important edge is used to set the value of the bit and timing of the bit cell. Then the timeout starts again. Normally an initial sequence which produces just one transition per bit is set to allow the circuit to synchronize. I think the EM4100 protocol starts with a degenerate case of two transitions per bit with "111111..." as the start. A proper sync sequence for Manchester is 101010... Are you sure this is Manchester and not Biphase as shown at
formatting link
The Biphase signal will produce one pulse per bit for a "11111" sequence and assure proper sync from the start. I would think this would be important for RF signals where a little noise at the start will corrupt the entire signal. But I suppose they deal with that by repetition and checksums, eh?
Then something else is wrong. The encoding/decoding *is* that simple, but if the signal is not right, you can't expect to decode it. Did you ever figure out why you get a 2/3 width pulse? That will foul up every time... or maybe 50%, lol.
That will be very hard to deal with. The idea is that you use timing to discriminate the edge you want to ignore and just use the edge with the information. Do the timing values vary slowly over time or will one message have pulse widths all over the map? If it varies slowly, you can use some sort of PLL or similar to vary your timeout value. But if it varies fast from one bit to the next, I don't know of a way to deal with that.
How is the RF modulated? Is it something you can see on a scope? First make sure the RF signal is right. I'm guessing it is amplitude modulated. Can you try viewing the signal at the "input" pin? Check the pulse timings there so see if the RFID tag is sending what you expect.
If the short pulse timing is as long as the long pulse timing, it is
*not* normal and likely can not be decoded by any means unless the variation is slow and can be compensated by tracking your timing with it. I downloaded the Temic data sheet and I don't see the above section. The Atmel site gives a lot of error pages when I search on U2270B. I found a copy of the Atmel sheet from other sources and I see the same info as the Temic sheet. Where did you get the data sheet you are quoting from?
Ah, it is *not* the data sheet, it is the app note ANT019 that you are quoting from.
Looking at figure 10, you don't need to detect short pulses in Manchester, they are just ignored, so you don't need to use the two timing parameters for short pulses. There is no advantage for detecting the long timing value of the long pulse, what do you do if it doesn't come by that value? So you are left with one timing value. Anything before that value is ignored, anything after is a data transition.
If you see the signal is not possible to decode because of timing variations, then no circuit can decode it reliably. So just how bad are your timing variations? Can you use the parity bits and have multiple reads to find one or two or three that pass parity and all agree?
Yes, a sequence of 9 ones. This sequence appears just one time in the code, because of even parity used in next data field.
On that page Biphase *and* Manchester modulations are described for EM4100 tags. Why are you thinking my tags can't use Manchester? Even if I assume Biphase modulation, the big jitter can't be simply explained.
Yes, you're right. The 64-bits code stored in the tag is continuously transmitted while there's RF power from the reader.
I don't know why this happens. Actually I think this behaviour is intrinsic in my RF complete system: maybe it depends on the circuit (identical to one of application circuits described in the datasheet of U2270B) or on the U2270B or on the low-quality tag. The thing that is sure is the great jitter I see on the scope at the output pin of the U2270B when the tag is in proximity.
Unfortunately, the second you said. I solved relaxing the timing thresholds. The waiting time for the next "important edge" is 340us and not the theoric value of 256us. If I use 256us, I risk to detect "unimportant edges" as important ones.
I'll try to analyze RF signal, until now I checked the demodulated signal at the output of U2270B. Anyway it's very difficult to understand if the signal is the one I would expect: the code is 64bits and is impossible to synchronize the start of the code on the scope.
Sometimes yes.
The short pulse minimum and maximum widths (Ts1 and Ts2) are used in the algorithm suggested in two cases. During the first phase when we are searching for a long pulse: if the detected pulse could be considered short, the search can continue, otherwise if it could be considered long the search is finished, otherwise it is an error. During the second phase, if the edge is not detected before Ts2 from the last "important edge", it is an error. I think this check could be skipped. It's there to understand immediately if something is wrong with the decoding.
The first step is important to search for the "important edge". And any "important edge" is exactly at the end of a long pulse. If this long pulse doesn't appear for a certain time, it's an error (tag is not present?).
Yes, I use parity bits for rows and columns and they are correct. So I'm confident my decoding algorithm is working well. The only problem is that the edges are very "jittered" and sometime the code can't be decoded: the parity bits aren't correct or I see some "important edges" too early since the last "important edges".
No, I'm not saying there is a relation between the two, I'm saying that it is uncommon to start a Manchester code with a series of 1's or 0's which give you a pattern that is not conducive to syncing up. But as long as you get the first edge, you will be fine in that regard.
I'm saying that if it used Biphase coding is used, you get the optimal sequence for syncing up with all 1's.
Ok, so you don't need to read every one right, just enough that you are confident you have the right values. The two dimensional parity bits should give high confidence in a good read.
Good luck with it. Sounds like you have it pretty well under control.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.