Closed jonas-schievink closed 5 years ago
Beacon
is now a thing, but BeaconScanner
is still missing PDU deserialization support. This isn't trivial in a no-alloc situation, but still doable. Just needs a bit of thought put into it.
Apparently to use BeaconScanner
you still have to create the entire link layer. This should be fixed, it's pretty silly.
Another thing to note: Data channel packets can be much larger than advertising channel packets (>255 Bytes vs. <40 Bytes). It would be nice if we could structure the radio interface in a way that allows using a smaller buffer if only advertising functionality is used.
Data channel packets can be up to 255 Bytes or so, but we don't have to support that. The smaller buffers are just fine.
I must have been hallucinating because BeaconScanner
doesn't seem to exist.
BeaconScanner
with filtering is now implemented
Beacon usage is different from other usages (which establish connections), so it should get its own interface. Beacon use doesn't need a CSPRNG or crypto engine, and it sends non-connectable advertisements instead of connectable ones. It should also be easy to implement a simple beacon scanner.
The API should probably look like this:
ble::Beacon
for the beacon advertisement sender. It only sends out non-connectable advertisements and never switches the radio to receive mode.ble::BeaconScanner<C>
for a beacon listener. It should be generic overC
, a consumer of the received beacons.C
effectively replaces what currently is the logger. We might also want to support filtering beacons by device ID, and should probably only look for non-connectable beacons in the first place (since this is not scanning for connectable devices). This will implement passive scanning only.This API should probably be limited to non-scannable beacons in any case (are scannable beacons even still called beacons?).