search

lancaster-university / microbit-dal

http://lancaster-university.github.io/microbit-docs
Other
254 stars 130 forks source link

Beacon services #166

Open ghost opened 8 years ago

ghost commented 8 years ago

I see there's some work in hand to make it possible to turn a micro:bit into a Bluetooth beacon. Excellent.

The current code is focused only on EddyStone however. It would be nice to also support AltBeacon and (if trademark rules allow it) iBeacon too and give micro:bit developers the choice.

On EddyStone I see the code is currently cycling through of the 4 sub-frame types. Is this correct? I don't recall reading this but that doesn't mean it's not correct. In my mind you'd either want to broadcast a location identifier (UID) or a URL. It would make sense to let use of the service indicate which frame type(s) are to be broadcast and perhaps in what order. Maybe add a method to let you add advertising frame content before initiating advertising?

finneyj commented 8 years ago

Afraid I don't know the spec well enough to comment here... Although I thought cycling through the frame formats was part of the protocol (saw a dude from Google give a talk on it once a while ago).

@jamesadevine did the integration here, so I'll hand this one over.

p.s. We have about 200 Eddystone beacons heading to Lancaster from Google just for the fun of it shortly. if you have any ideas for interesting projects, do shout! :-)

ghost commented 8 years ago

You may very well be right. I gave the spec a cursory glance last year which I was hoping would make me an 'expert' ;-)

Worth checking I suppose. I will do some digging if I find the time as I'd like to be clear on this either way.

ghost commented 8 years ago

Confirmed. The spec says "Eddystone is a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages. It describes several different frame types that may be used individually or in combinations to create beacons that can be used for a variety of applications".

So I think we need the ability to programmatically define the EddyStone frame types that will be advertised and in what order. I can't see it being possible to include multiple frame types in one packet.

It occurs to me that there may be a cost to changing the advertising packet content regularly since it requires the controller to be 'informed' every time, advertising stopped, the config changed and then advertising restarted. At least I believe that to be the case. Only mentioning this thought fyi.