Как мы разработали технологию обнаружения устройств поблизости

[GDXRepo]

Любопытный метод, я только не уловил один момент: каким образом вы анализируете «похожесть» двух сэмплов, если два устройства могут записать звук с неким рассинхроном по времени? Одно устройство может начать запись в момент N, а второе (в силу разных причин — поздно нажали кнопку, или устройство подвисло, или еще что, и получается момент N + k). Как их засинхронить для сравнения? Также, правильно ли я понимаю, что понять дистанцию друг от друга при таком методе позиционирования — довольно проблематичная задача?

[GermanW]

автор поправит, но как я понимаю, постоянно делается отпечаток куска времени и отправляется на сервер(тогда будет работать история про «пользователи молча ждут обнаружения секунд 10, после чего один из них говорит что-то вроде “Это не работает!”. Эта фраза работает как заклинание и через секунду устройства обнаруживают друг-друга. » )
по моему не решаемая «дистанцию друг от друга», но это и логично, цель сего: нужно с высокой долей вероятности доказать что устройства находятся в одном помещении\пространстве

[Lolman]

Верно. В начале работы мы синхронизируем локальное время с серверным. Отпечатки генерируются в реальном времени и отправляются на сервер вместе с точным временем записи исходного звука.
Понять расстояние таким образом не получится, да.

[GDXRepo]

Наверное, я немного не так выразился по поводу синхронизации. Я понимаю, что каждый сэмпл маркируется некой меткой времени, я о другом: как часто пишутся сэмплы, чтобы достичь хорошего качества позиционирования, но при этом не разрядить в ноль батарею и не забить до отказа свободное пространство на «диске»? Каждую секунду, каждые 10 секунд? И насколько длинными вы решили делать сэмплы, чтобы получалось с высокой точностью выполнять позиционирование, не расходуя тонну мегабайт свободного места? Допустим, если я от пользователя получаю 100 сэмплов с метками времени, и от другого ту же сотню, то потом я отброшу все сэмплы, не совпадающие по серверному времени, и проанализирую только те, что засинхронены. Верно же? А вот интервал какой между записью?

[Lolman]

SDK позволяет запустить и остановить поиск когда угодно. Когда поиск запущен — звук пишется постоянно, хэшируется и отправляется на сервер в реальном времени, не занимает место на «диске» устройства.
В нашем приложении поиск запускает сам пользователь, и он автоматически прекращается при сворачивании/закрытии приложения. По потреблению аккумулятора точных замеров нет. Алгоритм нагружает CPU Snapdragon 430 примерно на 3-4%.

[Lolman]

т.е. такого понятия как «интервал между записью» нету, запись происходит непрерывно.

[GDXRepo]

Интересно. Благодарю за ответ.

[zhenya_k]

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

[Lolman]

Да, не обязательно начинать поиск одновременно. Тот, кто запустил поиск позже — будет найден как только отпечатки начнут совпадать.

[shalomman]

iOS сканирует только BLE для обнаружения iOS, т.к. сканирование Bluetooth-устройств невозможно с помощью публичного API.

Насколько актуальна эта информация? Есть какое-то подтверждение из внешних источников?

[Lolman]

Информация актуальна для iOS 11. Есть два способа работать с BT: Core Bluetooth framework, который позволяет работать только с BLE и External Accessory framework, который позволяет обнаруживать только MFI устройства

[shalomman]

попробовал написать программу, которая светит 32 байтной строкой по BLE в peripherial mode на андроиде. IOs при сканировании видит эту строку без проблем.

Использовалась библиотека github.com/omergul/Discovery

Тесть нет проблемы идентифицировать 2 девайса iOS/android, android/android, iOS/iOS по этой строке. Выглядит гораздо менее енергозатратно. Да и проще в разработке.

[Lolman]

К сожалению, очень многие Android-устройства не поддерживают BLE peripherial mode. Здесь можно посмотреть статистику на эту тему.
В ОС поддержка добавлена начиная с Android 5 (уже теряем около 15% пользователей), в железе/firmware эта возможность тоже реализована не везде.

Именно поэтому в Google Nearby используется обычный Bluetooth для поиска Android-Android.

[dmbreaker]

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

[LeonidY]

Вот-вот, у меня вопрос — а почему просто не проиграть что-то уникальное на одном устройстве и найти это на других?

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

[Lolman]

