HI Barry, On Thu, Oct 6, 2016 at 3:49 PM, Barry Byford <31baz66@xxxxxxxxx> wrote: > Hello Emil, > > On 6 October 2016 at 12:21, Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote: >> Hi >> >> 2016-10-06 10:49 GMT+02:00 Barry Byford <31baz66@xxxxxxxxx>: >>> >>> Hello Luiz, >>> >>> >>> On 6 October 2016 at 09:23, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> >>> wrote: >>> > Hi Barry, >>> > >>> > On Wed, Oct 5, 2016 at 11:31 PM, Barry Byford <31baz66@xxxxxxxxx> wrote: >>> >> 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. >>> >>> >>> >> 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? You will need to do as the Android application and track this the reads on the application side, each read returns a new chunk/fragment, regardless of the offset, and in the end you return empty which indicates that there is no more data to read, afaik once the read is completed it resets the state so another read will read from the beginning. As you may have guessed this is non-standard and should probably be changed to use notification as pointed out by Emil, but that is how physical web is currently implemented. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
