概述
RFID相关通讯协议有很多种,我们这里要讲的是ISO/IEC14443A。
ISO/IEC14443A读卡流程我们可以从两个角度进行分析,一个是读卡器(PCD),另一个是卡片(PICC)
上述是卡片状态变化图(参考《射频卡协议ISO14443》)
POWER OFF : 卡片缺少载波能量,简单的说卡片没有进入到天线发射的范围内。
在有足够多能量后,卡片就会进入到IDLE状态。
IDLE : 卡片处于空闲状态,可以识别从PCD而来的REQA以及WAKEUP指令。
在接收到REQA或者WAKEUP指令后,卡片就进入到READY State。
READY:卡片处于就绪状态,就可以读取对应的UID了,但如果此时有多张卡片同时在射频场中,就可能发生冲突。这里采用的防冲突算法是基于位冲突检测协议,简单的说就是看冲突发生在哪一位,在从下位开始继续获取UID,直至获取完整的UID,可以通过下面的一个实例进行分析。
事先得到1卡片 EF 30 E2 84 2卡片 EF DB 8E 6F ,可以发现在第2字节第0bit两个卡片的UID开始不同,那么碰撞必然会发生,看看是不是这样。
这里我们用的就是4个字节uid的卡片,所以SEL = 0x93,在第一次发送防冲突时,NVB = 0x20 ,总共就2个有效字节(SEL+NVB),因为我们并不知道UID 。
SEL NVB
发送报文 93 20
收到报文 EF 读RC663寄存器,得到发生冲突的位置第2个字节 第0bit。
那么既然找到冲突位置了,那么我们就重新发送防冲突报文 SEL还是0x93,NVB 中完整字节数:(SEL+NVB+第一字节UID(EF)),NVB中的bit数(发送冲突位置在第2字节第0bit,所以有效位数是1(希望收到的是碰撞bit后的uid))
报文
SEL NVB UID0 UID1
发送报文: 93 31 EF 00
收到报文 30 E2 84 B9 收到4个字节 ,最后一个字节是完整UID的BCC校验
发送这个报文之后,2卡片因为收到的报文与自身UID不匹配,不会回复,所以得到的回复就只有一个,那就是1卡片后半部的UID,然后与前半部的UID合并起来就是完整的UID即(EF 30 E2 84 )。
如果读卡器里有多张卡,可能会有多次冲突,但是方法和上述步骤一样,直到收到完整的UID为止。
ACTIVE: 读取到完整UID后,发送SELECT指令就能进入到激活状态,在这个状态下,才能进行M1的操作,查看一下SELECT的实例:
SEL NVB UID0 UID1 UID2 UID3 BCC
发送报文: 93 70 EF 30 E2 84 B9
收到报文 28
实际上就跟获取卡号的报文是一样的,只是此时已经知道完整的UID,就把完整的UID添加到发送报文,就是SELECT。
通过HALT指令,可以让卡片从ACTIVE状态转化到HALT状态。HALT指令的实例:
发送报文: 0x50 0x00
如果定时器超时了说明HALT成功了。
HALT: 不会响应除了WAKEUP以外的指令,(这样就可以读下一张卡的卡号)。
这样其实也就能知道读卡器大概是怎么个流程,直接上图:
概括一下就是,打开射频场-----发送REQA/WAKEUP,使得所有卡片进入READY状态------获取UID(防冲突)-------获取到一个完整的UID----------发送SELECT,使这张卡片进入ACTIVE状态-------------发送Halt指令,使这张卡片进入HALT状态,就不会响应除了WAKEUP外的其他指令----------发送REQA,使其他的所有卡片重新进入READY状态(HALT的卡片不会),如果没有卡片响应就结束了,否则继续获取UID,这里就是循环操作了,直至所有卡片的卡号都读取出来。
自己测试了一下,最多可以同时支持9张卡,多余的卡片就感应不到了。
最后
以上就是隐形帅哥为你收集整理的ISO14443A读卡流程的全部内容,希望文章能够帮你解决ISO14443A读卡流程所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复