В этой статье мы определимся со способом передачи информации по IR-каналу 1WIR-сети. Так как в качестве приемника мы используем TSOP (который создан для того, чтобы принимать сигналы от различных IR-пультов), правильно будет не выдумывать велосипед, а выбрать для нашей сети готовый обкатанный протокол.
Вообще протоколов, фирмы производители радиоэлектронной техники, понавыдумывали огромное количество, но вариантов кодирования в посылке «0» и «1» не так уж и много. Пройдемся по наиболее ходовым протоколам IR-пультов и выберем подходящий для наших целей способ передачи информации. При выборе нас не будет интересовать как организована передача всей посылки, для нас главное определиться как нам передавать битовую информацию.
Для ознакомления с протоколами пультов советую просмотреть ресурс http://www.sbprojects.com/knowledge/ir/index.php — не скажу что это самое полное собрание описаний протоколов (в сети мне попадались ресурсы и побольше), но зато описано все простенько и доходчиво. Рисунки будут взяты именно с этого ресурса.
Изначально хочу отбросить протоколы, в которых информация кодируется изменением длины пачек. Причина – повышенный расход энергии. Пачка должна быть минимально возможной длины, а информация кодировалась длительностью пауз.
Начнем из наиболее популярного в сети протокола —
Philips RC-5
Этот протокол хотя и старый (Филипс давно уже придумал ему замену – RC-6), но довольно часто используется радиолюбителями в своих проектах. Причина тому, наверное, достаточно большое количество описаний, библиотек и готовых устройств с применением этого протокола.
В RC-протоколе используется бифазное кодирование (еще его называют манчестерский код). Идея этого кода заключается в том, что передача нуля и единицы осуществляется разными фазами сигнала.
Достоинство такого способа передачи информации в том, что заранее известно, сколько времени займет посылка.
Недостаток – не скажу что сложный, но с определенными приемами алгоритм декодирования бифазного сигнала.
Подобное кодирование используют еще в Nokia NRC17, Philips RC-6…
Philips RC-MM
Очень интересный протокол! И для наших целей, казалось-бы подходит как нельзя лучше (особенно там, где нужно сэкономить батарейное питание). В отличие от предыдущего протокола здесь кодирование 0 и 1 осуществляется длительностью периода (пачка+пауза). Но изюминка этого алгоритма в том, что одним периодом передается сразу 2 бита данных! Вот так:
Достоинство очевидно – тратиться меньше энергии на формирование пачек импульсов, так как их в 2 раза меньше.
Недостатки, опять таки, алгоритм реализации и менее надежное декодирование сигнала (нужны более точные замеры времени).
И напоследок — NEC.
Подобное кодирование используют еще в JVC, Sharp, RECS80, RCA…
Этот алгоритм сейчас наиболее используем в бытовых пультах. Кодирование бита данных осуществляется, как и в предыдущем протоколе, длительностью периода пачка+пауза. Но в данном протоколе один период отвечает за один импульс.
Достоинства:
— простой алгоритм, как формирования, так и декодирования посылки,
— хорошая устойчивость к ошибкам (замеры периодов не так критичны, так как их длительность различаются вдвое;
Недостатки:
— по сравнению с предыдущим методом вдвое большей расход энергии на передачу сообщения;
— в зависимости от передаваемых данных, длинна посылки будет разной.
НАШ ВЫБОР.
Посылка нашей сети будет использовать кодирование аналогичное NEC-протоколу. При котором период сигнала (пачка+пауза) «единицы» будет в два раза больше периода «нуля». Это позволит использовать самые простые алгоритмы кодирования-декодирования и иметь более надежную защиту от различных помех приема-передачи.
Главное, что-бы протокол обмена был несовместим с существующими. Иначе очень неприятно будет, если термометр за окном начнёт своими отчётами переключать каналы на телевизоре.
@avr410
Пардон, после хидера еще идет счетчик байтов, включаюwий в себя 2 байта CRC.
// The first byte is the byte count
// Check it for sensibility. It cant be less than 4, since it
// includes the bytes count itself and the 2 byte FCS
имется в виду, что сообщение не может быть короче чем 1 байт 🙂
Я так понимаю, что-то вроде этого http://icmicro.narod.ru/info_ru/rfm/rfm.htm
Т.е.:
— преамбула {0x2a, 0x2a, 0x2a, 0x2a, 0x2a, 0x2a, 0x38, 0x2c}
— сообшение где каждый байт кодируется 12 битами
// convert the high and low nybbles of the transmitted data
// into 6 bit symbols for transmission. Each 6-bit symbol has 3 1s and 3 0s
// with at most 2 consecutive identical bits
— crc16
Ну а дальше программа разбирает тело сообщения и что-то делает или нет.
Интересный ресурс. Посмотрел как там сеть организована — очень мало о том как она работает. Но есть уже на что ориентироваться.
Привет! А вот такую реализацию http://www.pjrc.com/teensy/td_libs_VirtualWire.html не анализировали? С пультом не работает, но с другой строны позволяет создать некое подобие широковещательной сети. А адреасацию и т.д. можно хранить в уже теле сообщения.
@GetChiper
Извените, моя ошибка — направильно открывал файлы исходников.
Вот сейчас скачал несколько исходников с разных статей — все те что нужно.
А в каких статьях исходники были не те?
Прошу меня извенить если неправ, но вопрос не только по этому посту:
Я новичек в контроллерах и поэтому хочется подробнее разобраться в каждой конструкции, но почему-то во сех постах, где есть исходники, они все одни и те-же (от поста 065-Четырехканального сенсорного переключателя).
@Vitaly
Вот здесь полезное устройство:
http://www.electro-tech-online.com/avr/38021-avr-infrared-remote-code-capture-project.html
оно рисует «осцилограмму» с временными интервалами, очень помогает в разбирательстве с пультами.
@Vitaly
Увы я код могу по осциллограмме попытаться опознать. Там развёртка калиброванная . У тут хз сколько между фронтами.
@anatoliy
Это не осцилограмма, есть код, в данном случае для ардуино http://www.arduino.cc/playground/Code/InfraredReceivers
Выводит по уарту что-то типа
Bit
0 0
3132 0
3132 1
6072 1
6072 0
9204 0
9204 1
13524 1
13524 0
14256 0
***** *
60612 0
60612 1
Bit stream end!
Далее загнал это дело в программу, которая уже отрисовала график.
@Vitaly
Я какая размерность шкалы времени на осциллограмме?
Это точно не RC-MM. Похоже на NEC-протокол. Вот только пилот свой. Похоже действительно свой протокол.
@anatoliy
Ну в моём случае явно в одну сторону, судя по конструкции пульта.
@Vitaly
У них обычно что-то своё притом в 2 стороны! По крайней мере какие изучал
Считал с пульта от кондиционера такую вот картинку: http://habreffect.ru/4d4/de8ab8043
Помогите пожалуйста опознать протокол (не забудьте учесть инверсию)
Philips RC-MM?
В основном все обсуждалось здесь http://www.getchip.net/v-razrabotke/1wir-set-prostaya-svyaz-ustrojjstv/
@GetChiper
Понятно. Тогда вопрос к целям сети. Хотим ли мы иметь 1-2 мастера которые управляют сетью, или есть желание организовать свободный доступ каждого устройства в любой момент времени?
Вариант 1 тут не сложно, действующих лиц всего 2: человек с IR пультом и какой-то центральный контроллер.
Вариант 2 я мне пока не понятно для чего это нужно.
И еще одно практическое соображение, какой бы протокол вы не выбрали, было-бы хорошо если он бы он поддерживался большинством универсальных пультов. В этом случае частично будет решена проблема «управляющего контроллера» и снят вопрос о его батарейном питании. Что касается скорости передачи информации, то как я понимаю должны в основном передаваться бинарные команды на исполнение и опрашиваться статус устройств. Т.е. 1-2 х байтов на посылку/команду должно быть достаточно?.
@anatoliy
но у нас вроде 50бод скорость 🙂 Смысл моего поста что за время пока мы будем передавать RC-MM. Мы можем 10 раз выпихнуть тоже сообщение. Но энергопотребление на 1 байт в случае случного набора для RC-MM выше. И интегрально потребление выше! При одинаковой скорости передачи выигрывает RC-MM. Если использовать все возможности канала то RAW имеет преимущество!
@GetChiper
«Достоинство очевидно – тратиться меньше энергии на формирование пачек импульсов, так как их в 2 раза меньше.»
Подумал над вашим изречением. Получается что минимальная длинна пачки не меряется. А увеличивается лишь пауза между пачками. И получается что на 1бит тратится 1 пачка*
в не зависимости от значения бита. А время на передачу увеличивается. В случае тупого метода передачи 1 есть пачка 0 нет. мы имеем потребление энергии в зависимости от количества единиц в пачке. Но время передачи сокращается. Значит потребляемая мощность на время то-же падает!
ИМХО энергетических преимуществ протокол RC-MM не даёт!
Могу просчитать этот вопрос если мои утверждения не убедительны 🙂
@GetChiper
Даже я бы сказал запихнуть эти сетевые протоколы в TINY2313
Да в общем-то не проблема с кодом. Проблема все организовать в виде сети устройств.
Привет!
Вот тут http://www.gjlay.de/pub/c-code/rc5.html лежит рабочая, сам проверял, и очень аккуратно написанная библеотека для RC5/AVR.
Рекомендую.
В вашем случае я бы использовал RC-MM и ввел проверку на длинну пачки. Те если пачка длиннее чем нужно. Или пауза короче. То имеет место наложение 2 сигналов.
Ну я же рассказывал что заказ был. телеметрию гнать в условиях электромагнитных помех. Около 1000В/м. Коаксиальный провод в гофрированной металотрубе толь-ко еле обеспечивал передачу без ошибок. Я решил поступить радикально 🙂 без проводов. Потом ещё систему управлением театральным освещением с этим методом кодирования. Там прожектор повернуть цвет поменять. (кстати с этим проектом меня кинули. Не заплатили. Извини мужик кризис.)Тоже этот метод обмена применял.
Протокол кстати вполне распространённый в промышленных беспроводных модемах.
Ого. Вы делали для себя? Или заказ такой был. Слишком уж сложно — такие методы должна оправдать цель. Даже боюсь спрашивать для чего такой протокол понадобился 🙂
Хотя я у ся реализовывал по другому. пакет кодировал по хемингу потом забивал его в массив его при передачи переворачиваем(строки меняем с столбцами). При приёме соответственно переворачиваем ещё раз. Передавал так 1 это пачка из 10 импульсов 0 соответственно отсутствие пачки. Заголовок 5 битный код Бейкера приёмник его распознает и включает сдвиг в входном регистре с частотой байтов. Задвигаем в регистр по столбцу из массива сообщения. Он не торопясь выпихивает в эфир. Приёмник после распознавания последовательности синхронизируется и начинает приём в массив потом его переворачивает производит контроль и исправление ошибок.
Anatoliy, общаясь с Вами, я для себя узнаю столько нового! 🙂 Вот тот-же NRZ. Не спорю, NRZ интересная идея, но не вижу в нем ничего такого (в данном случае) что его ка-то выгодно отличало, например, от той-же прямой посылки бит (1-высокий уровень, 0-низкий уровень). В плане понижения частоты основной гармоники? — нам это не интересно — она и так ниже некуда… Зато в плане приема сигнала будет более сложней следить за уходом частоты. И еще, нужно будет посылать какие-то разрежающие биты, для того чтобы прерывать длинные пачки в случае посылок с длинными последовательностями нулей или единиц (хотя на это можно и забить).
Насчет RC-MM — мне он тоже нравиться и я долго колебался, выбирая между простой NEC-овской передачей и RC-MM. Победила простота — в ущерб пропускной способности.
ИМХО если вы решили не придумывать помехоустойчивый метод то RC-MM для вас идеальный вариант. я бы заюзал что-то вроде NRZ 🙂