Which SD and Which Roles Do I Need?

RE: Which SD and Which Roles Do I Need?

Petter Myhre — Tue, 23 Dec 2014 14:56:27 GMT

If you are in a connection, maintaining the link has high priority. If you prioritize serial communcation over maintaining the link you will most likely get a disconnect. Then you would have to connect again. If you must do your serial communication during a connection, you should do this inbetween connection events, by using the radio notification event handler or the timeslot API (see Section 8 in the S110 SoftDevice Specification). If you are not in a connection then you might lose a few advertising packets. This is not critical, as long as you don't have any tough real time requirements.

RE: Which SD and Which Roles Do I Need?

Jeff Wormsley — Tue, 16 Dec 2014 19:13:11 GMT

Thank you. This was very helpful. At the top level, the board should not need to talk to both the device and the phone at the same time, it should be more lockstep than that, but there may be lower level things going on with the radio that I don't know about. Hopefully the radio can retry, so that if I need to spend 50 or 100 ms sending a pulse to a device, the radio can recover from the interruption. Until I get farther with the evaluation board to test these things, I won't know for sure if this is a problem or not, and that's probably many weeks away.

Jeff.

RE: Which SD and Which Roles Do I Need?

Petter Myhre — Tue, 16 Dec 2014 15:18:28 GMT

There are four GAP roles, explained in Vol 3, Part C, Section 2.2.2 in Bluetooth Core Specification 4.2. These are related to the different states in the link layer, see Table 2.1-

A Broadcaster can only advertise, while a peripheral can advertise and be in a connection (in the slave role).

Your evaluation seems correct, you need a peripheral. The phone will be a central.

There are two GATT roles, explained in Vol 3, Part G, Section 2.2 in the Bluetooth Core Specification 4.2.

The device with the information is usually the server while the device that wants to access the information is the client, so you evaluation seems correct again, you need a server. The phone will be a client.

SoftDevice S110 is our peripheral stack, so it is suitable, and most of the SDK examples also implement a server.

A peripheral can be connected to multiple centrals (phones), but not at the same time. A central can be connected to multiple peripherals at the same time.

Your interrupt requirement is more complicated. If you are in a connection, maintaining the link has high priority, so some connection events need to be handled, but it is usually not a problem. If you are not in a connection, it should certainly not be a problem, but it depends on the requirements of your serial communication. If you come into trouble on this, I recommend you to raise a separate question.