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

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

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

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

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

Наверное так мало сообщений потому что никто ничего не понял... Мега делает 16 замеров на 1 бит, а не на пакет. И что-то мне подсказывает, что с термином "бод" у Вас какая-то путаница в голове.

Насчет терминологии: http://www.iknowit.ru/words/word15766.html , ну и т.д. по википедии. Но речь не о бодах.
Если мега делает 16 замеров на 1 бит, то это еще хуже для меня =). Я собираюсь делать 1 замер на 1 бит. Вопрос пока таков: каков процент получения ошибочного результата при 1 замере на 1 бит?

В первую очередь ни один микрофонный вход ваш DC сигнал не пропустит, следоваткльно нужна несушая частота и демодулятор. Так что можете забывть об одном отсчете на бит и начинать читать пор модемы.

Все правильно там написано, а у Вас "Скорость передачи данных с микроконтроллера = 9600 бод/сек", т.е. скорость=скорость/время...
Если хотите использовать микрофонный вход, то нужно использовать кодировку, обеспечивающую отсутствие постоянной составляющей. Например manchester или 8b/10b. Ну или как уже было сказано МОДЕМ. А по поводу 1 замера на 1 бит - вероятность появления ошибки стремится к 1, потому как невозможно обеспечить абсолютное равенство частот и фазовые соотношения в приемнике и передатчике. Да и АЦП у меги может только 15kSPS, так что 44100 не получится.

А разве не достаточно делать замеры по пикам? То есть просто смотрим на пики, и всё?
Кстати, если мне не изменяет память - я на микрофонный вход звуковухи подавал импульсы, и видел импульсы в программном осциллографе, который берет сигнал со звуковой карты. Или я что-то путаю??
Вот пример:
http://biorezonans.3bb.ru/viewtopic.php?id=43

Про модемы я бы начал читать, если был бы уверен, что иначе никак.

А теперь представьте передачу не меандра, а последовательности символов 0x00 или 0xff, в зависимости от входа звуковой карты и скорости передачи что-то может получиться, а может и нет. И результат на разных картах может быть разным.

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


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

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

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



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

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

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

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

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

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

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

Понятно

Есть алгоритмы... но они жуткие все =)

Где-то читал, что таким методом на вход УНЧ можно передавать до 2400 бод . Была где-то в интернете таблица с частотами для единиц и нулей, и с максимальной скоростью при этих частотах. Мне нужно выжать 4000бод . Вроде бы это реально.

Вот, например, сайт хорошего проекта:
http://www.eecs.umich.edu/~prabal/projects/hijack/

Цитата:

При помощи FSK они получили 300бод. Затем получили 8.82кбод при помощи кодирования Манчестером.


Кстати, нашел еще информацию о прямом соединении http://web.media.mit.edu/~nanwei/MAS836-20...aafi_MAS836.pdf

Из всех этих статей видно, что нужно экспериментировать. И не факт, что это будет работать везде одинаково. Особенно нужно учитывать, что некоторые карточки цифруют на 48000 и потом понижают до 44100 и прочих частот, так что не факт, что частота получится точно 44100, а значит алгоритмы синхронизации точно потребуются.

А вообще - пошлите манчестер с МК и запишите. А там видно будет.

Только не понятно зачем это нужно.

Да, надо попробовать.

Здесь все конкретно расписано:

http://electronix.ru/forum/index.php?showtopic=98362

Скорость передачи данных я взял исходя из максимальных оборотов спортивного мотоцикла. А это около 10000 об/мин. Округлим до 12000, получим 2000 оборотов в секунду. То есть 2000 значений разрежения в секунду для одного цилиндра. 4 цилиндра = 8000 значений. Ну, итого примерно 64000 бит в сек. Огог! Что-то я раньше другое насчитывал...


Но можно уменьшить скорость передачи, засчет усреднения значений, и передачи уже усредненного значения. То есть берутся 4 значения, усредняются (или же фильтруются), и передается всего лишь одно усредненное значение. Итого, можно понизить скорость передачи в n раз. При этом реакция устройства ухудшится. Но в данном случае - это не так важно. Можно усреднять динамически - на малых оборотах не усреднять, а на высоких усреднять очень глубоко.

