Re: Fatbeacons and 'streamed read' of a characteristic

Hello Emil,

On 6 October 2016 at 12:21, Emil Lenngren [off-list ref] wrote:

Hi

2016-10-06 10:49 GMT+02:00 Barry Byford [off-list ref]:

quoted

Hello Luiz,


On 6 October 2016 at 09:23, Luiz Augusto von Dentz [off-list ref]
wrote:

quoted

Hi Barry,

On Wed, Oct 5, 2016 at 11:31 PM, Barry Byford [off-list ref] wrote:

quoted

Hello,

I've been doing some experiments with Googles Physical Web Fatbeacon

https://github.com/google/physical-web/issues/784#issuecomment-251571858

The experiments have been with BlueZ 5.40 using the DBus API with
Python 3. BlueZ is advertising a connectable Eddystone beacon. When
the Physical Web Android app connects there is one service with one
characteristic that it is looking for. That characteristic contains a
string that is the HTML content.
All is working well if the web page contained in the characteristic is
nice and short.
However if I make the web page content slightly longer then I end up
getting stuck in a loop where the Physical Web app is just reading the
first part of the characteristic over and over again.

How big is it? The spec actually limits the attribute contents to 512
bytes. On the other hand I remember the Android App returning
different parts of the data on every read, so it essentially doing its
own fragmentation.

My content is bigger than 512 bytes when it starts failing. The app is
definitely making multi-read requests of my characteristic. The bit
that I'm missing is how to make the beacon/service give the next chunk
of content on each read.

quoted

quoted

I'm assuming that it is not that uncommon for data to be larger than
can be retrieved in one read although I've not been able to find an
example. I'm a little bit at a loss as to what the ReadValue method
should look like for this characteristic.
Is anyone able to give me some pointers as to what I need to do to get
this to work?

Check out the Android physical web application:


https://play.google.com/store/apps/details?id=physical_web.org.physicalweb&hl=en

It is that app that I'm using to connect to the
beacon/service/characteristic I've created with BlueZ.

I seem to be missing something obvious. The app is making multiple
reads and I had expected the ReadValue to be called with an offset
given in the options. This isn't the case.

Since a characteristic can only be 512 bytes, you can never use Read
Requests or Read Blob Requests to get more than 512 bytes if the
characteristic is not updated.
Normally when you want to stream over a lot of data over BLE you don't put
everything in a GATT db and then read it. Instead you use set up to send a
lot of notifications for example when you receive some write to a control
point. Since there is no limitation how many notifications you can send,
just fragment your data into multiple notifications (according to the ATT
MTU size) and send them over.

Your comments seem to be inline with the discussion going on in the
issue tracker over on the Physical Web repository as how to possibly
implement this in the future. Your input I'm sure would be welcome
over there.

However this isn't what the Physical Web app is currently looking for.
Am I correct in assuming from your reply that I can't implement what
is currently required with the BlueZ DBus API?

Thanks,
Barry