В данной статье я не буду вдаваться в описания RFID технологии, есть множество ресурсов посвященных этой теме. Я затрону только один нюанс настройки, и алгоритм управления RFID сканером, которым никто не замечает, но который позволяет добиться феноменальной точности и полноты считывания меток в стационарном формате. Когда есть какой-то закрытый объем и в нем необходимо постоянно и точно мониторить все присутствующие метки, их появление и исчезновение.
Внедряя у себя RFID UHF технологии для инвентаризации большого количества товара в одном объеме, сталкнулись с проблемой нестабильного считывания всего объема меток. При работе сканера часть меток хорошо читалась и многократно откликалась на сигнал ридера. Но были метки находящиеся в худших условиях приема, и эти. Метки считывались не каждый цикл, до них просто не доходил ход.
Нам, для успешного внедрения проекта было необходимо снизить ошибку пропуска метки, хотя бы до 1 ошибки на 1000 циклов считывания. При этом количество меток могло достигать 250 штук. И эту задачу нам удалось решить. В процессе было оптимизировано множество вопросов касающихся оборудования и программного обеспечения. Но ключевой стала технология которую я хочу тут описать.
Основной проблемой безошибочного чтения большого объема меток, было разное качество связи с разными метками. Метки находящиеся в хороших условиях связи, за цикл считывания откликались сотни раз. Метки находящиеся в плохих условиях связи, расположенные далеко, или будучи экранированными, не откликались ни разу. Решить эту проблему удалось настройкой работы сканера и алгоритмом его опроса.
Идея была в том, что метки не должны перебивать друг друга, и даже самая плохо читаемая метка имела возможность откликнуться и передать информацию на сканер.
В протоколе обмена EPC gen 2 который применяется для обмена данными между сканером и метками есть режим работы который позволяет достичь нужной нам цели. Называется это «сессия». Их 4 штуки. 0 и 1 нам не интересна. А вот 2 и 3 Работают именно в том режиме что нам необходимо. Там есть еще такое понятие как флаг. Флагов 2 «А» и «В».
Работает все это следующим образом: Включаем сканер в режим «сессии 2» и выставляем флаг «А». В этом режиме каждая метка откликается только один раз и блокируется до тех пор пока сканер не переключит флаг в режим «В». Программа запускает несколько циклов сканирования на флаге »А» это происходит до тех пор, пока сканер не перестает получать отклики от меток. В данном режиме метки не мешают друг другу, те кто имеет лучшие условия связи откликаются первыми и замолкаю не мешая остальным, находящимся в худших условиях. И мы получаем отклик от всех меток находящихся в поле действия сканера. После отработки с флагом «А», Сканер переключается в режим флага «В» и производит повторное считывание всех меток. В результате объединяя список меток полученный от 1 и 2 сканирования, мы получаем список меток с очень высокой надежностью считывания всех присутствующих меток.
В случае нашего проекта, при цикле считывания раз в 10 минут, ошибка не считывания присутствующей метки встречается не чаще чем раз в неделю.
Если есть вопросы с удовольствием отвечу.
Внедряя у себя RFID UHF технологии для инвентаризации большого количества товара в одном объеме, сталкнулись с проблемой нестабильного считывания всего объема меток. При работе сканера часть меток хорошо читалась и многократно откликалась на сигнал ридера. Но были метки находящиеся в худших условиях приема, и эти. Метки считывались не каждый цикл, до них просто не доходил ход.
Нам, для успешного внедрения проекта было необходимо снизить ошибку пропуска метки, хотя бы до 1 ошибки на 1000 циклов считывания. При этом количество меток могло достигать 250 штук. И эту задачу нам удалось решить. В процессе было оптимизировано множество вопросов касающихся оборудования и программного обеспечения. Но ключевой стала технология которую я хочу тут описать.
Основной проблемой безошибочного чтения большого объема меток, было разное качество связи с разными метками. Метки находящиеся в хороших условиях связи, за цикл считывания откликались сотни раз. Метки находящиеся в плохих условиях связи, расположенные далеко, или будучи экранированными, не откликались ни разу. Решить эту проблему удалось настройкой работы сканера и алгоритмом его опроса.
Идея была в том, что метки не должны перебивать друг друга, и даже самая плохо читаемая метка имела возможность откликнуться и передать информацию на сканер.
В протоколе обмена EPC gen 2 который применяется для обмена данными между сканером и метками есть режим работы который позволяет достичь нужной нам цели. Называется это «сессия». Их 4 штуки. 0 и 1 нам не интересна. А вот 2 и 3 Работают именно в том режиме что нам необходимо. Там есть еще такое понятие как флаг. Флагов 2 «А» и «В».
Работает все это следующим образом: Включаем сканер в режим «сессии 2» и выставляем флаг «А». В этом режиме каждая метка откликается только один раз и блокируется до тех пор пока сканер не переключит флаг в режим «В». Программа запускает несколько циклов сканирования на флаге »А» это происходит до тех пор, пока сканер не перестает получать отклики от меток. В данном режиме метки не мешают друг другу, те кто имеет лучшие условия связи откликаются первыми и замолкаю не мешая остальным, находящимся в худших условиях. И мы получаем отклик от всех меток находящихся в поле действия сканера. После отработки с флагом «А», Сканер переключается в режим флага «В» и производит повторное считывание всех меток. В результате объединяя список меток полученный от 1 и 2 сканирования, мы получаем список меток с очень высокой надежностью считывания всех присутствующих меток.
В случае нашего проекта, при цикле считывания раз в 10 минут, ошибка не считывания присутствующей метки встречается не чаще чем раз в неделю.
Если есть вопросы с удовольствием отвечу.
