Альтернативные способы использования звукового разъёма для подключения сторонних устройств постоянно обновляются. Периферийные устройства, например, глюкометр iHealth Lab (определяющий уровень сахара в крови), Irdroid – ИК-пульт для дистанционного управления телевизором, приставками и звуковыми компонентами и Flojack – устройство чтения NFC (организующее радиосвязь между находящимися рядом мобильными устройствами) – всё это стало возможным благодаря наличию звукового разъёма.
Поскольку рынок мобильных и периферийных устройств имеет большое число потенциальных клиентов, я считаю, что разъём для наушников будет основным портом для передачи информации в скором времени. В этой статье я подробнее расскажу о данной функции.
Введение
Интерфейс звукового разъёма имеет два стандарта: OMTP и CTIA. OMTP – это международный стандарт; ATIS – Американский стандарт, используемый в таких устройствах как Apple iPhone и iPad. Они отличаются V-микрофоном, а также расположением заземления; отличия показаны ниже:
OMTP и CTIA
Как передаются данные
Когда мы отправляем 0x00FF данных, первый шаг – это преобразование цифровых данных в аналоговые. Поэтому нужно модулировать значение данных. Как правило, для этого используется синусоидальный носитель волн для аналогового сигнала.
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);
}
Получение данных
В приёмнике необходимо перевести аналоговый сигнал в значение данных, демодулировать сигнал, чтобы удалить входящий сигнал, и декодировать данные в соответствии с протоколом. Протокол может быть в формате общедоступных данных или частных.
Демодуляция сигнала
В системах с ОС 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.
Значение температуры, полученное с помощью Quick-Jack; через него же осуществляется управление светодиодным индикатором
Сводная информация
Носимые устройства с возможностью подключения периферии всё чаще появляются на потребительском рынке. Звуковой разъём как функция для передачи данных используется ODM-производителями всё активнее. Возможно, в будущем функция передачи данных через этот разъём будет поддерживаться мобильными ОС по умолчанию.
Об авторе
Лианг Ли получил степень магистра в области изучения сигналов и обработки данных в технологическом университете Changchun. Он пришел в корпорацию Intel в 2013 г. как Android-инженер в китайском подразделении. Сейчас он занимается созданием функций, которые бы позволили Android получить конкурентные преимущества (например, отображение нескольких окон приложений одновременно и прочее).
Ссылки по теме
Комментарии (63)
ntfs1984
27.05.2015 15:58+32Статья может быть новостью только для школьников.
Остальных передачей данных через аудиоразъем не удивить,
ибо мы не понаслышке знакомы сR Type loading errorЭТИМ:
Ivan_83
27.05.2015 20:05+1Был ещё и спекртум и пр.
Но последний раз я лет 10 назад передавал данные звуком — пользовался интернетом через диалап.
Отсюда примерно можно понять какие максимальные скорости можно ожидать на практике от такой передачи: 33600 и выше, те 4-8 килобайт/сек на практике. Вероятно даже выше, всё таки «линия» тут практически идеальная, в сравнении с телефонной лапшой в нашей стране.
Однако экономика подсказывает что это не эффективно: для скорости лучше блютус или вайфай задействовать, по деньгам, наверное, получится не хуже, чем достраивать приличный аудиотракт и кодить передачу.ntfs1984
27.05.2015 20:30Киллер-фича должна быть не в этом, а именно в универсальности этого разъема.
Его почти невозможно сломать, легко перепаивать, его нельзя вставить другой стороной, и можно подавать весьма мощный ток при желании.
Звуком передавать незачем, сильно медленно. Если снизить частоту того, что передается по USB — тоже получится звук.FYR
28.05.2015 12:35+2Киллер фича тут только в одном — в политике Apple в области разработки USB устройств/аксессуаров.
Передавать цифровой сигнал по аналоговой системе это из области 80-90х, еще и при наличии доступных цифровых каналов для подключения перефирии — это костыль для обхода всяких патентных других искуственных ограничений.
Daemon_Hell
28.05.2015 07:28+3Телефонная линия еще имела искусственное ограничение в виде фильтрации ВЧ.
uuuulala
27.05.2015 16:06+1Хотелось бы попросить автора статьи немного «причесать» перевод, смысл абзаца «Как извлечь энергию звуковых сигналов» уловить трудновато, это отвлекает от сути статьи) Спасибо!
spot62
27.05.2015 16:19+1зачем через аудиокабель? даешь wireless через микрофон!)
ntfs1984
27.05.2015 16:30+3Собственно wireless через микрофон я делал в порядке эксперимента.
Arduino + пьезодинамик + пару деталей, на компе микрофон и программка на С++ — принимало на компе то, что я выводил в UART Ардуины. Нефункционально, но прикольно. А если бы перейти на ультразвук, то вообще отпадно…
cher11
27.05.2015 16:41+4
Печальная картинка, на самом деле. Столько раз было, что вставляешь наушники нокии в айфон — не работают, наоборот — жутко фонят. И ладно бы веская причина была, так нет, всего-то два контакта местами поменять…
eboyko
27.05.2015 17:19+2Где этот рассказ был полтора года назад, когда я пытался понять как работает Jawbone :-) Спасибо.
lopatoid
27.05.2015 23:02+1А меня вопрос от новичка: а можно просто какой-то постоянный ток вывести через аудиоразьём? Не синусоиду, а чтобы там был 1 вольт, например.
Tios
27.05.2015 23:25+1Преобразовать переменный в постонный ток? Очень просто — диодный мост. Если не боитесь спалить, конечно.
lopatoid
27.05.2015 23:34+1То есть постоянный всё-таки нельзя без всяких диодов вывести?
Tios
28.05.2015 18:21+1Обычно после оконечного каскада усилителя ставится низкочастотный фильтр в виде конденсатора, которые обрезает частоты ниже 5гц (по разному). Одно из свойст конденсатора — пускать переменный ток и не пускать постоянный. Так что, если, чисто теоритически, Вы воспроизведете через устройство сигнал с максимальной амплитудой и частотой = 0Гц, фильтр все равно зарежет его. Если же фильтра нет, у Вас есть все шансы спалить оконечник.
Zuy
27.05.2015 23:44+3Если после DAC внутри телефона стоят разделительные конденсаторы то нельзя, если их нет, то можно. Но чтобы не гадать, как там внутри реализован выход, надежней вывести синус и выпрямить, таким способом будет работать везде.
Некоторые реализации так вообще всегда имеют небольшую постоянку на выходе.
TelnovOleg
28.05.2015 06:15+3Эм, простите за неуместный вопрос, а зачем это надо если все смартфоны идут с USB. Или я чего-то не понимаю?
Zuy
28.05.2015 06:55+2Если не ошибаюсь, Apple в отличии от Google не позволяет кому угодно сделать USB аксессуары, которые могли бы обмениваться данными со своим приложением. Нужно получить одобрение и встраивать в каждое устройство их чип, который будет выполнять аутентификацию. Под личный DIY проект врядли возможно это сделать.
bougakov
28.05.2015 13:12+2Про себестоимость не понимаете. Реализация через разъём наушников — грошовая, в отличие от USB host / bluetooth.
Klukonin
А зачем именно FSK?
Странный у него выбор.
GAS_85
Легче генерировать, чем сдвиг фаз. Помехоустойчивости в таком кротком кабеле достаточно для безболезненного использования.
Klukonin
На таком кабеле можно вообще спокойно делать фул дуплекс канал. =)
Самым простым вариантом было бы манчестерское кодирование. Я все равно не вижу смысла заморачиваться с FSK. кодирование ->Модуляция >-Демодуляция >-Декодирование. Зачем? Когда можно обойтись простым NRZI и не модулировать.
UART на 9600 спокойно потянет самый говенный DAC.
Что-то я не понимаю в этой жизни…
GAS_85
Сейчас мы начнем углубляться в теорему Котельникова и то что импульсы требуют бОльший спектр, но детишки балуются термометром и мигающим диодиком (хотя и Университет в Мичигане) и критиковать такое я бы не стал. Как говорится, чем бы дитя не тешилось, лишь бы лоб не разбило.
imwode
А давайте углубимся, хабр торт или не торт?
GAS_85
Про теорему Котельникова это я махнул, тут же ребята передают по аналоговому сигналу цифровой, а не наоборот.
Я не совсем понял почему они опираются на аналоговый сигнал и на синусоиду, видать были причины — аудио кабель не подходит для чистых цифровых сигналов, или, что вероятнее, они передают его как опорный сигнал, чтоб максимально упростить внешнее plug and pray устройство — ему нужно только играть на несущем сигнале и появляется возможность какого-то базового питания от телефона.
Совершенно согласен что манчестерское кодирование отлично подошло бы, но тут пока не встала проблема скорости передачи данных, а значит и эффективного использования спектра. Чтоб передать температуру и управляющий код диода пары бод будет за глаза.
Потом, написать программу которая смотрит на сдвиг частоты влево-вправо гораздо легче, чем детектировать и обрабатывать сдвиг фаз. Ещё это и более помехоустойчивое решение относительно амплитудной модуляции, не говоря про то что энергоэффективность будет в данном случае выше (меньше расход батареи).
Таким образом «кодирование ->Модуляция >-Демодуляция >-Декодирование» тут нужно чтоб использовать уже имеющийся девайс и писать только программу для декодирования, а не
впаиватьвключать в цепь UARTы, а как следствие — упрощение схемы.imwode
Аудио кабель прекрасно подходит для цифровых сигналов, хотя в природе их не существует. «Цифровой сигнал» — это сумма синусоид. Не помню точно, но уже при сложении пятка что ли синусоид правильной частоты сигнал выглядит вполне себе цифровым. Но дело не в этом. Дело в том, что этот аудио кабель они пихают в аудио разьем какого-нибудь айфона. Соответственно все, что они могут сделать — это подать некий звуковой сигнал на выход. И в этот некий звуковой сигнал надо зашить данные.
Почитать статью что ли, мож я вообще не про это.
imwode
Блин, периодический сигнал. Когда уже научусь не писать камменты на хабре, неуч же
GAS_85
Да, это все замечательно, но при этом значительно увеличиваются требования к ширине спектра и качеству кабеля, как и приемника/передатчика, а софт должен анализировать более широкий спектр т.е. или уменьшаем полосу пропускания --> увеличением длины импульса, или имеем мееееедленную и неэффективную систему. Этого всего можно избежать, воспользовавшись простой частотной модуляцией. Как я понимаю цель — сделать оборудование для существующего смартфона без изменений последнего --> модуляция must have. Почитайте про передачу сигналов в радио (быстрое гугление) никто не пихает туда импульсы — это неэффективно,
а также жестокои бесполезно.dmitrmax
Вопрос в целеполагании. Если задача связать хоть как-то, уменьшить вычислительную нагрузку, то да. Если стоит задача выжать максимум, организовать совместный доступ к среде, то подход меняется кардинально.
stychos
Plug-and-Pray — это надо запомнить :-)
dmitrmax
Даешь OFDM!
Klukonin
На таком кабеле? )))
Может что-то и получится. Но я бы не стал)
dmitrmax
Кабель-то тут каким боком вам мешает?
Я бы больше боялся за аналоговый тракт, чтобы он там не попортил ничего.
alk0v
Ну OFDM тут, пожалуй, не нужен, а вот если скорось понадобится поболее, QAM-64 или даже QAM-256 должен работать, исходники модулятора и демодулятора можно из GNU-Radio взять.
ZloAlien
На выходе ЦАП смартфора стоит конденсатор (или другой фильтр). Попробуйте записать аудиофайл с переходом 0->1 и воспроизвести его, при этом измеряя выходное напряжение осциллографом. Получите скачёк напряжения в сам момент перехода, но через доли секунды напряжение снова вернётся в ноль.
Klukonin
КЭП?
Речь идет о несущей частоте 9600 Гц=)
ZloAlien
Насколько я понял, имеется в виду частота дискретизации, а не несущая. Если дискретизации, то всё будет неплохо при попытке передачи последовательностей вида 010101, но станет плохо при попытке передать 00000 или 11111.
Klukonin
ШТА?!
UART c baud rate 9600 это периодический сигнал. С периодом в 104 микросекунды.
При чем тут частота дискретизации?
ZloAlien
Это не периодический сигнал, а дискретный.
Klukonin
*FACEPALM*