Reputation: 39
I already red some Questions about this topic like this one for example: Application never receives RSSI_CHANGED_ACTION
But they solved the problem using SCAN_RESULTS_AVAILABLE_ACTION. I also did this but now I have to use RSSI_CHANGED_ACTION because of customer requirements.
It seems like it reacts slow to rssi changes. For example it only change when I make bigger location changes. When I use SCAN_RESULTS_AVAILABLE_ACTION it changes very often. Even when I am just in one room.
So why is RSSI_CHANGED_ACTION slow reacting?
Upvotes: 0
Views: 516
Reputation: 39
I found the answer why it´s "slow reacting". In WifiStateMachine.java I found this snippet here:
/*
* Rather then sending the raw RSSI out every time it
* changes, we precalculate the signal level that would
* be displayed in the status bar, and only send the
* broadcast if that much more coarse-grained number
* changes. This cuts down greatly on the number of
* broadcasts, at the cost of not informing others
* interested in RSSI of all the changes in signal
* level.
*/
and in WifiWatchdogStateMachine.java I found this here:
/* RSSI Levels as used by notification icon
Level 4 -55 <= RSSI
Level 3 -66 <= RSSI < -55
Level 2 -77 <= RSSI < -67
Level 1 -88 <= RSSI < -78
Level 0 RSSI < -88 */
I think it is self explaining. I tested this out and you get only a Broadcast recieve If you pass one level. For example you have better or equal -55 dbm and after next polling you have betwenn -66 and -55 you get a Broadcastrecieve. But if your dBm Value just changes between -55 and -66 you will never receive a broadcast.
Upvotes: 1