Сенсорные сети, Вопросы потребления Опции

[Concorde]

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

[Dr.NoA]

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

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

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

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

[Concorde]

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

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

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

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

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