Описание устройства:
Есть 50 столиков и одна барная стойка. Клиент, сидящий за столиком №3, нажимает на кнопку передатчика. У бармена, любым удобным для меня способом, появляется сигнал о том, что официанта вызывает столик №3.
У меня есть готовая конструкция такого устройства. В конструкции один большой недостаток. Если на столике №2 и №3 одновременно нажали на кнопку, то к бармену поступит только один сигнал, второй потеряется или вообще не поступит ни один сигнал, так как передатчики работают на одной частоте и могут перекрыть друг друга.
Я решил поступить иначе. Буду использовать кнопки с обратной связью. Допустим, столик №3 нажал кнопку, и столик №2 нажал кнопку. Устройство у бармена постоянно по очереди опрашивает все кнопки. Если кнопка №2 была нажата, то при опросе этой кнопки она незамедлительно передаст код. Тем временем кнопка №3 то же была нажата, но пока на неё не поступит её же код, идентификация, она не передаст в эфир свой код обратно на приёмник.
Из всего проекта я не могу решить только одну проблему, о которой я и пишу ниже. Надеюсь на Вашу помощь.
Проект пишу на языке С, он мне достаточно хорошо знаком.

Опишу свою задачу:
1) Цель проекта.
2) Аппаратура.
3) Проделанная работа.
4) Полученный результат.
5) Вопрос.

Цель проекта:
Необходимо по радиоканалу (433.92 МГц) передать сигнал в COM порт компьютера с предварительным редактированием данных.

Аппаратура:
Передатчик – набор брелков от гаражных ворот, автосигнализаций, и ещё от чего то, с частотой 433.92 Мгц.
Приёмник – микросхема RX5000 с преобразователем уровня с 3 вольт до 5 вольт и подключённая к Atmega 8 к UART.
Принципиальная схема:
Нажмите для просмотра прикрепленного файла

Проделанная работа:
1) Создал проект в CVAVR с именем UART. Сгенерировал первоначальные настройки

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Программа сгенерировала код в который я вставил в бесконечный цикл только вот эту строку:



2) Скомпилировал код программы, стёр микроконтроллер, прошил скомпилированный файл. Прошил фузы и Лок биты:


Lock bits:
LB1=1
LB2=1
BLB01=1
BLB02=1
BLB11=1
BLB12=1


Fuse bit:
CKSEL0=1
CKSEL1=0
CKSEL2=1
CKSEL3=1
SUT0=1
SUT1=1
BODEN=1
BODLEVEL=1
BOOTRST=1
BOOTSZ0=1
BOOTSZ1=1
EESAVE=1
CKOPT=1
WDTON=1
RSTDISBL=1




Включил терминал на ПК, настроил COM порт согласно настройкам МК – 9600, 8N1. В терминал сразу же стал передаваться «мусор» шум эфира. Как только я нажимал кнопки различных передатчиков, в терминал поступали упорядоченные символы. При доскональном рассмотрении ситуации я нашел конец и начало передаваемой передачи кода.
Вернусь немного назад. У меня есть рабочая прошивка устройства, на которой я проверял работу всех имеющихся у меня пультов. Правда схема МК немного отличалась от моей схемы. Отличие состояло в том, что выход приёмника подключен не на вход UART, а к выводам PD2(INT0) и PD3(INT1) через сопротивления. Ниже привожу часть схемы.

Нажмите для просмотра прикрепленного файла

С этой рабочей прошивкой и этой схемой я принимал на терминал вот такие сигналы в ASCII
0001A46F>
0001A46F>
0002867E<
02C467CE>
02C467FE>
0001A46F>
0001A46F>
И вот такой сигнал я принял в HEX стандарте.
30 0 30 31 41 34 36 46 3E 0D 0A


Полученный результат.
Вернёмся к моему варианту. Как я уже говорил, при включении МК у меня в терминал выводился «мусор» И после нажатия на кнопки различных передатчиков я принимал упорядоченный набор символов. Но этот упорядоченный набор меня ввёл в тупик. Вот он в HEX стандарте при передаче вот этого кода 0001A46F>

