[Lost_Viking 0]

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

Интересует вот что:

Частота дискретизации входного сигнала = 44100гц.

Скорость передачи данных с микроконтроллера = 9600 бод/сек

На осциллограмме в VMLAB'е видно, что 1 пакет данных (10 бод) передается за 1мс. Длительность 1 бода = 100мкс.

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

 

С другом собираемся поступить так:

Оцифрованный сигнал с микрофона будет записываться в буфер определенной длинны. Далее, будет алгоритм выборки из этого буфера.

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

Отсюда вопрос: а что если "щупать" всего один раз? То есть изначально устройства будут как-то синхронизироваться между собой, на приемнике будет высчитываться длительность импульса, длительность всего пакета, и исходя из расчетов будет корректироваться шаг выборки из буфера?

 

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

Изменено 20 января, 2012 пользователем Lost_Viking

[andrewkrot 0]

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

[Lost_Viking 0]

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

Насчет терминологии: http://www.iknowit.ru/words/word15766.html , ну и т.д. по википедии. Но речь не о бодах.

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

 

 

 

 

[ataradov 0]

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

[andrewkrot 0]

Насчет терминологии: http://www.iknowit.ru/words/word15766.html , ну и т.д. по википедии. Но речь не о бодах.

Все правильно там написано, а у Вас "Скорость передачи данных с микроконтроллера = 9600 бод/сек", т.е. скорость=скорость/время...

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

[Lost_Viking 0]

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

А разве не достаточно делать замеры по пикам? То есть просто смотрим на пики, и всё?

Кстати, если мне не изменяет память - я на микрофонный вход звуковухи подавал импульсы, и видел импульсы в программном осциллографе, который берет сигнал со звуковой карты. Или я что-то путаю??

Вот пример:

http://biorezonans.3bb.ru/viewtopic.php?id=43

 

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

[ataradov 0]

Вот пример:

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

 

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

 

 

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

[Lost_Viking 0]

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

 

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

 

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

:smile3046:

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

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

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

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

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

 

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

[ataradov 0]

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

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

 

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

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

 

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

[Lost_Viking 0]

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

Понятно

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

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

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

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

 

Вот, например, сайт хорошего проекта:

http://www.eecs.umich.edu/~prabal/projects/hijack/

 

Цитата:

Data. The HiJack communications layer offers two data transfer schemes. The first allows 300 baud data transfer using Bell 202 FSK signaling. The second offers 8.82 kbaud using a Manchester-encoded, direct-digital communication using hardware accelerators on the HiJack microcontroller and a software-defined, digital radio modulator/demodulator on the phone. The first scheme is described in the ISLPED'10 Design Contest entry (below). The second scheme is described in the DEV'10 paper below.

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

 

 

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

[ataradov 0]

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

 

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

 

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

[Lost_Viking 0]

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

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

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

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

 

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

 

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

 

 

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

 

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

Изменено 20 января, 2012 пользователем Lost_Viking

[Lost_Viking 0]

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

[jcxz 217]

Несколько лет назад делал радиомодем с примерно похожими требованиями к скорости передачи и полосе пропускания: 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руб в бук воткнуть.

[Lost_Viking 0]

Да - и для дуплекса нужна 4-проводка, а по 2-проводке - только полудуплекс.

Думаю - за годик командой при наличии свободного времени и желания можно уложиться ;)

 

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

 

Спасибо за подробный ответ.

Но мы остановились на манчестере. У нас пока нет задачи делать туда-сюда =)) Нам надо только с устройства в телефон передавать.

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

 

Если у кого есть соображения как старт/стоп (ну или разделитель между пакетами) лучше закодировать - буду рад их выслушать =)

Да, и еще. На осциллограме на телефоне видно, что импульс, пройдя через все тракты телефона, имеет затянутый фронт и срез. Можно ли это дело математикой поправить? Это оффтопик, по этому киньте ссылку плиз.

 

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

Изменено 10 февраля, 2012 пользователем Lost_Viking