Компания
416,72
рейтинг
27 мая 2015 в 14:50

Дизайн → О передаче данных через аудиоразъём перевод 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 получить конкурентные преимущества (например, отображение нескольких окон приложений одновременно и прочее).

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


Автор: @CooperMaster Liang Lee
Intel
рейтинг 416,72

Комментарии (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
                  Это не периодический сигнал, а дискретный.
                  • +1
                    *FACEPALM*
  • 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
                Не углядел, пардон =)
  • +1
    Пишется про ATIS, но на картинке написано CTIA.
  • +3
    Эм, простите за неуместный вопрос, а зачем это надо если все смартфоны идут с USB. Или я чего-то не понимаю?
    • +1
      Присоединяюсь. И с bluetooth.
      Единственная причина на мой взгляд это чтоб сделать универсальное устройство ios/android.
      • +1
        С блутусом всё понятно — питание.
    • +2
      Если не ошибаюсь, Apple в отличии от Google не позволяет кому угодно сделать USB аксессуары, которые могли бы обмениваться данными со своим приложением. Нужно получить одобрение и встраивать в каждое устройство их чип, который будет выполнять аутентификацию. Под личный DIY проект врядли возможно это сделать.
      • +1
        Это и под вполне себе коммерческий проект сделать не просто.
        • +1
          Только религия позволяет терпеть такое надругательство над здравым смыслом )
    • +2
      Про себестоимость не понимаете. Реализация через разъём наушников — грошовая, в отличие от USB host / bluetooth.

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

Самое читаемое Дизайн