company_banner

О передаче данных через аудиоразъём

https://software.intel.com/en-us/articles/using-the-audio-jack-as-data-interface-on-android-systems
  • Перевод
  • Tutorial
Одним из важных интерфейсов на мобильных устройствах и планшетных компьютерах является разъём для наушников/микрофона. Однако не стоит думать, что он предназначен только для колонок-наушников-микрофона – его можно использовать в том числе для передачи данных. Об этом сегодня и поговорим.



Альтернативные способы использования звукового разъёма для подключения сторонних устройств постоянно обновляются. Периферийные устройства, например, глюкометр iHealth Lab (определяющий уровень сахара в крови), Irdroid – ИК-пульт для дистанционного управления телевизором, приставками и звуковыми компонентами и Flojack – устройство чтения NFC (организующее радиосвязь между находящимися рядом мобильными устройствами) – всё это стало возможным благодаря наличию звукового разъёма.

Поскольку рынок мобильных и периферийных устройств имеет большое число потенциальных клиентов, я считаю, что разъём для наушников будет основным портом для передачи информации в скором времени. В этой статье я подробнее расскажу о данной функции.

Введение


Интерфейс звукового разъёма имеет два стандарта: OMTP и CTIA. OMTP – это международный стандарт; ATIS – Американский стандарт, используемый в таких устройствах как Apple iPhone и iPad. Они отличаются V-микрофоном, а также расположением заземления; отличия показаны ниже:

image
OMTP и CTIA

Как передаются данные


Когда мы отправляем 0x00FF данных, первый шаг – это преобразование цифровых данных в аналоговые. Поэтому нужно модулировать значение данных. Как правило, для этого используется синусоидальный носитель волн для аналогового сигнала.

image
FSK-модуляция сигнала

Второй шаг в устройствах Android – обращение к audioTrack API – функции, используемой для проигрывания. Следующий код отправляет данные в буфер, используя для этого функцию audioTrack.

public void send(byte[] bytes_pkg) {
        int bufsize = AudioTrack.getMinBufferSize(8000,
                AudioFormat.CHANNEL_OUT_MONO,
                AudioFormat.ENCODING_PCM_16BIT);
        AudioTrack trackplayer = new AudioTrack(AudioManager.STREAM_MUSIC,
                8000, AudioFormat.CHANNEL_OUT_MONO,
                AudioFormat.ENCODING_PCM_16BIT, bufsize, 
AudioTrack.MODE_STREAM);
        trackplayer.play();
        trackplayer.write(bytes_pkg, 0, bytes_pkg.length);
    }

Получение данных


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

image
Демодуляция сигнала

В системах с ОС Android мы используем функцию audioRecord API записи звука:

public void receive(){
		int minBufferSize = AudioRecord.getMinBufferSize(AUDIO_SAMPLE_FREQ, 2,
				AudioFormat.ENCODING_PCM_16BIT);
		AudioRecord ar = new AudioRecord(MediaRecorder.AudioSource.MIC,
				AUDIO_SAMPLE_FREQ, AudioFormat.CHANNEL_IN_MONO,
				AudioFormat.ENCODING_PCM_16BIT, minBufferSize);
		ar.startRecording();
	   }

Как извлечь энергию звуковых сигналов


Очевидно, что для накопления на цепи питания для периферийных устройств требуется определённая мощность. Например, L-канал передаёт данные. R-канал отправляет устойчивый квадрат или синус сигнала. Эти сигналы могут быть преобразованы MCU (блок контроллеров Micro) и несколькими датчиками.

История успеха: ИК периферийные устройства


Androlirc – это проект на базе Github. Его функции можно использовать для отправки в приложение инфракрасного интерфейса звукового разъёма. Можно изучить этот проект для понимания процесса обмена данными через звуковой разъём. Androlirc использует LIRC-библиотеку для создания записи в буфере данных. Данная библиотека является ИК-библиотекой под Linux, которая поддерживает несколько типов интерфейсов, например USB, звуковой разъём и т.д. Androlirc позволяет использовать библиотеку LIRC для накопления данных. На рынке вы можете найти множество инфракрасных кодирующих типов, таких как протоколы RC-5 и RC-6. В приведённом примере мы используем протокол RC-5 для управления телевизором. Во-первых, мы должны модулировать значение данных с использованием 38k синусоидальныого сигнала, чтобы генерировать данные буфера. Затем мы используем Android audio API для воспроизведения звука из буфера данных. В то же время мы используем один из двух каналов для воспроизведения синуса или квадратного сигнала питания на оборудовании периферийных устройств.