F8 F8 F8 C0 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 C0 C0 C0 C0 C0
F8 F8 F8 C0 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 C0 C0 80 C0 C0
F8 F8 F8 C0 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 C0 C0 C0 C0 C0
F8 F8 F8 80 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 C0 80 C0 C0 C0

Я не могу дать объяснение этому сигналу и соответственно сделать какие то выводы.

Вопросы:
1) Что я в своём проекте мог сделать не так?
2) Как мне организовать проект, что бы я выход приёмника смог подключить к любому входу МК, кроме входа UART, а с выхода UART мог передать полученный сигнал от приёмника в терминал?
3) Смогу ли я при решении вопроса №2 предварительно записать принятый с приёмника сигнал в переменную и сделать с ним необходимые мне вычисления?
4) Как мне определить начало и конец посылки сигнала? Я представляю себе определение начала и конца сигнала по стартовому и стоповому биту. Так как они равны 0 то я могу из всего переданного сигнала программой написанной для ПК выделить только один, нужный мне сигнал.
5) Какие есть способы получения нужного мне сигнала из всей повторяющейся посылки?
Прошу всех желающий откликнутся и привести в пример рабочий кусок кода с описанием. Это мой первый проект с AVR, не считая включения светодиодов и кнопок.

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


ps. Реально ли сменить аппаратную базу ? Себестоимость точки вызова легко можно уложить в 6-8$, если все же надо радиоканал.

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

Так происходит по тому что приемник rx5000 прередает данные в МК со скоростью 115200 бит/с

Инвертор на UART-TX (TXD) нe забыли поставить?

Вроде при сборке этого приёмника в datasheet ничего небыло сказано скорости RX5000. Я сейчас перечитаю datasheet. Если вы знаете как можно изменить скорость в RX5000, подскажите пожалуста. Минут через 20 вырожу полную схему и фото собранного проекта.

