thaliproject/thali

We need to decide what to do about the manufactuer ID mess

Closed this issue · 1 comments

yaronyg commented

Right now on BLE we ran into an issue where some devices will not allow us to set the service type information so we can't advertise a Thali service on those devices. We have a work around that those broken handsets will allow us to set a manufacturer type which we can use to help others find us by using a manufacturer ID but that really isn't kosher since we haven't registered that ID.

Originally we thought what we would do is just support both, we would test a device and if it supported setting the service type then we would use services otherwise we would use manufacturer. The reason we decided against doing both is that we were concerned that if we tried to set two filters for incoming BLE announcements (one for manufacturer and one for services) that the hardware wouldn't handle it and would require the filtering to happen in software which would be extremely battery intensive. We haven't proved that this is the case but we were very worried about it.

So for now we have decided just to use the manufacturer type. This then ran into another issue which is that when we want to notify people that we have a new set of beacons we don't want to stop and start BLE because stopping and starting it a lot seems to cause instability on Android. The reason we would have stopped and started is because that would have given us a new BLE address with each stop and start and that would have acted as a signal that we had new beacons. E.g. if you see a BLE address that you haven't seen before then you know that it must have beacons you haven't seen before.

Instead what we are now doing is that because we are using manufacturer type and because that type is smaller than a UUID (it's only 2 bytes) this left us another byte worth of space to work with and so what we are doing now is anytime the beacons change we change the value of that extra byte (and yes, this does mean if you miss 256 updates you will get a roll over). We could, btw, use two bytes and we probably should but right now we are just using one.

So the problem is that we really shouldn't be using manufacturer type because we don't really own that value. And the 2 bytes (of which we use one) is not really a great protection against possible collisions. It also isn't great because it makes it harder to filter out duplicates since even if we have seen a particular BLE address we have to always check its announcement to see if it is token counter value (that extra byte) has changed.

So the questions are:

  1. Do we just ban phones that don't support service data (as required by the spec) and so stop using manufacturer type? If we do ban those phones then we need to switch from using Manufacturer type to just using service data.
  2. Do we really want to use these counter fields or do we want to experiment with start/stop to cause new BLE addresses? Note that if we want to use counter fields and we want to use service data then we only have a single byte to work with, not the two byte we have with manufacturer.
  3. When do we think we will switch to using a GATT server? If we do that then many of these issues might possibly go away.