История успеха: звуковой разъём для разработчиков


Новое решение от NXP Semiconductors, Quick-Jack – устройство на базе прототипа под названием Hijack. Hijack – это проект студентов университета Мичиган. Платформа Hijack позволяет создавать новый класс компактных, дешёвых, ориентированных на телефон датчиков периферийных устройств с поддержкой операций plug-and-play. Можно использовать платы NXP Quick-Jack для создания прототипа.

Ниже показан смартфон, отображающий температуру внутри помещения с помощью температурного датчика на базе аудиоразъёма. Через него же осуществляется управление светодиодным индикатором периферийных устройств с помощью приложения на базе ОС Android.

image image
Значение температуры, полученное с помощью Quick-Jack; через него же осуществляется управление светодиодным индикатором

Сводная информация


Носимые устройства с возможностью подключения периферии всё чаще появляются на потребительском рынке. Звуковой разъём как функция для передачи данных используется ODM-производителями всё активнее. Возможно, в будущем функция передачи данных через этот разъём будет поддерживаться мобильными ОС по умолчанию.

Об авторе


Лианг Ли получил степень магистра в области изучения сигналов и обработки данных в технологическом университете Changchun. Он пришел в корпорацию Intel в 2013 г. как Android-инженер в китайском подразделении. Сейчас он занимается созданием функций, которые бы позволили Android получить конкурентные преимущества (например, отображение нескольких окон приложений одновременно и прочее).

Ссылки по теме


