Итак, по поводу адресов, вот основные требования, которые должны к ним предъявляться, на мой взгляд:
1. Каждый датчик должен иметь уникальный адрес, это очевидно: иначе на линии будут коллизии. Два датчика буду пытаться ответить одовременно, и даже при идентичных ответах тайминги не сойдутся.
2. Пользователь должен иметь возможность сопоставить определенным датчикам определенные параметры в настройках повязки: например, коффициент урона. Это нужно, чтобы организовать зоны поражения.
3. Датчики, для которых пользователь не задал никаких особых параметров, должны работать по-умолчанию. То есть, если к повязке подключается новый датчик с неизвестным адресом, он должен работать корректно. Другими словами, нужен механизм автоматического определения адресов датчиков. В самом простом варианте - юзер взял мозги повязки, достал из коробки наугад 5 датчиков, подключил, всё заработало без правки конфигурации и т.п.
4. Может ещё что-то?..
Как это все реализовывать:
По п. 1:
Тут все легко. Если адрес - это 2 байта, сгенерированных случайно при прошивке (или взятых из id чипа), и если к повязке подключено 10 датчиков, вероятность коллизии будет примерно 1/1460. То есть каждые полторы тысячи собранных комплектов может возникнуть коллизия, которая исправляется просто заменой части датчиков на какие-то другие. Можно увеличить адрес до 3 байт, тогда коллизия будет возникать в среднем каждые 370.000 комплектов, то есть практически никогда. Если датчиков 20, а не 10, то числа изменятся где-то на пол порядка. Ниже приведен график зависимости числа комплектов, среди которых в среднем у одного будет коллизия, в зависимости от битности адреса датчика при условии, что число подключенных датчиков равно 10:
Вложение:
Коллизии2.png [ 29.78 KiB | Просмотров: 8764 ]
Кому интересно, откуда это, вот тривиальный скрипт на Питоне, который я написал, чтобы построить такой график:
Вложение:
Комментарий к файлу: Скрипт расчета вероятности коллизии адреса
address-collision-prob.py.zip [532 байт]
Скачиваний: 497
По п. 2:
Тут несколько вариантов:
- Можно адрес датчика писать на самом датчике. И пользователь в конфиг-файле явно укажет: доля такого-то учитывать, например, половину урона.
- Можно сделать ИК-пульт, который будет присваивать датчикам номер зоны поражения, по которому потом пользователь в конфиге что-то укажет. Но ИК-пульт - это лишнее устройство.
- Можно сделать такое конфигурирование через Андроид, чтобы на телефоне выводился список адресов подключенных к повязке датчиков, а по нажатии на адрес датчик подсвечивался, и можно было задать его параметры. Это сложнее, но вполне осущетвимо, учитывая, что в Caustic блютус будет в каждой повязке и управление с телефона прекрасно работает.
Разумнее для начала ограничиться первым вариантом. Всё-таки датчики меняются, или переставляются с жилета на голову крайне редко.
Но это уже не вопрос протокола, а скорее детали реализации.
По п. 3:
Вот тут самое интересное. Протокол должен предусматривать механизм получения повязкой адресов всех подключенных сенсоров. Просто перебрать все адреса не выйдет: их слишком много даже в двухбайтном пространстве, на это уйдут часы при скорости порта 112000 бит/с. Нужно использовать стандартные механизмы, которые применяются при коммуникации через общую физическую среду (как в WiFi, например). Упрощенно, это выглядит так: повязка попросит все датчики представиться. Датчики через случайные промежутки времени будут посылать сообщения со своими адресами. Рано или поздно получится принять пакет от какого-то датчика без коллизий. Такому датчику тут же посылается команда молчать. Если организовать процесс правильно, то он займет не более 20-30 итераций для комплекта из 10 датчиков, и не более 10 итераций для 4 датчиков.
У меня есть черновик этой процедуры с довольно нетривиальным алгоритмом. Как испытаю, расскажу.
Вход
Регистрация
FAQ
Поиск
