ISO14443 Type A的解码图

corball · 发表于 2013-4-9 11:27:19

回复 7# xujie06023613
有一些介绍，见下文：
http://bbs.eetop.cn/thread-373252-1-1.html

lvluo · 发表于 2013-10-29 13:32:39

本帖最后由 lvluo 于 2013-10-29 13:48 编辑

你好，我正在尝试设计基于ISO14443 typeA的电子标签设计中（PCD到PICC的数据速率为106kbps）变形的miller码的解码电路，有两个问题想请教大虾。
1.射频接口部分提供给数字部分的13.56M时钟是连续的么？以我的理解，射频接口部分的调制解调电路应该已经分离出了完整的fc和miller数据。但从很多资料中发现，貌似变形米勒解码的数字设计还是认为输入时钟是不连续的，求大虾解惑。。。
2.输入的miller信号的脉宽可以理解为2us~3.5us即28~41个fc周期么？

corball · 发表于 2013-10-29 20:02:59

本帖最后由 corball 于 2013-10-30 08:39 编辑

回复 12# lvluo

1、106Kbps的速率下，从天线恢复出来的时钟（13.56MHz分频）信号在Pause期间（95~100%ASK）肯定是没有的；212-847Kbps可能有但是也不敢用（因为根据阅读器器端的信号，ma:40~100%，也可能没有）。有些论文可能会有些误导：就是在芯片内置一个VCO，这样即使是Pause期间，也可以有连续的时钟。这样的话，芯片的功耗得多低啊，严格来说，标签这种低速度、轻量级可能还能用这个设计，智能卡，我是不相信的；

2、是这样的，只是这个时候没有fc，所以使用同步电路（fc时钟驱动）来设计解码器就不行了。根据ISO14443，Pause的宽度有一个范围，比如你说的2-3.5us@106Kbps。除了阅读器来的原始信号的影响，芯片的ASK解调电路对解调出来的“改进Miller编码”的pause边沿也有影响。在106Kbps可以采用计数器溢出的方法来恢复占空比不是那么好的ETU Clock，但是计数器简单溢出不能用于高速率，原因就是Pause对应的脉冲数没有那么多，比如847KHz，一个Bit也就是16个13.56MHz的振荡，Pause能占几个？

lvluo · 发表于 2013-10-30 09:14:53

本帖最后由 lvluo 于 2013-10-30 14:10 编辑

pcd传输过来的数据位宽是106kbps，在标签解调电路中，因为fc不完整的原因，无法得到与数据位宽相等的时钟信号（fc/128)，该如何保证数据的正确接收呢？是否可以理解为,标签中的工作时钟clk_128由不连续的fc和DATA_MILLER两个信号产生,然后借由clk_128时钟得到解码的NRZ数据?

corball · 发表于 2013-11-1 15:54:21

单纯的由fc分频是得不到和码位一致的时钟的，要结合改进的Miller编码信号，恢复出我们称为ETU_CLK的时钟，由这个时钟在解码出来的不归零码（NRZ）的中间采样，实现本地的存储和后续的使用。
ETU_CLK和NRZ是同时输出的：
                              |--------|
带Pause的Fc ---------> |       | ==> ETU_CLK
                              | 电路 |
改进Miller编码的包络 -->|       |===>NRZ
                              |_____|

lvluo · 发表于 2013-11-5 15:40:19

本帖最后由 lvluo 于 2013-11-5 15:41 编辑

回复 15# corball

多谢回答。再请教：
1.得到的NRZ和得到的etu沿必须得对齐吧？

2.14443协议中描述的PCD到PICC的帧延迟时间时，说最后一位为1时，FDT=（n*128+84）；
最后一位位0时，FDT=（n*128+20）
是不是说反啦，否则该怎么理解呢？

3.解码出的NRZ数据要通过串转并，得到控制部分易于处理的信号。但pcd发送给picc的数据宽度不总一致，该如何解决这个问题呢？

corball · 发表于 2013-11-5 16:49:51

回复 16# lvluo
我的看法如下：
1、恢复的NRZ编码的边沿和ETU-CLK是要对齐的，这样可以使用ETU-CLK的上升/下降沿采集完成串-并转换。这个NRZ和PCD的数据肯定对不齐，有滞后，但是这个滞后不能影响FDTx；

2、对照一下ISO14443规范

登录/注册后可看大图

没有反。

3、我理解PCD端的一个码位（ETU）必须对应128/fc(106Kbps）、64/fc（212Kbps）、32/fc（424Kbps）和16/fc（848kbps），否则就没有办法玩了。因此，按照载波fc的分辨能力而言，PCD端的码位宽度必须是一致的。

lvluo · 发表于 2013-11-5 17:25:05

本帖最后由 lvluo 于 2013-11-5 17:45 编辑

问题3我描述有误了。

我要表达的是，解码出的NRZ数据要通过串转并，得到控制部分易于处理的信号。但pcd发送给picc的不同命令的比特数不总一致，该如何解决这个问题呢？

还有一个问题，从楼主给的解码图可以看出，解码得到的fc_128只在接收frame期间出现，之后就没有了，那么标签内部的时钟由谁来提供呢？
以我的理解，既然帧延迟时间有严格的规定，那应该从pcd发送数据给picc直到picc发送数据出来给pcd这个过程都应与fc_128同步，那这个时钟最终怎么处理的呢？

corball · 发表于 2013-11-5 19:25:55

本帖最后由 corball 于 2013-11-7 08:55 编辑

回复 18# lvluo

嗯。我理解一下，比如有短帧（7Bit），有标准帧（8Bit+O/P校验），标准帧的字节数也不一致。为了处理这个，需要256字节（也可以小一些，看芯片设计的规格）的SRAM做缓存，先将PCD发送的数据缓存到SRAM中，然后由状态机或者处理器处理。

fc_128在完成数据解码后就没有了，然后fc就有稳定的输出了，系统由fc分频的时钟（比如有的芯片采用3.38MHz=13.56/4）驱动。fc_128不是供芯片内部电路工作的，仅用于处理NRZ解码的缓存，因为这时候的pause芯片外界的供电是停止，原则上，芯片的处理器或者其他非接收数据的逻辑都停止工作，否则电源端需要多大的电容也不够使。比如一个设计，仅接收电路工作，15uA就够了；如果处理器也开跑，可能需要3～5mA，这还是平均电流。因此，在Pause期间，不给基带供应时钟（固定电平）的。
FDTx的同步只看最后一个Pause的边沿，而非整个过程，ISO标准也是如此。

对于106Kbps的标准速率，我们使用fc_128表达和码率等同的时钟信号。为了兼容212-848Kbps的高速率，更一般的，我们称这个信号为ETU_CLOCK，意思是这个时钟和码率的速率一样，仅在接收数据的时候用于缓存接收并解码的NRZ信号。

http://bbs.eetop.cn/thread-373252-1-1.html
这个帖子是我们的设计验证，可以阅读一下更好的理解相关的内容。

lvluo · 发表于 2013-11-7 17:06:45

谢谢楼主的回答，很详细，很有帮助。

另外仍请教一个14443协议的问题。协议中类型A提到CRC—A，具体计算过程我是明白了，我疑惑的是，从pcd到picc的带有crc校验信息的数据信息位不总一致，比如pcd发来的HLTA命令的数据信息时2bytes，pcd发来的防冲突选择命令的数据信息是7bytes，那么在做具体的设计时，我的CRC解码模块中的输入数据位因为不确定，是否要做两个模块来与这个需求对应呢？

账号		自动登录	找回密码
密码			注册

[原创] ISO14443 Type A的解码图

站长推荐 /1