fast rsponse time wireless network, выбор подходящей элементной базы Опции

[Electronics Engi...]

Добрый день!

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

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

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

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

Дмитрий

[Plain]

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

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

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

[Electronics Engi...]

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

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

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

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

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

[Plain]

Питание для датчиков не критично, предусматривается внешнее питание.

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

[Electronics Engi...]

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

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

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

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

[_pv]

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

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

[Electronics Engi...]

минимальная длина пакета с один байтом в 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, чтобы справиться с этой задачей.
Это решение мне кажется намного сложнее и ненадежнее.
Просто рассматривал как вариант.

Сообщение отредактировал Electronics Engineer - Mar 1 2012, 10:16

[Plain]

мне кажется, при правильном выборе временных задержек

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