0

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?

Community
  • 1
  • 1
O key
  • 39
  • 8

1 Answers1

1

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.

O key
  • 39
  • 8