TR24A + USB

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


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

Модуль TR24A построен на базе однокристального трансивера EM198810A. Работает в диапазоне 2,4ГГц на тех же частотах, что и блютус. Заявлена фиксированная скорость передачи 1Мбит/c, однако в реальности скорость выходит в несколько раз меньше.
Питать модуль можно от 2,5 до 3,6 вольт, однако, испытания показали, что он нормально функционирует при питании 1,9В (внутри стоит стабилизатор на 1,8В).
Из официальной информации только пару вариантов даташитов на трансивер и 3 аппнота. Документация очень и очень грустная. На форумах много жалоб на этот модуль и все что с ним связано. Готовые примеры кода есть, но у всех авторов что-то да различается. Опять же, если 5 раз перечитать документацию — все вполне нормально работает.
Поскольку ранее были куплены 2 х AT90USB162 — отладочные платы было решено делать на них. В качестве USB-программной части используется атмеловский пример USB-CDC. В системе устройства видятся как обычные ком-порты.
AT90USB162 имеет на борту встроенный преобразователь на 3,3В, так что модуль и сам контроллер запитываются от него.

Схема первого варианта:


Второй вариант:

Работать можно через любой терминал, например, PuTTY.
Формат общения с платой следующий:
<команда>,<параметр1>,<параметр2>,…
Текущий вариант прошивки понимает следующие команды:

  • i — инициализация;
  • q — вывести значение регистра (например, q,9 — выведет текущее значение 9го регистра трансивера);
  • w — записать значение в регистр (например, w,9,0×3003);
  • r — перейти в режим приёма;
  • t — отправка пакета/пакетов. Первый параметр — количество пакетов, второй режим передачи: 1 — повторять, 2 — повторять + переключение каналов, 4 — пинг, 5 — повторяющийся пинг (например, t,1000,4 — отправка 1000 пакетов с ожиданием ответа);
  • p — включение и отключения ключа питания;
  • s — переход в режим сна;
  • l — установка размера пакета (параметр 1 — число 1..63);
  • с — установка номера канала (частота) (параметр 1 — число 1..127, реально каналы>110 нестабильны);
  • v — уровень детальности сообщений (параметр 1 от 0 до 3);

Как уже было сказано выше, 1Мбит/с — фиксированная битовая скорость потока. Но, поскольку для устойчивой связи желательно применять избыточное кодирование + коррекцию ошибок, а также то что буфер FIFO всего 64 байта реальная скорость выходит в разы меньше. Хотя, можно отправлять пакеты и длиннее 64 байт, но это значительно усложняет программную реализаци и для моих текущих задач не требуется.
Значения конфигурационных регистров и некоторые полезные сведения были позаимствованы из кода a9d. Завелось почти сразу.
В ходе тестирования было выяснено, что наилучшая достоверность передачи возможна при использовании избыточного кодирования 8/10 бит (2 избыточных бита/байт) + FEC1/3 (каждый байт передается три раза подряд). Хотя, вместо 8/10 можно применить код Манчестер, тем самым увеличив избыточность, но результат от этого не улучшается.
При таком решении и размере пакета 63 байта реальная скорость передачи составляет порядка 20килобайт/ в секунду (модули на расстоянии метра).

Расстояние

  • В пределах 1-2м количество правильно принятых пакетов >90%;
  • На расстоянии коэффициент падает до 70%;
  • 10м + 2 бетоные стены дают потери больше 50% пакетов, хотя все сильно зависит от канала и расположения модулей
  • Заявленные 100м на прямой видимости получить можно только специальным расположением модулей. И то, приемник нормально может уловить лишь 5-10% пакетов.

Данные расстояния вполне ожидаемы для диапазона 2,4ГГц и передатчика 1мВт, да еще и с такой антенной.

Потребеление

  • В режиме приема: 26мА
  • В режиме передачи: 18-20мА
  • Спящий режим: 8,5мкА(заявленных 3,5мкА никакими манипуляциями получить не удалось).

В целом, спящий режим оказался более полезным, чем я ожидал: достаточно опустить нргу SS, выждать 1мс — и модуль полностью готов к работе. Повторная инициализация регистров не требуется.

CRC

Почему-то все ругаются на внутренний модуль контроля ошибок. Провел испытания в различных режимах, с разной длиной пакета — внутренний подсчет контрольной суммы сообщения работает вполне нормально. «Битый» пакет детектируется обязательно. Довольно редко наооброт, CRC «ругается» на нормальный пакет, но этим можно пренебречь.

Файлы

Документация

Другие решения и обсуждения

Выводы

Несмотря на то что многие кто испытывал модуль, остались им недовольны — решение вполне применимое. Основной плюс — цена. Любой другой «более приличный» подобный модуль стоит в разы дороже.
Собрал прототип малопотребляющего датчика на основе TR24A, выложу чуть позже.

