Радиомодули HopeRF HM-R433 и HM-T433. Проблемы и решения

При первоначальных испытаниях сея железка показала себя с лучшей стороны, но вот на практике вылезли не просто баги, а прям гигантские тараканы убийцы. Казалось бы, чему там работать не так? А, как оказалось, есть чему. Точнее это не баги, а особенности, о которых производитель самым подлым образом умолчал в даташитах. Знай я о них я бы еще подумал стоит ли их покупать. Итак:

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

Ждущий режим
У передатчика, к моему, а также ряда внимательных читателей, удивлению нет входа Enable. У приемника то есть. Редкостный бред, особенно ввиду того, что спустя 70mS простоя на линии DATA передатчик впадает в спячку и… правильно, отрубает несущую — на выходе приемника начинается в этот момент жуткий срач. Так что либо шли данные непрерывным потоком, либо перед каждой посылкой шли идентификационный пакет. А еще не забыв предупредить приемник о том, что передача закончена и дальше ловить нечего.

Совместная работа
Тут все просто, два передатчика одновременно работать не могут. От слова совсем. Либо по отдельности, либо никак. Это было ожидаемо и это надо учитывать.

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

Ок, раз несущая у нас пропадает, попробую я финт ушами — буду слать управляющие команды не по одному байту, а пачками. Среди мусора десять повторяющихся байт будут очень заметны и передающая сторона без труда их вычленит из этого шума. Сказано сделано. Думаете работает? А вот хрен там! Нет, 10 то одинаковых байт передаются отлично, вот только это каждый раз разные 10 байт. С передающего контроллера всегда уходит 10 единичек (код 0х31), а из приемника может вылезти «что угодно» *10, например, 10 букв «А» или десять закорючек и прочее. Нет, 10 единичек тоже вылазят, примерно в 30%. Но это же писец какой то, а не передача.

И тут я опять почесал репу. Как же так? Ведь пила (байты от 0 до 255) передается на ура, без помех и искажений. Осмысленный кусок текста, передаваемый по UART, тоже приходит отлично, без опечаток вообще, словно по проводу. А десять одинаковых байт превращаются во что угодно. Такое ощущение, словно несущая восстанавливается абы как и настраивается уже по ходу передачи символов. Послал в UART текстовое послание, и точно — первые 3 символа превратились в кашу, а остальные идут молодцом. Гхм. Ладно, перед нашей посылкой делаю отправку небольшого слова — «PREVED», а потом 10 единичек. Гляжу в терминал… PREVED??? Ага, ЩАЗ! МЕДВЕД! На выходе явно какое то слово, но оно, словно сдвинуто по таблице символов на какую то константу. Причем в тех же 30% передача идет нормально. Гхм. Засада какая. Выходит отправляешь один и тот же символ — не работает, посылаешь слово — не работает. Ладно бы ваще не работало, а почему когда гонишь абзац текста, то месит только три первых символа, а остальное идет нормально? Мистика да и только.

Решил попробовать сделать свою несущую, чтобы передатчик не замолкал ни на миг стал по прерыванию от UART слать в канал символ, а как полезная передача, то отрубаю прерывания и шлю вручную. Гхм. Символ то шлется, вот только на выходе то он, то какой то другой символ. Опять не айс. Тут, думаю, раз уж ты, зараза такая, не можешь отстроить канал на одном символе, пошлю ка я тебе пилу в качестве несущей. Послал — заработало все без ошибок. В Idle режиме у нас тупо гонится пила, а как надо передать данные — пила без проблем прерывается и пакет данных уходит бит в бит. Тока не нравится мне, что у меня под пила постоянно гонится — на детектирование пакета нужно дополнительные телодвижения совершать и я стал экспериментировать дальше. Логика и шестое чувство, расположенное в пятой точке, подсказывало мне, что тут дело в каком то хитром байте, на котором канал встает нормально и дальше работает без проблем. Стал проверять какой же символ лучше всего инициализирует работу канала.
Нашел — если отправить 255, то канал поднимается сразу же и шлет дальше данные без ошибок вообще.

