Help With Code for Objective-C

BLE Beacons
1

Okay so I have an idea but am struggling with implementation!

Firstly imagine 20 beacons all positioned on the ground floor in a building.
Each time someone walks past a beacon I want to play a sound.

This is easy enough but it gets more complicated:
The beacons are relatively close together, let’s say on average they are 15 metres apart but I don’t want the sound to play again if they haven’t moved far enough away.

For example:
A person walks near beacon 1 and the sound plays (perfect) BUT if they only walk say 5 meters beyond it and then doubles back I don’t want the sound playing again otherwise it would become rather tedious. The person would have to have walked at least 10+ meters away before the sound will play again the next time they are close enough.

Let’s then say they walk away but only walk 8 metres away (not far enough for the sound to play again if they go near it). It’s likely they might have come into range of another 1 or 2 beacons at this stage and I start to lose track of the minor value of that first beacon and the distance from it.

So what I’m asking is how would I keep track of all the beacons the person has got close enough to and whether or not the sound has played for that beacon and how far they have moved away from it before determining to play the sound again?

I’m not sure if that makes any sense but if it does I sure would appreciate some help.

Thanks :smiley:

2

I’d use ranging + some hand-coded logic to keep track of which beacons were recently “visited”. In pseudocode:

visitedBeacons = []

func didRangeBeacons(listOfBeacons) {
  foreach (beacon in listOfBeacons) {
    if beacon.distance < 1m && !visitedBeacons.contains(beacon) {
        playSound()
        visitedBeacons.add(beacon)
    } else if beacon.distance > 5m && visitedBeacons.contains(beacon) {
        visitedBeacons.remove(beacon)
    }
  }
}

Two things to keep in mind:

  1. Ranging works only in the foreground, i.e. with the app on screen. There are some options we could discuss if you need it to work in the background though.
  2. Distance estimations are just that: estimations. Why is that? We cover it in great detail in our The physics of beacon tech blog post.
3

Thanks for that. Basically I need to get the accuracy as good as possible. I work for Guide Dogs in the UK and had the idea of using beacons in all our offices so that when someone with sight loss visits our offices they have a better understanding of where they are in the building.

I initially set up 3 beacons that would relay a message using speech on the phone to describe where they were. I then realised this could become rather annoying so have now changed it to a very gentle ping when the user is in range (at a particular distance, this is when I refer to needing accuracy) and then the user can choose whether to listen to the message by tapping and holding the screen.

Currently the concept of the gentle ping works really nicely and although the accuracy is not bad I’d like to refine it.

Thanks for the link, I hadn’t seen that before and is very useful :smiley:

4

Sure, makes sense. We’re doing a lot of work around fine-tuning distance estimations as part of our Indoor Location SDK. We’ll eventually port all of that work back to the regular SDK, so that non-Indoor apps can benefit from our (honestly, quite sophisticated) algorithms too. That’s a few months down the line though.

5

That’s really good to know that you’re working on fine-tuning the distances. Not sure if you’d look for any Beta testers but I’d sure be happy to give it a try especially as my deployment purpose needs the accuracy. Are you saying the fine-tuning you’ve done is already up and running in in the Indoor SDK? The reason I ask is I have now ordered another 3 beacons so that I can try your indoor SDK which looks very cool in the video.

Also are you referring to BLE 4.2 when you’re referring to fine-tuning or is that something Estimote isn’t considering right now?

6

Yup, the fine-tuning I’m talking about is already included in the Indoor SDK, but at the moment it’s for internal purposes only and we don’t expose the smoothed-out distance estimations in a public API. That’s what I had in mind when I mentioned that we’ll be porting this into the regular SDK: it’ll become publicly available.

I don’t know of any smartphone devices that’d fully support BLE 4.2 already. We’ll definitely continue monitoring the situation and once 4.2 adoption rises, we’ll consider it.