Ottieni scansione BLE senza filtro UUID duplicato

Question

Sto scrivendo un'applicazione BLE, in cui è necessario tenere traccia delle periferiche che la periferica sta facendo pubblicità o si è fermata.

Ho seguito getting peripherals without duplications questo e BLE Filtering behaviour of startLeScan() e sono completamente d'accordo qui.

Per rendere possibile, ho tenuto il timer che esegue nuovamente la scansione delle periferiche dopo un certo periodo di tempo (3 secondi). Ma con il nuovo dispositivo disponibile sul mercato (con aggiornamento 5.0), un po 'di ri-scansione dei tempi richiede poco tempo per trovare le periferiche.

Qualche suggerimento o se qualcuno ha raggiunto questo?

Answer 1

Primo caso: Bonded Dispositivi

Sappiamo che se un bond è fatto, quindi la maggior parte dei dispositivi disponibili in commercio inviare directed advertisements durante riconnessione. In situazioni come questa, in base alle specifiche BLE 4.0, non è possibile eseguire la scansione di questi dispositivi su qualsiasi sniffer BLE.

Secondo scenario: dispositivi collegabili

Le periferiche sono di solito in questa modalità quando si trovano inizialmente nella fase di reset. La centrale invia un iniziatore connect in risposta a un pacchetto advertisement. Questo scenario ti offre molta flessibilità dal momento che puoi giocare con due opzioni di configurazione predominanti per modificare i tempi di connessione. Questi sono: slavelatency sulla periferica e conninterval sulla centrale. Ora, non so quanti sforzi ci vorrà per farlo funzionare sulla piattaforma Android, ma se usi lo stack Bluele BLE e una periferica configurabile come un tag TI Sensor, puoi giocare con questi valori.

terzo scenario: dispositivi Beacon

Dal momento che questo è ciò che la tua domanda ruota attorno, secondo l'architettura BLE, non ci sono parametri con cui giocare. In questo scenario, la centrale è solo un dispositivo stupido lasciato in balia di quando una periferica sceglie di inviare il suo segnale di segnalazione.

Riferimento:

http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796/ref=pd_bxgy_14_img_z

http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X/ref=pd_bxgy_14_img_y

Answer 2

Suona come siete interessati a pubblicità di scansione, piuttosto che il collegamento a dispositivi. Questo è il ruolo di "osservatore" in Bluetooth Low Evergy e corrisponde al ruolo di "broadcaster" più comunemente noto come Beacon. (Bluetooth Core 4.1 Vol 1 Parte A Sezione 6.2)

In genere si attiva la scansione passiva, cercando i pacchetti ADV_IND trasmessi dai beacon. Questi possono contenere o meno un UUID. In alternativa, è possibile eseguire la scansione attiva trasmettendo SCAN_REQ a cui è possibile ricevere un SCAN_RSP. Molti dispositivi utilizzano contenuti pubblicitari diversi in ADV_IND e SCAN_RSP per aumentare la quantità di informazioni che possono essere trasmesse. Ad esempio, potresti inserire un UUID128 in ADV_IND seguito dal nome del dispositivo in SCAN_RSP. (Bluetooth Core 4.1 Vol 2 Part E sezione 7.8.10)

Ora è necessario definire "andare via" - si prevede che gli annunci si fermino o svaniscano?Viene visualizzata l'indicazione di potenza del segnale di ricezione "RSSI" con ogni annuncio (Bluetooth Core 4.1 Vol 2 Parte E Sezione 7.7.65.2) - questo è il modo in cui funziona il posizionamento di iBeacon e c'è molto supporto per i ricevitori beacon in Android.

In alternativa si attende per N secondi per una pubblicità che dovrebbe essere trasmessa ogni T secondi in cui N> 2T. Il rovescio della medaglia è che probabilmente non ricevere un faro non è lo stesso che ricevere un faro debole; per essere sicuro di aver bisogno di N di essere grande e questo influisce sulla latenza tra l'emittente che si spegne o si sposta fuori dal raggio d'azione e la tua app lo rileva.

