Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFID tag EM4100: strange protocol
1,126 views
Skip to first unread message
pozz
May 24, 2013, 6:03:51 PM5/24/13
to
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?
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?
Jack
May 25, 2013, 3:44:07 AM5/25/13
to
pozz <pozz...@gmail.com> wrote:
> 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?
It's normal.
> 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?
With Manchester decoding you can have pulses (measuring time between
risign edge) of 1, 1.5 and 2 bit in length.
__ __
1 bit: __| |__|
____ __
1.5 bit: __| |__| |__
____ __
2 bit: __| |––|
Here:
http://www.freescale.com/files/microcontrollers/doc/app_note/AN3015.pdf
http://www.atmel.com/images/doc9164.pdf
There is some theory and some example code.
Be careful with the EM4100 coding because you have to put the 8 received
byte in a matrix and do some parity test on the rows and on the columns:
http://www.priority1design.com.au/em4100_protocol.html
Bye Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
rickman
May 25, 2013, 11:28:42 AM5/25/13
to
not sure you get three different widths though.
http://en.wikipedia.org/wiki/Manchester_code
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?
--
Rick
pozz
May 25, 2013, 7:15:43 PM5/25/13
to
Il 25/05/2013 09:44, Jack ha scritto:
> pozz <pozz...@gmail.com> wrote:
>
>> 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?
>
> It's normal.
> With Manchester decoding you can have pulses (measuring time between
> risign edge) of 1, 1.5 and 2 bit in length.
>
> __ __
> 1 bit: __| |__|
> ____ __
> 1.5 bit: __| |__| |__
> ____ __
> 2 bit: __| |––|
For me the pulse is the time the signal is high or low (the time between
> pozz <pozz...@gmail.com> wrote:
>
>> 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?
>
> It's normal.
> With Manchester decoding you can have pulses (measuring time between
> risign edge) of 1, 1.5 and 2 bit in length.
>
> __ __
> 1 bit: __| |__|
> ____ __
> 1.5 bit: __| |__| |__
> ____ __
> 2 bit: __| |––|
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.
> Here:
> http://www.freescale.com/files/microcontrollers/doc/app_note/AN3015.pdf
> http://www.atmel.com/images/doc9164.pdf
>
> There is some theory and some example code.
>
> Be careful with the EM4100 coding because you have to put the 8 received
> byte in a matrix and do some parity test on the rows and on the columns:
>
> http://www.priority1design.com.au/em4100_protocol.html
pozz
May 28, 2013, 4:59:51 AM5/28/13
to
Il 25/05/2013 00:03, pozz ha scritto:
> [...]
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.
> [...]
> Any help or similar experience? Could the tag be of different type?
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.
rickman
May 28, 2013, 7:22:13 PM5/28/13
to
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.
--
Rick
pozz
May 29, 2013, 2:30:05 AM5/29/13
to
Il 29/05/2013 01:22, rickman ha scritto:
>> [...]
> I'm
> not sure which protocol you are working with, bi-phase or Manchester,
> they are slightly different.
Manchester.
> 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...
Yes, this in theory. Indeed I started working with this simple logic,
but it never worked.
> but then we didn't have the third pulse width
> you are seeing.
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!
> 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.
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.
---
The method described in Figure 10 is similar to the algorithm I have
described. It seems the jitter I measured is normal.
>> [...]
>> 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.
Why not sharing this "hardware" with the newsgroup? :-)
>> 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 it never worked.
> but then we didn't have the third pulse width
> you are seeing.
are too much variable. The maximum short pulse width is very similar to
the minimum long pulse width!
> 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.
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.
---
The method described in Figure 10 is similar to the algorithm I have
described. It seems the jitter I measured is normal.
rickman
May 29, 2013, 6:08:10 PM5/29/13
to
On 5/29/2013 2:30 AM, pozz wrote:
> Il 29/05/2013 01:22, rickman ha scritto:
> >> [...]
>>> 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.
>
> Why not sharing this "hardware" with the newsgroup? :-)
Just open your eyes, it is easy to find using something called "Google".
> Il 29/05/2013 01:22, rickman ha scritto:
> >> [...]
>>> 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.
>
> Why not sharing this "hardware" with the newsgroup? :-)
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.
>> I'm
>> not sure which protocol you are working with, bi-phase or Manchester,
>> they are slightly different.
>
> Manchester.
"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
http://www.priority1design.com.au/em4100_protocol.html
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?
>> 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...
>
> Yes, this in theory. Indeed I started working with this simple logic,
> but it never worked.
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.
>> but then we didn't have the third pulse width
>> you are seeing.
>
> 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!
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.
>> 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.
>
> 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:
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.
> 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.
> ---
>
> The method described in Figure 10 is similar to the algorithm I have
> described. It seems the jitter I measured is normal.
*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?
--
Rick
pozz
May 30, 2013, 12:31:42 PM5/30/13
to
Il 30/05/2013 00:08, rickman ha scritto:
> On 5/29/2013 2:30 AM, pozz wrote:
>> Why not sharing this "hardware" with the newsgroup? :-)
>
> 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.
Ah, ok, I got it now.
> On 5/29/2013 2:30 AM, pozz wrote:
>> Why not sharing this "hardware" with the newsgroup? :-)
>
> 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.
>>> I'm
>>> not sure which protocol you are working with, bi-phase or Manchester,
>>> they are slightly different.
>>
>> Manchester.
>
> 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.
code, because of even parity used in next data field.
> A proper
> sync sequence for Manchester is 101010... Are you sure this is
> Manchester and not Biphase as shown at
>
> http://www.priority1design.com.au/em4100_protocol.html
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.
> 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?
transmitted while there's RF power from the reader.
>>> 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...
>>
>> Yes, this in theory. Indeed I started working with this simple logic,
>> but it never worked.
>
> 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.
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.
>>> but then we didn't have the third pulse width
>>> you are seeing.
>>
>> 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!
>
> 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.
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.
>>> 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.
>>
>> 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:
>
> 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.
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.
>> 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.
>> ---
>>
>> The method described in Figure 10 is similar to the algorithm I have
>> described. It seems the jitter I measured is normal.
>
> 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.
>
> 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.
The short pulse minimum and maximum widths (Ts1 and Ts2) are used in the
> 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.
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.
> 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?
"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?).
> 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?
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".
Thank you for loosing time with me...
rickman
May 30, 2013, 1:35:14 PM5/30/13
to
On 5/30/2013 12:31 PM, pozz wrote:
> Il 30/05/2013 00:08, rickman ha scritto:
>> On 5/29/2013 2:30 AM, pozz wrote:
>>>> I'm
>>>> not sure which protocol you are working with, bi-phase or Manchester,
>>>> they are slightly different.
>>>
>>> Manchester.
>>
>> 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.
>
> Yes, a sequence of 9 ones. This sequence appears just one time in the
> code, because of even parity used in next data field.
>> A proper
>> sync sequence for Manchester is 101010... Are you sure this is
>> Manchester and not Biphase as shown at
>>
>> http://www.priority1design.com.au/em4100_protocol.html
>
> 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.
No, I'm not saying there is a relation between the two, I'm saying that
> Il 30/05/2013 00:08, rickman ha scritto:
>> On 5/29/2013 2:30 AM, pozz wrote:
>>>> I'm
>>>> not sure which protocol you are working with, bi-phase or Manchester,
>>>> they are slightly different.
>>>
>>> Manchester.
>>
>> 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.
>
> Yes, a sequence of 9 ones. This sequence appears just one time in the
> code, because of even parity used in next data field.
>> A proper
>> sync sequence for Manchester is 101010... Are you sure this is
>> Manchester and not Biphase as shown at
>>
>> http://www.priority1design.com.au/em4100_protocol.html
>
> 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.
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.
>> 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?
>
> Yes, you're right. The 64-bits code stored in the tag is continuously
> transmitted while there's RF power from the reader.
confident you have the right values. The two dimensional parity bits
should give high confidence in a good read.
--
Rick
0 new messages