Beacon Gateways

Though the Beacons you create are fantastic and ahead of the curve from what’s already out there, are there any plans for you to create a Gateway device that would allow the aggregation of Beacon information to be linked to your or other cloud based systems.

Our need which I am unable to see a workaround with your beacons is to essentially have the beacons tracking the beacons.

With new products coming to market, it would be a shame to have to leave the estimote family, but having a specific technology requirement that I don’t believe you provide may take that choice out of my hands.

We ourselves strongly believe in using what everybody already has in their pocket—a smartphone—to do all the scanning. With gateways, you have to power them, you have to have WiFi so that it can upload data to Cloud, and since it’s usually static, you actually have to deploy a dense grid of them in order to cover the entire area. With smartphones, they are already powered and people recharge them every day. They have always-on 3G/LTE. And people move around with them, making the smartphones little mobile scanners, “crawlers” almost, for beacons.

We even built a prototype of such solution ourselves, into our Indoor Location demo app:

Of course, we’re still seeing developers building their own gateways with super-cheap commodity components, like the $35 Raspberry Pi 3 with Bluetooth and WiFi. There’s a ton of 3rd-party Linux libraries for scanning beacons out there, ready to “plug and play”. And we ourselves are also committed to open-sourcing our packets, so that developers can parse them on their own if they want, however they want. (e.g., Estimote Telemetry packet specs) We ourselves may not believe this is the best option, but hey, it’s an option, and you can totally do that (:

I think this is a great conversation to be had, and I’d love to put it in more context—what’s your idea/use-case for the gateway?

Our current requirement (ideally I should add) is to use beacons as in this example.

We have a device which we build the beacons into, for example an order for a coffee. The customer takes this unit and finds somewhere to sit down. This maybe anywhere within the building or maybe outside.
When the customer find somebody, the beacon is then stationary and we and identify where they are for a quick delivery of their item when ready, This data would then be fed back to a system which would identify, maybe on a screen where that customer would be.

My misguided idealism is that with the long battery life available within the beacons, we could use one set of beacons which as normal indoor tracking would be stationary and fixed around the location and an additional beacon built within the device to be passed to the customer.

Though yes, we have looked at and successfully built systems with both Raspberry Pi 3 as the collector (the fixed beacon locations) and as Raspberry Pi 3 as the item being tracked, they give us two issues that are not suitable for using in a scale able business product.

1). They need power. Yes they can be run from battery packs, but even with the Pi Zeros, the power consumption is too high. Building in a rechargeable system into the units and the back end for that makes the product cost prohibitive.

2). They are fragile. There are too many things that can “just go wrong” and with hundreds if not thousands of these being deployed, the ongoing maintenance is not something that I would want to manage. Again the cost of providing that would make the end result cost prohibitive.

There are plenty of similar systems already on the market, using both RF and WiFi connectivity, but BLE with it’s stability, portability and long individual battery life makes it a very compelling product to use.

There are new devices coming onto the market all the time, with the new generation of BLE beacons being able to run code directly on them, allowing for the ability to create mesh networks and conversations between devices which would create this very outcome. The market for BLE is not just for those who have a phone in their pocket.

Look through your own forums and you will see there are plenty of posts from others looking for the reverse scenario of what you’re creating and something that some of the other early adopters of BLE have already seen and are bring products to the market this year.

I agree the reverse scenario is absolutely great for many use cases—heck, I myself have built many, many apps for RPi’s and Intel Edisons that scan for beacons, stickers, telemetry, etc. during hackathons. It’s just, like you noticed, it’s technically more clunky that using the smartphone, for all the reasons I gave above—you have to power the receivers, you need to have WiFi or have a receiver with 3G/LTE, etc.

The scenario you described, i.e., beacons scanning for other beacons, is not really feasible at this time. The sole reason why a beacon can last years on a small battery is, it spends most of its time sleeping, only waking up for a few nano/micro-seconds to broadcast a packet. And then back to sleep for 100 or 300 or 950 ms. But scanning for other beacons would require it to be powered for much, much longer, and then the battery would drain much faster. Take a very close look at those mesh solutions you mentioned, and you’ll notice that they either require you to power the beacons, or can only transmit very small amounts of data rather infrequently.

This is not to say we’re not working very hard here at Estimote at trying to figure this out :slight_smile: Innovating takes time though!