Absolute minimum discovery

RE: Absolute minimum discovery

Hung Bui — Tue, 22 Mar 2016 08:53:42 GMT

@keith: Next time, when you want to give more information, please use the comment section, not answer, or you can edit your question to add more info.

As your required bidirectional communication, a connection is needed. You still can do connectionless by switching between advertiser and scanner, but I think it will bring more trouble.

It would take less than 3ms to establish a connection and send the first data packet. But as RK mentioned, it depends on how fast you advertise and how frequently you scan. Since you have interrupt on only one side (when you pick up the remote, and/or press the button on the remote), you can't do advertising all the time or scanning all the time on the other side. You would need to balance the latency and the power consumption.

And, yes, if you bond to the device, the Attribute table and the service context will be stored, and it would take a couple of packets before the link is encrypted and you are ready to read/write or receive notification. No re- service discovery needed. I would say from the time you receive the advertising packet to the time you send data it could be as low as ~50ms. If you don't need encryption, it could be even faster, considering the ATT table can be pre-stored on the client.

RE: Absolute minimum discovery

RK — Mon, 21 Mar 2016 15:34:01 GMT

Security is up to you, that's a few more packets exchanged. If you determine that just whitelisting a resolvable private address is good enough, you can skip that bit. Connection is something like 6 packets, it can be quick. Your limiting factor is how quickly the central finds the peripheral, so if you are the central and want to connect quickly, you need to listen with the minimum time interval to your (also power constrained) peripheral which would be advertising as infrequently as possible.

Under a second is quite practical, I'm under a second from button press to working, you notice the lag. I do have the accelerometer option as my remote mostly sits on a table so I can get a head start on the whole thing. I'm just waiting for my mCube board to show up, it promises me 1uA in sniff mode which is insane low power.

RE: Absolute minimum discovery

keith v — Mon, 21 Mar 2016 15:15:55 GMT

Thanks for the replies. Yes both pieces have very limited power budgets, the peripheral the lowest power requirements, scanning would kill the battery pretty fast I think

There is 2 way communication, it's very small data but it is there. So it looks like, once it's bonded with the UUIDs stored, Its just a connect and go, no need to discover anything GATTs and stuff. That would be nice.

Security, dang I hope not, but probably.

Anyone want to guess what a connect time would be? under a second hopefully?

The accell sounds cool, but this may be put in a pocket and would be constantly be active!

Keith

RE: Absolute minimum discovery

Hung Bui — Mon, 21 Mar 2016 10:29:34 GMT

@keith: I have the same question as Bill, do you have limited power budget on both sides ?

Also would the communication is only in one direction ( the remote sends command to the device) or it should be bidirectional (the remote reads data from the device ) ?

RE: Absolute minimum discovery

Bill Siever — Sat, 19 Mar 2016 03:45:53 GMT

Ah --- excellent idea! I thought about trying to leverage the scan response somehow, but I hadn't thought about using it as an ACK. I tried to think of a good way to identify the optimal number of advertisement periods, but having an ACK makes eliminating unnecessary power consumption much easier. If you do some experiments please keep us posted on the energy utilization of this approach.

RE: Absolute minimum discovery

RK — Sat, 19 Mar 2016 01:51:26 GMT

This is increasingly a great idea and now the peripheral+central softdevice is becoming standard it's quite possible to make something which is both, a 'normal' peripheral for being connected to by smart centrals and a central to listen out for this kind of event from a simple device, like a remote.

You can get some kind of feedback, if you make the advertising scannable you'll get scanned and will receive the scan event report, when you get that, you at least know your advertisement was received and who received it.

I've been avoiding adding that complexity into my current design, and only just moved up to the S130/S132 anyway .. I think it's time for me to implement something like this, the current way I'm doing it does have noticeable lag sometimes.

RE: Absolute minimum discovery

Bill Siever — Sat, 19 Mar 2016 01:31:45 GMT

Do both sides of the link have limited power budgets?

It might be worth doing some estimates on the energy usage if you were to flip the central/peripheral roles. You could use an initial connection event to exchange a signing key. The remote control could be a peripheral that only advertises briefly when a button is pressed. It could send a signed packet in the data portion of the advertising packet that includes the remote code and a sequence number to ensure it's not processed more than once. Of course, there wouldn't be any feedback path to ensure receipt (but in some applications the user closes the feedback loop anyway).

RE: Absolute minimum discovery

RK — Sat, 19 Mar 2016 00:06:12 GMT

Yes you can use the UUID if you are bonded and you've checked the service changed characteristic to ensure the service hasn't changed whilst you were disconnected. But you still have to connect, there's no 'ACK response' to an advertisement you can do anything with, you have to go through the connection procedure. If the characteristic you want to write requires security, you have to encrypt the link too (a signed write would be faster but I don't recall ever seeing one in the Nordic API anywhere).

I'm just working on something similar, a remote, I'm been messing about with the idea of putting a cheap(ish) accelerometer with low current and interrupt-on-motion into the remote so it starts pairing the moment you pick it up and by the time you press the button, it's ready.