Un'altra cosa: fare attenzione che la pubblicità si interrompe se qualcosa si connette a una periferica (se si sta veramente cercando periferiche) un altro buon motivo per monitorare l'RSSI.

Answer 3

Modifica: Ho dimenticato, hai provato a impostare l'inserzionista su non collegabile? In questo modo dovresti essere in grado di ottenere risultati di scansione duplicati

Mi sto occupando di un problema simile, cioè, monitorare in modo affidabile i valori RSSI di più dispositivi pubblicitari nel tempo.

È triste, il modo più affidabile che ho trovato non è bello, piuttosto sporco e consuma molta batteria. Sembra a causa del numero di dispositivi Android che gestiscono BLE in modo diverso il più affidabile.

Avvio scansione LE, non appena ottengo una richiamata ho impostato un flag per interrompere e avviare nuovamente la scansione. In questo modo si aggira il problema DUPLICATE_PACKET con il filtro poiché esso ripristina ogni volta che si avvia una nuova scansione.

Gli ScanResults eseguo il dump in un dl sqlite che si restringono e valutano ogni x secondi.

Dovrebbe essere facile adattare il restringimento al proprio caso d'uso, ovvero rimuovere le voci più vecchie di X, quindi interrogare l'esistenza di un dispositivo per scoprire se si è ricevuto un ScanResult negli ultimi X secondi. Tuttavia Non mettere questo valore X troppo basso, come si deve tener conto che si perde ancora un sacco di pacchetti di pubblicità su Android le scan, rispetto ad una scansione BLE su IE bluez ..

Edit: posso aggiungere alcune informazioni che ho già trovato per velocizzare le prestazioni sulla scoperta di pubblicità. Si tratta di modificare e compilare i sorgenti bluedroid e l'accesso root al dispositivo. Il più semplice sarebbe costruire un android completo da soli, ad esempio Cyanogenmod.

Quando una scansione LE è in esecuzione, il modulo Bluetooth invia la risposta di scansione tramite HCI allo stack bluedroid. Ci sono vari controlli fino a quando non viene finalmente consegnato a Java onScanResult(...) a cui si accede tramite JNI.

Confrontando il log dei dati hci inviati dal modulo bluetooth (può essere abilitato in /etc/bluetooth/bt_stack.conf) con l'output di debug nello stack bluedroid e nel lato Java ho notato che un sacco di pacchetti pubblicitari vengono scartati, specialmente in alcuni assegni. Non capisco davvero, oltre a ciò ha qualcosa a che fare con il database di inchiesta bluedroid Dalla documentazione di ScanResult vediamo che ScanRecord include i dati di annuncio più i dati di risposta di scansione.Quindi potrebbe essere che Android blocchi il rapporto fino a quando non ha ricevuto i dati di risposta della scansione/finché non è chiaro che non ci sono dati di risposta di scansione. Questo non ho potuto verificare, tuttavia una possibilità.

Dato che sono interessato solo a aggiornamenti rapidi sul RSSI di quei pacchetti, ho semplicemente commentato il check out. Sembra che ogni singolo pacchetto che ottengo dal bluetooth moduly di hci sia passato al lato Java.

Nel file di btm_ble_gap.c in funzione BOOLEAN btm_ble_update_inq_result(tINQ_DB_ENT *p_i, UINT8 addr_type, UINT8 evt_type, UINT8 *p) commento fuori to_report = FALSE; nel seguente controllo di partenza sulla linea 2265.

/* active scan, always wait until get scan_rsp to report the result */ 
if ((btm_cb.ble_ctr_cb.inq_var.scan_type == BTM_BLE_SCAN_MODE_ACTI && 
    (evt_type == BTM_BLE_CONNECT_EVT || evt_type == BTM_BLE_DISCOVER_EVT))) 
{ 
    BTM_TRACE_DEBUG("btm_ble_update_inq_result scan_rsp=false, to_report=false,\ 
          scan_type_active=%d", btm_cb.ble_ctr_cb.inq_var.scan_type); 
    p_i->scan_rsp = FALSE; 
    // to_report = FALSE; // to_report is initialized as TRUE, so we basically leave it to report it anyways. 
} 
else 
    p_i->scan_rsp = TRUE;