Раз уж мы решили реализовать IR сеть, давайте посмотрим на что мы, в конечном счете, сможем рассчитывать. Какие физические возможности такой сети? Рассмотрим ограничения накладываемые элементами сети на скорость передачи информации.
Определимся — а стоит ли вообще сооружать что-то такое?
НАША IR-СЕТЬ БУДЕТ ОРГАНИЗОВАНА ПОСРЕДСТВОМ:
1 Передатчик – IR-светодиод (IR-Led)
[Загрузка не найдена]
Этот даташит взят для примера, на самом деле IR светодиод может быть любой.
2 Приемник – интегральный IR-приемник TSOP
[Загрузка не найдена]
Тоже касается и TSOP – особо не важно, какого он типа или чьего производства.
Передача в одну сторону организована следующим образом:
Если нам нужна двусторонняя передача, устройство должно содержать как IR-Led, так и TSOP.
РАССМОТРИМ ЭЛЕМЕНТЫ СЕТИ И ВНОСИМЫЕ ИМИ ОГРАНИЧЕНИЯ.
1 Микроконтроллер.
Особых ограничений нет (конечно, в пределах возможностей микроконтроллера).
2 IR-светодиод.
Тут все понятно: можно через него передавать информацию с любой скоростью (с любой возможной для микроконтроллера), чем больше ток через светодиод, тем интенсивней световой поток и тем дальше передача.
3 Интегральный IR-приемник TSOP.
Это «бутылочное горлышко» всей системы — все ограничения в сеть будет вносить именно он.
КАК РАБОТАЕТ TSOP?
TSOP довольно сложное устройство, которое способно эффективно «бороться» с неизбежными посторонними засветками фотодатчика (постоянная составляющая), помехами в виде одиночных импульсов и постоянными помехами в виде света от люминесцентных ламп и ламп накаливания (переменная составляющая). Платой за эффективную защиту от посторонних сигналов является небольшая скорость передачи информации. Для того чтобы эффективно отсеивать посторонние сигналы TSOP настроен на определенную несущую частоту (ряд фиксированных частот лежит в пределах от 30 до 56кГц). Так вот, работа TSOP заключается в том, чтобы воспринимать только определенную несущую частоту, обрезая все остальное, включая и постоянную составляющую.
НА ЧТО МЫ МОЖЕМ РАСЧИТЫВАТЬ, делая канал связи с применением TSOP-приемников?
Для того, чтобы ответить на этот вопрос нам нужно определиться с тем, какую несущую частоту (соответственно и какой TSOP-приемник) мы будем использовать. Само собой напрашивается решение взять приемник с самой большой частотой (56кГц), но это неверное решение – они очень редки и достать их будет трудно.
Самыми ходовыми являются приемники с частотой 36 и 38 кГц – вот их мы и выберем. Кроме того выбрав TSOPы с частотой 36 и 38 кГц, мы сможем «видеть» сигналы подавляющего большинства бытовых IR-пультов, что тоже немаловажно, так как мы сразу получаем устройства управления в нашей сети.
По моему личному опыту TSOPы на 36кГц довольно хорошо воспринимают посылки с пультов на 38кГц и наоборот. Поэтому, чтобы не ограничиваться каким то одним TSOPом будем использовать для передачи несущую частоту в 37кГц. В этом случае приемником может быть как TSOP на 36кГц, так и на 38кГц.
С несущей частотой определились. Дальше смотрим в даташит на TSOP и определяемся с полезным сигналом (TSOPы различных производителей имеют небольшие различия в характеристиках, но они не критичны).
[Загрузка не найдена]
Из даташита мы получаем следующую информацию:
Полезный сигнал (цифровой конечно) нужно промодулировать несущей частотой (в нашем случае 37кГц)
Последовательность модулирующих импульсов называется «пачкой».
TSOP при приеме таких пачек демодулирует их и выделяет полезный сигнал. Сигнал выдается TSOPом инверсно и это нужно учитывать.
Для того чтобы TSOP «понял», что идут полезные импульсы, а не помехи пачка должна быть определенной длинны, а именно не менее 10 импульсов.
Постоянные сигналы (в том числе и на несущей частоте) считаются посторонними и нещадно подавляются, поэтому пачки не могут быть длинными и должны прерываться на определенные промежутки времени — «паузы». После каждой пачки длинной 10-70 импульсов минимальное время паузы должно быть не менее 12 периодов импульсов. Для пачек больше чем 70 импульсов минимальное время паузы должно быть в 4 раза большим.
Так как нам нужна максимальная скорость, то договоримся, что длинна пачки при передаче сигналов будет 10 импульсов, а длинна паузы не меньше 10 периодов импульсов.
И в заключение, в даташите оговаривается ограничение на общее количество коротких пачек в секунду – их должно быть не больше 800 пачек в секунду. Сразу оговорюсь — это наихудший показатель из различных приемников (например, тот-же TSOP17.. может потянуть 2400 bps), но пока решил ориентироваться именно на этот приемник — позже проведу кой-какие эксперименты — определюсь окончательно.
Вот мы и определились с номинальной скоростью передачи – она составляет не более 800 бит в секунду. Если учесть, что в сети с полезными данными должна передаваться служебная информация, то мы получим около 400 бит или 50 байт полезной информации в секунду.
Есть способы увеличить пропускную способность такого канала в разы посредством:
– применения более быстрого TSOP;
– уменьшения временных промежутков, оговоренных в даташитах (при передачах сигналов с бытовых пультов правила даташита на TSOP зачастую соблюдаются не полностью – но ничего, все работает);
– применения специального способа передачи информации.
Вот только есть ли необходимость усложнять алгоритм работы и залазить в предельные возможности TSOP? Об этом подумаем позже.
На данный момент принимаем скорость передачи — 50 байт полезной информации в секунду.
Прямо скажем – скорость передачи не фонтан! Но если учесть что:
— сеть, в основном, предназначена для беспроводного УПРАВЛЕНИЯ «умным рабочим местом»;
— такую сеть будет легко и дешево реализовать;
— для таких скоростей потребуется небольшое количество ресурсов микроконтроллера (не будет мешать основной программе);
— в процессе создания сети можем скорость увеличить — есть резервы.
этого должно нам хватить.
Продолжаем дальше?
Да — это вариант.
Увеличить скорость можно, перейдя к другой системе счисления.
Если принять протокол: пачка = 20 пульсаций + кратная пауза.
При 2-й системе имеем «0» — 20 + 20, «1» — 20 + 40. 8 пачек на байт. Ограничение в 800 пачек/с позволяет передать 800/8 = 100 Б/с. Средняя длина пачки (с паузой) 50. 400 пульсаций на байт в среднем. 38кГц/400 = 95 Б/с. Служебная информация 50% (как в статье). Итого 47,5 Б/с
При 4-й с/с, пачки 20+20, 20+40, 20+60, 20+80. 4 пачки на байт. Ограничение в 800 пачек/с позволяет передать 800/4 = 200 Б/с Средняя длина пачки 70. 280 пульсаций на байт в среднем. 38кГц/280 = 135 Б/с.
50% — 67,5 Б/с.
@GetChiper
Ну если в лоб передовать 1-0 кодом Бэйкера в прямом или инверсном виде:-)
AVR хватит 🙂 Даже на FFT в realtime! куда-то надо девать такую толпу регистров.:-D Просто нужно подходить к решению вопроса с неожиданной стороны.
Самый простой метод это контроль четности. ИМХО Для вашего ТЗ больше заморачиватся не имеет смысла. Ну разве что код Хемминга. просто и со вкусом
Открою маленький секрет по проектированию! Как говаривал мой учитель: «Настоящий инженер не решает тех.проблемы, он их обходит:-D». Этим принципом пользовались инженеры старой советской школы. А не то что щас, производительности не хватает поставим ARM 🙁
anatoliy, Вы заставляете меня смотреть на простые вещи совсем с другой стороны — спасибо 🙂
Про LDPC до этого не знал. Почитал вики, и про LDPC, и про турбо-коды, и вообще про передачу цифровой информации по каналам связи с шумами — тема, конечно, интересная, но смотря на математические выкладки я думаю AVR для таких делов вапще не хватит. Может есть какие более приземленные методы (если учесть что сообщение будет порядка 4 байт)?
Это как?
CRC8? Имхо также избыточно как LDPC 🙂 поксорить между собой сообщение и дописать контрольный байт.
Если уж вносить избыточность то с запасом 😀
Как насчёт расширение спектра методом прямой последовательности?
Восстановление поврежденных данных по моему излишне — оно того не стоит.
Посылка будет завершаться CRC8. В случае если принимающая сторона обнаружит ошибку она будет иметь возможность попросить повторить эту посылку — по моему это более простой вариант.
В случае слепых устройств, действительно, придется сообщения посылать дважды.
@vuln
А почему только 2? 🙂 Имхо решение в лоб и не самое правильное. Есть чудесная книжка «В.В. Золоторев Г.В. Овечкин Помехоустойчивое кодирование методы и алгоритмы» Прочитайте много нового для себя обнаружите. 🙂 Ещё есть книжка на эту тему кто автор не помню называется : «коды исправляющие ошибки»
так-же в тему «Прокис Дж. Цифровая связь»
мне кажется для лучей помехо защищенности каждую пачку передавать по два раза, а на приемнике сравнивая можно отфильтровать ложные данные
Т.е. запрашиваем ты кто. а оно уже отвечает какой оно класс и подкласс и где оно находится. И что оно показывает. А никак не по адресации выбирать какую функцию задействовать!
@GetChiper
Забыли про возможность составных устройств?
ИМХО функциональность выносить в адресацию ошибка! Курите в сторону МОДБУС. Тама запросом состояния регистра сделано. Должно быть пофигу где оно расположено! Это как в инете! Ну право ваше пробуйте 😀 ИМХО по пол часа вызывать вольтметр в тумбочке это лажа! И 256 устройств в сети заглаза!
Вот такая тупая адресация и предполагается. Только не будет различий между устройствами IR и проводными — передача по линии будет вестись теми-же посылками, что и по IR.
Два байта идентификатора (ориентировочно) будут расходоваться на:
Первый — тип посылки (обычная, короткая (для устройств с батарейным питанием) и передача пакета данных) + класс устройства
Второй — подкласс устройства
Например, классом может быть «измерительный прибор», а подклассом «измерение тока», «измерение напряжения», «измерение скорости» …
Или классом может быть «градусник», а подклассом его место расположения «рабочая точка», «рабочее место», рабочая комната», «здание», «улица» …
Об этом я пока не сильно думал — позже нужно будет определиться более обоснованно.
Мы блин не инет делаем 😀 А nanolan 😉
А время на то что-бы этот байт передать?
ну вот первый байт как раз под тип устройства и пойдет. Чего их жалеть? 🙂
А еще нужны будут служебные пакеты. Типа занят я, повтори пакет #. Всем слушать. Канал занят. канал свободен. Такой-то дайте канал! Такой-то сеанс закончил. такой-то ты там живой? Ну и ещё несколько
@GetChiper
ИМХО просто зделать тупую адресацию например 0-127 ИК устройства 127-256проводные. назначить им классы устройства например 0-9 термометры.10-20 диммеры. 20-30 выключатели. 40-50 вентеляторы. Итд.
2 байта ИМХО много! ВЫ представляете в своей квартире 4294967295 устройств? Ну и конечно броадкаст запросы пинги и вхоисы 🙂
@GetChiper
не увидел решение проблемы скрытого узла
Решение принципе правильное. Я бы реализовал так.
например у нас есть :
Обычные устройства А,Б,С. И слепое устройство Д.
А желает передать С что-то. Говарит А для С канал дайте! А устройство Б не видит устройство А но видит С. С отвечает Канал занят. Это видит устройство Б и Передает сигнал канал занят (для исключения что кто-то не понял) и блокирует передачу, до получения им пакета канал свободен. А выжидает паузу пока сигнал распространится по сети. Примерно длительность 2 пакетов. С этого момента произошла инициализация канала между А и С. А шлет данные С просто пакетами вида данные|номер пакета|контроль. Если в момент обмена A-C cлучается передача Д к B. Д при этом просто передает FF на длительность 1 пакета. То А или С кто там будет в тот момент на приёме отсылает пакет «СТОП ВСЕМ слушать!» Д после передачи ждет длительность 2 пакета. И передает что он хотел сказать. После передачи Д B отсылает пакет типа все получил можно продолжать! И сеанс связи A-C продолжается. пока кто-то из них не освободит канал.
Еще для передачи данных от слепого устройства можно пременить посылки увеличенной длительности не 10 импульсова 100.
Имхо этот алгоритм решит все проблемы с организацией связи в сети!
И еще, нужно понимать, что канал узок до немогу, поэтому от функций самоидентификации устройств в сети и их взаимоконфигурирования придется отказаться (ну или свести их к минимуму). Я так предполагаю каждое устройство будет иметь свой индивидуальный двухбайтовый код. Этот код будет не просто цифрами, а именно конкретным устройством (градусник, вольтметр, настольный светильник, свет в комнате… нужно будет это еще продумать) Каждым устройством в сеть будут отправляться посылки с идентификатором отправляющего устройства. Все устройства принявшие посылку должны будут сами решать, нужна ли им посылка от этого устройства и, если нужна, то что с ней делать. Наверное нужно еще оставить запросы к устройствам на выдачу посылок принудительно?
Да с арбитражем будет туго, но для наших задач можно будет подзабить на некоторые испорченные посылки.
По поводу арбитража я вижу решение проблемы примерно так:
1 перед передачей посылки любое устройство сети должно выждать определенную паузу наблюдая за сетью;
2 если другое устройство успело начать передачу первым — устройство дожидается окончание посылки и опять выжидает паузу;
3 устройства одновременно с передачей ведут прием своей посылки (все работает в прерываниях, поэтому это будет получаться автоматически) и в случае если переданная посылка не соответствует принятой (устройства умудрились начать передачу одновременно или влезло слепое устройство) посылка будет повторена (после положенной паузы);
4 любой IR сигнал во время контрольной паузы воспринимается как просьба повтора последней посылки;
5 слепому устройству нужно будет передать свою посылку дважды — первая посылка (может быть даже не информационной) заставит другие устройства выжидать паузу, а вторая посылка должна пойти чуть раньше положенной паузы — опередив ожидающие устройства.
Все было-бы просто если бы не «глухие» устройства:-) Но и эта проблема решаема, приоритетным запросом на обслуживание глухого устройства при серьёзной ошибке приёма, или получении пакета «всем молчать!» 😀
@dansar
ИМХО принципиальной разницы нет!
Организовать арбитраж. задача на 1000000$ 😉 Как решить проблему скрытого узла?
Лично я жду пока своё мнение выскажет GetChiper. Это его проект. Я могу толь-ко посоветовать и подсказать 🙂
По поводу совместимости с бытовыми устройствами:
Можно выбрать такую стартовую последовательность пакета, скажем, байта 3, которая не встречается в большинстве протоколов. Если это будет сеть с количеством мастеров более одного, то нужно придумать какой-нибудь арбитраж, что бы одновременные посылки не накладывались друг на друга. Например если устройство поймало стартовый пакет, который адресован не ему, то оно ждет завершения передачи. Или же, если скорость передачи постоянна, то ждет некоторое время, за которое пакет по любому будет передан.
Но все равно все это более подходит для радиосвязи, чем для ИК.
В догонку 🙂
Искажения сигнала из-за рассеяния на аэрозоле! У честно говоря насмешили меня. Мы же не 1GB/c передаем? Ну завалим мы фронт на 1н/с от это-го на 36кГц ничего не изменится.
А сколько энергии дойдет из А в B определяется. Мощностью передатчика,КНД передатчика КНД приёмника, потерями в среде (в свою очередь от частоты и состояния атмосферы).
@aui2002
Ну давайте по порядку 🙂
Мощность ИК диода я к своему стыду не померил. Это был отечественный ИК диод в стеклянном корпусе. Стоял в каком-то пульте управления. Ток был 100мА.
Длинна волны вроде как функция обратная частоте сигнала.
Поглощение воздухом не линейно для разных частот особенно в ИК диапазоне. Т.к. происходит поглощение излучения на резонансных частотах молекул. (почитайте про спектроскопию).
Про не очень существенную разницу в длине волны! Просто отошлю к датасшиту на TSOP к графику Relative Spectral Sensitivity vs. Wavelength. Притом в воздухе есть вобще глухие частоты. Где сигнал очень сильно затухает.
Дифракция и рассеяние на атмосферном аэрозоле будет в любом случае. Так-же будет т.н. романовское рассеяние. И много чего еще 🙂
По поводу влияния размера частиц на рассеяние излучения. Отправлю вас к замечательным книжкам по оптике атмосферного аэрозоля. Если кратко зависимость есть но не столь выраженная.
Ну в «точке» если мне не изменяет память стояла лампочка под светофильтром.
Единственные «глюки» это если луч не расширять дополнительной оптикой. я точил линзу из полистирола. Говорят что из текстолита то-же на ура идет. Там букашки заползают на ик приёмник или передатчик. И все каюк связи.
ТSOP по сути это многопороговый детектор без обратной связи. те если он примет 6 из 10 импульсов он уверенно распознает посылку. Обладает очень большой чувствительностью. Уверенно распознает сигнал при плотности потока 0,4-0,3 мВт/м2. А если ещё применить помехоустойчивое кодирование в канале передачи? И ещё применить согласованный цифровой фильтр по приёму?
Имхо ТSOP для задачи «пару байтов переслать» очень правильное решение!
Да, в красивых фразах Вам не откажешь )))
Смущает только, что ни слова не сказано о мощности передатчика (ИК-диода) и его частоте. Длина волны тут не очень существенна, поскольку поглощение воздухом ЭМ волн можно считать линейным. А вот какое количество энергии дойдет от точки А до точки В определяется как раз мощностью и частотой источника.
Длина волны ощутимо скажется только в случае тумана, размер частичек (капель) которого соизмерим с длиной волны. Вот тогда за счет дифракции пойдут искажения сигнала.
Действительно, существуют оптические линки и т.н. ИК-барьеры с дальностью действия днем 150-250м, а ночью и до 300-400 (при влажности воздуха 30-40%), но они работают в мегагерцовом диапазоне и мощность излучателя в них составляет 0,5-1,5 Вт.
И уж в «Точке», наверняка стоял не диод на несколько милливат )))
Таким образом, возможность безглючного использования обсуждаемого здесь «железа» в уличных условиях видится мне весьма и весьма сомнительной.
Не не далековато!
Странно а я всегда был уверен что 250метров через дождь это не предел:-) Почему я так думаю? Изучаем оптику атмосферы и рассчитываем сколько мы потеряем на 950нм на трассе в 250м при худших условиях. потом смотрим какой минимально распознаваемый уровень TSOP при точно установленной несущей!! Образовавшимся запасом будите приятно удевленны.
Ик подходит только для дома! Это увы стереотип. Оптические линки. С начала использовались в промышленности и оборонке. А потом уже перекочевали в бытовую технику. Пример Диагностический ИК порт на ракете Точка-У!
@anatoliy
А от сарая или скважины через двор до дома не далековато для ИК?
С туманом, опять же как быть?
Все-таки ИК больше больше подходит для использования внутри помещений, а не для связи с внешним миром.
В моем случае это почти невероятно ))
@aui2002
Ну уж не совсем и не известно? Известна частота. Известны коды с которыми может пересечься. Известно что будет приамбула адреса источника и приёмника. дальше данные в принципе случайные. И контрольные биты с номером пакета.
У мя рабочие место 3 стола буквой П. на одном паяльные пренадлежности. Паяльная станция микроскоп пинцеты. На другом измерительное оборудование. Осциллограф, частотомер, вольтметр, сигнал генератор. на 3 комп ноут итд.
Мне умное рабочие место как корове 5 нога. Все есть и работает. А вот сеть датчиков, там метеостанция, скважина. периметр. освещение в доме. Влажность и температура у курей в сарае. Очень бы пригодились.
А вот попадет на ваш рабочий стол бытовой DVD плеер? Или там муз центер?
Спецподготовки, честно говоря, не имею, но если это так элементарно посчитать, и у Вас есть желание оперировать конкретными цифрами, приведите расчеты в доказательство своей позиции.
Только как Вы это сделаете, если протокол работы устройств еще не реализован, а значит плотность и структура потока импульсов неизвестны?
Или можно подождать, когда будет готово какое-нибудь из устройств и проверить на практике ))).
Если рассматривать разрабатываемую ИК сеть как «оснастку» для умного рабочего (паяльного) места, то лично для меня влияние на бытовую технику вообще не критично, т.к рядом с рабочим местом нет ни одного ИК-приемника.
@aui2002
У Вас с МАТАнализом как? В принципе можно элементарно просчитать вероятность этого счастливого события.
ИМХО пилот сигнал не спасет ситуацию. Там код от пульта декодируется по совпадению. Если 2 пачки от пульта склеить между собой то команды выполнятся в последовательности передачи. Проверено.
Т.е. приёмник приамбулу пропустит а вон на содержание кадра может сработать.
@aui2002
Нет там сначала сигнал запоминается и вешается на кнопку. Или выбирается семейство протоколов в настройке.
Думаю если подбирается код то из 2-3 разных семейств. Щас практически только у Sony свой протокол. А так большинство RC6 кажеться
Значит опыт, действительно, штука индивидуальная )))
Все мои 3 пульта (телек, проигрыватель и комп) ведут себя вполне примерно и в провокациях замечены не были ))
Если _целенаправлено_ и _непрерывно_ DDoS-ить приемники через меандр, как советует anatoliy, то ложное срабатывание техники весьма вероятно.
А вот при работе даже нескольких ИК-передатчиков по протоколу, резко отличающемуся от протокола пультов, вряд ли получится настолько «плотный» поток сигналов, чтобы ложные срабатывания бытовой техники происходили каждые 10 сек.
1-2 случайных совпадения в месяц, GetChiper прав, вполне можно пережить.
Кстати говоря, кто-нибудь знает, как работают универсальные пульты для телеков? Там что при нажатии на кнопку генерируется несколько разных сигналов (кодов) один за другим, по принципу «какой-нибудь да подойдет»?
Форум обязательно нужен. Ведь нужно народу гдето пообщаться чтоб темы флудом не засирать. А насчет темы то у меня если пульт от телека LG недай бог попадет в зону действиЯ приемника муз центра LG то последний такие вещи начинает выдавать пото хрен разберешься что там было настроено.
@aui2002
Посмотрю, что можно сделать с редакцией постов.
У меня другая история на эту тему. В комнате люстра с четырьмя экономками и в момент ее включения примерно раз в пару месяцев включается телевизор. Вот такая теория вероятности.
А по поводу срабатывания бытовой техники можно не бояться — самое главное сделать пилотную последовательность IR-посылки непохожей ни на один IR-протокол и все передачи будут игнорироваться (пару раз в месяц случайных совпадений можно пережить).
Ну раз пойдет такая тема, то придется, наверно, и форум прикручивать.
@GetChiper
По поводу ТЗ. Неплохо было-бы озвучить верхний предел стоимости линка.
Еще вопрос: Может контроллер интерфейса реализовать на отдельном МК? Tiny2313 вполне справиться с серьёзным помехоустойчивым кодом.
Допустимо ли применять в проекте мс стандартной логики?
Про программируемую логику не спрашиваю. Далеко не бюджетный вариант. Хотя на какой-нить пал можно своять полностью аппаратный многопороговый кодер декодер.
Где форум?
В который раз убеждаюсь что опыт вещь не только субъективная но и индивидуальная.
Вести себя оно будет по разному!
Если совпадет частота канала, скорость передачи, протокол будет веселье!
У мя например давно телевизор выключался когда на видеомагнитофоне перемотку включал.
А тут сетевой обмен!
Если есть желание можете произвести опыт.
Соберите цифровой генератор псевдослучайных последовательностей затактуйте его 1/10 от 36 кгц. А выходным сигналом промодулируйте 36 кгц меандр и на светодиод. И посмотрите как ваша бытовая техника будет посторонние коды просто отсеивать. А потом сообщите 🙂
У мя получалось полностью сорвать презентацию где проектором рулили с пульта 😀
Если данные гнать в лоб через ик канал. То сигнал рано или поздно совпадет с какой-либо командой ПДУ.
@GetChiper
Евгений, раз уж всплыл вопрос по поводу русского языка, есть маленькая просьба. Нельзя ли добавить в блог возможность править свои собственные комментарии? А то ночью запостишь с ошибкой, потом заметишь, устыдишься )), а поправить уже нельзя…
@anatoliy
По поводу OSI — поддерживаю!
А как ведет себя телевизор, когда пультом от DVD увеличиваешь громкость воспроизведения в самом DVD-плеере? Громкость динамиков телевизора ведь не увеличивается. А расстояние между ИК-приемниками при этом сантиметров 20 от силы. Посторонние «коды» просто отсеиваются.
50% решения это грамотно поставленная задача!
Посему
@GetChiper
Пожалуйста сформулируйте ТЗ на разработку сети передачи данных.
ИМХО надо разбить задачу на элементарные этапы. Как там в сетевой модели OSI?
потом последовательно разобрать каждый уровень. В потом все это осмыслить и написать стандарт 1WIR.
А уже после это-го думать как все это реализовать.
GetChiper наверно желает сеть по концепции «Умная пыль?»
Да сразу не просто грабли а противотанковая мина: «Как буду вести себя устройства в поле действия сети имеющие ИК канал?». Там телевизор DVD кондиционер?
Каюсь, русский язык это единственный предмет в школе на котором я боролся за четверку и был счастлив когда ее получил 🙂 Прошу меня извинить за прошлые и будущие орфографические ошибки.
По поводу адресации и контрольной суммы — поддерживаю — боюсь без них не обойтись.
Радиомодули, конечно хорошо, но дорого…
@aui2002
Комп конечно будет — куда его деть 🙂
С железом, в общем и целом, понятно. А вот что с протоколом передачи?
Как будет организована программная (микропрограммная) часть
Такой вкусной штучкой, кстати говоря, хотелось бы и с компа управлять.
Не в плане создания централизованной системы, управляемой с ПК; девайсы и пульты пусть «общаются» между собой напрямую.
Просто было бы удобно параллельно контролировать работу всего комплекса с ПК. например, через тот же UART.
Я вообще думаю про похожую сеть, но на основе FSK радиомодулей. Будет подороже, но зато не нужна прямая видимость.
Вот я специально для этого зарегистрировался. Сайт хороший, идеи вообще отличные, особенно про 1WIR-сеть. Но вот грамотность хромает на обе ноги. Почти в каждой статье вижу это жуткое слово «длинна». Пожалуйста, уважайте великий и могучий.
Предлагаю ввести адресацию и контрольную сумму в пакете.
Это из личного опыта. Собранная схема реагирует на любой пульт куда бы он небыл направлен — разницы чувствительности я не замечал. В любом случае в результате обкатки бока повылазят — будем думать.
GetChiper:Тоже касается и TSOP – особо не важно, какого он типа или чьего производства.
Странно а в Даташит есть картинка Frequency Dependence of Responsivity. Из нее следует что при изменении частоты на 10%, для нашего примера на 360герц чувствительность составит 40% от максимальной. Я конечно согласен что если светить прямо в TSOP то мощи хватит. А вот если отражённый сигнал? Не уверен!