Let's Talk About Beacons | Hacker News Reader

Let's Talk About Beacons

nfarina.com

219 pointsnfarina93 comments

As an iOS developer who has spent the last 9 months making beacon enabled things for my employer, I personally think beacons are shit. Some of my findings over the last 9 months:

- Estimated battery life was estimated very poorly.

- Nobody likes things they didn't ask for getting sent to their phone.

- Indoor navigation that relies on iBeacons only is going to shoot you in the foot. I recommend www.indoo.rs as the only solution that got close to what we needed (though it's still pretty darn immature).

- Speaking of indoor navigation, you need a ton of points to do it well (whether that's beacons or wifi routers, you decide).

- Using beacons for granular location-aware uses might as well go out the window if you're looking for accurate and precise readings around ~1-3ft.

- Did I mention power yet? All of the beacons we started with around 9 months ago have dead batteries. Even with conservative power modes set. The only beacons that don't are RadBeacons USB sticks that plug into wall outlets. And that's only because they don't have batteries.

I really, really want them to be good. But they die too quickly, and don't provide granular signal data. Hold the phone between you and the beacon and get a decent signal, then turn 180 degrees so that you are between the phone and the beacon. Apparently you've moved 45ft.

(Disclaimer: I work for Estimote) Indoor location works much better if you utilize data from other sensors in the phone (like accelerometer etc) and apply machine learning to make better sense out of all the signals. I'd suggest you take a look at our SDK that works surprisingly well even with just 4-5 beacons. You can also map your room with our iOS app by just walking around it. You can find it here if you're interested: http://estimote.com/indoor/

We've also implemented some adaptive algorithms to optimize the battery life in our beacons, so with conservative settings they should work for 5+ years now.

The beacons my company received from you guys must have been out of the norm then. All 3 Estimote beacons are dead, and they all died around the same time (one in super conservative mode, one in what should be a normal use case, and then one in max power mode).

I was excited when I saw your indoor SDK, but it's too simplistic and not realistic enough for the production apps we have and are building (walking around and mapping every single room in a hospital is untenable).

I don't mean to bash your company at all here, so I'm sorry if this comes off that way. I also found that almost all clients scoff at ~$33/beacon when you're pitching something in the 10,000 beacon range. Even then, for $30/beacon I can get ones that run off the wall circuit and last until that's off (for all intents and purposes, longer than 5 years).

Obviously at 10,000 beacons we're talking enterprise pricing, but even if you were to get that to around $5 that's still too much for what's essentially a CR2032 battery and a tiny radio chip.

I'm excited to see where Estimote takes beacons though, since they seem to be doing the most R&D type pushes with this technology compared to the other manufacturers.

Thanks for your feedback! Sorry to hear about faulty beacons, what happened definitely doesn't sound normal. I'd suggest to contact our community team at contact@estimote.com and they're probably able to replace these beacons with new ones.

Indoor SDK is still in very early phase, but we're pushing very hard to roll out a series of updates with new features like multiple rooms support, cloud integration and even better accuracy, so you can expect more comprehensive solution in the near future.

And if you're interested in bigger deployments we also offer beacons in bulk quantities with much better pricing.

We're treating R&D very seriously as we're thinking of beacons as much more than simply hardware. There's still a lot of ideas to explore and we try to support the community as much as we can, so I hope you'll give it another chance.

Thanks again for sharing your thoughts. That's extremely important to us and makes it possible to address issues people have with beacon technology ASAP

Yeah no problem, I'll talk to my director at work to reach out about the beacons since he's been the point of contact with Estimote so far. Thanks for following up and fielding my concerns/criticism. Like I said earlier, I honestly can't wait to see what you guys come out with next in advancing this technology.

(Disclaimer: Work at TAH) I totally agree to what you are saying. We have had a similar experience working with our devices and SDK.

http://tah.io/get

I absolutely agree with this. I pushed beacons really hard internally, and got a couple projects with them. Unfortunately, they're an absolute pain in the ass as far as reliability goes. One iPhone 5 detects the beacon immediately, the other has to sit around it for 3 minutes before it's detected, one can't detect it at all. Makes life pretty difficult when my only answer is "Is your bluetooth on?".

I hope that some OS level improvements give us some free reliability and performance increases. Supposedly Android recently got some updates re: beacons.

We at our company also tried to develop solutions based on beacons for our customers. The major hindrance to acceptance of beacons is people here almost always switch off bluetooth in their phones. I think phone designers should give 2 different switches for switching bluetooth on/off in the UI. One for traditional bluetooth and another for BLE. That way customers can be pursuaded to keep ble on.

Ahh yes, I totally forgot about the phones maybe, sometimes, probably could this time work and range the beacons. Half the time my suggested method for getting the ranging to work is to delete app, restart phone, turn bluetooth on/off, redownload app, pray, sleep, buy new phone... It's unbelievable how ridiculously inaccurate the system software is using CoreLocation out of the box. I've written a wrapper for it (https://github.com/Intermark/Buoy/) to make internal dev a lot easier, and even then it's a pain in the ass to find why this prototype isn't working.

I wonder whether the fault is at the iBeacon API/CoreLocation framework or the hardware beacons used? From your description above it sounds to me the hardware beacons are of questionable quality (low quality batteries and bad antenna maybe?)

I thought this too. But even with the plugged in RadBeacon (http://www.radiusnetworks.com/ibeacon/radbeacon/) and no EM interference between it and the phone, I was still getting extremely spotty results.

It's most probably a combination of all random variables (EM interference, beacon hardware, software, phone BLE antennae, etc) that makes it so frustrating and practically non-deterministic.

Have you tried emulating iBeacon with iDevice or a Mac? I'd consider those to have high quality Bluetooth chips and great antennae. If it is still not ideal, the blame could be on the software stack or maybe the whole idea is flawed :|

> ... then turn 180 degrees so that you are between the phone and the beacon. Apparently you've moved 45ft.

Why don't you fit the beacons on the ceiling?

You're right - antenna placement is super important with any real-world practical implementation. However, placing them on the ceiling/floor is not always an option.

Is there a specific reason for the coin cell batteries?

I would be much happier paying the same amount for something that looks like a AA battery and will last a few years.

I got some demo units from these guys[1] that use AA batteries for that very reason.

no affiliation. haven't tested the units yet. [1] http://www.bluecats.com/

I think it's size. Most beacon companies are doing what the phone companies are doing - slimming everything down.

Batteries last 5 years in very dry packages under 90 degrees Fahrenheit, but this might be a nice place to mention new coats for batteries; PD&D Magazine mentions them as cutting the electrical damage bit out of the swallowed batteries risk. Then I would ask about the naivety of supercaps, now with catastrophic conversion -over- 110 degrees Celsius (or when ingested, I suppose.)

I don't know why everyone is talking about pushing ads in the first place, whenever BLE beacons come up. As if the visual clutter created by outdoor advertisement wasn't enough, now I'll get garbage on my phone? No, thanks. Really, No Thanks.

As the article mentions, it's not obvious what value iBeacons provide compared to direct audio/visual information. For the same reason QR codes never took off. Ever since QR came into existence I haven't seen a single person who'd voluntarily scan a code (or an NFC label for that matter) in the street, anywhere in the world.

Clearly iBeacons/QR/NFC are not interesting in terms of providing information "on the spot", let alone advertisement. OK, then maybe microlocation? Finding lost items? Checkin/checkout? Payments? I don't know, none of these is so unique and indispensable that it triggers the excitement light bulb in me. Most of these things can be achieved somehow else, except maybe finding items lost within 20-30m from where you are.

Maybe the problem is that iBeacons are a bit too passive/static. But even a full BLE device that can transmit a bit more complex information is still debatble in terms of value. Where are the BLE A/V remotes, why aren't they replacing the IR ones? Would you trust a BLE baby monitor? How important is BLE for fitness tracker users? (Answer: somewhat, but if BLE never existed everyone would just use the USB connection to charge and exchange information at the same time, no big loss).

Plus purely engineering problems, such as unreliability, poor battery life, etc.

So let me be that guy who turns out to be wrong some years from now, but: despite the hype BLE turns out to be a niche technology with poor capabilities and questionable benefits.

I think the technology here is so deceptively simple and generic that it's hard to say what the true killer use case is yet. It's definitely unfortunate that the "ads" examples are the most prevalent. Despite that, I'm betting devs will find cool and novel uses for it.

Public transit is one of the more compelling uses for beacons. If every bus, say, transmitted their vehicle ID you could improve the real-time experiences in third-party apps.

For instance, to precisely know which vehicle you're on when showing arrival estimates or vehicle locations. You can also determine a bunch of other contextually aware info when you know which vehicle a user is on (traffic delays, detours, trackwork, etc)

I feel like, as for QR codes, there are industrial uses for this tech. I think consumer use will be very very niche and not widespread at all. Perhaps things like beacons in a museum or archive or library to help you navigate it faster or in an exploratory way.

>I haven't seen a single person who'd voluntarily scan a code (or an NFC label for that matter) in the street, anywhere in the world

Post-men do it all the time.

>Maybe the problem is that iBeacons are a bit too passive/static. But even a full BLE device that can transmit a bit more complex information is still debatble in terms of value

You are missing the point, too. I guess, the value of iBeacon is in reception, not transmission, as is also said about RFID terminals, while it still may have some other use.

Post-men don't do it "voluntarily", by which I mean e.g. out of curiosity, whereas the purpose of advertisement QR codes is just that. "Wow, look an advertisement QR code, I should definitely scan it and see what they are offering!". Really?

despite the hype BLE turns out to be a niche technology with poor capabilities and questionable benefits.

While I agree that beacons are over-hyped, I think it's worth pointing out that BLE does other things that I think are more useful. Being able to talk to devices without having to perform the awkward pairing process, for example.

Pairing is an equivalent of connecting devices with a physical wire. When you stream music you want to know exactly where it goes, or e.g. which BT headset is connected to which phone in the room.

Pairing can be combined with connecting in a lot of situations though, and I believe the Bluetooth standard, as well as implementations are moving towards simplification. For example, I'd rather have a list of BT audio speakers around me directly in my music player app, then I'd just tap on one of them and hear music playing straight away. This is a protocol/API/UI issue rather than a fundamental limitation.

I've always thought BT pairing kind of backward - the computer is the 'master' in the protocol; the headset is the 'slave'. But its the headset I have picked up; I know which one I have in my hand, but the computer (iphone/music station) knows about many of them. So I have to select one from a list, and maybe I don't know which one in the list is the one in my hand. MAC address? really. How about vendor string? What if I have two of those? A mess.

Instead, the headset could scan for the computer, select it and voila we're bound.

True, and actually some cleverly designed BLE devices advertise only for a limited time after pushing a button. I don't see why classic BT devices shouldn't do the same and work (almost) like you described: only advertise for a minute or two when asked to, and shut up for the rest of the time.

Using un-paired BLE devices you can do things such as adhoc mesh networking, which isn't possible with "old" Bluetooth. That's kind of cool, and possibly useful.

I agree that general Bluetooth usability could be improved - having to switch to an OS-provided, generic "add device" wizard before being able to use any Bluetooth device is just UX murder.

Agree! With http://tah.io/get we have tried to make use of BLE not just as beacons but also for combining the power of your physical sensors with 'smartphone' sensors to have much more interesting use cases!

Like what, for instance?

Stuff like this: http://docs.tah.io/examples With a bunch of shields you can add more functionality

Which one of them uses exactly the iBeacon protocol?

"What we call a Beacon today was originally invented and popularized by Apple way back in 2013 when they introduced the iBeacon API." --> It's funny (and sad) to see how Apple is given credit for "inventing" so many different technologies.

Based on several months of experimentation last year when iBeacon dropped, we concluded that Beacons will be more pervasive in personal automation rather than business automation. The author of the post talked about some great business use cases, but in general these expect the user to have the beacon's corresponding app. For any kind of app, the user has to opt-in, so the apps they are most likely to opt into are the ones where users install the beacon themselves in order to have a corresponding app on their device automatically adjust to their location.

There is also much more value to the user in personal automation, and it isn't fraught with the privacy/scaling issues that business automation ideas are. In the grocery store example, how does the app know what the user has in their cart? How many times will it remind the user to pick something up (i.e. what is the user's "push message annoyance threshold")? What if the user decides they no longer need eggs, but the app keeps reminding them to pick up eggs - the friction from opening the app and having to remove an item from a shopping list just so the store's beacons will stop annoying you to buy it will make anyone seriously weigh the value of having the app in the first place. As the author pointed out, beacons in a commercial setting have enormous potential to annoy the hell out of consumers.

What I really want is a beacon that I can install in my home office, and another that I can install in my work office, so my computer can automatically open up the workflow I had open when I left yesterday. A great side effect of this is that I would be much less inclined to start the day with a dosage of HN.

These kind of experiences are entirely up to the app developer to implement properly in a way that's not annoying like you describe. It can be done in a way that is nice (i.e. not notifying over and over). Not saying they'll all do it right at first, or even for a while.

i use screen for that

Beacons.

The thing where everyone has some idea of what they want people to see it as useful for (Ads, etc), but don't understand how to jive this from what consumers want from them.

At this stage, it still looks like a technology solution in search of a consumer problem (it certainly solves the "how do i push indoor location based ads/etc" problem, but consumers don't care or want that).

Watching most of these companies is like watching microsoft announce the xbox one.

Everyone tries to sell indoor location, but there are better ways to do indoor location, cheaper, than placing $200 of beacons and meticulously mapping where you put them. So that isn't going to go very well over time (highly likely to be supplanted by something better).

Even some of the examples are just a result of otherwise poor planning on companies part.

For example, i don't want to know "things on my shopping list are nearby", i want to know, ahead of time, exactly where the things on my shopping list are.

It's only recently (past year or two) home depot or lowes would even tell me what aisle stuff was in. I still can't go to a safeway website and get an idea what aisle my items are in.

In some cases, this is deliberate - they want you to have to browse. In any case, beacons solve none of this problem (except maybe the "i'm in aisle 46 and i still can't find x" problem, but the distance issues often stop this from being particularly useful use case).

I struggle to think of an interesting use case on the consumer side for beacons.

Maybe locations for things that move like booths at a farmers market or something.

What would be some of the better alternatives for doing indoor location? It'd help me a bunch to see a few examples, as I was previously thinking of beacons for this purpose.

You can do a better job of indoor location by using tv signals, than you can with beacons.

(All of the antennas are registered, along with type, propagation, etc, with the FCC, and they produce a large database)

Not that TV signals are great.

But even the bluetooth group itself says not to use beacons:

"According to the Bluetooth Special Interest Group,[24] Bluetooth is all about proximity, not about exact location. Bluetooth was not intended to offer a pinned location like GPS, however is known as a geo-fence or micro-fence solution which makes it an indoor proximity solution, not an indoor positioning solution."

Interesting thought. But I can't sample TV signals from a mobile device. I'm looking at applications that can be implemented underground as well, unique use case. And in this case, proximity might be just fine enough rather than positioning.

"Interesting thought. But I can't sample TV signals from a mobile device. "

You couldn't sample FM radio or GPS from them in the past either :)

But honestly, i don't expect this to take the world by storm either, i'm just pointing out it's a better possibility of working for the use case of "indoor mapping".

" I'm looking at applications that can be implemented underground as well, unique use case. And in this case, proximity might be just fine enough rather than positioning."

Underground is really hard, yes. If all you care about is knowing you are within 40 feet, great.

Truthfully, specialized wifi points are likely to be better for indoor positioning than bluetooth.

So drop the GUID in favor of a simple coordinate system -- you have enough space for a latitude-longitude-altitude triplet, with a reasonable amount of precision.

Then you need to program your beacons at the time of placement, using whatever locating system you have that works but is too bulky/expensive/power-hungry/hard for users to use.

There are companies using Kinect to track users travelling through retail stores. There's also using existing WiFi recieved signal strength, which is not terribly granular but benefits from existing infrastructure.

> * In fact, referring to these devices as just “Beacons” is a bit funny, considering no one was talking about Beacons before iBeacons existed.*

Well...I recall unpaired advertising events in the Bluetooth 4.0 Low Energy Spec back in 2010 - way before Apple ever got involved.

I was doing an internship at a big semiconductor company the summer announced iBeacon. They had something very similar in the works (presumably started about the same time as Apple), and called them beacons - they certainly worked by exactly the same method.

Absolutely ... this wasn't an entirely new "invention," although Apple's technique of cramming their metadata in the spec is definitely novel, although nonstandard.

Mmm, I'm not so sure. If you read the Bluetooth 4.0 spec [1], it's very obvious on page 1047 (numbered 801 in the pdf) the exact advertising format, with its block of bytes for sending data. Sending a UID would be exactly what you would do, as a first approximation. There are actually much more interesting schemes that can be used - say if you don't want your competitors to be able to derive any information of their own from your beacons.

[1] - https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?d...

Around 2003/2004 a local magazine called NAG (http://www.nag.co.za/) had an opinion piece at the end in which the author theorized using beacons for an inverse purpose: attach Bluetooth fobs/beacons to your keys and then triangulate given how your phone scales the signal strength of the BT signal. IIRC it would have only worked with Nokias because no other brand implemented this Bluetooth power consumption optimization spec. I do remember the article indicating that such beacons could be found with a little bit of effort.

The only piece missing from the puzzle was that phones only have one Bluetooth aerial, so triangulation would have been impossible. It would still be possible to determine unitless distance.

The handheld phone is moving, the accelerometers track it, it's no problem; since beacons happen only every 10s, you should make kale juice and do stretches then look, or wait for the drone to spam light near them (because they're still black keys.) It's not an instant joy and the antenna gain to make it so...

It rarely matters who is first.

Beacons are being used as a micro-surveillance tool [1,2]. And that is the only prominent use they have found, among all the ones listed. Interestingly Gimbal, is a Qualcomm company or rather was a Qualcomm company as it was spun off [3]. Gimbal also had $5 beacon giveaways [4]. Gimbal had embedded its beacons in phonebooths in Chicago, LA and New York [1, 2].

[1] -http://www.buzzfeed.com/josephbernstein/exclusive-hundreds-o...

[2] - http://www.buzzfeed.com/josephbernstein/hidden-beacons-were-...

[3] - http://www.fiercewireless.com/story/qualcomm-spins-gimbal-be...

[4] -https://www.qualcomm.com/news/releases/2013/12/09/qualcomm-a...

They can only be used as "micro-surveillance tools" once you install an app that shares your proximity to a beacon with a remote server... and by installing a 'malicious' app you've already lost.

Yes, an app is required to trigger the surveillance since beacons are one-way, but not really a 'malicious' app install. If tomorrow candy crush/angry birds want to tap into the gimbal database, well congratulations. Worst, if FB/Google want to tap into the database, nearly every android/iOS phone with BLE on will be a target due to their massive app install base.

What about beacons being not so one-way? Assuming you enabled the beacon on your own phone for whatever reason (some fancy app), then information can be gathered easily without you giving permission or noticing at all.

Absolutely true, but this is also possible with just about every other technology today. "Bad Apps" can report information about Beacons, GPS, or any other sensor on the phone they have access to.

Hm, maybe not so easily with other technologies. GPS is a passive thing and you can select which apps can use it. Beyond that or outside of your phone nobody will be able to register your location.

WiFi is active and yes, wiretapping is possible, at least for locating you. Hardware/software for doing this though is not readily available as far as I can tell.

Finally, iBeacons: very simple software running on a passive BLE device that simply records all BLE UUIDs passing by, that's all!

The Gimbal 10 beacon line blows. Battery life is around a month at best. I literally changed all of the Gimbal 10 beacons' batteries in my office two weeks ago and some are at 50% power right now. But they were free, so tradeoffs...

Not to mention their sales team will chastize you for using them in iBeacon mode since apparently the price is subsidized by the use of their API.

Unsubsidized price then? No response.

Really cool technology. I think the really hard part is 'What is a good interaction?' Clearly the offer isn't too useful, but the hospital one seems good. In general, I think 'help me find stuff' and 'notify on exit' will be the dominant modes of beacon interaction. What do you all think?

It was surprisingly challenging to come up with just those two examples to be honest. I don't think we really know what the killer location-based notifications are going to be yet.

Personally, I really like location-aware app features. My favorite is search suggestions. If I'm in BestBuy and I open the app to the products section, chances are I want more details or reviews on the product I'm standing in front of. Why make me search for it? Have "smart suggestions"

The grocery store example is something I've been debating creating for myself. I have a hunch if I stick Estimote stickers underneath stuff at my grocery store no one will find them for a while.

Because if you're standing there on you're phone, there's more of an opportunity for their sales person to come over and upsell you on their Service Plan.

Think about it from their point of view :)

museum self-guided audio tours

It seems apps have to be built to recognize a fixed set of beacon IDs. Is it possible for apps to discover and monitor a dynamic set of beacons, including beacons intended for other purposes? I'd like to be able to tap into existing beacon networks for my own app's use, but that would require being able to detect their IDs, present them to the user in some meaningful way, and then have my app watch for them.

Another scenario where this particularly matters is allowing multiple devices (phones, tablets, PCs, watches) to "pair" and keep track of their proximity from each other.

Scanning for arbitrary beacon IDs is not possible on iOS by Apple's design. You could certainly do that on Android however.

Interesting. So is it possible for Apple devices to dynamically exchange their beacon IDs amongst each other (perhaps via an app's back-end service) to enable my second scenario of devices being "paired" and monitoring proximity to each other?

For beacons, it does have to be a fixed list of UUIDs. The beacons also cannot detect the device which is monitoring it.

However, you could use the BTLE GATT profile. This lets you expose services & characteristics/attributes. It does allow for two way comms.

How do you manage 1,100 beacons at once App side?

I thought Apple limited you to 20 region monitoring locations at a time, or are the beacons treated differently? Just logic around which 20 you're looking for at any one time?

For region monitoring (typically used for the "notification" case) the limit of "fences" is indeed 20...it gets into a bit more detail about "what's a fence" [edit: most of the time you can assume one monitored beacon == one fence]. But for "ranging" meaning "what beacons with this UUID are around me", the system gives you a report of visible beacons every second with no (defined) upper limit.

You can monitor for one region per UUID, meaning that if all of your 1100 beacons share the same proximity UUID, then you should be good.

While this is a very useful article, recurring attempts to convince readers that privacy is not an issue had an opposite effect on me. I didnt even know spying was a concern, but when out of the blue I'm told "dont worry about privacy", and told five times in a row - well, this makes me suspicious :) More unfortunate is the fact there is only one argument, served multiple times under different sauces: don't use the app if you think it does something creepy; vote with the delete button.

And this is actually a poor excuse:

concerned that google stores your search history and has your email? - dont use google.

Don't like Facebook sharing your friend list with advertisers? - delete your facebook profile.

Don't want your browsing history agregated and sold to the highest bidder? - stop using websites

Worried that government listens to your phone calls and reads your text messages? - move to another country.

To me these constant remarks about how you are always in control of your privacy were just annoying and not convincing at all. The article would be better without that.

While I like the minimalism of the beacon API, I wonder if it doesn't limit the usefulness of this technology, as it leads to an over-reliance on mobile Internet (apps need to fetch information after detecting a relevant beacon) and/or preinstalled apps (which will probably not talk to each other very well).

It'd be interesting if beacons could send some structured data along with their identification header. This way you could have general purpose apps which handled common types of beacon data, and an user wouldn't have to install MegaWorld, GroceryMart and BigHealth to get generic grocery or health-related notifications.

For example: if there was a standard beacon format for bus routes, I could install a BusRoute app which would let me see bus routes for any beacon-enabled bus in the world, even in places where I don't have an Internet connection.

It's still possible to have a general-purpose app for beacons, you just need to make that structured data available in a standard format on the Internet.

You could treat the UUID as a domain name, have a DNS-style system where an app looks up a UUID, gets some structured data, and caches it.

That does mean, for your bus example, that you would have to have seen one of those UUIDs before while internet connected, in order to have the route data already cached.

If someone is going through the effort of placing bus beacons, there's a good chance that the location either already has good data coverage, or they could place a wifi hotspot at the same time.

---

Alternatively, certain UUIDs could be taken to mean "connect to this device over wifi, and download structured information". This does have the battery issues mentioned in the article, but I expect that, for permanent installations, people will prefer externally powered beacons anyway.

It's a tradeoff. Packing more data into the beacon would mean more spectrum used per beacon - also, changing what the beacons are saying is much harder than flipping a switch on a cloud server.

Also it's not required that you go talk to the internet after hearing a beacon - if you already knew what beacons to look for and what to do about them, you wouldn't need to use the internet at all to create "local notifications."

If I had the coding ability I'd play around with these:

- home automation, get home in the dark & lights go on or other possible location based activities.

- conference badge/phone app, allows user to interact with displays or other conference attendees + more

- other ideas.

IMO advertising via bluetooth would make people turn off bluetooth, and leave it off.

Do you know (can you share) if the WiFi and BLE networks at Levi Stadium were designed with each other in mind. I am wondering if it is truly as easy as using "a network that the venue probably already has" considering that all of the Beacons would need to be in BLE range of a WiFi device. I don't know enough about the ranges of each different technology or how their signals interact with all the various material that would exist in a football stadium. However I imagine that if you were designing these two networks in isolation, there is a decent chance that the required placements for full Bluetooth coverage and full WiFi coverage would leave some Beacons that aren't reachable.

Wifi-Beacon interop is quite new; it turns out the Wifi network at Levi's is really dense so it does have insane coverage. Also the Beacons are surprisingly visible even without further interop tricks - you can see them across the stadium at times.

My colleagues at Shopster [http://getshopster.com/] are implementing really awesome indoor navigation project with 300+ beacons installed in largest Russian mall. See demo: http://www.youtube.com/watch?v=VAM4bJst2Jw

And yes, we built custom beacons on top of OpenWRT routers & USB dongles –> hence high frequency updates, high power & no battery dependance. Also we built a mechanism that allows us to update majors/minors/uuids so that no external party can use our beacons.

Battery beacons are only usable for a couple toy usecases in my opinion.

How hard would it be to log all beacon identifiers detected by your phone and then have your phone (or another device) cycle through the list and rebroadcast them continuously? Seems like you could have some fun at large events with that.

I'm more impressed that phones can get any positional info from beacons. Determining distance to a radio source is hard with any fidelity - light is pretty fast.

So can phones get decent info about distance to any WiFi/bluetooth source, or is there something about beacons?

I think a cool use would be some sort of high tech paintball game. Have objectives to hold with beacons, and a listening device on all players guns. You can earn points by holding certain positions. You could come up with some pretty fun/dynamic scenarios.

Yeah, that was my reaction - AR gaming would be the killer app.

Also, my wife works at a school that allows students to sign out of their classes into other classes. Beacons would be great for this - "student X is not in the room they said they'd be in".

Am I the only one who keeps my Bluetooth and Wi-Fi turned off unless I am specifically using them? I do this both for security/privacy and battery reasons.

Beacons are nifty, but buying shoes is comparatively boring. Why do consumers get soooo much attention from these smart people selling smart phones?

I think everyone's trying to save retailers from Amazon :)

you can try to use Core Bluetooth devices as tags: http://bdp.linkstore.ru

Carry a beacon (or a bunch of them) with you into a shop and the store will recognize you the next time you enter. That's handy! It's like a cookie that you physically bring every time. ~

Or, in other words, no thanks.

Boy oh boy, this technology is going to run into a lot of misinformed speculation like the above. I know that YOUR LOCATION DATA is super important to you and all the technology ghosts are trying to steal it from you but that is not how this works.

Who is suggesting that users would carry beacons?

Only the specialized economists who suggest people would ever need to have signs, surely. Also, the rare restaurant that wants to garner advocates. Then perhaps amateur entomologists. Works engineers who want to know when something erodes would surely bury fiber optics rather than a RFID or battery device with 30 year lifetime.

Nobody would use beacons this way. They don't have to -- your cell phone, if it passively scans for Wi-Fi, will check into the local access points for you.

Shops will have beacons, not you.

Reply on news.ycombinator.com