What's up with Nearby / Eddystone / Physical Web?

[andersborgabiro]

I'm leaving my accumulated (intentionally opinionated, and now slightly edited) comments and questions here, as I couldn't find any better place for them. They mainly concern Eddystone-URL, as that's the only thing I bother with right now (except iBeacon of course), and it's primarily addressed to Google.

I call Nearby / Eddystone / Physical Web together as NEPW below, as the name confusion is an issue in itself, which is very hard to explain to customers. Adding support in Chrome and then removing it shortly after is another confusing thing, but understandable due to integration of Nearby in Google Play Services and considering very few (any?) iOS users have Chrome installed anyway.

It seems Google has moved away from promoting NEPW. It's a viable alternative (and competitor) to iBeacon, both as an analogue via UID/EID and due to the conceptual simplicity of Eddystone-URL. I've found that the only ones still posting any fresh information about NEPW are providers of proximity marketing solutions, that try to promote use of beacons to their customers. Well, I do too.

Setting up UID or EID the Nearby way seems way too complicated and dependent for most (and almost all short-term) scenarios. In my opinion, the whole point of Eddystone is Eddystone-URL without use of Google's central configuration, but rather directly linking to a CMS without further intervention. Analogues: QR codes and NFC tags.

For NEPW to be a viable generic option there's need for a reliable and up-to-date iOS app too, and from Google, so there's a chance users have it installed or care about installing it. The smartphone market is still very much iOS and Android, not only Android. It would be very unwise to run a campaign (or any other use of beacons) for only Android users.

The Physical Web app for iOS is old, but luckily (?) still works, despite now mandatory usage descriptions in plist etc. I've seen a few other providers making analogous applications, like MobStac and Bleesk, and potentially my own company as well (it's working, but barely).

A few questions:

At what distance is NEPW considering being within a beacon's region? My experience when it comes to Eddystone-URL is that it seems to be when the mobile device is at all receiving any "pings", which makes for little possibility to pinpoint in-door locations. iBeacon has the option of far/near/immediate, and for most cases I've found near to be the best option, e.g. within shops.

What method is used to avoid inside/outside region "flickering"? Timers on both entering and exiting a region?

Does NEPW use both TX and RSSI to calculate distance? My app does that (right now just TX - RSSI with moving average) to enable the user to configure when to get notified.

At what intervals does NEPW scan for advertisements? Doing it constantly drains the battery, but on the other hand doing it too seldomly might miss beacons. I currently scan constantly for quick response, well aware that won't do.

[RyanDool]

The Physical Web app for iOS is very old, and it doesn't post any notifications when detecting beacons...On Android, notifications posted from any NEPW app don't show up on the status bar, yet they are shown when dropping down the list of notifications... It is worth noting that physical web notifications are intended to be soft-notification, as to prevent intrusive behavior. I am currently running PhyWeb 0.1.4 on iOS 11.4 and I am able to receive notifications when beacons (eddystone-url) are detected. Is it possible you have not allowed notifications from the PhyWeb app? This is done by swipping to notifications screen on your iOS device and tapping "Edit", from the list of applications tap the "+" next to "Physical Web Beacons".

At what distance is NEPW considering being within a beacon's region? This is dependent on the transmission settings of your beacon. Due to the number of manufacturers it would be best to consult the documentation specific to your device(s) HOWEVER, if you are developing your own application you can also use RSSI as a conditional to define the region. There are many options in defining the region but it depends on your specific use case and hardware/software.

What method is used to avoid inside/outside region "flickering"? Timers on both entering and exiting a region? I suppose that would work.

Does NEPW use both TX and RSSI to calculate distance? RSSI

At what intervals does NEPW scan for advertisements? Are you talking about a specific application? Typically that is entirely dependent on the code within the application.

[andersborgabiro]

1. Yup, notifications were deactivated. Physical Web Beacons doesn't show up on Settings / Notifications though. Different things?

2 to 5. I was more wondering how it's actually done in Physical Web and Nearby now. I've started developing my own minimalistic Eddystone-URL app in Cordova, so emulating what the existing apps do would probably be a good thing, unless further practical testing indicates I need to stray from that.

4. The issue with using only RSSI is that distance measurements get dependent on the radio power of the beacon, which could vary greatly.

I do have issues with battery drain in my iBeacon app, as I try to capture beacons quickly, even for near or immediate. This might not be as important for Eddystone-URL though, if it's by default the same as iBeacon far.

PhyWeb also seems to show WiFi devices, like routers etc.

[andersborgabiro]

Oddly, my Android 7 phone now showed a notification icon on the status bar. First time it's happened.

[adriancretu]

I'm pretty sure "NEPW" doesn't do any distance calculation, but if it did, it would definitely need both the RSSI and the TX information, since the distance is pretty much the relative difference between those two, not an absolute measurement on itself. I worked on beacon scanning for so long that I can assure it's impossible to do distance estimation due to the so, so many differences in Android hardware chipsets and also beacon chipsets and firmware. Not even mentioning interference due to basic things like human bodies.

[andersborgabiro]

"since the distance is pretty much the relative difference between those two" Right, that was why I asked.

And yes I have the same experience, yet far/near/immediate is precise enough to have some relevance for iBeacon, at least when you control both what beacons are used and how they are configured.

I've found that configuration software for beacons often don't set TX based on selected radio power, which makes it quite unreliable, but in my configuration app for Wellcore beacons I do that. I believe also Estimote's app does it.

[adriancretu]

Things change when you discover that two different phones placed at the exact same spot present two rssi values 10 dB off of each other. I believe Apple calibrates their devices knowing precisely the location of the BT antennas and chipset specs. On Android, simply having the BT sillicon on the other corner can cut the RSSI in half.

[andersborgabiro]

That's true. The difference can be quite substantial. TX has to assume a certain device sensitivity. And something watery in between (like a human) also affects much.

Indoor location solutions can compensate by having enough beacons for there to be averaging (between beacons and over time) and also discrimination of "crazy" RSSI levels. Also, multiple beacons of the same type and the same radio power can compensate for different receiving device sensitivity (it's the relative rather the absolute powers that matter most). But AFAIK that's not used by "NEPW".

[andersborgabiro]

When the phone is lying on a table I can use TX - RSSI to roughly express proximity, but that goes out the window as soon as I hold the phone.