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

Сообщение отредактировал rx3apf - Nov 6 2009, 16:45

У 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 комовских портов