Bluetooth LE RSSI pour la détection de proximité iOS
Je vais commencer par la question.
Le BTLE RSSI est-il un bon moyen d'indiquer la proximité de deux appareils ou non? cela ne fonctionne-t-il qu'avec de petits appareils comme des télécommandes, etc.?
Le problème:
Je cherche actuellement à créer une application qui utilisera BTLE et permettra des connexions basées sur la proximité. À cet égard, cela ressemble beaucoup à l'application de démonstration qui Apple apparaît dans le discours principal d'Advanced Core Bluetooth (lorsque deux appareils se touchent presque, ils se connectent ensuite).
Si je comprends bien, la proximité est déterminée en fonction de la valeur RSSI lorsque le central découvre le périphérique. Cependant, lorsque j'essaie avec deux iPads, le signal semble trop fort pour cela, il est également trop incohérent pour avoir un coup précis à la proximité car il ne montre pas beaucoup de corrélation avec la proximité des appareils.
J'ai essayé le Apple exemple de code et c'est similaire en ce sens que les appareils n'ont pas besoin d'être du tout proches pour que les informations passent de l'un à l'autre.
Si seulement il y avait un moyen de réduire la puissance du signal de la publicité des périphériques ...
Merci d'avance pour votre aide.
L'expérience de Matthew Griffin correspond à la mienne. Cependant - lorsque nous pouvons mesurer pendant une bonne période de temps, deux choses nous ont aidés à mieux calibrer cela.
Nous avons dû enrouler un simple filtre (kalman) sur l'orientation de l'antenne et l'IMU pour obtenir un commentaire de fonctionnement approximatif - et ce n'est pas très léger pour le processeur ou la batterie.
- En utilisant l'IMU, vous avez une bonne idée de la distance/direction du trajet - et si cela se fait sur une courte période de temps - nous supposons que l'autre "côté" est immobile. Cela aide beaucoup à obtenir une valeur pour l'orientation "actuelle" et pour "calibrer le bruit de l'environnement actuel".
- De même - faites de même pour les rotations/changements de position.
Nous avons constaté qu'en général, une réorientation de l'appareil est une meilleure façon d'obtenir la direction; et cette distance n'est fiable que jusqu'à 30 à 600 secondes après un étalonnage de "déplacement" et uniquement si l'appareil n'est pas trop tourné. Et dans la pratique, il fallait une fois 4-5 "autres" appareils; idéalement pas trop mobile, pour se maintenir dynamiquement calibré.
Cependant, l'inverse est assez fiable - c'est-à-dire que nous savons quand ne pas mesurer. Et le résultat net est que l'on peut assez bien vérifier des choses comme "au clavier" et "relocalisé"/éloigné par une porte/ouverture ou direction spécifique. De même, mesurer un champ en dansant au hasard dans la pièce; changer beaucoup d'orientation - fonctionne bien une fois que les lobes de l'antenne du récepteur ont été quelque peu travaillés après une période stationnaire.
Vous avez tout à fait raison de dire que RSSI saute sauvagement et aléatoirement. Vous devez récupérer vos valeurs RSSI toutes les deux secondes (plus rapidement et vous obtenez un tas d'erreurs). Jetez les valeurs RSSI qui sont supérieures à un pic de ~ -40 décibels et utilisez un agrégat des valeurs passées avant de déclarer votre plage approximative à l'utilisateur.
Quant à votre déclaration suivante, vous avez de la chance.
Si seulement il y avait un moyen de réduire la puissance du signal de la publicité des périphériques ...
Le service que vous recherchez s'appelle TX Power Service . La mise en œuvre de ce service sur votre périphérique vous permettra de diminuer la puissance d'émission de l'appareil. De cette façon, vous pouvez réduire la plage à partir de laquelle les données de publicité sont visibles. Nous n'avons malheureusement pas cependant accès à ce service sur un appareil iOS. Mais si vous écrivez votre propre firmware pour un périphérique BLE, c'est le service que vous souhaitez.
J'ai passé la semaine dernière à traiter strictement le RSSI, à essayer d'utiliser les capteurs Wifi et Bluetooth LE pour la triangulation de l'emplacement et pour la conversion de distance.
Malheureusement, ce que j'ai trouvé, c'est que RSSI est tout simplement trop capricieux et peu fiable pour être utilisé systématiquement pour déterminer la distance. En théorie, le RSSI et la distance se comportent selon la loi du carré inverse (le double de la distance, et le RSSI descendra d'un nombre fixe de décibels), mais en pratique le RSSI est affecté par des facteurs incontrôlables tels que la météo (le temps sec permet = RF champs pour mieux voyager) et les obstacles (tout objet métallique ou humain se trouvant sur le chemin d'un capteur à l'autre provoquera une atténuation, et tout objet métallique placé à proximité de l'un des capteurs entraînera un gain de force du signal).
Il existe des moyens d'essayer de compenser cela. Cet article est l'un des meilleurs articles que j'ai lus sur la façon d'obtenir des résultats précis, mais l'essentiel est que cette méthode n'est pas fiable, sauf si vous voulez juste une idée générale de l'endroit où se trouve l'appareil.
Si je comprends bien, vous essayez d'implémenter des fonctionnalités similaires à celles de la démo WWDC et à des applications comme Bump implémenter. Pour cela, RSSI sera suffisant. Testez les valeurs de seuil appropriées (par exemple> -30) et tout ira bien.