CoreBluetooth для маяков

Question

У меня есть проект, требующий ранжирования маяков, я рассмотрел множество примеров кода, который использует CLLocationManager и CLBeaconRegion. Моя проблема заключается в том, что обратный вызов didRangeBeacons получает вызов один раз в секунду.

Хотя я не нашел каких-либо примеров кода для маяков, могу ли я правильно подумать, что CoreBluetooth даст мне больше контроля над тем, как часто приложение сканирует маяки?

Мое мышление заключается в том, что если я могу сканировать маяки с более высокой скоростью (скажем, когда-либо 200 мс), я смогу использовать больше значений rssi в своей функции фильтрации и, следовательно, получить более точную близость, не занимая слишком много времени. Правильно ли я предполагаю это?

Может ли кто-нибудь указать мне на какой-либо пример кода/учебник по использованию CoreBluetooth с маяками (если это стоит дополнительных усилий)?

Answer 1

Если вы используете CoreBluetooth для сканирования маяков вместо CoreLocation, вы получаете один обратный вызов для каждого рекламного пакета, обнаруженного против одного обратного вызова каждую секунду для CoreLocation.. Есть два преимущества и недостатки обоих подходов, поэтому важно точно понимать, как каждая работа делает правильный выбор. Преимущества и недостатки сильно зависят от скорости рекламы маяка, при этом стандартная рекламная ставка iBeacon составляет 10 Гц.

Использование CoreLocation в диапазоне

Следующий метод получит обратный вызов один раз в секунду, но только для BLE рекламы, которые соответствуют раскладку IBeacon и занесенных в ProximityUUID в этой компоновке, которое было зарегистрировано в пределах как часть a CLBeaconRegion объект. Когда эти условия выполняются, каждый обратный вызов вызывается каждую секунду независимо от того, сколько пакетов маяков обнаружено за этот промежуток времени:

locationManager(_ manager: CLLocationManager, didRangeBeacons beacons: [CLBeacon], in region: CLBeaconRegion).

Каждый объект CLBeacon в массиве beacons имеет поле rssi. Это поле содержит среднее значение rssi всех пакетов маяковых сигналов, обнаруженных за прошлый один второй интервал.

Если маяк рекламируется с частотой 10 Гц, это считывание rssi будет в среднем по 8-10 пакетам, полученным в прошлую секунду (только 80-90% пакетов обычно принимаются из-за радиошумов, столкновений и помех).

Если маяк рекламируется на частоте 1 Гц или ниже (типичный для маяков батареи, которые пытаются сэкономить электроэнергию), в среднем будет включено только одно считывание rssi. (Нет способа узнать, сколько обнаружений попало в значение rssi, возвращаемое обратным вызовом.)

Так что, пока вы не получаете доступ к значению rssi из каждого обнаружения, и вы не можете контролировать интервал усреднения , вы получаете выгоду от множества обнаружений в том смысле, что значение rssi усредняется и менее шумно, чем если бы было только одно чтение. CoreLocation поэтому дает вам такую ​​же точность, как CoreBluetooth при условии, что вы готовы принять его жестко закодированные интервалы усреднения.

CLBeacon объекта также содержит поле для accuracy и proximity, которые основаны на производное значении RSSI отфильтрованного в течение более длительного интервала (эксперимент показывает, что около 20 секунд).В этом интервале усреднения нет контроля над API, а 20 секунд - очень длинное отставание для некоторых приложений, где требуется быстрое обновление в оценках расстояния.

Использование CoreBluetooth сканирования

Обычно это делается путем установки флага позволяет дублирующие результаты:

centralManager.scanForPeripherals(withServices: [], options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

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

centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber)

Номер rssi в этом обратном вызове - это необработанное значение для обнаружения одного пакета. Если ваш маяк рекламируется с частотой 10 Гц, вы получите 8-10 обратных вызовов в секунду на этом методе (опять же, не на 100% пакетов), и вы можете усреднить или фильтровать свой rssi, как вам нравится. Это дает вам тонкий контроль над использованием rssi, и вы можете делать оценки расстояния по произвольным интервалам усреднения.

Вышеуказанная мотивация привела меня к разработке открытого источника iOS Beacon Tools, который позволяет обнаруживать беконы с CoreBluetooth и вычислять оценки расстояния на основе rssi, собранных по произвольно заданным интервалам усреднения.

Однако, есть несколько недостатков с помощью CoreBluetooth:

• IBeacon пакеты не могут быть декодированы, так как операционная система отфильтровывает полезную нагрузку данных любого пакета, соответствующий его расположение. По этой причине вы должны использовать аналогичный макет, например AltBeacon, или использовать кадр Eddystone.

• Рекламные объявления производителя, такие как AltBeacon, не поставляются в фоновом режиме, только на переднем плане.

• Рекламные объявления, такие как Eddystone, поставляются в фоновом режиме, но только очень и очень медленно. Поэтому это не полезно для сбора данных rssi.