В этом случае как минимум одному из вас все равно придется разрешить доступ к микрофону. Рано или поздно этим человеком станете Вы, верно? Кстати, а где у вас зажигается иконка доступа к звуку или видео? Не припомню такого в Android и iOS.

[perfect_genius]

А как же QR-код? Вряд ли сейчас есть телефоны без камеры.

[Lolman]

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

[perfect_genius]

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

[IGR2014]

А если, допустим, мы с другом на расстоянии, скажем, 10 км, смотрим одну и ту-же телепередачу?
Да, сценарий средней реалистичности, но всё-же. Время одно и то-же, звук одинаковый.

[Lolman]

В очень редких случаях. Дело в том, что каждый провайдер и оборудование даже в рамках города вносит различные задержки в вещании, по нашему опыту от 5 до 30 секунд.
Это возможно, если вы оба смотрите радиовещение (без задержек), а посторонних звуков мало.
Способ решить эту проблему у нас уже есть, но пока пользователей не так много — он не имеет смысла.

[IGR2014]

Выходит, Вам нужно точное время, так?
А раз каждый провайдер вносит свои задержки, то даже у двух человек, стоящих рядом, но имеющих разного оператора, сэмпл будет иметь немного разное время? (те-же 5 — 30 секунд).
Но в целом идея понравилась, интересное решение. Не слышал раньше о подобном

[Lolman]

Мы сами синхронизируем локальное время с серверным при помощи протокола, похожего на NTP, поэтому разница времени на устройствах пользователей не играет роли.

[devpony]

Простая и классная идея, супер! Вы берёте хэш от спектрограммы или от исходного сигнала?

[Lolman]

Спасибо! От спектрограммы

[UsatBorodat]

Если в МакДональдсе несколько пар решили только попарно соединиться и пересеклись во времени включения, все соединятся?

[Lolman]

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

Более яркий пример — концерт или выступление. Когда один источник звука гораздо громче остальных — все пользователи будут соединены.
Мы пробовали использовать приложение на конференции — голос спикера очень быстро соединяет всех в зале и это было то, чего ожидали пользователи.

С точки зрения UX мы считаем, что нужно дать пользователю выбор или подтвердить действие «соединения».

[UsatBorodat]

Приложение для фанатов «Спартака» будет очень популярно )

[rPman]

Реализацию алгоритма (и данные нейросетей или коэффицентов в формулах, которые используются) ожиается закрытой? не собираетесь открывать ее на публику?

Такие вещи, по мне, так должны быть в операционных системах по умолчанию желательно без завязки на сервер (кроме как ради точного времени).

[MyOnAsSalat]

Если бы это собрали в кроссплатформенную библиотеку, вполне можно написать ещё одну статью.

[Lolman]

Думаем насчет opensource, вполне возможно.

[DenisMarkov]

Не уверен, что тут можно постить ссылки, но вот ссылка на технологию Resonance www.getresonance.net и приложение DROP, которое ее использует www.getdrop.net

[FackExcuses]

Хабр мотивирует!)

[AllexIn]

− работает на слишком малых расстояниях

А это минус?
Почему вы этот минус у бампа не написали? Там то вообще надо стукнуть телефоны друг о друга.
По сути это бамп только для кучи устройств сразу и без необходимости долбить телефоны друг о друга.

[Lolman]

В нашем случае — минус. У Bump тоже этот минус стоит указать, согласен с Вами.

[ganqqwerty]

Гениально, правда. Всяческих успехов и обязательно защититесь патентами со всех сторон.

[Lolman]

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

[rrrrex]

Обнаружен смартфон Apple Iphone X. Примерное расположение- левый карман куртки справа стоящего человека.

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

[arcman]

Триангуляция оперирует углами, коих по понятным причинам нет в случае определения координат по базовым станциям и Wi-Fi.
На самом деле в таких случаях используется трилатерация.

[Durimar123]

Что на счет штрихкода?
Вася нажимает кнопку показать штрихкод.
Петя, Таня, Оля, делают фотку дивайса с штрихкодом и с отправлением на сервер,
5- 10 сек и все в группе.

ps
Юзайте на здоровье.

[lizarge]

Очень круто, жаль что вы вероятно нарушаете патенты www.getresonance.net, хотя очень бы хотелось бы увидеть вашу реализацию в опенсоурс.

[Lolman]

Мы и есть www.getresonance.net :-)

[Lolman]

<del/>