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



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

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


Комментарии (63)


  1. Klukonin
    27.05.2015 15:17
    +2

    А зачем именно FSK?

    Странный у него выбор.


    1. GAS_85
      27.05.2015 16:07
      +3

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


      1. Klukonin
        27.05.2015 16:21
        +4

        На таком кабеле можно вообще спокойно делать фул дуплекс канал. =)
        Самым простым вариантом было бы манчестерское кодирование. Я все равно не вижу смысла заморачиваться с FSK. кодирование ->Модуляция >-Демодуляция >-Декодирование. Зачем? Когда можно обойтись простым NRZI и не модулировать.
        UART на 9600 спокойно потянет самый говенный DAC.
        Что-то я не понимаю в этой жизни…


        1. GAS_85
          27.05.2015 16:41
          +3

          Сейчас мы начнем углубляться в теорему Котельникова и то что импульсы требуют бОльший спектр, но детишки балуются термометром и мигающим диодиком (хотя и Университет в Мичигане) и критиковать такое я бы не стал. Как говорится, чем бы дитя не тешилось, лишь бы лоб не разбило.


          1. imwode
            27.05.2015 17:04
            +5

            А давайте углубимся, хабр торт или не торт?


            1. GAS_85
              27.05.2015 17:35
              +1

              Про теорему Котельникова это я махнул, тут же ребята передают по аналоговому сигналу цифровой, а не наоборот.
              Я не совсем понял почему они опираются на аналоговый сигнал и на синусоиду, видать были причины — аудио кабель не подходит для чистых цифровых сигналов, или, что вероятнее, они передают его как опорный сигнал, чтоб максимально упростить внешнее plug and pray устройство — ему нужно только играть на несущем сигнале и появляется возможность какого-то базового питания от телефона.

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

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

              Таким образом «кодирование ->Модуляция >-Демодуляция >-Декодирование» тут нужно чтоб использовать уже имеющийся девайс и писать только программу для декодирования, а не впаивать включать в цепь UARTы, а как следствие — упрощение схемы.


              1. imwode
                27.05.2015 18:00
                +3

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


                1. imwode
                  27.05.2015 18:03
                  +3

                  «Цифровой сигнал» — это сумма синусоид.

                  image
                  Блин, периодический сигнал. Когда уже научусь не писать камменты на хабре, неуч же


                  1. GAS_85
                    28.05.2015 11:32
                    +1

                    Да, это все замечательно, но при этом значительно увеличиваются требования к ширине спектра и качеству кабеля, как и приемника/передатчика, а софт должен анализировать более широкий спектр т.е. или уменьшаем полосу пропускания --> увеличением длины импульса, или имеем мееееедленную и неэффективную систему. Этого всего можно избежать, воспользовавшись простой частотной модуляцией. Как я понимаю цель — сделать оборудование для существующего смартфона без изменений последнего --> модуляция must have. Почитайте про передачу сигналов в радио (быстрое гугление) никто не пихает туда импульсы — это неэффективно, а также жестоко и бесполезно.


                    1. dmitrmax
                      28.05.2015 14:00
                      +1

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


              1. stychos
                28.05.2015 15:15
                +2

                Plug-and-Pray — это надо запомнить :-)


        1. dmitrmax
          27.05.2015 23:21
          +2

          Даешь OFDM!


          1. Klukonin
            28.05.2015 07:11
            +1

            На таком кабеле? )))
            Может что-то и получится. Но я бы не стал)


            1. dmitrmax
              28.05.2015 09:00
              +1

              Кабель-то тут каким боком вам мешает?

              Я бы больше боялся за аналоговый тракт, чтобы он там не попортил ничего.


          1. alk0v
            29.05.2015 14:10
            +1

            Ну OFDM тут, пожалуй, не нужен, а вот если скорось понадобится поболее, QAM-64 или даже QAM-256 должен работать, исходники модулятора и демодулятора можно из GNU-Radio взять.


        1. ZloAlien
          28.05.2015 11:28

          На выходе ЦАП смартфора стоит конденсатор (или другой фильтр). Попробуйте записать аудиофайл с переходом 0->1 и воспроизвести его, при этом измеряя выходное напряжение осциллографом. Получите скачёк напряжения в сам момент перехода, но через доли секунды напряжение снова вернётся в ноль.


          1. Klukonin
            28.05.2015 13:45
            +2

            КЭП?

            Речь идет о несущей частоте 9600 Гц=)


            1. ZloAlien
              28.05.2015 13:58

              Насколько я понял, имеется в виду частота дискретизации, а не несущая. Если дискретизации, то всё будет неплохо при попытке передачи последовательностей вида 010101, но станет плохо при попытке передать 00000 или 11111.


              1. Klukonin
                28.05.2015 14:04
                +1

                ШТА?!

                UART c baud rate 9600 это периодический сигнал. С периодом в 104 микросекунды.
                При чем тут частота дискретизации?


                1. ZloAlien
                  28.05.2015 14:06

                  Это не периодический сигнал, а дискретный.


                  1. Klukonin
                    28.05.2015 14:11
                    +1

                    *FACEPALM*


  1. LeshiyUrban
    27.05.2015 15:27

    Просто и гениально


  1. ntfs1984
    27.05.2015 15:58
    +32

    Статья может быть новостью только для школьников.

    Остальных передачей данных через аудиоразъем не удивить,
    ибо мы не понаслышке знакомы с R Type loading error ЭТИМ:
    image


    1. qw1
      27.05.2015 16:46
      +6

      Tape


      1. ntfs1984
        27.05.2015 18:04
        +2

        Виноват, это было 20 лет назад.


    1. Ivan_83
      27.05.2015 20:05
      +1

      Был ещё и спекртум и пр.
      Но последний раз я лет 10 назад передавал данные звуком — пользовался интернетом через диалап.

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

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


      1. ntfs1984
        27.05.2015 20:30

        Киллер-фича должна быть не в этом, а именно в универсальности этого разъема.
        Его почти невозможно сломать, легко перепаивать, его нельзя вставить другой стороной, и можно подавать весьма мощный ток при желании.

        Звуком передавать незачем, сильно медленно. Если снизить частоту того, что передается по USB — тоже получится звук.


        1. FYR
          28.05.2015 12:35
          +2

          Киллер фича тут только в одном — в политике Apple в области разработки USB устройств/аксессуаров.
          Передавать цифровой сигнал по аналоговой системе это из области 80-90х, еще и при наличии доступных цифровых каналов для подключения перефирии — это костыль для обхода всяких патентных других искуственных ограничений.


      1. Daemon_Hell
        28.05.2015 07:28
        +3

        Телефонная линия еще имела искусственное ограничение в виде фильтрации ВЧ.


        1. mayorovp
          28.05.2015 09:26
          +1

          Аудиотракт тракт тоже имеет подобное ограничение.


          1. w0lf
            28.05.2015 10:35
            +1

            Ну не 0.3...3.4 кГц же, как линия тональной частоты, применяемая в телефонии. ФВЧ если и есть то минимум на 22 кГц.


            1. mayorovp
              28.05.2015 10:58
              +1

              Разумеется, диапазон шире. Но и мегабиты все равно никак не передать.


  1. uuuulala
    27.05.2015 16:06
    +1

    Хотелось бы попросить автора статьи немного «причесать» перевод, смысл абзаца «Как извлечь энергию звуковых сигналов» уловить трудновато, это отвлекает от сути статьи) Спасибо!


  1. spot62
    27.05.2015 16:19
    +1

    зачем через аудиокабель? даешь wireless через микрофон!)


    1. ntfs1984
      27.05.2015 16:30
      +3

      Собственно wireless через микрофон я делал в порядке эксперимента.

      Arduino + пьезодинамик + пару деталей, на компе микрофон и программка на С++ — принимало на компе то, что я выводил в UART Ардуины. Нефункционально, но прикольно. А если бы перейти на ультразвук, то вообще отпадно…


  1. Byteman
    27.05.2015 16:41
    +4

    А теперь все дружно вспомним старый добрый ZX Spectrum и Радио-86РК :)


  1. cher11
    27.05.2015 16:41
    +4

    image
    Печальная картинка, на самом деле. Столько раз было, что вставляешь наушники нокии в айфон — не работают, наоборот — жутко фонят. И ладно бы веская причина была, так нет, всего-то два контакта местами поменять…


    1. GAS_85
      27.05.2015 16:48

      Вы не поверите, но в Америке и «метры» с «литрами» не такие как у нас… Всегда отличаться — вот их девиз.


      1. yosemity
        27.05.2015 17:02
        +7

        А еще они там ходят вниз головой :)


      1. dmitrmax
        28.05.2015 14:15
        +3

        «А в Европе четверьфунтовый чизбургер называется 'рояль с сыром', потому что у них метрическая система» )


    1. k0ldbl00d
      27.05.2015 17:32
      +1

      Возможно, вот такой вариант подойдёт?


      1. k0ldbl00d
        27.05.2015 17:33
        +1

        Упс… немножко ошибся пока рисовал, но смысл я думаю ясен.


  1. eboyko
    27.05.2015 17:19
    +2

    Где этот рассказ был полтора года назад, когда я пытался понять как работает Jawbone :-) Спасибо.


  1. lopatoid
    27.05.2015 23:02
    +1

    А меня вопрос от новичка: а можно просто какой-то постоянный ток вывести через аудиоразьём? Не синусоиду, а чтобы там был 1 вольт, например.


    1. Tios
      27.05.2015 23:25
      +1

      Преобразовать переменный в постонный ток? Очень просто — диодный мост. Если не боитесь спалить, конечно.


      1. lopatoid
        27.05.2015 23:34
        +1

        То есть постоянный всё-таки нельзя без всяких диодов вывести?


        1. Tios
          28.05.2015 18:21
          +1

          Обычно после оконечного каскада усилителя ставится низкочастотный фильтр в виде конденсатора, которые обрезает частоты ниже 5гц (по разному). Одно из свойст конденсатора — пускать переменный ток и не пускать постоянный. Так что, если, чисто теоритически, Вы воспроизведете через устройство сигнал с максимальной амплитудой и частотой = 0Гц, фильтр все равно зарежет его. Если же фильтра нет, у Вас есть все шансы спалить оконечник.


      1. MacIn
        28.05.2015 05:36
        +3

        … и конденсатор, иначе постоянного не получится.


    1. Zuy
      27.05.2015 23:44
      +3

      Если после DAC внутри телефона стоят разделительные конденсаторы то нельзя, если их нет, то можно. Но чтобы не гадать, как там внутри реализован выход, надежней вывести синус и выпрямить, таким способом будет работать везде.
      Некоторые реализации так вообще всегда имеют небольшую постоянку на выходе.


      1. Klukonin
        28.05.2015 07:09
        +1

        Разве на частоте 9600 эти конденсаторы окажут существенное влияние?


        1. Zuy
          28.05.2015 07:16
          +1

          Не совсем понял, влияния на что и причем тут частота 9600?
          Вопрос был в том, можно ли через аудиоразьем выдать постоянное напряжение.


          1. Klukonin
            28.05.2015 08:20
            +1

            RC фильтр.

            А нам не нужно постоянное, у нас вполне себе периодический сигнал. С частотой 9600 Гц.


            1. Zuy
              28.05.2015 08:35
              +1

              Это все безумно интересно, но только как оно касается текущей ветки, которая началась с вопроса пользователя Lopatoid о получении постоянного напряжения напрямую на аудиоразьеме?
              Про непостоянное вроде как выше обсуждается.


              1. Klukonin
                28.05.2015 08:53
                +1

                Не углядел, пардон =)


  1. DjOnline
    28.05.2015 01:03
    +1

    Пишется про ATIS, но на картинке написано CTIA.


  1. TelnovOleg
    28.05.2015 06:15
    +3

    Эм, простите за неуместный вопрос, а зачем это надо если все смартфоны идут с USB. Или я чего-то не понимаю?


    1. some_x
      28.05.2015 06:52
      +1

      Присоединяюсь. И с bluetooth.
      Единственная причина на мой взгляд это чтоб сделать универсальное устройство ios/android.


      1. dmitrmax
        28.05.2015 14:17
        +1

        С блутусом всё понятно — питание.


    1. Zuy
      28.05.2015 06:55
      +2

      Если не ошибаюсь, Apple в отличии от Google не позволяет кому угодно сделать USB аксессуары, которые могли бы обмениваться данными со своим приложением. Нужно получить одобрение и встраивать в каждое устройство их чип, который будет выполнять аутентификацию. Под личный DIY проект врядли возможно это сделать.


      1. FYR
        28.05.2015 12:44
        +1

        Это и под вполне себе коммерческий проект сделать не просто.


        1. dmitrmax
          28.05.2015 14:18
          +1

          Только религия позволяет терпеть такое надругательство над здравым смыслом )


    1. bougakov
      28.05.2015 13:12
      +2

      Про себестоимость не понимаете. Реализация через разъём наушников — грошовая, в отличие от USB host / bluetooth.