Перейти к содержанию
    

Протоколы используемые в промышлиных proximity card readers с RS485

Всем привет,

Суть, у меня есть считыватель Mifare карт, наружу торчит rs485, и нет никаких док, я не знаю что за протокол там пользуют, после подачи питания, девайс молчит, реакция на карту есть, моргает диод, но на шине ничего нет.

Собственно вопрос, может кто знает какие стандартные протоколы используют для работы с такими считывателями?

Девайс российской сборки, работает с оборудованием siemens ADD5100 (документация также скудная)

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не уверен что фото помогут, вечером его сфоткаю.

Мне бы помогла информация о том, с какими протоколами Вы сталкивались.

Либо в данном случае мне можно ожидать какогото кастомного протокола?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Видел HIDовский протокол. Лучший для вас вариант это CCID без канала прерываний пущенный через 485. В худшем случае - полностью из головы придуманный велосипед. Если есть возможность заснифать процесс общения - заснифайте, можно будет сказать CCID/неCCID.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Указанный сименс использует скорее всего проприетарный протокол. При желании можно, конечно, снять и разобраться. Но лучше купить какой айронлоджик с известным интерфейсом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Заснифил обмен, теперь нужна помощь, может кто-то сможет узнать протокол.

 

Передача осуществляется в ASCII. Пример обмена:

.010002Rc002                   >>>>Посылка в считыватель, полагаю какой-то опрос состояния
.000106RrC28206C            <<<<Ответ
.010002Rc002                   >>>>Посылка в считыватель, повтор предыдущей посылки
.000106RrC28206C           <<<<Ответ
.010000130                      >>>>Посылка в считыватель, полагаю запрос UID, карта в этот момент поднесена к считывателю
.000112Hg0000001521232933111<<<<Ответ, содержит UID
.010000130                      >>>>Посылка в считыватель, повторный запрос, карта в этот момент убрана
.000100130                      <<<<пустой ответ

 

Каждая посылка начинается с 0x2E ('.') заканчивается 0x0D ('\r', перевод строки).

Если бегло посмотреть на пакет, можно выделить следующие поля:

. 00 01 12 Hg0000001521232933 111

0x2E      : '.'  : SOF
0x30 0x30 : 00 : Dest addr
0x30 0x31 : 01 : Source addr
0x31 0x32 : 12 : Data len 0x12 = 18

0x48 0x67 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x35 0x32 0x31 0x32 0x33 0x32 0x39 0x33 0x33 : DATA, Hg - DATA TYPE????, 0000001521232933 - UID DEC

0x31 0x31 0x31 : "111" : - ????

 

Не ясно назначение последних байт, чексумма ли это, или какойто статус

 

Если кто-то сталкивался с подобным форматом, буду рад увидить детали :)

 

И, с наступившим Новым Годом!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Заснифил обмен, теперь нужна помощь, может кто-то сможет узнать протокол.

 

Передача осуществляется в ASCII. Пример обмена:

.010002Rc002                   >>>>Посылка в считыватель, полагаю какой-то опрос состояния
.000106RrC28206C            <<<<Ответ
.010002Rc002                   >>>>Посылка в считыватель, повтор предыдущей посылки
.000106RrC28206C           <<<<Ответ
.010000130                      >>>>Посылка в считыватель, полагаю запрос UID, карта в этот момент поднесена к считывателю
.000112Hg0000001521232933111<<<<Ответ, содержит UID
.010000130                      >>>>Посылка в считыватель, повторный запрос, карта в этот момент убрана
.000100130                      <<<<пустой ответ

 

Каждая посылка начинается с 0x2E ('.') заканчивается 0x0D ('\r', перевод строки).

Если бегло посмотреть на пакет, можно выделить следующие поля:

. 00 01 12 Hg0000001521232933 111

0x2E      : '.'  : SOF
0x30 0x30 : 00 : Dest addr
0x30 0x31 : 01 : Source addr
0x31 0x32 : 12 : Data len 0x12 = 18

0x48 0x67 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x35 0x32 0x31 0x32 0x33 0x32 0x39 0x33 0x33 : DATA, Hg - DATA TYPE????, 0000001521232933 - UID DEC

0x31 0x31 0x31 : "111" : - ????

 

Не ясно назначение последних байт, чексумма ли это, или какойто статус

 

Если кто-то сталкивался с подобным форматом, буду рад увидить детали :)

 

И, с наступившим Новым Годом!

 

Дак вы почти весь обмен и просканировали. Видно, что идет все в "текстовом режиме", извесны команды, по которым получают код карты, просто реализуйте это же самое на МК и делов то :laughing:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дак вы почти весь обмен и просканировали. Видно, что идет все в "текстовом режиме", извесны команды, по которым получают код карты, просто реализуйте это же самое на МК и делов то :laughing:

Да, на данном этапе этого функционала достаточно, и я реализовал его на своей стороне, но в будущем, может возникнуть необходимость прочитать данные из карты (а не только UID как это делает текущая система). Поэтому, на данном этапе хочется понять на что способен данный считыватель, а для этого нужен набор команд, который наверняка завязан на этом протоколе обмена.

Плюс ко всему не зная протокола, я не могу быть уверенным в том что для других типов карт я получу какой-то другой ответ.

 

PS: Последние два байта это ASCII XOR всех данных (не включая первый байт 0x2E), осталось понять что назначение одного полубайта

И так, на примере сообщения, имеем:

.000112Hg0000001521232933111
.___________________________ Старт фрейма
_00_________________________ Адрес назначения (или команда)
___01_______________________ Адрес источника  (адрес слейва)
_____12_____________________ Длинна полезной нагрузки
_______Hg0000001521232933___ Hg + UID, Hg -  вероятно индификатор команды
_________________________1__ Назначение неизвестно, вероятно какой-то статус
__________________________11 Чексумма, XOR всех предыдущих данных за исключением 0x2E(.)  
____________________________ 0x0D Непечатаемый символ, конец сообщения

Как я уже писал, если кто-то сталкивался с подобным форматом, буду рад увидить детали! :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вероятность, что кто-то ковырялся с такой экзотикой скорее всего равна нулю. Попробуйте поискать в мануалах по слову cerpass protocol. К примеру http://qps.ru/R3ZrI

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В этом направлении уже работал. Так же есть мысли, что эта так называемый "cerpass protocol" но описания подходящего под мой формат нигде не нашел, одна надежда что найдётся тот кто с этим уже работал :)

Все равно, спасибо за совет!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё вариант - к производителю обратиться. Тут, правда, вопрос. Почему российской сборки? Сименс это скорее экзотика. Кому нужно производить экзотику? В Беларуси в начале нулевых был распространен шведский скуд беватор (позднее Сименс его купил). На тот момент не было альтернативы. Сейчас в СНГ ставят в основном российский.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...