# Synchronization of BPSK with variable-length symbols (ISO 14443)

Does anyone have an idea how one would perform BPSK symbol synchronization if symbol length is allowed to vary?

As dumb as that sounds, this is not a theretical question.The "Proximity" Type B NFC protocol defined in ISO/IEC 14443 has such a scheme.

Brief Background of ISO 14443 Type B

For communication from a Proximity tag/card (e.g. a wireless smart card) to a reader, BPSK modulation is used*. The symbol period is (usually) equal to 16 carrier cycles. To begin communication, a start-of-frame synchronization sequence is sent, allowing the reader to A) identify the carrier frequency, and B) determine the phase for a logic 0. Then the card sends data out in characters. Each character contains a logic 0 start bit, 8 bits of data, then a logic 1 stop bit. (Think UART.) This means that between bytes you always see bit 7 -> 1 -> 0 -> bit 0.

For historical reasons, the specification allows the card to include "Extra Guard Time" (EGT) between each character. Before proceeding to the logic 0 start bit, the card is allowed to arbitrarily extend the logic 1 stop bit up to 32 carrier cycles, in increments of 0.5 carrier cycles. (So phase changes still always occur at 0° or 180° of the carrier.) This is something that can be done dynamically; the reader does not know in advance what the card will do.

Since the bit following the EGT is always the logic 0 start bit, you can of course pick back up symbol synchronization, but it complicates the whole process. It's hard to find information online on such a convoluted scheme, and the textbooks I have do not cover this. I'm wondering if anyone else has run into a similar situation and has some ideas on how decoding might work.

*The actual details are more complicated. The card performs load modulation of the 13.56 MHz carrier frequency using an 848 KHz sub-carrier. However the 13.56 MHz carrier signal can be easily filtered out by the reader, leaving just the sub-carrier information from the card.

• The first approach that comes to mind, given your UART analogy, would be to process the signal like a UART receiver does: oversample it by a large enough factor that you can recover the bit timing easily by finding the (coarse) positions of each transition. – Jason R Jun 27 '18 at 14:39
• How were planning to perform symbol timing recovery, if you didn't have the bit stretching? Are the BPSK pulses shaped by a filter (e.g. RRC filter)? PLL symbol timing recovery blocks can be tuned to handle some jitter in the timing between symbol centers. And, as you imply, the upper layers of processing can recognize and throw away any extra 1 symbols by looking for the next 0 symbol. – Andy Walls Jun 27 '18 at 19:55