И, действительно, интересует именно совместимость с разными устройствами.

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

такой вопрос: как лучше ослабить сигнал с выхода контроллера? обычным делителем? Необходимо ослабить до 100-150мВ

Несколько лет назад делал радиомодем с примерно похожими требованиями к скорости передачи и полосе пропускания: 1200/2400/4800 бод FSK и 9600 PI/4-QPSK в полосе 7кГц.
Т.е. - поток данных с UART кодировался-модулировался и подавался на звуковой вход радиостанции с полосой 7кГц.
Проект давно уже работает и продаётся.
Так вот, чтобы вы примерно оценили требования к аппаратуре и ПО: я писал его на асме на TI-шном C5502. Никакой ARM7/ARM9 не потянул-бы требумое количество математики (уж не говоря о меге
На 9600 QPSK загрузка процессора составляла около 30% при непрерывном потоке данных полным дуплексом (при тактовой ==220МГц и работе только из внутренней ОЗУ).
По стоимости комплектации примерно укладывается в ваши требования: кроме DSP остальное железо ерунда - кодек да гальваническая трансформаторная развязка, флешка I2C, имп.источник питания+несколько LDO и сторожевик.
Кодек - на частоте 48000кГц.
Ну и основные затраты конечно - уйма потраченного времени
Примерно на приёме был такой тракт (всё программно): полосовой КИХ-фильтр, DC-delete-фильтр, эквалайзер (для корректировки АЧХ тракта), передискретизатор (частота была не совсем 48000, а близкая к ней), далее - разбиваем на квадратуры (умножаем сигнал на sin и cos), далее - ФНЧ на каждую квадратуру и в конце - квадратурный демодулятор. Всё - половина работы по приёму выполнена
В этой точке получаем примерно то, что вы нарисовали на осциллограмме (для QPSK - две таких осциллограммы параллельно). Осталось только засинхронизироваться и преобразовать поток сэмплов в биты, а биты - в байты - это примерно еще половина работы приёмника (как оказалось - более сложная чем первая половина).
Если это реализуете, то передатчик будет - плёвое дело, не забудьте только внести в передаваемый сигнал предискажения для корректировки АЧХ.
Еще вам надо будет продумать предварительное кодирование, чтобы в передаваемых данных не было длинных последовательностей 0 или 1. А также защиту от ошибок (какой-нить CRC).
Ну и канальный уровень протокола передачи.
Да - и для дуплекса нужна 4-проводка, а по 2-проводке - только полудуплекс.
Думаю - за годик командой при наличии свободного времени и желания можно уложиться

ИМХО: для вашей задачи больше подойдёт канал bluetooth если уж не хотите USB-COM за 200руб в бук воткнуть.

Спасибо за подробный ответ.
Но мы остановились на манчестере. У нас пока нет задачи делать туда-сюда =)) Нам надо только с устройства в телефон передавать.
После того, как мы еще раз все пересчитали, мы пришли к выводу, что нужно плясать от экрана. Точнее - от глаз. Мы делаем, грубо говоря, интерфейс для человека. По этому нам нужно всего лишь обеспечить поступленние пакетов с частотой 25Гц. Так как мы делаем под 4 цилиндра, то нужно нам 100Гц. 100Гц*8 = 800бит/сек, или 1600манчестер-бит в сек. Плюс старт/стопы. Ну и т.д. В общем, уже реализовали передачу. Друг пишет на андроиде прием.

Если у кого есть соображения как старт/стоп (ну или разделитель между пакетами) лучше закодировать - буду рад их выслушать =)
Да, и еще. На осциллограме на телефоне видно, что импульс, пройдя через все тракты телефона, имеет затянутый фронт и срез. Можно ли это дело математикой поправить? Это оффтопик, по этому киньте ссылку плиз.

p.s. немного не в тему, но... нам надо еще находить экстремумы для каждого сигнала с каждого датчика. киньте ссылкой плиз, хотя бы в раздел, где обсуждается вся эта канитель.

Сообщение отредактировал Lost_Viking - Feb 10 2012, 08:45