0

I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)

There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.

I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.

I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.

However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.

I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).

Some constraints I'm working with:

  • The peripheral is battery powered.
  • The usual search and pair method must also still work.

My own half-baked ideas:

  • Make the peripheral able to be a central too, but then does that introduce more nuances and complications?
  • Broadcast from the peripheral, "whoever has X mac address, please connect to me"
  • Put a similar message in the advertising packet and increase advertising rate.
  • Directed advertising similar to above?
Kenzi
  • 1,059
  • 8
  • 10

1 Answers1

1

You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?

Emil
  • 16,784
  • 2
  • 41
  • 52
  • Yes it does! I'm curious what other possibilities there are, and what the implications are ... just to make sure I'm not doing something absurdly silly just to get the connection to happen. – Kenzi Mar 02 '17 at 18:11
  • 1
    Since when programming the central, you must configure exactly what peripheral you want to connect to, I guess otherwise the only way is that you advertise the pair of bd addresses that should be connected is the only way. If you switch role in the peripheral and start scanning, that will consume a lot of power. – Emil Mar 02 '17 at 18:15
  • Would it make sense to send the central's mac address in the blob, then put that address in the "Public Target Address" field of the peripheral's advertising packet, then have the central automatically connect to any [supported] peripheral that has that field as a match to its own mac? Or is that field really not meant to be used that way? – Kenzi Mar 02 '17 at 18:56
  • Yes that is one way of doing it if your central software supports handling that. You however have to use ADV_DIRECT_IND which is quite power hungry since it uses an advertisement interval of at most 3.75 ms. Also, the defined directed advertising procedure should only last for max 1.28 seconds, so that might be a problem if your central doesn't get the signal. Since there is no procedure to connect to the first device it sees, you have to still on the host side handle the advertisement packet and then initiate the connection to that address. – Emil Mar 02 '17 at 20:25
  • ... but since ADV_DIRECT_IND is only meant to be used for fast reconnections I think you should rather use a standard ADV_IND packet and define some custom manufacturer data or service data and include the address in there instead. – Emil Mar 02 '17 at 20:26