www.open-tager.ru

ИМХО должна быть проверка импульсов на соответствие по мин. и макс. длине, как то так:
Стартовый импульс 2300 - 2500 мкс
Пауза между битами 550 - 650 мкс
И в декодировании проверять:
Бит "0" - 550-650 мкс,
бит "1" - 1150 - 1250 мкс.

Всего-то надо добавить в проверки еще несколько условий, компактности не повредит.
Сделать для заголовка проверку так:
И для паузы:

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

а зачем проверять это при приеме пакета?
чтобы отработать ошибку и тут же принять новую? Проводить проверку при приеме можно только для пауз. Все остальное не имеет особого смысла. Ибо известна заранее точно только длина пауз и их положение в посылке. Даже проверка длинны стартового импульса помоему не имеет смысла. Пусть он будет к примеру длиннее, ну и что? Может это наоборот даст лучшую чувствительность к приему. Слишком жесткие условия тоже же не айс

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

есть правда одно но, которое пришлось допустить наобум - максимальная длинна паузы. Я сделал ее 1800 (900 мкс) и думаю это многовато, но для эксперимента оставил. И нижний предел длинны паузы не проверил. Вот тут конеш ошибка явная. Факт. Если паузы будут всегда короткими, то примется все что угодно

Проверять придется затем, что-бы не засчитать засветку от солнца как начало пакета, чтоб люминесцентные лампе не "нагенерировали" выстрелов.
И паузы проверять не только на макс длинну, но и на минимальную. Иначе любой самый кратковременный перерыв импульса во время приема засчитается как коректная пауза.

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

так наверное правильнее будет
но опять же, только для пауз. Остальное целесообразнее делать в обработчике пакета уже в основной проге, чтобы не загружать этой работой прерывание. Их итак хватает

Про допуски в длительностях импульсов - из практиик приемники ТСОП имеют свойство уменьшать принимаемые сигналы на 10-20мкс (наверное АРУ так отраьбатывает). Так что в допусках коректный диапазон для импульсов желательно расширять "вниз", а для пауз - "вверх".

ЗЫ - такое условие никогда не сработает , логическое ИЛИ надо вместо И

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

про старт подумаю. Может и правда стоит сделать. Потому как неизвестно заранее в какой момент посылки шумового пакета будет принят именно он. Он просто может оказаться в середине где нибудь.
да, надо проверять. Спасибо за настойчивый пинок )))
при или второпях затупил. конечно ИЛИ

поправил код

Правильное использование "железа" контроллеров позволяет писать весьма компактный и быстрый код. За что люблю ПИКи - что у них можно подобрать для себя почти любую нужную конфигурацию по ресурсам, хоть 7 ССР модулей .
Берем PIC16F737 - имеем 3 ССР модуля, на один вешаем прием от ТСОР, на другой - ШИМ выстрела ИК, на третий - ШИМ звука. Чем не бюджетное решение?

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

эту строчку наверное можно даже убрать и читать значения прямо из буфера чтобы избавиться от переменной. Хотя есть вероятность что импульс будет очень короткий и успеет за несколько тактов процессора обновить буфер приема. Но тогда по идее не успеет переключиться детектор фронта/среза и 2 импульса примутся как один с общей длинной.... хм. Над подумать
вроде ничего особенно плохого случиться не должно