Thanks Luiz. That's clear On 6 October 2016 at 18:44, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > 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