Метки:
Intel 140,51
Компания
Поделиться публикацией
Комментарии 63
  • +2
    А зачем именно FSK?

    Странный у него выбор.
    • +3
      Легче генерировать, чем сдвиг фаз. Помехоустойчивости в таком кротком кабеле достаточно для безболезненного использования.
      • +4
        На таком кабеле можно вообще спокойно делать фул дуплекс канал. =)
        Самым простым вариантом было бы манчестерское кодирование. Я все равно не вижу смысла заморачиваться с FSK. кодирование ->Модуляция >-Демодуляция >-Декодирование. Зачем? Когда можно обойтись простым NRZI и не модулировать.
        UART на 9600 спокойно потянет самый говенный DAC.
        Что-то я не понимаю в этой жизни…
        • +3
          Сейчас мы начнем углубляться в теорему Котельникова и то что импульсы требуют бОльший спектр, но детишки балуются термометром и мигающим диодиком (хотя и Университет в Мичигане) и критиковать такое я бы не стал. Как говорится, чем бы дитя не тешилось, лишь бы лоб не разбило.
          • +5
            А давайте углубимся, хабр торт или не торт?
            • +1
              Про теорему Котельникова это я махнул, тут же ребята передают по аналоговому сигналу цифровой, а не наоборот.
              Я не совсем понял почему они опираются на аналоговый сигнал и на синусоиду, видать были причины — аудио кабель не подходит для чистых цифровых сигналов, или, что вероятнее, они передают его как опорный сигнал, чтоб максимально упростить внешнее plug and pray устройство — ему нужно только играть на несущем сигнале и появляется возможность какого-то базового питания от телефона.

              Совершенно согласен что манчестерское кодирование отлично подошло бы, но тут пока не встала проблема скорости передачи данных, а значит и эффективного использования спектра. Чтоб передать температуру и управляющий код диода пары бод будет за глаза.

              Потом, написать программу которая смотрит на сдвиг частоты влево-вправо гораздо легче, чем детектировать и обрабатывать сдвиг фаз. Ещё это и более помехоустойчивое решение относительно амплитудной модуляции, не говоря про то что энергоэффективность будет в данном случае выше (меньше расход батареи).

              Таким образом «кодирование ->Модуляция >-Демодуляция >-Декодирование» тут нужно чтоб использовать уже имеющийся девайс и писать только программу для декодирования, а не впаивать включать в цепь UARTы, а как следствие — упрощение схемы.
              • +3
                Аудио кабель прекрасно подходит для цифровых сигналов, хотя в природе их не существует. «Цифровой сигнал» — это сумма синусоид. Не помню точно, но уже при сложении пятка что ли синусоид правильной частоты сигнал выглядит вполне себе цифровым. Но дело не в этом. Дело в том, что этот аудио кабель они пихают в аудио разьем какого-нибудь айфона. Соответственно все, что они могут сделать — это подать некий звуковой сигнал на выход. И в этот некий звуковой сигнал надо зашить данные.
                Почитать статью что ли, мож я вообще не про это.
                • +3
                  «Цифровой сигнал» — это сумма синусоид.

                  image
                  Блин, периодический сигнал. Когда уже научусь не писать камменты на хабре, неуч же
                  • +1
                    Да, это все замечательно, но при этом значительно увеличиваются требования к ширине спектра и качеству кабеля, как и приемника/передатчика, а софт должен анализировать более широкий спектр т.е. или уменьшаем полосу пропускания --> увеличением длины импульса, или имеем мееееедленную и неэффективную систему. Этого всего можно избежать, воспользовавшись простой частотной модуляцией. Как я понимаю цель — сделать оборудование для существующего смартфона без изменений последнего --> модуляция must have. Почитайте про передачу сигналов в радио (быстрое гугление) никто не пихает туда импульсы — это неэффективно, а также жестоко и бесполезно.
                    • +1
                      Вопрос в целеполагании. Если задача связать хоть как-то, уменьшить вычислительную нагрузку, то да. Если стоит задача выжать максимум, организовать совместный доступ к среде, то подход меняется кардинально.
                • +2
                  Plug-and-Pray — это надо запомнить :-)
            • +2
              Даешь OFDM!
              • +1
                На таком кабеле? )))
                Может что-то и получится. Но я бы не стал)
                • +1
                  Кабель-то тут каким боком вам мешает?

                  Я бы больше боялся за аналоговый тракт, чтобы он там не попортил ничего.
                • +1
                  Ну OFDM тут, пожалуй, не нужен, а вот если скорось понадобится поболее, QAM-64 или даже QAM-256 должен работать, исходники модулятора и демодулятора можно из GNU-Radio взять.
                • 0
                  На выходе ЦАП смартфора стоит конденсатор (или другой фильтр). Попробуйте записать аудиофайл с переходом 0->1 и воспроизвести его, при этом измеряя выходное напряжение осциллографом. Получите скачёк напряжения в сам момент перехода, но через доли секунды напряжение снова вернётся в ноль.
                  • +2
                    КЭП?

                    Речь идет о несущей частоте 9600 Гц=)
                    • 0
                      Насколько я понял, имеется в виду частота дискретизации, а не несущая. Если дискретизации, то всё будет неплохо при попытке передачи последовательностей вида 010101, но станет плохо при попытке передать 00000 или 11111.
                      • +1
                        ШТА?!

                        UART c baud rate 9600 это периодический сигнал. С периодом в 104 микросекунды.
                        При чем тут частота дискретизации?
                        • 0
                          Это не периодический сигнал, а дискретный.
          • 0
            Просто и гениально
            • НЛО прилетело и опубликовало эту надпись здесь
              • +6
                Tape
                • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Был ещё и спекртум и пр.
                  Но последний раз я лет 10 назад передавал данные звуком — пользовался интернетом через диалап.

                  Отсюда примерно можно понять какие максимальные скорости можно ожидать на практике от такой передачи: 33600 и выше, те 4-8 килобайт/сек на практике. Вероятно даже выше, всё таки «линия» тут практически идеальная, в сравнении с телефонной лапшой в нашей стране.

                  Однако экономика подсказывает что это не эффективно: для скорости лучше блютус или вайфай задействовать, по деньгам, наверное, получится не хуже, чем достраивать приличный аудиотракт и кодить передачу.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +2
                      Киллер фича тут только в одном — в политике Apple в области разработки USB устройств/аксессуаров.
                      Передавать цифровой сигнал по аналоговой системе это из области 80-90х, еще и при наличии доступных цифровых каналов для подключения перефирии — это костыль для обхода всяких патентных других искуственных ограничений.
                    • +3
                      Телефонная линия еще имела искусственное ограничение в виде фильтрации ВЧ.
                      • +1
                        Аудиотракт тракт тоже имеет подобное ограничение.
                        • +1
                          Ну не 0.3...3.4 кГц же, как линия тональной частоты, применяемая в телефонии. ФВЧ если и есть то минимум на 22 кГц.
                          • +1
                            Разумеется, диапазон шире. Но и мегабиты все равно никак не передать.
                  • +1
                    Хотелось бы попросить автора статьи немного «причесать» перевод, смысл абзаца «Как извлечь энергию звуковых сигналов» уловить трудновато, это отвлекает от сути статьи) Спасибо!
                    • +1
                      зачем через аудиокабель? даешь wireless через микрофон!)
                      • НЛО прилетело и опубликовало эту надпись здесь
                      • +4
                        А теперь все дружно вспомним старый добрый ZX Spectrum и Радио-86РК :)
                        • +4
                          image
                          Печальная картинка, на самом деле. Столько раз было, что вставляешь наушники нокии в айфон — не работают, наоборот — жутко фонят. И ладно бы веская причина была, так нет, всего-то два контакта местами поменять…
                          • 0
                            Вы не поверите, но в Америке и «метры» с «литрами» не такие как у нас… Всегда отличаться — вот их девиз.
                            • +7
                              А еще они там ходят вниз головой :)
                              • 0
                                Не, это вы с Австралией перепутали.
                              • +3
                                «А в Европе четверьфунтовый чизбургер называется 'рояль с сыром', потому что у них метрическая система» )
                              • +1
                                Возможно, вот такой вариант подойдёт?
                                • +1
                                  Упс… немножко ошибся пока рисовал, но смысл я думаю ясен.
                              • +2
                                Где этот рассказ был полтора года назад, когда я пытался понять как работает Jawbone :-) Спасибо.
                                • +1
                                  А меня вопрос от новичка: а можно просто какой-то постоянный ток вывести через аудиоразьём? Не синусоиду, а чтобы там был 1 вольт, например.
                                  • +1
                                    Преобразовать переменный в постонный ток? Очень просто — диодный мост. Если не боитесь спалить, конечно.
                                    • +1
                                      То есть постоянный всё-таки нельзя без всяких диодов вывести?
                                      • +1
                                        Обычно после оконечного каскада усилителя ставится низкочастотный фильтр в виде конденсатора, которые обрезает частоты ниже 5гц (по разному). Одно из свойст конденсатора — пускать переменный ток и не пускать постоянный. Так что, если, чисто теоритически, Вы воспроизведете через устройство сигнал с максимальной амплитудой и частотой = 0Гц, фильтр все равно зарежет его. Если же фильтра нет, у Вас есть все шансы спалить оконечник.
                                      • +3
                                        … и конденсатор, иначе постоянного не получится.
                                      • +3
                                        Если после DAC внутри телефона стоят разделительные конденсаторы то нельзя, если их нет, то можно. Но чтобы не гадать, как там внутри реализован выход, надежней вывести синус и выпрямить, таким способом будет работать везде.
                                        Некоторые реализации так вообще всегда имеют небольшую постоянку на выходе.
                                        • +1
                                          Разве на частоте 9600 эти конденсаторы окажут существенное влияние?
                                          • +1
                                            Не совсем понял, влияния на что и причем тут частота 9600?
                                            Вопрос был в том, можно ли через аудиоразьем выдать постоянное напряжение.
                                            • +1
                                              RC фильтр.

                                              А нам не нужно постоянное, у нас вполне себе периодический сигнал. С частотой 9600 Гц.
                                              • +1
                                                Это все безумно интересно, но только как оно касается текущей ветки, которая началась с вопроса пользователя Lopatoid о получении постоянного напряжения напрямую на аудиоразьеме?
                                                Про непостоянное вроде как выше обсуждается.
                                    • +1
                                      Пишется про ATIS, но на картинке написано CTIA.
                                      • +3
                                        Эм, простите за неуместный вопрос, а зачем это надо если все смартфоны идут с USB. Или я чего-то не понимаю?
                                        • +1
                                          Присоединяюсь. И с bluetooth.
                                          Единственная причина на мой взгляд это чтоб сделать универсальное устройство ios/android.
                                          • +1
                                            С блутусом всё понятно — питание.
                                          • +2
                                            Если не ошибаюсь, Apple в отличии от Google не позволяет кому угодно сделать USB аксессуары, которые могли бы обмениваться данными со своим приложением. Нужно получить одобрение и встраивать в каждое устройство их чип, который будет выполнять аутентификацию. Под личный DIY проект врядли возможно это сделать.
                                            • +1
                                              Это и под вполне себе коммерческий проект сделать не просто.
                                              • +1
                                                Только религия позволяет терпеть такое надругательство над здравым смыслом )
                                            • +2
                                              Про себестоимость не понимаете. Реализация через разъём наушников — грошовая, в отличие от USB host / bluetooth.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое