Easyelectronics.ru

Электроника для всех
Текущее время: 26 май 2019, 20:40

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/10pcs (Любой цвет!)
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 12 ] 
Автор Сообщение
 Заголовок сообщения: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 18:38 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2014, 13:25
Сообщения: 560
Откуда: Earth
Доброго времени суток. Возникла необходимость создать портативный носимый считыватель карт (брелков) формата ЕМ4100. Не придумал ничего проще, чем купить готовый считыватель RDM6300 и подключить его к МК по UART. Нигде не могу нагуглить формат, в котором этот считыватель выдает информацию. В интернетах полно примеров для ардуино, но там люди не заморачиваються, а просто парсят полностью сообщение, выдаваемое считывателем и считают, что это и есть уникальный код метки. Но это совсем не так. Нашел инфу на похожий считыватель, RDM630 (https://elty.pl/upload/download/RFID/RDM630-Spec.pdf), для него указывается, что формат сообщения следующий:
1 байт - всегда 02 (hex), признак начала передачи
2-11 байт - уникальный идентификатор (10 байт)
12 байт - checksum
13 байт - всегда 03 (hex), признак конца передачи

В моем считывателе (RDM6300), протокол явно немного другой. У меня есть 2 брелка, и 1 карточка. На брелках номера: 0008644799 и 0008588885, на карточке номер отсутствует.
Считвыаемые кода для всех них, по порядку (столбцы HEX и ASCII, остальное я сам дописал для понятности):

Код:
   HEX                                       ASCII         DEC(на брелках)   (DEC to HEX)

02 30 38 30 30 38 33 45 38 42 46 44 43 03   .080083E8BFDC.      0008644799   (0083E8BF)          Брелок №1
02 30 38 30 30 38 33 30 45 35 35 44 30 03   .0800830E55D0.      0008588885   (00830E55)          Брелок №2
02 30 32 30 30 42 35 34 37 38 30 37 30 03   .0200B5478070.                                                            Карточка


Видно что:
1-й байт (02h) - тоже cимвол начала передачи
2-11 байт - тоже уникальный идентификатор (10 байт)
14-й байт (03h) - тоже символ конца передачи

Возникает вопрос, почему байта контрольной суммы 2 (12-13), и как они считаються ? Это не CRC-16, я проверял.

Какие закономерности вижу я:
1. У брелков одинаковые первые 5 байт идентификатора. Поэтому одинаковые первые байты контрольной суммы. Может ли это означать, что 1 байт контрольной суммы считаеться для первых 5 байт идентификатора, а второй - для второй половины идентификатора ?
2. У брелов в номере на корпусе отсутствует 08 в начале. Возможно это тип устройства: 08 - брелок, 02 - карточка. Тогда возможно контрольная сумма считаеться для 8 байт идентификатора, отдельно 1 байт для первых 4 байт, и второй байт для вторых 4 байт.

У кого какие идеи ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 18:55 
Старожил
Аватара пользователя

Зарегистрирован: 11 авг 2016, 20:52
Сообщения: 612
Откуда: GMT+6
ASCII
08 xor 00 xor 83 xor E8 xor BF = DC
08 xor 00 xor 83 xor 0E xor 55 = D0


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 19:08 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2014, 13:25
Сообщения: 560
Откуда: Earth
Спасибо !!!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 19:09 
Старожил
Аватара пользователя

Зарегистрирован: 18 апр 2017, 03:01
Сообщения: 987
12 и 13-й байт, это и есть CRC, и считается точно так же как в приведённом Вами документе, только что посчитал для первого и второго брелка - всё сходится.
А, уже ответили...


Вложения:
CRC.png
CRC.png [ 10.06 Кб | Просмотров: 1888 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 19:30 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2014, 13:25
Сообщения: 560
Откуда: Earth
Тогда еще вопрос. Учитывая, что при прикладывании карточки/брелка считыватель начинает непрерывно сыпать в UART код метки, как бы вы организовали работу с ним:
1. Заводим фиксированный буфер на 12 байт, ловим 02h, начинаем прием, получаем 12 байт, считаем чексум, сравниваем, делаем действие.
2. Заводим фиксированный буфер на 13 байт, ловим 02h, начинаем прием, получаем 13 байт, смотрим что 13-й байт = 03h, считаем чексум, сравниваем, делаем действие.
3. Заводим кольцевой буфер (минимум 13 байт), в который непрерывно пишем все что приходит по UART, как только ловим конец посылки (03h), читаем предыдущие 12 байт, считаем чексум, сравниваем, делаем действие.

Или предложите свой вариант.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 20:06 
Старожил
Аватара пользователя

Зарегистрирован: 11 авг 2016, 20:52
Сообщения: 612
Откуда: GMT+6
4. заводим 2 массива на 5 байт, ловим 02h, принимаем по 2 байта, сразу начинаем считать чексум и длину посылки, декодировав 2 байта в 1, сразу записываем их в 1-й массив и проверяем на соответствие 2-му массиву, по достижению длинны посылки сравниваем чексум и по приему 03h ставим флаг валидности данных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 20:17 
Старожил
Аватара пользователя

Зарегистрирован: 18 апр 2017, 03:01
Сообщения: 987
Для меня - с кольцевым буфером было бы удобнее работать(размером минимум на две посылки), наверное.
Каждый вычитываемый из этого буфера байт отправлять на конечный автомат, который будет искать нужное (если 02h, а через нужное число байт будет 03h, то, возможно, оно - считается CRC, если подходит, то уже наверняка оно).
Ну и если шлёт постоянно - не забыть про блокировку и таймаут снятия этой блокировки после прекращения передачи (если нужно одно действие на одно прикладывание). Как-то так...
Тут можно очень по разному сделать, вариантов много.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 21:14 
Старожил
Аватара пользователя

Зарегистрирован: 11 авг 2016, 20:52
Сообщения: 612
Откуда: GMT+6
Show Кому конечный автомат на C++?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 21:42 
Старожил
Аватара пользователя

Зарегистрирован: 18 апр 2017, 03:01
Сообщения: 987
А что в нём от плюсов? И... он точно рабочий?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 22:48 
Старожил
Аватара пользователя

Зарегистрирован: 11 авг 2016, 20:52
Сообщения: 612
Откуда: GMT+6
h4lf писал(а):
А что в нём от плюсов?
Хотя-бы объявление локальной переменной не в начале функции.
h4lf писал(а):
И... он точно рабочий?
В Visual Studio 2015 компилируется без ошибок, а на юнит тестах не проверял (все мы люди, каждый может ошибиться).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 25 июн 2017, 23:12 
Старожил
Аватара пользователя

Зарегистрирован: 18 апр 2017, 03:01
Сообщения: 987
А, понятно. Но я в обычном С тоже объявлял в самом for и ничего (C99 или ещё новее, не знаю). И что в каждом блоке кода можно свою переменную объявить - читал где-то и делал.
Ну да, сразу не додумался - _beginByte и _endByte не могут появиться посреди нормального сообщения от считывателя, потому что всё остальное он передаёт в ASCII. Ну если ТС нужно будет - проверит и сам, я думаю. Ну а компиляция без ошибок... наверное Вы знаете лучше меня, что это значит.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расшифровка формата сообщения RDM6300
СообщениеДобавлено: 02 авг 2017, 01:58 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2014, 13:25
Сообщения: 560
Откуда: Earth
Доброго времени суток. Так как EEPROM в целевом контроллере (PIC12) маловато, и при этом необъодимо запоминать как можно больше меток, я решил писать туда не весь код метки, а только checksum метки (1 байт). То что у разных меток может быть одинаковый checksum я прекрасно понимаю, и это не является проблемой (есть возможность заранее выбрать метки для считывания устройством, и можно выбрать такие, чтобы их checksum не повторялся).
Был написан следующий алгоритм:
1. Очистка ascii, ascii_temp, и счетчика принятых байт,
2. Ловим байт пакета
3. Смотрим количество принятых байт. Если не 0, goto пункт 5. Если 0, проверяем на 0x02
4. Если не 0x02, goto пункт 2. Если 0x02 - инкримент счетчика принятых байт, и goto пункт 2
5. Инкримент счетчика принятых байт
6. Каждый парный (считая 0x02) принятый байт (0 бит в счетчике байт - сброшен) пишем в buffer и goto пункт 2
7. Каждый непарный (считая 0x02) принятый байт (0 бит в счетчике байт - установлен) пишем в buffer+1
8. После записи байта в buffer+1 конвертируем байт из buffer в старшую тетраду ascii_temp, а байт из buffer+1 в младшую тетраду ascii_temp
9. Если счетчик не насчитал 13 байт (1 старт байт + 10 байт кода метки + 2 байта checksum), "ксорим" ascii_temp и ascii, результат в ascii и goto пункт 2
10. Если насчитал, сравниваем ascii_temp и ascii
11. Если не идентичны, goto пункт 1
12. Если идентичны, ждем еще 1 байт (0x03)
13. Если байт не 0x03, goto пункт 1.
14. Если есть 0x03, фиксируем время, пишем ascii в EEPROM.

Он прекрасно работает, все метки распознаються, и их checksum пишеться в EEPROM.
Но есть проблема. Моя отладочная плата питаеться от USB, антена считывателя находиться в непосредственной близости от кабеля USB, и когда я оставляю ее на ночь на прогон, то иногда (!) за ночь самопроизвольно возникает запись кода какой-то неизвестной метки в EEPROM. Во время прогона ни одной метки в радиусе 1 метра от отладочной платы нет (да и метки с такой checksum у меня просто нет). Тоесть проблема именно в алгоритме. Подскажите пожалуйста, где у меня косяк. Я ведь вроде все обнуляю, если хоть 1 бит в checksum не совпадает, а все равно есть ложные считывания иногда.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 12 ] 

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB