Добрый день!

Нужна консультация, помощь по выбору подходящей беспроводной технологии
для ниже описанной задачи.

Нужно создать беспроводную систему сбора данных с периодом опроса 1мс.
Количество устройств / сенсоров в системе желательно иметь до 30 штук / датчиков.
С датчика нужно считывать 1-2 байта данных.
Пока нет определенной топологии или протокола.
Стоит вопрос выбора элементной базы, чтобы радио чип обеспечивал
быстрое время отклика. Было бы хорошо получить время отклика порядка 50-100мкс.
Тогда можно делать разветвленную топологию, потом объединять поток данных в один
и гнать его в главное устроиство по проводному интерфейсу.
Если время отклика будет еще меньше, то будет даже лучше.

Рассматривал вариант реализации на ATMEGA128RFA1 со скоростью передачи пакета данных до 2Мbps.
Но из-за синхронизации, преамбулы эквивалентная скорость при маленьких пакетах данных
приближается к 250кbps. В результате длительность пакета составляет около 200мкс.
В две стороны получается более 400мкс. Такой результат не подходит.

Просьба помочь в выборе нужной элементной базы. Может я пошел вообще по другому пути.
Плохо ориентируюсь в радио технологиях. Широко распространенные стандарты (например, IEEE 802.15.4)
в основном предусмотрены для передачи данных на небольших скоростях.

Дмитрий

Расстояния какие ? Метры ? Или больше ?

Расстояния какие ? Метры ? Или больше ?

Желательно расстояние 10-20 метров, минимум 5 метров.

P.S.

Подходящие диапазоны частот:
2.4GHz
915, 920MHz

Обыкновенный Wi-Fi чем не подходит?

Я особенности и детали передачи пакетов данных Wi-Fi не знаю.
Не смотря на большие скорости передачи данных (от 11Mbps до 60Mbps),
не уверен, что эффективная скорость для маленьких пакетов будет
удовлетворять требованиям поставленной задачи.

Длительность отсылки пакета, состоящего из 1-2 байта данных,
желательно не должна превышать 50-100мкс.
Если не путаю, то в пакете данных Wi-Fi также включается синхронизация,
адресация, подтверждения и т.д.
Если Вы хорошо знакомы со стандартом Wi-Fi, то не подскажете, пожалуйста,
формат пакета Wi-Fi и его приблизительную длительность, если в пакете
всего несколько байт данных.

Накладные там естественно большие.

В этом и ответ — в разрешённых диапазонах задача нерешаема, потому что требуется соблюсти все протоколы.

Вопрос скорее был о том, откуда у датчиков настолько неограниченное питание.

Питание для датчиков не критично, предусматривается внешнее питание.
Согласен, задача сложная, больше исследовательская.
Желательно использовать в данном проекте готовые радио трансиверы,
а протокол можно самим придумать или взять за основу что-то имеющееся,
не требуется соблюдать все протоколы. Главное, чтобы это позволяла
выбранная элементная база.

Вы имеете в виду диапазоны частот?
Конечно, желательно использовать указанные частоты,
но можно рассмотреть и другие.

всё-таки 2мБита за 1мс это 250 байт данных. достаточно для 30 устройств. на каждого по аж 8 байт
может немного пересмотреть логику работы, чтобы не требовалась быстрая отзывчивость каждого датчика.
мастер посылает один запрос каждую милисекунду, его принимают все и все начинают на него отвечать, но по очереди, каждый со своей задержкой 30мкс*N, чтобы предыдущие успели высказаться в эфир. задержка на раскочегаривание передачитка будет только один раз на все устройства.
вот например nRF24L01 если его дернуть за передатчик, он через 140мкс начнёт передавать в эфир, 2 - байт преамбула+packet control, 3 - адрес, и еще 2 байта данных = всего 7. может и получится. да и данные можно в младшие байты адреса впихнуть. чтобы еще байт-другой сэкономить.

можно еще модули от nanotron посмотреть, у них там широкополосный передатчик для определения расстояния, соответственно должен уметь отвечать сразу довольно быстро, без задержек.

Трансиверы, которые рассматривал (например, ATMEGA128RFA1) передают
со скоростью до 2Mbps только сами данные, а синхронизация, преамбула - на 250kbps. Поэтому только синхронизация
занимает почти 200мкс.
Предложенный Вами вариант опроса датчиков также рассматриваю. Но все уперается в низкую скорость передачи "ненужной" информации.
Радио трансивер nRF24L01 еще не смотрел.
Спасибо! Обязательно взгляну на него.

Вот о том и речь. Если это провода, то какие тут вообще могут быть проблемы со связью.

Данный проект в большей степени исследовательский, задача которого
обеспечить беспроводную связь с быстрым временем отклика.
Конечно, на небольшом расстоянии проводной интерфейс справится
с поставленной задачей без проблем. Вопрос именно по беспроводной
передаче данных.


Взглянул на даташит nRF24L01. На сколько понимаю, весь пакет данных, включая синхронизацию,
адресацию и т.д., передается на скорости до 2Mbps. Теоретически длительность пакета может
быть менее 50мкс, что уже вполне подходяще.
Буду иметь в виду этот вариант.
Спасибо за совет!

