Eddystone is not in a range or batteries are removed.
In SDK 0.16.0: onEddystonesFound is only invoked for next 1000ms and then I dont get any data from beacon. —> it’s correct behavior.
In SDK 1.0.13: onEddystonesFound is invoked for next 20000ms, although the beacon is off ( battries are removed).
The problem is, that I get fake-data from beacon.
How can I prevent the App/ SDK to generate the fake data?
Setting setRegionExitExpiration is used only for monitoring and won’t affect Eddystone ranging.
Expiration time for ranging (time is no packet from beacon) is set to 20s to avoid irregular batch scans in Android 7.+ and it is not user changeable.
Mentioned issue is about setRegionExitExpiration when monitoring iBeacons and already has been fixed and is during verification.
But how can you explain a problem, that a onEddystonesFound event is invoked, although a beacon is off?
The beacon is set to -30dBm broadcasting power and 200ms advertising intervall.
In 0.16.0 a beacon didn’t invoked an onEddystonesFound if it was off or outside a maximal range,
but now in 1.0.+ an onEddystonesFound event is even invoked for max. 20s, when the beacon is off.
All this time the app delivers fake data and rssi of a beacon stays almost the same, although a beacon isn’t in a range.
And if I use computeAccuracy(eddystone) the result is always almost the same, although a distance to a beacon increases.
My question is: why onEddystonesFound is onvoke although there is no beacon?
P.S. I’d rather removed the batteries of a beacon for tests.
Even if I leaving, it (the app) received fake data for 20s, same is, when I remove the batteries.
As I said, with 0.16.0 all worked fine, but now not anymore.
As I mentioned before 20s is expiration time. It means that SDK will consider beacon missing 20s after it received last packet from it and will report that beacon is there before this time is due.
On Androids 5.0 and newer Bluetooth stack uses something called batch scans. It means it will report received packets after in groups instead to avoid waking up application processor. Those batch scans by our experience are quite irregular (even when you tell Android exact time) and can take up several seconds.
Other thing is that due to uncertain nature of radio waves and way Bluetooth perform scans some some packets from single beacon may be missing from time to time.
Expiration time prevents beacon from appearing and disappearing frequently from the list that is returned in callback.
Pre 1.* SDKs suffered from too short expiration time which caused many false onEnter/onExit events.
@Wojciech_Wawerek@heypiotr@pober
I understand what you mean, but I’m using EddystoneDiscovery and EddystoneListener.
There are no onExit/onEnter event, only onFound.
You mean, that batch scanning is the cause, why the onEddystonesFound event is still invoking although the beacon is off, do you?
If yes: why in 0.16.0 the batch scanning didn’t affect onEddystonesFound event?
Too short expiration period was causing problems in both ranging and monitoring.
Batch scan is not only one reason why longer expiration period was introduced (way Bluetooth scans for packets, properties of radio waves) and it was causing problems only on some phones.
There is a list of currently visible beacons that its updated each time new scan record arrives. If the beacon is not scanned for 20s it is removed from the list. There is also a timer that periodically calls onFound method with that list as a parameter. That is why you are receiving callbacks.
@pober
I just switched to 0.16.0 and found some strange behavior:
I commentedthis line
//beaconManager.setRegionExitExpiration(1000);
and onEddystonesFound event is invoked for next 20s although the batteries were removed from beacon.
I uncommented the line
beaconManager.setRegionExitExpiration(1000);
and now, the onEddystonesFound doesn’t invoked after I removed the batteries.
So: in 0.16.0 setRegionExitExpiration setting was affecting the behavior of EddystoneListener!
and in 1.0+ anymore. I’ve tried it on the same device with the same app.
It could be very usefull to make a function like setEddystonesFoundExpiration in 1.0+ version!
We are working on a solution for this problem. First we will try to automatically calculate expiration time based on how frequently we receive packet. Secondly we are adding timestamp field to packet classes so you will know when the last packet was really received and you can filter them in onFound method.