Помогите подключить к STM8 радиомодуль на 433 мГц

niXto · 20.01.2016, 17:57

AR_Favorit
При потреблении 4 мА дальность совсем никакая, не больше десятка метров. Обычно такие передатчики потребляют при 3 В питании не меньше 30 мА

За 30...50 мс он передаст только один пакет на скорости 2400...4800, случайная помеха в канале = пакет битый и отвергается. Обычно для надёжности передаётся 5...10 пакетов с паузой сотня мс

СС1101 при дальности 50 м потребляет около 20 мА вместе с контроллером, передача пакета и приём подтверждения на 100 кбит укладывается в 10 мс. Если нет подтверждения - моментально валится в сон с потреблением микроамперы и через некоторое время проц стартует повторную передачу, поэтому данные Всегда Гарантированно доходят, а потребление всегда минимальное

niXto · 20.01.2016, 18:01

marera, с фифо но без аппаратного crc тоже постоянно ловят мусор
И преамбула НИкогда не FF или 00
Обычно E7 или A5

AR_Favorit · 21.01.2016, 03:26

Сообщение от marera

Нецифровые радимодули без FIFO в приемном канале всегда гонят мусор!
Поэтому обязательна приамбула - передача в пакете предваряющей посылки в несколько десятков байт. При приеме этой посылки в приемнике срабатывает АРУ, ловится несущая и он выходит на нормальный режим.

Все верно. Можно подсмотреть, например, в даташите на hcs301 (кодер keeloq) пример организации посылки. Преамбула там вообще набор импульсов, отбрасываемых декодером.

AR_Favorit · 21.01.2016, 03:37

Сообщение от niXto

AR_Favorit
При потреблении 4 мА дальность совсем никакая, не больше десятка метров. Обычно такие передатчики потребляют при 3 В питании не меньше 30 мА

За 30...50 мс он передаст только один пакет на скорости 2400...4800, случайная помеха в канале = пакет битый и отвергается. Обычно для надёжности передаётся 5...10 пакетов с паузой сотня мс

СС1101 при дальности 50 м потребляет около 20 мА вместе с контроллером, передача пакета и приём подтверждения на 100 кбит укладывается в 10 мс. Если нет подтверждения - моментально валится в сон с потреблением микроамперы и через некоторое время проц стартует повторную передачу, поэтому данные Всегда Гарантированно доходят, а потребление всегда минимальное

Метров 20 получалось на открытом пространстве. Тут еще от антенн зависит.
Если нужна гарантированная доставка, то трансиверы типа СС, конечно, лучше. Но для уличного датчика температуры она не особо нужна, а сформировать пакет и дешифровать его на стороне приема куда проще, чем разбираться с программированием трансивера. Схема и монтаж тоже примитивней.
А вообще, если уж брать трансивер, то, может, имеет смысл выбирать для датчика сразу со встроенным микроконтроллером что-то типа nrf24LE1?

vovik_t · 21.01.2016, 09:02

Занимался много радиомодулями. В конечном счете остановился на rfPIC12F625. Работает на 300, 430 и 900 МГц при питании от 2,3 до 6 вольт при токе потребления до 10 мА. Удобно, что в одном корпусе микроконтроллер и трансивер. Реальная дальность при 3-х вольтовом питании до 500 м при прямой видимости. Если интересует, могу поделиться информацией. Есть еще неплохие готовые модули с АИМ и ЧИМ.

Jazz777_ · 21.01.2016, 12:24

Сообщение от vovik_t

Если интересует, могу поделиться информацией

Интересует:
1. Дешево
2. Эноргоэффективно для передатчика, т.к. он на батарейке. Очень желательно работа от 3в обычной таблетки. Приемник от сети.
3. Не заморочено в плане изобретения велосипеда

Не критично:
1. Не критичная потеря пакетов
2. Расстояние. Приемник и передатчик будут находиться в одной комнате

Кто-нибудь подключал радиомодуль на 433 мГц на ардуино с их библиотекой? Нормально работает?

vovik_t · 21.01.2016, 15:10

Алгоритм работы такой:
- 5 минут микроконтроллер спит (ток потребления около 1 мкА)
- просыпается (на 10 мс), получает информацию от сенсора и включает передатчик (передает пакет данных). Также анализирует собственное питание (посредством внутреннего АЦП). При понижении установленного уровня передает сигнал о понижении.
Батарейки типа CR хватит на год. Ничего сложного нет.

Someone · 21.01.2016, 23:18

Сообщение от Jazz777_

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

Это означает 5 минут спать, просыпаться на какое-то время, проводить измерения, сборку данных в пакеты, и передачу в эфир этих пакетов. После чего снова спать. Отсюда выводы:
1) Более быстрый контроллер быстрее соберёт пакет, потребив больше энергии, более медленный потратит больше времени, но и энергии меньше уйдёт. В среднем, потребление будет примерно одинаково.
2) Время передачи пакета будет одинаково. Очевидно, что более шустрый контроллер в активном режиме при ожидании скушает больше, время-то передачи одно.
3) Время измерения будет определяться не производительностью контроллера, а частотой АЦП, и для одной и той же задачи будет сопоставимо. А с учётом примерного равенства характеристик АЦП современных микроконтроллеров, можно принять, что разницы либо не будет, либо она будет незначительна, и, так как время примерно равно, шустрый опять скушает больше.
4) Все действия контроллера в активном режиме займут ничтожное время по сравнению с временем сна, следовательно более экономичным будет контроллер потребляющий меньше в режиме сна. Тут всё зависит от архитектуры и производителя контроллера. Шустрый может во сне потреблять меньше медленного, а может больше.

Получается, что подбирая контроллер для наименьшего потребления, главное, на что надо смотреть - сколько потребляет в режиме сна. Вторым по важности фактором идёт меньшее потребление в активном режиме.

Someone · 21.01.2016, 23:22

Сообщение от niXto

Посмотри СС1101 и аналогичные трансиверы

Кстати, а каким балуном пользуешься?

Someone · 21.01.2016, 23:31

ЗЫ: Кстати, стм8, если верить иностранным источникам, например

http://electronicdesign.com/microcon...t-design-s-mcu

вовсе не является рекордсменом в пониженном потреблении в режиме сна (см. режим Static в таблице раздела "Power Consumption"), и в немножко более, чем в 2 раза (в домашних условиях), уступает по этому показателю 32-битным ядрам арм. Если тебе важен именно стм, стоит присмотреться к стм32, он должен проработать дольше.