Нет, задача сделать беспроводной сбор с требуемой частотой, а это решается достаточно просто разделением ответов во времени.

минимальная длина пакета с один байтом в payload - 49 бит. время в эфире 25мкс.
единственное только вот приёмнику еще какая-нибудь пауза может потребоваться. тут надо внимательно даташит читать.
ну и плюс этих приёмопередатчиков что готовые модули за 2-3$ у китайцев купить можно чтобы попробовать.
http://www.ebay.com/itm/4PCS-Arduino-NRF24...#ht_2640wt_1164

Да, в идеальном случае длительность пакета может быть около 25мкс.
Но в этом трансивере большое время переключения из RX в TX (130мкс).
Поэтому нужно протокол реализовывать таким образом, чтобы эта задержка
не оказывала большого влияния, например, как уже тут предлагалось.
Допустим, главный модуль посылает команду / запрос для считывания первого датчика.
В этот момент времени все сенсорные модули находяться в режиме приема.
Модуль с адресом 1 переключается в TX режим и посылает свои данные.
А остальные модули, приняв команду, запускают счетчик на определенную длительнось
в зависимости от своего адреса (учитывая время переключения из RX в TX),
по истечении которого переключаются в режим TX. И так поочередно главное устройство
принимает данные с модулей.
Как мне кажется, при правильном выборе временных задержек для отправки пакетов данных,
можно минимизировать влияние времени переключения из RX в TX. При этом добиться считывания
максимального количества датчиков за 1мс. В идеальном случае теряются только 130мкс при считывании
данных с первого датчика. Может еще дополнительные 130мкс потребуется, чтобы главный модуль
в конце опроса датчиков успел переключиться с режима RX в TX.
Нужно рисовать временные диаграммы...
Как Вы думаете, такой подход будет работать в реальности?
На мой взгляд можно пробовать.
Спасибо за ссылку на дешевые готовые платы. Для прототипа самый лучший вариант.

P.S.
Еще рассматривал вариант реализации на низкоуровневых трансиверах от RFMD, например,
ML2722 (1.5Mbps FSK Trasceiver 902-928MHz)
ML2730 (2Mbps FSK Transceiver 2400-2485MHz)
У них есть только вход для данных, которые будут модулировать несущую частоту в TX режиме,
а также выход демодулированных данных, полученных в RX режиме.
Проблема в том, что нет встроенных FIFO, поэтому эти данные нужно обрабатывать в реальном времени.
Нужно ставить скорее всего FPGA, чтобы справиться с этой задачей.
Это решение мне кажется намного сложнее и ненадежнее.
Просто рассматривал как вариант.

Нет, правильнее — это без "кажется". Можно на месте откалибровать под конкретные модули и ПО все задержки — даёте команду калибровки паре модулей, один начинает передавать сразу, второй выходит в эфир с задержкой, мастер фиксирует момент начала порчи данных, затем второй уходит из эфира, а мастер фиксирует момент возобновления приёма.

Действительно, только в реальных условиях можно определить минимально допустимые задержки.
На данной стадии разработки главное, чтобы это было реализуемо чисто теоретически, беря во
внимание основные временные параметры трансивера.
На практике нужно все равно будет оставлять небольшой временной резерв (5-10%).

Сейчас получается, что на одном канале можно опрашивать до 14 сенсоров, исходя из того, что
передается 3 байта адреса (минимально допустимо), 2 байта данных, 2 байта CRC.
По моим подсчетам получилось 73 бита. На скорости 2Mbps длительность пакета получается не более 40мкс.
Тут также бралось во внимание 2 задержки на переключение главного устройства с режима RX <-> TX (130мкс).

Если требуется большее количество датчиков, то, наверно, можно будет использовать несколько каналов
по 14 датчиков в каждом канале. Думаю, соседние каналы не будут влиять друг на друга.
Дальше информация с локальных главных контроллеров будет стекаться по проводам (например, используя USART
на скорости до 2Mbps ) в центральный контроллер (FPGA или ATXMEGA).

crc можно сделать один байт (а то и вообще выкинуть, но лучше не надо), а из трех байтов адреса - два использовать под данные, если более 256 устройств не планируется. то есть поменять адрес и данные местами. раз под адрес всё равно минимум 3 байта выделено.
правда всё равно, хоть один байт в данных должен быть. но минимум всё таки 49 бит. в полтора раз меньше.

есть еще одна похабная идея:
как только датчики получили команду от мастера, часть из них переключается на другие частотные каналы и начинают сливать данные нескольким другим выделенным датчикам, когда придёт их время эти особые датчики передадут мастеру все собранные от соседей данные за раз, то есть адрес, crc и синхронизация будет передана только один раз а данные сразу от нескольких датчиков.
учитывая что полезных данных 16 бит, а неполезных - под 40бит, то должно заметно помочь.

В моем случае одного байта для адреса достаточно. Было бы хорошо два оставшихся байта использовать для данных.
В детали данного трансивера (nRF24L01+) еще не вникал. Когда поверхностно просматривал его даташит,
у меня сложилось впечатление, что он адрес проверяет железно. И пакет принимается и записывается в FIFO, если совпал
адрес, т.е. все три байта. Может ошибаюсь.
Пока в детали вникать не стоит, т.к. реальная разработка может начаться только через пару месяцев.