З.Ы.
Я их еще на дальность не тестировал. Ждите, скоро будет.

58 thoughts on “Радиомодули HopeRF HM-R433 и HM-T433. Проблемы и решения”

  1. В самом начале даташита черным по белому написано, что эти модули являются заменой ASK-модулям и не более. То есть реализован чистый радиоканал с ЧМ-модуляцией вместо АМ-модуляции. И никакого пакетного модема. Чудес в радиотехнике не бывает.

    1. Да понятно, что не пакетный он просто вход и выход, но в таком случае что на входе, то и на выходе должно быть. Своего рода замена проводу.
      А тут не так, точнее через раз. Или я неправильно понял логику его работы?

      1. На обычном проводе тоже могут быть наводки ;-)

        Приёмник-передатчик тебе позволяет только передавать данные. А вот правильные они или нет, контролировать приходится уже тебе на протокольном уровне.

        Полистай на тему кодов Баркера и вообще шумоподобных сигналов.

        Ещё посмотри протокол LinkBell который поверх serial работает.

        1. Пока сидел в сортире понял откуда все беды — стандартный UART не позволяет определить конец байта. Т.е. при сдвиге у нас стоп неотличим от обычного бита. А поскольку на выходе изначально шум, то неизвестно в каком месте начнется передача, и где будет следующий байт. Так что в данном передатчике надо перед передачей обеспечить пробуждение несущей, потом подержать в течении одного-двух байт линию в High, а после уже гнать туда UART.

          1. там у него на выходе шум эфира или прямоугольник?
            пилы там быть не должно

            защита от шума реализована внешним компаратором и передатчик как раз при отсутствии данных молчит и позволяет другим приемникам принимать

            1. Шум был в терминале. Т.е. хаотичные символы в отстутсвии передатчика. Что за сигнал конкретно на выходе приемника я осцилом не смотрел. Думаю прямоугольники.

          2. Я вот так сразу и подумал… Такая же фигня, если подключить МК к COM порту компа во время неприрывной передачи данных.

          3. Не, серьёзно. Попробуй LinkBell заимплементить. Он работает поверх обычного serial (uart), предусматривает преамбулу для синхронизации, эмулирует похожий на манчестер поток бит, контролирует правильность пакетов через CRC16. Поддержка проводных и беспроводных сетей.

            Поскольку где его описалово сейчас в сети лежит, я не нашел, закинул к себе: http://tuxotronic.org/wiki/protocol/linkbell

      2. Я тоже искал «замену проводу». Почитал про Ваши проблемы с отсутствием Enable и сном передатчика, поискал по датшитам и прикупил на пробу фирмы Telecontrolli два модуля RTFQ1-433 и RRFQ1-433. На первый взгляд «честные» модули с Enable. НО! Как оказалось через них нельзя протолкнут лог «1» длительностью более 2.5-3мс, дальше на выходе приемника вместо «1» опять «0». (несущая «0» передается — помех на приемнике нет, просто лог «0»).
        Как результат, пришлось инвертировать UART («0» передается сколь угодно долго, а «исходный» уровень UART «1» и держиться только 2.5-3мс). Но и с минимальной скоростью естественно тоже проблемы. Т.к. если старт_бит + 8 лог «0» -> и после инвертора = один «длинный» импульс «1», а его длительность ограничена. Т.е. теоритически миним. скорость в районе 3000 бит/с. А максимальная у него по датшиту 9600.
        При тестах так и получалось: на скоростях ниже 3000 происходили искажения байт с «длинной» последовательностью «0» (1,2,..,64,128). Стабильно работает только на 4800. На 9600 опять потери инфо.
        И об нюансе этом ни слова в датшитах, что мне попадались на него.

        Я это все к чему, не наступите на грабли на низких скоростях при работе с этим модулем.
        (может правда это только у меня «ущербные» такие модули? взял только один комплект, надо бы на нескольких проверить)
        Цена модулей в районе 280-350 рублей. По дальности при антенне на 1/4 (без какого либо согласования) около 100м на открытой.

  2. Ждём-с! А то я уж губу раскатал…
    Собрался на них управление фотоаппаратом делать. Тем, который на воздушном змее …

    1. OFF. На осенней выставке узнал об готовящемся проекте запуска воздушного шара, который полетит через всю Сибирь. На нем будет установлен трансивер 433МГц и каждый радиолюбитель Сибири сможет связаться с ним, чтобы получить телеметрическую информацию. Может быть туда встроять полуватный трансивер RFM12BP-433.

  3. Столкнулся с той же фигней.
    В интернете не нашел не какой толковой подробной инфы как работать с такими модулями. Все пишут «юзайте манчестерский код». Ну заюзал, так все равно проблем куча и качество приема плохое. А производитель до 300м пишет! Ха ха! Описали бы хоть протокол, какие-то реккомендации как они выжали 300 метров.
    Мдя.
    Пока отложил.

    1. «манчестерский код» был разработан для систем, где нет возможности сохранить постоянную составляющую (она у него нулевая). Кроме того, у него в спектре вроде присутствуют только 2 частоты (при АМ), что облегчает фильтрацию и автоподстройку. Ну и полярность (перемена линейных проводов местами) не критична. В остальном особых преимуществ вроде не имеет.

  4. Попробуй поставить в UART 1,5 или 2 стоповых бита. При 1 стоп не отличим от других посылок, и синхронизация легче теряется. В телеграфии это давно известно, поэтому передатчик телеграфного аппарата при автоматической работе (непрерывная передача из памяти или с перфоленты) формирует стоп длиной 1,5 посылки. Даже при потере синхронизации при таком стопе она через несколько знаков восстанавливается. Или при паузе (стоповая полярность) длиной чуть больше символа. Идеальна для синхронизации комбинация, в которой все посылки стоповой полярности, тогда фактически передается один «Старт». В ASCII это 255 ($FF, 11111111), в телеграфии — «Латынь» (11111 в коде МТК5). Так что отправка перед сообщением двух «я» гарантируют тебе синхронизацию. Если она в процессе приема не нарушится…
    Другой вариант — как в работе телетайпа по радио у вояк или радиолюбителей. (Да и в старых модемах). «Стоп» передается одной тональной частотой, «Старт» — другой. Тональные частоты приема и передачи разные и не кратные друг другу. Скорость, конечно, вряд ли получится больше 1200 бод, да нам много и не надо. Правда, придется городить 2 генератора (или 1 с перекл. частотой) и 2 фильтра на каждый конец. Ну да связистам не привыкать, второй век так работают… В телефонный канал 300-3300гц еще в 60х годах запихивали 12 телеграфных 50 бод (по 200 Гц на канал, защитный промежуток 50 гц), или 6 — 100 бод, или 3 — 200 бод. В 80х, на аппаратуре с цифровыми фильтрами 6го порядка на операционниках, и импульсным кодированием, уже до 48 50-бодных каналов или 12 200-бодных в одном телефонном.
    Для контроля правильности приема достаточно для начала включить в UART контроль по четности, (точнее, чаще используют НЕчетные комбинации, выше надежность- всегда будет передан хотя бы 1 бит). Уже половина проблем отпадет. Кроме того, раньше для контроля данных на ленте или в канале, передавали информацию небольшими блоками, в конце которых добавляли еще байт «продольного» контроля — каждый бит в нем дополнял до четности или нечетности сумму соответствующих бит всех байт блока. В общем, проблема стара, и вариантов решения уже накоплено множество. Жалко, что ты не связист, было бы проще.

    1. У меня пока проблема синхронизации вылезла, в целом уже допетрил как ее решить, либо выдавать 1ю паузу длинной в символ, чтобы канал проснулся, а на приемнике закончился байт шума к этому времени, а потом ловить уже чистый старт. Ну и передача избыточных данных решает проблему ошибок. Технологий тут дофига.

  5. Большинство радиомодулей «высокого» уровня кстати строятся как конструктор — микросхема приемника/передачика/приемо-передатчика + контроллер который реализует уже некий протокол и обеспечивает корректную передачу и прием. Все вкусные плюшки радиомодуля возлагаются именно на этот управляющий контроллер. Примером тому — модули Radiotronix(Semtech) внутри которых Silab’овский 8051.
    Я вот до сих пор решаю покупать подобную готовую радиосборку или заморочится с разработкой устройства с нуля. Первый вариант существенно ускоряет разработку, но «не спортивный», второй интереснее да и дешевле.

    1. Для меня выбор между вот таким вот «радио проводом» и полноценным пакетным трансивером решился на антенне. Банально этот модуль мне было проще и дешевле вывести наружу, чем модули TR у которых под антенну SMА разъём и нужно еще антенну покупать. А тут простой четвертьволновый провод проканает.

      1. Дело в том, что сборка сборке рознь. Согласно документации на те же WI.232FHSS-25/250-R модули от Radiotronix у них единственно требование — 50-омная антенна. А какая она будет — это зависит от того как мы собираемся использовать наше устройство с данным модулем.
        Говорю об этих сборках потому что в фирме которой я работаю для разработки одного устройства было принято решение использовать именно их. Так что позже могу отписаться о результатах :)
        Если интересно самому почитать, то поиск в яндексе по WI.232FHSS-25-R первым же результатом дает описание продукта на сайте производителя, правда на английском.

    2. Мой опыт общения с разными китайскими устройствами с радиоуправлением показал, что простой сверхрегенератор (иногда с фильтром на ПАВ) и операционником, обычно LM358, выдает в отсутствии сигнала брелка все, что угодно, но применение сравнительно простых (на первый взгляд) кодеков и декодеров обеспечивает стабильную работу месяцами без каких-либо ложных срабатываний. Так что не все так печально. И простой приемник, соответственно поддержанный аппаратно и программно, вполне может пригодиться, по крайней мере, в домашних самоделках. Не на Луне же им работать. Или радиоуправляемые модели. Работают рядом, по нескольку штук, (особенно в автогонках), на очень близких частотах, и ничего…

  6. Ага, а я предупреждал!
    Я использовал манчестерский код не только из-за нулевой постоянной составляющей (при AM это критично), как писал SWG, но и из-за возможности синхронизировать приемник и передатчик в каждом бите — при передаче бита в середине всегда есть фронт, по нему можно засинхронизировать таймер. Для устранения помех я выдавал не постоянный уровень, а последовательность 00110011 и т.д. (тоже критично при AM), на входе ловил последовательность и прием начинал только при наличии на входе нескольких нормально принятых байтах. Сигналом к приему служит короткий импульс — 0011001101…. — вместо точек начинаются осмысленные данные. Могу поделиться исходниками, если DI HALT захочет выложить их на сайте. Правда, реализация чисто программная (с использованием прерываний) — как заставить UART нормально принимать я не придумал из-за сдвига момента запуска приема байта.

  7. Могу ляпнуть чушь так как про модули не читал, но они вобще цифровые или аналоговые? А то может контроллер не доконца словить сигнал с выхода приёмника умудряется?

    1. Вроде как цифровые, по крайней мере производитель о аналоге ничего не заикался и в примере у него исключительно цифровой источник сигнала (MCU or Encoder)

  8. Жуть… я вот прикупил 2 таких модуля HOPE RF «HM 433 R» и «HM 433 T» хотел сделать радио управление двумя моторами с регулировкой скорости + 2 сервы, ну и ещё пару простых штук типа включено\выключено(робот на гусеницах с камерой на 2 сервах и выключаемой подсветкой). Данные надо передавать в несколько пакетов

    К примеру так:
    Байт 1:
    первые 4 бита код в котором записан номер пакета «1» грубо говоря, следующие 4 бита команда(выходит 16 команд).
    Байт 2:первые 4 бита также как и в первом, а следующие 4 бита значение.

    Ну вообще конечно хотелось бы чтоб значение было по больше 4 бит…

    Что думаете по этому поводу, на сколько это плохо будет работать(передатчик вешаю на FT232 подключеную к USB ПК, а приёмник к UART на AT контроллер) ?

    1. Все решается программно. Главное недавать модулю впадать в спячку т.е. постоянно слать данные. Иначе могут быть приколы. Ну и отличать шум от сигнала.

      1. Ясно, ну как я понял если перед полезной информацией, пропихнуть байта 3 со значением «255» то канал встаёт и далее передав полезные байты можно расслабится.

          1. Ммм у меня связь в 1 сторону, спасибо буду пробовать если получится стабильный протокол, то зпилю статейку :)

              1. Всё оказалось лучше, чем казалось на первый взгляд, после отправки пару байт мусор резко исчезает и приходят данные которые были отправлены следом :), а потом вновь мусор. Написал простой протокол по идее должно работать.

                1 пакет данных будет состоять из 4 байт:

                Байт 1 — стартовый байт сигнализирующий о начале передачи данных — 255

                Байт 2 — команда 0-254 /не может быть 255 т.к мы пятью байтами «255» будем будить передатчик.

                Байт 3 — аргумент 0-255

                Байт 4 — контрольная сумма исключающее или Байт4=(Байт2 xor Байт3)

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

    1. Добрый день, думаю для экспериментов приобрести данные модули. Не могли бы Вы скинуть код для передатчика?

      1. Можно попросить небольшие пояснения к представленному выше листингу? Думаю прикрутить вашы наработки вот сюда http://www.ebay.com/itm/315Mhz-RF-Link-Kit-Arduino-ARM-MCU-Transmitter-Receiver-Pair-/250997071148?_trksid=p4340.m185&_trkparms=algo%3DSIC.NPJS%26its%3DI%252BC%26itu%3DUA%26otn%3D5%26pmod%3D250826077551%26ps%3D63%26clkid%3D6413882848069597566#ht_1913wt_1185

  9. Столкнулся с такой проблемой — приемник иногда не запускался (перепробовал 5 модулей). Не генерировался белый шум и вообще не принимал. ПРичем, когда клинило, то при работе от мощного блока питания (где кривая подачи напряжения не очень высока) перезапустить было очень проблематично даже после 10 перемыканий питания. Это составляло серьезную проблему (управлять надо было устройством на очень большой высоте и я влетел на вызов вышки) Решил проблему таким образом — поставил супервайзер ADM695 ( контроль наличия белого шума идет на ножку 11, ножка 15 ( с подтяжкой 3,7кОм на питание) идет на ENABLE модуля, питание +5В на ногу 3, земля — 4, вывод 1 заземлить (это вход батарейки). Теперь при подаче питания идет небольшая пауза , потом подается «1» на ENABLE, если белый шум или сигнал не появился, идет сброс в «0», после чего опять на ENABLE подается «1». Больше приемник не зависает.

    1. Такая же проблема, но попроще: я изначально припаял перемычку между VCC и ENABLE, но приемник при включении питания иногда не стартовал.
      Что странно: я замыкал эти же (соединенные перемычкой) контакты касанием пинцета — и модуль запускался.

      Такой вопрос — у Вас приемник не отключался ли (или зависал) со временем? Просто я думаю имеет ли смысл ставить аналогичную вашей систему принудительного старта модуля и постоянно его контролировать, или достаточно будет просто написать простенькую функцию при сбросе основного управляющего контроллера.

      1. Писал там чуть ниже о своей проблеме.
        У меня один модуль с передёргиваниями запускается, а вот что интересно — взял ещё один модуль, EN соединил с питанием проводком.
        Подключаю к аккуму.
        Так вот ещё ни разу не вылез этот «не запуск».
        Может проблема со скоростью питающего напряжения ?
        Потому что первый блок у меня подпаян к PICу и питается от программатора,
        а второй непосредственно от аккума.

        1. Это ваше наблюдение наводит меня на мысль, что стоит параллельно входу ENABLE и земле подключить конденсатор. Тогда разрешение будет подаваться плавно и не одновременно с питанием… *ушел пробовать*

          1. Тут проблема больше в том, что при отсутствии активности на входе трансмиттер засыпает и глушит несущюю, а у передатчика начинается упячка.

  10. Такая же беда.
    После старта PIC пуляет десяток импульсов длительностью с периодом 0,2 с (меандр) на Enable.
    Включал-выключал, иногда сигнал на выходе появляется через 4-5 «передёргиваний», но в основном сразу. (сужу по светодиоду, подкл на выход)

  11. Делаю систему, типа «брейн-ринга» — несколько команд, у каждой кнопки.
    На выхлопе у центрального блока должна быть последовательность нажатия кнопок.

    Центральный блок + 5-6 кнопок, в каждом из которой передатчик. Умножаем на 72 мс и получаем кучу времени.
    А т.к ENABLE у передатчика нет, нормальный ли будет режим работы, если я его буду вкл/выкл через транзистор ?
    т.е «кнопка 1» включила передатчик, передала , вырубила. Т.е на передачу будет уходить пару мс.
    дальше «кнопка 2» включилась, передала, вырубилась.

    Синхронизировать думаю по «сигналам точного времени» с управляющего блока, после которого каждая кнопка передает своё состояние в свой временной коридор.

    Читая ваш блог, понимаю что желательно ещё 255 передавать перед началом посылки.

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

      1. Хороша штука, жаль не попалась на глаза ранее.
        Хоть и подороже в несколько раз чем радиомодули, но наверное было бы более быстрее всё сделано.

      2. В общем потестил немного и судя по тестам передатчик после подачи питания приходит в себя прибл. через 200-250 мс
        Вход долбил посылками, питание врубал через транзистор.

  12. У вас вон написано что время засыпания 70 мс, а у меня получается 120, не менее.

    делаю так:
    1-й блок шлёт пачку импульсов на 2-й блок.
    2-й блок принимает, выдерживает паузу в N мс
    и шлёт в ответ пачку импульсов.
    1-й блок принимает и радостно моргает светодиодом.

    Так вот если эта пауза меньше 115-120 мс, то светодиод не проявляет признаков жизни.
    Время передачи пачки импульсов около 12 мс (пуляю 8 раз 255, потом 254,253 и данные 1 байт).

    Это блоки такие или я где-то туплю ?

  13. Кто работал с RFM01-RFM02?
    2 глюка —
    1 в адекватном виде доходят только половина данных,
    2 при считываниии из FIFO не устанавливается nIRQ, и процессор считывает данные дальше (по 2-3 раза) пока nIRQ всеже не установится в 1. Но иногда все получатся с первого раза.

    Мне нужны компактные модули (минимальный размер (ширина) не более 20 мм), которые работали бы >=100 м реального радиуса действия, скорость — хватит и 2400. данные (несколько байт) отправляются все время, или раз в секунду, или раз в 10 секунд. как попало. приемник должен с первого раза получать посылку.
    рфм01-02 по описанию подходят отлично, но почему-то мне не удается их заставить нормально работать.
    Нужна помощь, готов заплатить.

  14. Как всегда, DI HALT, огромное спасибо за сайт! Я себе заказал вот таких модулей из Китая: http://tinyurl.com/pp6dtce (ссылка на Ebay). Хочу сделать машинку, радиоуправляемую с компа. Уже разобрался со всеми составными частями (колеса на шаговых двигателях, UART, а больше там ничего и не будет), кроме передатчиков. Почитал комменты, ужаснулся :D Надеюсь, у меня получится :)

  15. Производители автосигнализаций забарывают подобного рода проблему посылкой преамбулы. Она же (преамбула) может служит для коррекции частоты , дрейфующей по температуре, свежести батарейки и всего такого.

Добавить комментарий

Ваш e-mail не будет опубликован.

Перед отправкой формы:
Human test by Not Captcha