Программный UART на микрофонном входе Опции

[Lost_Viking]

Есть идея реализовать прием данных через микрофонный вход телефона. Гораздо проще по ЮСБ, но мы не ищем легких путей =))
Интересует вот что:
Частота дискретизации входного сигнала = 44100гц.
Скорость передачи данных с микроконтроллера = 9600 бод/сек

На осциллограмме в VMLAB'е видно, что 1 пакет данных (10 бод) передается за 1мс. Длительность 1 бода = 100мкс.
В документации на atmega16 указано, что внутренний usart делает замеры (отсчеты) 16 раз за 1 пакет. Почему - не помню, но мне голова подсказывает, что надо делать 20 замеров, 2 раза за один бод, учитывая старт-бит и стоп-бит.

С другом собираемся поступить так:
Оцифрованный сигнал с микрофона будет записываться в буфер определенной длинны. Далее, будет алгоритм выборки из этого буфера.
Но, для более высокой точности необходимо "щупать" сигнал с частотой 20кГц. Не каждый УНЧ может похвастаться работой на такой частоте, а тем более микрофонный усилитель. То есть вряд ли получится каждый бод щупать по два раза.
Отсюда вопрос: а что если "щупать" всего один раз? То есть изначально устройства будут как-то синхронизироваться между собой, на приемнике будет высчитываться длительность импульса, длительность всего пакета, и исходя из расчетов будет корректироваться шаг выборки из буфера?

Какова вероятность приема с ошибкой? Какие есть алгоритмы исправления? И т.д.

Сообщение отредактировал Lost_Viking - Jan 20 2012, 16:56

[Lost_Viking]

Идея началась с этой статьи: http://www.eecs.umich.edu/~prabal/pubs/pap...kuo10hijack.pdf

На одной из диаграмм видно, что импульсы модулированы импульсами. Этот модулированный сигнал подается на вход телефона, где потом обрабатывается. Почему здесь применили модуляцию? Я думаю, что из-за того, что с выхода УНЧ сложно получить хорошие импульсы, и это тоже показано на одной из диаграмм. В результате двунаправленной передачи данных будет трудно добиться. Как я понял, импульсы все-таки на вход УНЧ подать можно. Да, там стоит разделительный конденсатор. Но, однако, как-то импульсы получают в программах!?

А теперь представьте передачу не меандра, а последовательности символов 0x00 или 0xff,

А об этом я не подумал. =))) Спасибо! Ха... Тогда придется разбираться с алгоритмами демодуляции FSK сигнала... Или , действительно, манчестером пользоваться.

А потом в UART-е нормальный уровень - высокий, так что нужен как минимум инвертер, а то межсимвольный интервал точно убьется.

Нормальный уровень - это постоянная составляющая что ли? Расскажите подробней, пожалуйста.

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

Передача будет непрерывной. В том-то и проблема.

Может кто-нибудь посоветовать алгоритм демодуляции FSK сигнала? Хотя бы с чего начать штудировать книгу "Цифровая обработка сигналов". Не зря же я ее два года назад купил =))

[ataradov]

Нормальный уровень - это постоянная составляющая что ли? Расскажите подробней, пожалуйста.

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

Передача будет непрерывной. В том-то и проблема.

Тогда точно про модемы читать, в непрерывном потоке вы с ходу даже стартовый бит так не найдете.

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