Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Помогите с реализацией Манчестерского кода
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
hd44780
Начитался всякой доки, примеров по RC-5 ...
ничего пока не получилось.

Передатчик у меня - Mega8515L, приемник - Mega32.
Сигнальный провод повесил на INT1 Mega32, прерывание возникает (светодиод моргает, на LCD сообщения правильные идут), таймер запускается, а потом - пропасть. Такое ощущение, что где-то я во временных интервалах путаюсь.
На LCD все сообщения выводит главная программа, а не обработчики.

Нет ли у кого готовой реализации или чего?

Спасибо.
=VRA=
Я все понимаю - бывает очень нужно, но зачем трахаться и тратить ресурсы с манчестером, когда на борту уже есть готовые аппаратные UART/I2C/SPI? Если все это добро уже занято, то почему бы не сделать дополнительный программный UART/SPI/I2C - опять же манчестер-то зачем?
hd44780
Да радиомодули есть самодельные (http://cxem.net/rmodem/rmodem14.php), под них и огород.
=VRA=
Тоже не шибко оптимально - лучше уж бы FSK тогда, а еще лучше - нормальные радиомодули. Но раз решил так - то изучай http://forum.sparkfun.com/viewtopic.php?t=...06040ed7e7f9439
hd44780
Почитаю, спасибо.
AVR
Цитата(hd44780 @ Jan 27 2008, 13:42) *
Да радиомодули есть самодельные (http://cxem.net/rmodem/rmodem14.php), под них и огород.
Прошу прощения за оффтоп, давно уже мечтаю слепить радиомодуль себе какой-нибудь. Интересует насколько хорошо работает схема по этой ссылке? Возможно ли её ещё больше упростить?
hd44780
Народ пишет, что работает нормально.

Насчет упрощения не знаю, я в радиосвязи практически не шарю.
mrKirill
Цитата(AVR @ Jan 27 2008, 16:20) *
Прошу прощения за оффтоп, давно уже мечтаю слепить радиомодуль себе какой-нибудь. Интересует насколько хорошо работает схема по этой ссылке? Возможно ли её ещё больше упростить?

Работа конкретно чего интересует?
Передатчик типовой, сам не раз подобные собирал, начинали работать сразу, без проблем.
Приемник еще не собирал, руки не дошли.
А вот насчет упрощать, неужели и это сложно? Проще уж точно не найти.
Kuzmi4
2 hd44780 - посмотрив в теме "Исходники программ и библиотек" - я там полный проэкт выкладывал когда то - с ресурсов - INT1 и таймер 1-й вроде всё.....
hd44780
Да, я видел.

Но тут в интернете заманчивое решение нарыл - RF over UART.
Идея в том, что данные кодируются так, что на выходе UART-а получается манчестер.
При этом один байт данных превращается в 2, т.к. в манчестере по сути одному инф. биту соответствует 2 бита.

Правда так это или нет, пока не проверял.
singlskv
Цитата(hd44780 @ Jan 29 2008, 11:07) *
Но тут в интернете заманчивое решение нарыл - RF over UART.
Идея в том, что данные кодируются так, что на выходе UART-а получается манчестер.
С отправкой через UART никаких проблем нет.
А вот с приемом...
Подумайте, как Вы будете выделять начало приема данных на фоне помех ?
hd44780
Не знаю пока.

Хоть через UART, он тоже может всякую белиберду эфирную ловить.
Пока видится только одно решение - CRC и прочие проверки на уровне всего пакета.
singlskv
Цитата(hd44780 @ Jan 29 2008, 12:41) *
Пока видится только одно решение - CRC и прочие проверки на уровне всего пакета.
Проблема в том, что Вы будете терять кучу пакетов.
Если менее чем за длительность передачи одного байта перед реальной посылкой
будет помеха которую UART примет за стартовый бит, Вы потеряете весь пакет.
А такие помехи будут постоянно...
hd44780
Да согласен я.

Но любой радиообмен этим чреват.
=GM=
Цитата(hd44780 @ Jan 29 2008, 08:07) *
Но тут в интернете заманчивое решение нарыл - RF over UART. Идея в том, что данные кодируются так, что на выходе UART-а получается манчестер. При этом один байт данных превращается в 2, т.к. в манчестере по сути одному инф. биту соответствует 2 бита

Невероятно, самосинхронизирующийся код манчестера передают с помощью асинхронного рс-232 по каналу с импульсными шумами. Извините, но это не просто дурь, а дурь образцово-показательная. Обе кодировки принципиально не подходят к передаче по каналу с импульсными помехами. Вам singlskv правильно сказал, что вы будете терять кучу пакетов. И что помехи будут постоянно.

Если уж непременно хотите передавать данные с помощью рс-232, сделайте простейший подавитель импульсных помех, аппаратный или программный. Аппаратный - это просто счётчик с насыщением в 0 и в МАХ, на D-вход которого подаётся входной сигнал от приёмника, а на С-вход подаётся меандр с частотой в 10-20 и более раз выше, чем частота рс-232. Выход берётся со старшего разряда счётчика. Надеюсь, работа такого подавителя интуитивно понятна - он подавляет все импульсные помехи с длительностью не более Тсч*2^(N-1), где N-ёмкость счётчика. Еще проще сделать такой подавитель программно, единственное но - придётся делать программный уарт.
singlskv
Цитата(hd44780 @ Jan 29 2008, 13:22) *
Да согласен я.
Но любой радиообмен этим чреват.

Одно дело терять 1% пакетов и совсем другое 50% или еще хуже.
Вы смотрели что творится на приемнике когда нет передачи ?
Посмотрите, очень позновательно...

Если все же решите делать прием через UART, то можете попробовать следующее:
первый байт отправлять типа 0b00001111 а за ним отправлять уже значимую часть
на приеме изначально UART выключен на прием и нога RX сконфигурированна как
вход с подтяжкой
первый байт(0b00001111) принимаете ручками(прерываниями) как просто
импульс 0 длинной 5бит(4+1старт) отсчитывая время таймером
если импульс такой(чуть меньшей) длинны был принят, за время пока идут 1111
включаете прием UART на RX и всю значащую последовательность принимаете UARTом.

Только нужно иметь в виду что 0 на UART должен быть активным уровнем для
передатчика/приемника, те возможно понадобятся инверторы
hd44780
Спасибо, когда начну экспериментировать - проверю все.
=GM=
Цитата(singlskv @ Jan 29 2008, 10:54) *
...если импульс такой (чуть меньшей) длины был принят, за время пока идут 1111, включаете прием UART на RX и всю значащую последовательность принимаете UARTом

Тоже плохо. Кто мешает помехе налететь, пока идут эти 1111 или даже когда идёт стоп-бит? Уарт зацепится за ложный старт-бит и весь байт, а с ним и весь пакет- псу под хвост.
singlskv
Цитата(=GM= @ Jan 29 2008, 14:12) *
Тоже плохо. Кто мешает помехе налететь, пока идут эти 1111 или даже когда идёт стоп-бит? Уарт зацепится за ложный старт-бит и весь байт, а с ним и весь пакет- псу под хвост.
Мешает АРУ, который за время 00000 настроится на наш сигнал и уже не будет
ловить маломощные помехи со всей округи на полном усилении.
Конечно это не панацея и при наличии других передатчиков в зоне видимости
пакеты все равно будут пропадать, но такой настроечный байт позволит уменьшить вероятность
пропадания пакетов в разы.
А по хорошему конечно нужно ловить каждый битик отдельно.
GDI
Если есть он, этот АРУ....
Я вот тут в другом сообщении уже давал ссылку http://electronix.ru/forum/index.php?showtopic=42502 на отличный проект по теме, там применены корреляционные методы выделения сигналов, даже есть модели тракта приема-передачи для матлаба, где можно промоделировать помеховую обстановку, сам все хочу попробовать этот проект, да все руки не доходят и задачи нет...
=GM=
Цитата(singlskv @ Jan 29 2008, 11:21) *
Мешает АРУ, который за время 00000 настроится на наш сигнал и уже не будет ловить маломощные помехи со всей округи на полном усилении

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

Подавитель импульсных помех, о котором я писал, легко подавляет такие врезки и вырезки, потерь пакетов будет 0,1% или меньше...Подавитель тоже не панацея, но гораздо лучше, чем передавать 0х07 в начале пакета и, тем более, манчестер под рс-232. Конечно, лучше всего сделать согласованный или корреляционный фильтр с решающим устройством, но на атмеловском мк это сложная задача, хотя и подъёмная.
singlskv
Цитата(=GM= @ Jan 29 2008, 15:35) *
Похоже вы хотите бороться только с шумами, которые вытягивает ару, когда нет сигнала. Но в жизни всё не совсем так происходит. Ещё есть помехи, сопоставимые по уровню с вашим сигналом, они легко пролезут на выход приёмника, и никакое ару ничего с ними поделать не сможет. Выглядеть это будет так: идёт уровень логической 1, потом вдруг, раз, и врезка, и вы получаете ложный стартовый бит и так много раз.
Не только бороться с шумами, но и еще точно определять момент включения UART на
прием. Если его включение будет в районе 5%длительности бита от начала предполагаемой
посылки то вероятность поймать шум становится очень маленькой.
Цитата
Подавитель импульсных помех, о котором я писал, легко подавляет такие врезки и вырезки, потерь пакетов будет 0,1% или меньше...
Такой фильтр у меня стоит в каждой проге, например как подавитель дребезга кнопок,
дискретных входов, итд
Цитата
Подавитель тоже не панацея, но гораздо лучше, чем передавать 0х07 в начале пакета и, тем более, манчестер под рс-232. Конечно, лучше всего сделать согласованный или корреляционный фильтр с решающим устройством, но на атмеловском мк это сложная задача, хотя и подъёмная.
Посылка 0x07 это только как вариант прикручивания всего к UART, и использовать
его нужно совместно с манчестером.
Кстати, не забывайте что у UART тоже голосующая схема работы, так что на небольших скоростях
все должно быть Ok.

Ну а сам я реализовывал все чуть по другому...
=GM=
Цитата(singlskv @ Jan 29 2008, 13:34) *
Кстати, не забывайте что у UART тоже голосующая схема работы, так что на небольших скоростях все должно быть Ok.
Ну а сам я реализовывал все чуть по другому...

Голосующая схема останется ни при чём, если уарт захватился за ложный старт-бит.

Честная реализация должна быть такой: преамбула-подходящая модуляция (бпск, кпск,...), снятие допплера-модем, фазовый пуск, свёрточное декодирование, перемежение, блочное декодирование, данные-контрсумма. Ну это, конечно, для серьёзных задач, типа 256 каналов, два скачка до исз,...и не по зубам авр.
singlskv
Цитата(=GM= @ Jan 29 2008, 17:05) *
Голосующая схема останется ни при чём, если уарт захватился за ложный старт-бит.
Возможно Вы не до конца меня поняли, ложных стартовых битов почти не будет,
все время после 00000 пока идет 11111 мы вобще ничего не принимаем, приемник UART
включается по таймеру только непосредственно перед началом стартового бита реальных
данных. Таким образом мы уменьшаем вероятность ловли ложного стартового бита
примерно в 100 раз. Мешать нам будут только 2 вида помех, помеха присосавшаяся к импульсу
00000 и изменившая ее длинну и помеха успевшая проскочить между включением приемника
UART и реальным началом передачи.
Нет никаких оснований не сделать эти периоды <1/100 от длительности приема
одного байта например...

Так что голосующая схема уарта вполне в деле...
Нужно только как можно точнее определять момент возможного начала передачи.
Ну и научиться реагировать на каждый переход 1->0 для того что бы не пропустить начало
нашего 0x07.
_Pasha
Вставлю и свои 5 коп.
1. Преамбула(продувка канала) обязательна, и это навевает мысли о том, что софтовый уарт сюда очень кстати.

2. Каждый, кто начинал заниматься помехоустойчивым кодированием, наверняка сталкивался с простейшим примером построения избыточного кода, корректирующего одиночные и некоторые двойные ошибки без значительных программных напрягов. Пусть нам надо передавать 9 бит данных b0..b8. Из них делается блок из 16 бит
Код
b0 b1 b2 P1
b3 b4 b5 P2
b6 b7 b8 P3
P4 P5 P6 P7


P1,P2,P3 - это xor между битами в соотвествующей строке,
P4,P5,P6 - в столбце,
P7 - xor по всем P1..P6.

Понятное дело, сие неприемлемо для хардового уарта.
Предлагаю данную схему еще более упростить. Получим
Код
b0 b1 P1
b2 b3 P2
P3 P4 P5

т.е. информационных бит аж четыре, зато кол-во корректируемых двойных ошибок посвыше, и скорость передачи аж в 12 раз выше, чем FSK smile.gif

!!! Сам не делал.

Когда надо было передавать, пользовался fsk, потому что держали границы канала связи, и данных было немного. Нужно было таймер 0, 1, OCR1, ICP1. Писалось под 90s2313. Исходников уже нет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.