Сейчас занимаемся созданием распределенной беспроводной сети для датчиков. Используем продукты от RFM, т.к. они имееют наименьшее потребление/время выхода на режим. Пока все устраивает, но хотелось бы перейти на многочастотную сеть. Проблема в том, что задержка доставки сигнала события должна быть очень небольшая. Сейчас решаем этот вопрос проверкой сигнала RSSI (оцифровкой) каждые 50мсек. (если есть несущая - проснуться и попробывать принять пакет). Варианты с обычными супергетеродинами не подходит, т.к. у них очень большое время выхода на режим (пока заработает кварц, потом VCO/PLL). Сам я в радиотехнике смыслю плохо, но есть идея. Оцените, пожайлуста. Можно ли использовать ЦАП (бит 16) для настройки на частоту (управлением варикапом) для быстрого выхода на режим приема. Это позволило бы не включать кварц/PLL. И изредка (раз в несколько секунд, скажем) корректировать напряжение управлением варикапа с помощью обычного PLL, для компенсации температурных эффектов. Т.е., микроконтроллер просыпается каждые 50мсек, включает быстрый ЦАП, необходимые блоки для приема (LNA, Mixer, IF amp), потом оцифровывает выход с IF для определения - есть ли несущая или нет.

Предлагаю Вам беспроводной сенсор на 2,4ГГц с микроконтроллером MSP430 на борту, потребляет в спящем режиме 4мкА, время выхода на прием из спящего режима - 2 милисек, переключение RX-TX - менее 1 милисек, при скорости 250кбод, вероятность пакетной (16 октетов) ошибки PER<5% при расстоянии 50..100 метров в черте города (прямая видимость между передатчиками) при работе на 1/4 волновую антенну (~2.5 см).
Также к платформе предлагается бесплатная ОС TinyOS + аппаратная прослойка (HAL) + пример приложения реализующий механизм множественного доступа к каналу передачи данных и маршрутизации.
За 2..4 мсек Вы успеете передать пакет, принять ACK или определить коллизию.

И сколько же он будет потреблять в ждущем режиме при необходимости прослушивать эфир каждые 50 мсек ? Просыпается он 2 мсек, т.е. только на "просыпание" он будет потреблять 4% от потребления в режиме приема. При, скажем, 15 ма в режиме приема - получится будет жрать 600 мка в ждущем режиме. Боюсь, это неприемлимо.

Вы, случайно, не люксофтовские платы предлагаете?


Интересно, каким образом Вы определите коллизию?

Если не секрет, какое время требуется Вашему устройству для принятия решения о наличии или нет полезного сигнала?

А что Вы имели в виду под многочастотной сетью?

1. Нет, свои, а HAL - переделал из telosb, а вы случайно не оттуда?
2. Я имел ввиду отсутствие ACK

Более подробно про момент просыпания см. CC2420 DataSheet, часть веремени затраченное на просыпание ~1mA, а прием длительностью 16байт - 0,5мс.
А вообще надо еще определить что в вашем случае будет эффективнее - применение S-MAC, CSMA-CA, CSM-CD, ALOHA или др. механизмов MAC. Может определение несущей вовсе необязательно, а достаточно определить наличие колизии уже после передачи.
Интересно Ваше мнение. Сколько элементов в сети? Какой объем передаваемой информации? Сколько элементов попадает в зону приема одного элемента. Интересная статья например есть C.-F. Chiasserini and M. Garetto «Modeling the Performance of Wireless Sensor Networks»

Да передачи может и не быть. Главное - минимальное latency. Т.е., приемник должен быть или постоянно включен, или время сна/проверки несущей у приемника должно быть минимальным для того, что бы гарантированно начать прием/передачу скажем, через 50-60 мсек. Элементов может попадать от 10 до 100, количество элементов - 3000. Задача - доставить сообщение через сеть в течении максимум 3 секунд. Количество прыжков может дойти до 15-20.


Не секрет - 200 мксек, при потреблении приемником 3мА + АЦП (не помню сколько из MSP430) + процессор. Итого, где-то 7-8 мА.

Боже упаси, конечно, я не оттуда
А Вы пытались реализовать какой-нибудь MAC-протокол на CC2420? Просто, на мой взгляд, микросхемка весьма хорошая в плане энергопотребления и соответствует 802.15.4, но в этом и заключается ее беда, т.к. она слишком заточена под MAC уровень 802.15.4 и не оставляет свободы творчества. На это, кстати, и напоролись ребята из беркли. Хотелось бы узнать Ваши впечатления от CC2420.



Не плохо. При таких характеристиках средний ток будет небольшим при проверке канала каждые 50 мс, но ведь Вам еще надо гарантировать, что моменты передачи пакета и проверки состояния канала приемником совпадут. Следовательно, необходима синхронизация, что приводит к дополнительным затратам, либо требуются другие меры.
А что за протокол маршрутизации Вы используете? Ведь он также оказывает влияние на латентность системы.

А на чем они напоролись? Нормальный кристал, MAC переделал из того что делали в беркли, маршрутизация - с учетом особенностей задачи. На компе иммитировалась модель 100-элементной сети, в реальности 10 элементной.

Гарантия обеспечивается длинной первой преамбулой (60мсек). Протокол свой. Исходя из категории сообщения выбираются разные маршруты (минимальное потребление, максимальная скорость, etc.). "Тонкую" настройку маршрутов обеспечивает dedicated нода после полной автоматической настройки комплекса (фактически, компьютер на арме и с нормальным питанием). Смотрел на TinyOS, но достаточно сложно запихнуть свои дополнительные задачи в код операционки (обработка датчиков). MAC получается по сути - B-MAC.
Супергетеродинные схемы не подойдут такими, какие они есть. Потребление получается больше в разы (за счет долгого выхода из спячки). Сейчас даже кварц не используется (используется DCO MSP430), а для супергетеродина он необходим. Поэтому и размышляю над непосредственном управлением варикапом VCO - должно помочь.

А какой именно MAC вы переделали? Например, упомянутый B-MAC на telos'е так и не смогли сделать.
Кстати, по поводу моделирования. Вы пользуетесь только симулятором под tinyos или применяли какие-то другие симуляторы для отладки протоколов?


Неужели у Вас есть боевая реализация протокола маршрутизации, решающего описанные задачи, или это просто планы?

Нет не B-MAC. Только TOSSIM+TinyWiz, правда пришлось исправлять ошибки присутствующие в TOSSIM-CC2420 на тот момент и вызывающие некорректную работу очереди сообщений.

Понятно. Лично мне не нравится tinyos из-за своей узкоспециализированности, которая по большому счету ничего кроме проблем не приносит.

Да. Будем ставить скоро на реальный обьект - будет видно на сколько он "боевой". Боюсь, часть маршрутов придется редактировать ручками. Пока проходит тест на 300 элементов.