А что мешает изменить скорость UART'а в меге? Поставьте 115200-8-N-1.
Поменяйте также кварц 8Mhz на что-нибудь более адекватное - 14.7456Mhz например или 11.0592Mhz (частоты заточенные для UART'ов).

У меня Atmega8L она работает до 8 МГц. Поэтому в своём проекте я не могу использовать частоту кварца больше 8МГц. И ещё, как я уже писал с этой же схемой, с этим же приёмником но при другой прошивке я уверенно принимаю правильный код. Я перечитал datasheet про RX5000 и там сказано, что она работает до скорости 115200, а значит и 9600 то же будет пропускать. Предоставляю всем фото моего проекта и схему без схемы приёмника, он есть в datasheet.
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Протокол множественного доступа в канал с контролем занятости. На каждой точке должен быть приемник, контролирующий занятость канала и выходящий на передачу только в случае его освобождения.
Нажатие кнопки не сразу передает вызов, а ставит этот вызов в ожидание свободного канала.
Для исключения одновременного выхода на передачу двух или более ожидающих запросов, предусматривается рэндомная задержка.
Если времена задержек расписать вручную, можно распределять приоритеты "кнопок".
Все это есть в литературе.

Правильно. Я так и планирую. Идея в следующем: В каждой кнопке есть свой уникальный код и приёмо-передатчик. Как только была нажата кнопка на столле №2 в этой кнопке активируется приёмник и если этот приёмник принял по эфиру свой уникальный код то сразу же активируется передатчик и передаёт свой уникальный код в приёмник на барной стойке.
Работа устройства на барной стойке будет следующая: В устройстве находится приёмо-передатчик. Передатчик будет отправлять в эфир последовательно код каждой кнопки и в промежутках между передачей кода он будет переходить в режим приёма на ~3 сек. если за эти 3 сек. не пришёл ответ с кнопки он передаёт в эфир следующий код. И так по кругу все коды кнопок которые учавствуют в этом ресторане.

Если готовы поменять радиочастотную часть то проше всего будет сделать применив вариант (базовая станция)-(подчинённые приёмники) с фиксированным адресом. Базовая станция шлёт в эфир запрос к устройству с конкретным адресом на получение статуса кнопки. Все устройства принимают запрос, декодируют адрес и при совпадении одно из них шлёт ответ на базовую станцию.
ИМХО просто пытаться ловить сигнал от всех 50 кнопок одновременно - неэффективно и может привести к сбоя (особенно при нажатии нескольких кнопок одновременно).

Уважаемые участники данной темы, я искренне признателен Вам всем за присланные Вами советы. Но у меня пока остался открытым следующий вопрос:
Как мне организовать проект, что бы я выход приёмника смог подключить к любому входу МК, кроме входа UART, а с выхода UART мог передать полученный сигнал от приёмника в терминал?

Почитайте статьи по организации систем беспроводных датчиков. У Вас по сути датчик нажатия кнопки. Кое-что было в журнале "Беспроводные технологии". Вам нужна только идея организации сети.

Глянул на ваши фото
Можно же просто подключить rx5000 напрямую к FTDI, по мимо контроллера, и опредилиться со скоростью передачи данных.

Схема не проясняет вопрос про инвертор.
Напрямую как показано на схеме PIN TXD к COM порту подключать нельзя. Нужен либо преобразователь уровней, либо хотя бы инвертор.


Сигналы UART'а - 0 -> лог "0", +5В ->лог "1".
Сигналы RS232 Com port'a, +3..+15 (лог 0), -3..-15 (лог 1).



Никак. Если данные от приемника идут через UART, то подключать его нужно к UART'у.
Еслу нужна двухсторонняя связь и с приемником и с терминало, то можно взять МК с двумя UART'ами на борту. ATMega162 например. Тогда один UART соединяете с приемником, а второй - с PC.

Начать с правильного выбора элементной базы. Отказаться от дорогого и неудобного RX5000 и уж, разумеется, не стоит полагаться на прозрачную передачу через него асинхронной посылки с UART. Программный-то полудуплексный UART на небольшой скорости сделать не просто, а очень просто. На любой ноге (хотя предпочтительно для этого использовать аппаратные средства, типа ICP). Но не стоит так делать, честное слово. Все ж надо делать модем. А еще лучше, по нынешним временам - взять радиотракт с встроенным модемом. Например, Chipcon/TI CC1100 (или CC2500). Он заодно (и в первую очередь, исходя из озвученных требований) решит и проблему обратного канала. Можно взять и микроконтроллер с встроенным трансивером (из того же выводка от TI), но это получится дороже и может оказаться менее удобным. Atmega8 (или 48 или 88) и CC1100 - очень удобная связка. Но в освоении CC11xx несколько сложнее, да. Зато потом, после освоения - полная свобода (говорю как автор десятка изделий на этой связке, с общим тиражом уже под 100K, если не больше).

Уже пробовал. Результат то же, что и в первом посту. Тем более мне намного проще согласовать приёмник и COM так как я в своей сжеме использую FT232 преобразователь COM too USB. А в ней как всем известно входной и выходной сигналы TTL уровня. Перед тем как создать тему я провёл множество различных эксперементов, но всё безуспешно. Поэтому и прошу помощи в виде работающего куска кода программы.

Сорри в схеме которую Вы привели не было это показано. Вопрос с инвертором снимается.

Только, что ознакомился сописанием CC2500, приглянулась. Но сейчас я не готов приобрести эту микросхему, но обязательно её на неделе опробую. Если Вы разрабатывали конструкции которые используют часть моей задумки, прошу поделиться опытом. У Вас наверное был опыт работы с моими исходными данными и Вы наверное так же стакивались с моими проблеммами. Я уже отключал от МК приёмник и напрямую аппаратный UART МК подключал к терминалу. В терминале я писал что либо и при отправке в МК я незамедлительно получал то же, что и отправил обратно в терминал. Поэтому осмелюсь сделать вывод:
МК программно правильно настроен на работу с COM потром.
А вот аппаратно не уверен. Так как с приёмника я получаю какую то постоянную последовательность кода, но на совершенно не похожа на то, чего ожидалось получить. Поэтому либо проблемма со скоростью, что мало вероятно, либо, но это вообще абсурд, сигнал с приёмника нужно сначало инвертировать, и только потом отправлять на UART МК. И тогда сразу же следующий вопрос: А как я спогу принятый сигнал на МК преджварительно обработать? В какую переменную или регистр он попадает?

Кусок программы что в вашем первом посте рабочий, раз уж вы что то получаете в терминале.
просто нужно знать с какой скоростью передает данные rx5000 и настоить контроллер и компьтер на эту скорость.

По даташиту на rx5000 у него три режима со скоростями 2.4 kbps, 19.2 kbps и 115.2 kbps.

При том что на скорости 115.2 kbps контроллер с кварцем 8МГц скорее всего работать не будет т.к. большой процент ошибки

Решение с двумя UART конечно же интересное но когда своими глазами видишь рабочую схему в которой сигнал с приёмника приходят не на UART то уже уверен, что такое возможно.... Но как?

Сушествует множество решений програмного UARTа

Я бы классифицировал такую реализацию как "через одно место". 50% ресурса процессора будет занято эмуляцией второго UART'a. В итоге ни шага влево ни шага вправо. Вам оно действительно нужно?

Из описания проекта на ~50 столиков будет только один приемник, неужели для него нельзя взять МК на доллар дороже, и без буквы L, поставить кварц с частотой делящейся на 115200 без остатка. Тем самым всего за $1 избавить себя от проблем?

Вы правильно сказали по поводу фиксированных скоростей в RX5000 я из-за своей невнимательности не посмотрел в верзнюю строку колонки где указаны номиналы для скорости 19200. Сейчас пересмотрю свои настройки и результаты проверки выложу на форум.
Меня ввёл в заблуждение рабочий проект этого устройства в котором используется такая же элементная база как в моём проекте. Я её просто скопировал но программу решил написать свою. Так вот в рабочем проекте с собранным приёмником для скорости 19200 я настраивал терминал на скорость 9600 и при прошивке рабочего проекта у меня выводился в терминал правильный код. А будучи уверенный в том, что скорости я установил правильные, то есть 9600 я и не пытался обратить внимание на эту существенную деталь. Спасибо.

Поскольку я пишу на asm, то вряд ли мои наработки пригодятся. И, естественно, know how никто не раскрывает

Лениво вникать в предисторию, поэтому спрошу, как я понял - так что, Вы ожидаете, что принятый приемником RX5000 сигнал брелка можно передать в компьютер через UART непосредственно ? Просто забудьте это как страшный сон, и больше не вспоминайте. Начинать надо с принципов работы кодера в брелке, с формата его выходных данных. Просто в данном случае это не нужно и неинтересно, поскольку для решения поставленной задачи неприменимо (по причине абсолютной необходимости обратного канала. Которая, кстати, проистекает в первую очередь вовсе не из-за гипотетической возможности одномоментного нажатия кнопок на двух брелках)...

Это про обработку выхода RX5000 ? Превратить входной сигнал в последовательность "0" и "1", декодировать, превратить в осмысленную посылку для компьютера и передать по UART. А как декодировать - зависит от формата посылки, определяемой кодером. И уж, конечно, это не 115200,8,n,1, и штатный UART тут не в помощь (впрочем, могу представить себе вариант, когда можно было бы применить, в конце концов, UART успешно используют при общении, скажем, с 1-wire).

И так, из всего написанного делаю следующие выводы:
Для данного проекта необходимо использовать МК с двумя UART. Один на приём с выхода приёмника, другой на передачу в COM компьютера. Следовательно принятый сигнал с первого UATR я смогу редактировать непосредственно в МК и передавать его на второй UART.
Теперь о только что проведённых мной эксперементах с моим железом и настройкой скоростей.
Эксперемент 1.
Подключил выход приёмника на вход FT232. В терминале на разных скоростях принимал сигнал с кнопок. Ближе всего к положительному результату была скорость 2400.
Эксперемент 2.
Подключил выход приёмника на вход МК UART. Выход UART водключил на вход FT232. В терминале на на скорости 2400 были похожие сигналы на реальный сигнал с кнопки.
Завтра я разберу прошивку любой из кнопок и посмотрю с какими настройками передаётся сигнал. Хотя я в asm ничего не понимаю, но с дизасемблером и самоучителем попробую разобраться. Если кто знает настройки таких брелков или правельнее сказать, по какому протоколу они передают свои коды, буду признателен за предоставленную информацию.

Да нет у RX5000 никаких "режимов". Он примитивен как грабли. Все, что относится к скорости передачи - это выбор обвязки фильтра. Ничего больше. Предположение, что сигнал с OOK/ASK приемника можно подать на вход UART и получить осмысленный отклик от брелка автосигналки - у меня лично цензурных выражений для комментариев не находится, честное слово. Ну учите же матчасть или скопом гляньте... Поглядите, в конце концов, даташит на микрочиповские HCSxxx (даташиты на прародителей, продукцию Nanoteq, пожалуй, найти будет трудновато) - на выходе у них типично PWM. Вот его и надо декодировать. Да, можно, конечно, согласовав полярность и выбрав правильную скорость, заставить UART принимать посылку побитно (только скорость надо тогда выбрать порядка 1200 bps), но лучше фигней не страдать. Тем более что описанную задачу так вообще не решить...

Пардон, скорость должна быть где-то 9600...

Проанализировав datasheet HCSxxx стало понятно, что она шифрутет данные как я понял по какому то протоколу. И теперь становится понятно почему я постоянно получаю не то, что хотелось бы. Если я не ошибаюсь надо просто на уровне МК расшифровать полученный сигнал и тогда я ы терминале получу то, что мне нужно. Я проавильно думаю?

Ну наконец-то ! С этого (ознакомления с даташитом и просмотр выходного сигнала брелка скопом) и надо было начинать. Да, надо декодировать этот сигнал, превратив PWM в "0" и "1", разобраться с форматом посылок (а кодеров вообще-то много разных, с разными форматами), надо проверять контрольную сумму посылки (если она есть), найти и выделить серийный номер (иначе как различать кнопки ?) Но, главное, это не решает поставленной задачи - надежную передачу запроса с подтверждением можно реализовать только при наличии обратного канала. Так что с брелками стоит играть разве что для общего развития или под какую-то другую задачу...

Меня непосредственно интересует HCS301 KEELOQ Code так как есть возможность приобрести таких кнопок от гаражных ворот сотни по 10$ за штуку. А если учесть, что они используют один и тот же протокол шифрования, то осталось только разобраться в этом протоколе, написать свою программу дешифрования и результат налицо. Теперь понятно почему у меня в рабочем проекте и прошивке все брелки с этой HCS301 прекрасно отображают свой код в терминале. Где бы только найти протокол этого KEELOQ

Там в аппликухах все должно быть. Алгоритм собственно шифрования вряд ли нужен, ведь требуется определить номер брелка, а все эти наворот с плавающим кодом - они для другого... Себестоимость комплектующих для решения на CC2500+ATmega8 будет даже меньше (тем более что вряд ли годится корпус автомобильного брелка), а будет обратный канал...

У CC2500 очень жесткие требования к кварцу, по ДШ нужен строго 26-27Mhz, а их найти довольно проблематично.
Как думаете, если поставить 25Mhz будет работать?

Вероятно да. Но это за пределами спецификации, я такое делать сильно не рекомендую. На самом деле, никакой проблемы нет. Более того, настоятельно не рекомендую искать дешевый ширпотреб в HC-49, слишком велика вероятность того, что либо будет неприлично большое начальное отклонение частоты либо, впридачу, еще и кварц окажется на третюю гармонику. Качественный SMDшный кварц с куда большей вероятностью окажется тем, что нужен, а стоить будет не сильно дороже. И все равно, нужно прикинуть возможный разброс номинала несущей, при необходимости сделать калибровку, особенно при узкой полосе. Либо использовать CC1100 на 433 MHz, допуск при прочих равных будет пропорционально больше. Ну и в любом случае помнить о том, что в диапазоне хватает всякой дряни - на 433 брелки и LPDшки, а на 2.4 - bluetooth и WiFi, причем в ресторане-то этого добра может оказаться еще больше...

Стоит также посмотреть на Silabsовские приёмо-передатчики аналоги rf12 - si4421a например.
Корпус у них удобный для пайки вручную и управление лёгкое. У нас на м48+si4421a построена сеть датчиков с базовой станцией способной работать на 16 каналах с опросом до 16 датчиков на каждом канале (кол-во определяется только программой).

Уважаемые, а можно ли подавать на вход передатчика сигнал с уарта? Где вероятность, что вы примете его правильно, ведь в этом сигнале МОЖЕТ присутствовать ПОСТОЯННАЯ составляющая, и, скорее всего, она там будет!!! Для передачи по радиоканалу, как и по длинным линиям, необходимо преобразовать сигнал так, чтобы в нем отсутствовала постоянная составляющая. В радиобрелках часто передают манчестером, это хорошо видно осциллографом, есть сигналы только двух длительностей, а в уарте они могут быть и трех и более.

Существует немало передатчиков, в которых есть соответствующее преобразование и даже пакетирование, например тот же СС2500. Если такого преобразования на борту нет, то об этом и не пишут в DS:) Только длинные линии тут ни при чём - просто определённая схемотехника демодуляторов (а-ля data slicer http://www.maxim-ic.com/appnotes.cfm/an_pk/3435 http://www.maxim-ic.com/appnotes.cfm/an_pk/3671) наиболее эффективна при постоянной составляющей модулирующего сигнала близкой к нулю.

Можно, но дальность и помехоустойчивость будут ГОРАЗДО меньше, чем при том же манчестере, не говоря уже о FSK который юзается в большинстве чипов трансиверов

И так, продолжая тему я закинул техзадание своим коллегам, умным головам. Хочу паралельно в теме выложить зарядку для головы. У кого есть желание, свободное время прошу принять участие в разработке. Как я уже говорил в первом посте, идея взята с готовой конструкции. Есть работающая прошивка в которой написана программа-дешифратор к брелкам с протоколом KEELOQ.
Задача: Найти тот самый кусок кода с дешифровкой и по аналогии написать его на С.
Основной принцип работы программы будет следующий: Сигнас с передатчика поступает в первый UART или на любой порт МК. Программа-дешифратор обрабатывает полученный сигнал и записывает его в переменную. А далле с этой переменной можно делать всё, что душе угодно.
И так, у кого есть желание поработать мозгами я могу выложить архив рабочего устройства, с принципиальной схемой, прошивкой и кратким описанием работы устройства.

Желающих вряд ли найдете. Разве что переместив тему в "Предлагаю работу"
А так не понятно зачем Вам декодировать Keeloq? В посыке от hcs301 ( в большинстве дешевых сигналок и ворот используется именно она) и так есть все что нужно для счастья - 28 битный серийный номер, состояние кнопок, состояние батареи и признак повторной посылки. Незакодированные! Берите и пользуйтесь. А "плавучая" часть пусть живет сама по себе.

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

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

А почему не применить скажем nRF2401, на 2.4ГГц...?!
Есть возможность использовать режим работы сразу с двумя каналами приёма/передачи.
А nRF24L01 так вобще может сразу с 6-ю подобными устройствами обмениваться.
Что касаемо KeeLoq, могу выложить код приёма посылок от HCS300, написан на ассемблере,
приёмником был RR10 от TELECONTROLLI.

Подкину еще бензинчика в огонь
1. А если не зацикливаться на AVR, а посмотреть в сторну rfpic http://www.trt.ru/products/microchip/rfpic.htm
Там весьма демократичные цены
2. Я на 128 меге на 16 МГц делал 32-канальный программный дешифратор манчестера (1200 бод). При параллельном поступлении на все каналы информации вполне успевали декодировать 23-24 канала. В реальной ситуации (с разбежкой по времени) все 32 канала пашут вполне надежно, так что проц 1 каналом манчестера сильно загрузить сложно.
3. Xmega32 имеет корпус как у меги 16 (qfp44) и 5 комовских портов