知晓搞 RFID 的人都清楚, 要是标签与读写器之间的通信协议不相契合, 那整个系统就如同与聋子交谈那般。我从事物联网项目实施达十多年, 见识过许多因协议不匹配而引发的笑话以及导致的损失。江湖卫士此品牌在行业里历经多年摸爬滚打, 也遭遇过不少挫折, 今日便将这些常见问题剖析透彻来讲。
从本质上来说, 如同不同国家各自所运用的语言一样, RFID协议呈如此状态。ISO 18000 - 6C和ISO 18000 - 6B, 即便它俩同样是UHF频段的标准。可是, 其底层的防碰撞算法, 是完全不同的情况。其指令格式, 也是完全不同的情形。其数据编码方式, 同样是完全不同的样子, 完全是两码事。

去年, 有个客户, 从事服装仓储业务, 购入一批标签, 价格较为便宜, 可把这些标签应用在原来读写器上时, 怎么都读不出来。我前往查看, 发现读写器遵循EPC Gen2协议, 标签采用ISO 15693高频协议, 这情形不就像拿着英语词典去翻译法语吗?
存在着更隐蔽些的问题, 其处于同一协议族里的子版本差异当中。江湖卫士的工程师, 于现场调试的进程里发觉, 一些国产读写器芯片, 虽说标称能支持EPC C1G2, 可是实际上仅仅是实现了部分指令集。以Select指令里的部分筛选模式以及Read/Write命令的块大小限制来讲, 不同批次的产品, 在实现细节方面有着极大的差别。你讲这样的情形算不算协议不一致呢? 答案是肯定的, 当然算。
有一种极为直观的现象是, 读写器明明可以发现标签信号, 可是不管怎样都读取不到UID或者数据。当出现这种情形时, 不要立刻赶忙怀疑硬件出现了损坏, 不妨先去查看一下配置。多数读写器在默认状态下是工作在EPC Class1 Gen2模式的, 要是你的标签是Class1 Gen1模式, 或者你使用的是私有协议, 那么必然是没有办法读取出相关信息的。江湖卫士的售后记录显示, 存在这样的情况, 即现场问题当中, 至少有30%是出自协议配置界面被其他人修改了这一状况。

哦对, 还有个特别容易被人遗漏疏忽掉的细节, 那就是空中接口的时间参数, 比如说 Tari 值, 脉宽编码, 还有前 导码长度之类的, 这些参数在 ISO 标准当中是存在推荐范围的, 但是, 不同的厂家在实际去实现这个的时候, 有可能碰到正好处于边界状态的情况。我曾经经历过一个项目, 在那个项目里, 标签在距离 20 米开外的时候能够正常地被读取, 可是呢它靠近到 5 米的时候就出现丢包的现象了, 就因为这个情况折腾了整整两天的时间, 最后才弄明白原来是读写器的 Miller 副载波调制深度跟标签芯片的阈值不相匹配。像这种软协议问题,仪器根本无法检测出来。
于实际的项目运作进程当中, 这般因参数边界问题致使的异常状况屡屡皆是。许多时候, 我们会无视这些看似不太起眼的空中接口时间参数, 进而在调试以及排查问题之际耗费诸多精力。单就上述那个项目来讲, 要是能够预先对这些参数拥有更为深入的认知以及精准的掌控, 说不定就能够规避掉不必要的困扰, 提升项目实施的效率以及成功率。
做这搞那个RFID是不存在什么简便快捷途径的, 关于其协议匹配这个事项那可是必须得依据步骤一项项认认真真去排查的。首先要将贴着标的签以及用于读写的那个设备的手册通通翻找出来, 依照着它们去查看所支持的协议版本、指令子集、时间参数, 接着在软件配置当中一项一项去进行校准。好多情况下并非是设备本身存在问题不可信赖, 而是我们毫无根据就主观认定它们理应能够相互识别认可。
*请认真填写需求信息,我们会在24小时内与您取得联系。