комментариев 39 to “TR24A + USB”

  1. Boris:

    Статья супер, то что я искал, молодец!!! жду статью про датчик.

  2. Boris:

    А зачем PB4 и PB3 соеденять?

    • Klim:

      PB4 не используется. Так получилось для более простой односторонней разводки платы ))

  3. Boris:

    На второй схеме появилась L1, была необходимость ставить?

    • Klim:

      Я на всякий случай и в первую потом поставил…
      Просто, была некоторая разница в качестве приема — при отправке с мелкой платы на большую меньший коэффициент ошибок. Но, скорее всего из-за того, что большая плата у меня на пятиметровом шнурке, в то время как маленькая была или напрямую в ноут втыкнута или через 0,5м удлинитель.

  4. Boris:

    А после того как поставил индуктивность в первую, количество ошибок стало меньше?

    • Klim:

      Точно не скажу, скорее всего да, но незначительно.
      Вероятно, модули сами по себе немного отличаются.
      В любом случае, какой-никакой фильтр по питанию не повредит.

  5. Boris:

    Спаял плату, регистры читаются и записываются, жду датчик на основе TR24A. Спасибо за Ваш труд.

  6. Boris:

    Инициализация выдает — «tr24init: 0 MCUSR= 5» Это провильно?

  7. Boris:

    Спаял датчик, как прочитать его значения с компа, в каком режиме должен быть USB-TR24?

    • Klim:

      те же значения регистров, тот же канал
      потом в терминалке:
      v,1
      r
      можно еще v,3 — тогда будет видно полное содержание сообщения и битые пакеты

  8. Boris:

    Почемуто, чтобы появился девайс /dev/ttyACM0 нужно передергивать устройство. Заменил атмеловский USB-CDC на LUFA CDC проблема исчезла.

    • Klim:

      Наверное, при Stand-by, Hibernate — тоже ?
      Там, в атмеловском стеке, вроде не реализован USB-stanby режим. Так что вполне нормальное поведение )

  9. Boris:

    После перегрузки компа устройство отваливаеться, перешол на LUFA

  10. Boris:

    Первый пост сразу не прошел (не увидел что отправился), сори.

  11. Klim:

    В общем, для дальнейшего развития идеи построения «сети» с множеством датчиков, пока что есть такая идея:
    Датчики шлют данные с постоянным интервалом времени (например, 1с, 10с, 60с)
    Хост постоянно находится в режиме приема, при получении пакета от нового датчика, присваивает ему порядковый номер и отправяляет датчику текущее время и порядковый номер.
    Датчик корректирует у себя часы.
    Далее все пронумерованные датчики используют временное разделение канала согласно их порядкового номера. Например, время полного периода 60с, значит датчик с номером 0 шлет данные в 60,000с, датчик #1 — 60,010с, датчик N — 60+N*10мс.
    Раз в несколько периодов опроса (5,10 например) Хост после получения пакета от датчика передает ему корректировку часов (Расхождение времени на несколько мс за 5 минут будет наверняка)

    • Boris:

      Я пока планирую односторонний обмен, датчики шлют температуру, влажность и состояние батареи. Данные с датчиков пишутся в базу. На веб страничке отображаю текущие данные и строю графики. Пишу на С демона а веб на PHP и javascript.

      • Klim:

        ну это самый простой вариант)
        Просто, если датчиков несколько — будут коллизии. В таком случае, надо устанавливать различный интервал передачи для каждого. Также, можно передавать вместе с тепущими данными несколько предыдущих значений датчиков.

        • Boris:

          Полностью согласен, собрал еще один датчик, всего пока их 2. (Буду частями писать, может капча не будет выскакивать.)

        • Boris:

          пробовал вчера TR24P, запустился сразу, но передавал на 0,5 м, погуглил, оказалось, что нужно включать усилитель, подал 1 на нужный вход и заработал

        • Boris:

          буду его ставить на USB вместо TR24A только прошивку нужно адаптировать. Даже если использовать TR24P только на хосте, то уже вся квартира будет в зоне уверенного приема. Сейчас на TR24A есть комната где датчик не работает.

          • Klim:

            Не факт. Для уверенного приема в помещении, все таки, лучше 433мгц. У 2,4 почти всегда буду мертвые зоны.
            Как обстоят дела с антеннами ? На TR24P их же надо две? отдельно ?

  12. Boris:

    Извините, CAPTCHA была заполнена неправильно. — 10 раз пытался ответ написать.

  13. Boris:

    поле для ввода на 2 символа а нужно ввести 5, хотя пару дней назад получилось с каптчей написать.

  14. Boris:

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

  15. Boris:

    Пришлось на 3 части сообщение разбить.

    • Виталий:

      Скинь пожалуйста схему твоего подключения TR24P. Как я понял, регистры там одни и те же, а вот на какую ногу надо подавать единицу так и не нашел…

  16. Валерос:

    Как переход на CC1101?

  17. Валерос:

    Датчик давления не планируете на хост?

Оставить комментарий

Или