roboforum.ru

Почему бы не починить р/у вместе с форумом? И опыта наберетесь заодно...

_________________
if(!Operate) Read(pDatasheet);

судовольствием просто так быстрее =)
добавлю фото

потому что все молчат у меня впечатление что все печально... =)

ок, я фотку своего приемника скину ))

Делаю прект аппаратуры радиоуправления с использованием техники прямого преобразования
http://aviamodelka.ru/forum/index.php?s ... entry75665
встал вопрос о протоколе обмена. Может ли кто-нибудь подсказать готовые решения?
Как отличать передается 1 или 0 понятно, но дальше встают проблемы.
1 Получение синхросигнала для отдельных бит.
2 Получение синхросигнала кадров данных.
3 Загрузка кадров в буфер и исправление ошибок.

Для не очень быстрого обмена данными видимо можно рассчитывать на относительно
стандартные и легко реализуемые UART или RС-5.

Для скоростных обменов обычно используют коды Баркера,
которые имеют хорошие автокорреляционные свойства.


Требует регистрации.

имхо нехорошо давать ссылки туда где необходимо регестрироватся перед тем как что то посмотреть ....

_________________
die Wahrheit ist irgendwo da draußen

Прошу прщения, как-то забыл, что там только для "своих", у меня кукесы туда пускают автоматом.
Задумал я прект самодельной аппы прямого преобразования, давно меня эта идейка мучала лет 8. Вот решил воплотить в жизнь. Приемник и передатчик уже собрал. На недельке повешу на приемник atmega48 на передатчик atmega16. И надо будет туда что-то запрограммировать. Сам я вполне сносно владею СИ, работаю в IAR. Никогда вплотную с передачей цифры по радио не сталкивался (только GSM модем). Кнал работает вполне достойно.
В прицепе схема передатчика (она актуальна и доведена), и приемника (сейчас уже немножко другая и пока не задокументирована.

Пользуйтесь УАРТОМ и не парьтесь... Если связь односторонняя,
то нужно передавать хотя бы контрольную сумму пакета, чтобы не реагировать на заведомо неправильные команды.

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

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

Самый простой способ - это передавать одну и ту же команду по возможности часто
и добавить контрольную сумму или (лучше, но посложнее) CRC.
Тогда приемник будет считать, что если контрольная сумма не совпала, то пакет неправильный и нужно ждать следующего. Пакеты можно относительно просто и надежно распознавать по паузе перед ним и преамбуле.

UART не подходит ну только разве что для очень комфортных условий. Обратите внимание на описание процесса синхронизации UART в разделе “Asynchronous Clock Recovery” стр 186 документа ATmega48/88/168 (в DS на 128ю тоже самое). Восстановление несущей происходит по спаду стартового бита, потом делается проверка в 3 отчетах 8,9,10 или 4, 5, 6. При этом дрожание фазы несущей из-за шумов эфира соединяется с ошибкой в 1/16 или 1/8 тактовой частоты. Проверка в 3х отсчетах – весьма слабый механизм отбраковки ошибок, CRC сильней. А зачем нужен слабый алгоритм если есть сильный? Нужно использовать статистические методы восстановления несущей. Например, для NRZ кода, программируем таймер, так чтобы период счета от 0 до max равнялся периоду 1го бита принимаемого сигнала. Сигнал от приемника подаем на компаратор, и всякий раз, когда есть перепад с 1 на 0 или 0 на 1 проверяем накопленное таймером значение, после 256 перепадов входного сигнала вычисляем среднее арифметическое значение того, что накапливал таймер. Потом двигаем таймер на величину усредненной ошибки. После первых 256 перепадов ставим флажок, что фаза несущей захвачена, можно принимать и обрабатывать данные. Подсчет ошибки и коррекция фазы таймера происходит и после первых 256 бит данных, те всегда.
В интервале 1/2T таймера ЕДИНОЖДЫ проверяем состояние бита, а наличие ошибки проверяем уже на более высоком уровне.
Главное – радиосигналы (в смысле сигналы на выходе качественного приемника) – спектрально ограниченны, а это значит что вероятность того, что число переключений компаратора в интервале периода 1го бита будет более 2х почти 0, даже если на входе приемника ничего кроме собственных шумов. Те наиболее вероятное искажение в радиоэфире – это уход реальных фронтов принятого сигнала (после компаратора) , от границ каждого бита. Алгоритм должен быть устойчив при уходе фронтов вплоть до +-1/2T.
Все о чем я писал выше называю битовой синхронизацией. Вопросы кадровой синхронизации и контроля ошибок я пока еще не обдумывал.
У меня есть вопрос, а как программно восстанавливается несущая (проводиться битовая синхронизация) на манчестере? Этот метод проще или сложней, эффективней предложенного мной метода?

Кстати, манчестер по идее - неплохой вариант, а реализацию можно стырить из процедур работы с кассетным магнитофоном древнего бытового компьютера (Радио-86РК или ЮТ-88), там ведь тоже был спектрально ограниченный канал с помехами. У ЮТ-88 я ее когда-то давным-давно разбирал, там достаточно просто все - передается преамбула - десяток байт FF (или 00 - не помню), затем синхробайт Е9, а затем идут данные. В конце - контрольная сумма. Декодирование бита - довольно простое, ловим любой переход 0->1 или 1->0, ждем 3/4T и значение на порту считаем значением бита. Затем снова ждем перепад и т.д. Более того, любой перепад нужно ждать из-за того, что изначально неизвестно, прямой сигнал идет или инверсный. В случае нашего радиоканала это известно, так что можно на преамбуле ждать конкретного перепада. Так вот, на преамбуле принятые биты просто кладутся в сдвиговый регистр, и после каждого бита он сравнивается со значением синхробайта. Если совпал - все, дальше принимаем байты по 8 штук и кладем в ОЗУ.

Хотя по идее для радиоканала лучше бы организовать ФАПЧ по принятым данным, для большей помехоустойчивости.