Testing out BLE beacons with BeaconDB(blog.matthewbrunelle.com)
blog.matthewbrunelle.com
Testing out BLE beacons with BeaconDB
https://blog.matthewbrunelle.com/testing-out-ble-beacons-with-beacondb/
19 comments
The original mozilla MLS was killed off due to litigation by Qualcomm(I think?). MLS wasn't for commercial use and neither is this, so What's the licencing/sustainability difference between these two and what kind of support might be needed to keep this going?
Maybe Qualcomm hoped Mozilla had enough money to pay up in a bogus settlement? BeaconsDB is, as far as I know, just one guy.
I'm surprised that these things transmit at around 1Hz, I thought it'd be on the order of every 10 seconds to a minute. Given that I assume a lot of beacon devices are running on a coin cell battery I would have thought it would be slower. Or is that particular only to this device?
1hz seems slow to me. A company that I worked at was designing robust industrial, apple airtag/tiles with a specific application 8 or 9 years ago.
BLE operates on a very crowded frequency. WiFi, Bluetooth, etc are all on the same frequency and spamming out thousands of packets constantly.
We had to triple our broadcast frequency and period in order to reliably detect a beacon within 5 seconds of a phone being in range.
We settled on 200ms frequency and broadcast for 15ms.
Our decide had a 10 year battery life on a couple coin batteries…
BLE operates on a very crowded frequency. WiFi, Bluetooth, etc are all on the same frequency and spamming out thousands of packets constantly.
We had to triple our broadcast frequency and period in order to reliably detect a beacon within 5 seconds of a phone being in range.
We settled on 200ms frequency and broadcast for 15ms.
Our decide had a 10 year battery life on a couple coin batteries…
I find it very intriguing you landed on 200ms, considering the default beacon rate of the majority of WiFi access points is 100ms. Clients do not like going much longer before you start dropping beacons and discoverability tanks... which is shown in your results. Genuinely fascinating.
>We had to triple our broadcast frequency
What do you mean by this ?
What do you mean by this ?
I think they meant triple how often they broadcast, not using a radio frequency x3 higher on the spectrum.
That answers my question perfectly, thankyou!
1 Hz is slow. Apple's iBeacon standard specifies 10 Hz, for instance. Also, every packet is transmitted on three different channels, so there is actually quite a lot of traffic generated.
I looked into this a few years ago for a personal project. One reason why BeaconDB only uses WiFi APs for geolocation, is because they are usually stationary (excluding mobile hotspots) and so their location, once identified, can be used as a reference point for triangulation.
But the BLE beacons are by design small, portable and usually attached to a moving object. Since BeaconDB doesn't know whether a specific beacon is meant to be stationary or moving, its not safe to use it as a reference point for geolocation.
But the BLE beacons are by design small, portable and usually attached to a moving object. Since BeaconDB doesn't know whether a specific beacon is meant to be stationary or moving, its not safe to use it as a reference point for geolocation.
Way back in 2014, I once built a neat test of a product I wanted. I was CEO of a company that allowed an internet API to interface with bar/restaurant POS systems. We could open/close tabs, make orders, etc..
I always hated closing my tabs at the end of the night at bars since it could frequently take a little while for only a few seconds of work.
So I built an app that detected once you entered a beacon's area, and opened a bar tab for you with your name on it. You'd just go up to the bar and order as if you had a tab open already, and when you were done, you'd leave. If your phone didn't detect the beacon for 15 minutes, it closed the tab with your preferred credit card and tip (which you could edit).
We had a demo going for employees at Local Edition on Market street. It was really cool and worked really well. The issues came that exact position was not very exact at that time and I didn't think it was a feasible product to build and market since the installation of beacons at bars vs gaining users would be difficult.
But for a brief period, I never had to hand my credit card to a stranger or worry about getting stuck 20 minutes trying to close my tab.
If you like the idea, take it and run with it. I'm not going to do it but I feel like people would love it.
I always hated closing my tabs at the end of the night at bars since it could frequently take a little while for only a few seconds of work.
So I built an app that detected once you entered a beacon's area, and opened a bar tab for you with your name on it. You'd just go up to the bar and order as if you had a tab open already, and when you were done, you'd leave. If your phone didn't detect the beacon for 15 minutes, it closed the tab with your preferred credit card and tip (which you could edit).
We had a demo going for employees at Local Edition on Market street. It was really cool and worked really well. The issues came that exact position was not very exact at that time and I didn't think it was a feasible product to build and market since the installation of beacons at bars vs gaining users would be difficult.
But for a brief period, I never had to hand my credit card to a stranger or worry about getting stuck 20 minutes trying to close my tab.
If you like the idea, take it and run with it. I'm not going to do it but I feel like people would love it.
This is the first time I realized that restaurant POSes were open to something akin to a plugin. I'm guessing you had to set up everything for your test location. Was it more difficult than you would expect a non technical person to be able to do?
This was obsoleted by UWB and Apple’s Nearby Interactions API.
https://www.qorvo.com/innovation/ultra-wideband/products/uwb...
https://www.qorvo.com/innovation/ultra-wideband/products/uwb...
Interesting, because I do detect many BLE beacons in a residential building. These aren't bona fide beacons, this I can infer, but not sure what devices they are.
They could be anything from indoor location augmentation to hundreds of TV, headphone, pacemaker and other media/medical/anything-you-can-imagine devices.
Not quite sure what the author's project is, but these sound interesting.
Is there something like war-driving for BLE Beacons?
Is there something like war-driving for BLE Beacons?
Author here. I have a big backlog of posts, but I did this one first because I was trying to cram an explanation of BLE beacons into the project post.
> Is there something like war-driving for BLE Beacons?
Yup, that essentially what Neostumbler is! If you have an Android device go check it out.
My hope for the project is to make a little embedded device I can use, so I don't have to drain my phones battery. Also because it's fun to learn about a new topic.
> Is there something like war-driving for BLE Beacons?
Yup, that essentially what Neostumbler is! If you have an Android device go check it out.
My hope for the project is to make a little embedded device I can use, so I don't have to drain my phones battery. Also because it's fun to learn about a new topic.
Thanks. (iPhone user though. I'll look for another solution. :-))
Yes! the WiGLE project does Bluetooth geo-logging as well as WiFi.