Fatbeacon service and characteristic UUIDs

angst7 commented 8 years ago

I'm working on a Fatbeacon implementation on the nRF52, and I just want to verify a couple quick things for my own sanity.

From the Physical Web App code, It looks like you want a fairly standard Eddystone-URL frame, albeit with the URL scheme prefix set to 0x0E. It also looks like you're using a Service UUID of ae5946d4-e587-4ba8-b6a5-a97cca6affd3 but a UUID of d1a517f0-2499-46ca-9ccc-809bc1c966fa for the characteristic.

Is this correct? If so is there any reason for using separate base UUIDs for the service and characteristic? Is there anything else in the advertising or service data that I'm missing?

Thanks

cco3 commented 8 years ago

@hayesjordan

jacobrosenthal commented 8 years ago

@angst7 On my list to do as well, you publishing?

angst7 commented 8 years ago

@jacobrosenthal hope to once it's working.

hayesjordan commented 8 years ago

@angst7 Yes it should look something like this: [URL frame type, tx power level, 0x0E, title]. However I do want to point out that this not a final specification of FatBeacon, just a first pass experiment.

At this time there is no specific reason for using separate UUIDs. It looks like you got everything that you need to get a FatBeacon up and running. Have you ran into any specific issues?

angst7 commented 8 years ago

Great. I'm having a few issues, but I haven't been able to determine whether it's my firmware or the app. I was about to file a bug report and a separate PR for a few things I've noticed.

In particular, I'm able to see and read the custom service and characteristic, along with the web-page data using Nordic's nRF connect, but when I use the Physical web browser I get a few different behaviors:

Clicking the notification for a Fatbeacon does not seem to establish a connection at all.
Clicking a Fatbeacon result within the PWS app does make a connection, but then never seems to complete collection of the characteristic data (this may be a problem on my end, not sure) and never closes the connection. (I let it run several minuted before manually closing the app)
Turning on the Debug settings in the PWS app while the Fatbeacon broadcasts causes an immediate crash of the PWS app. The crashes continue until I turn the Fatbeacon off.

So there are some strange happenings. I've only just started trying to run these down, and wanted to double check the UUIDs and so forth before I went too far down the rabbit hole. I'm happy to file these as individual issues, but I want to make sure it's not me causing them first.

angst7 commented 8 years ago

Quick update: I went ahead and built the PWA here so I could watch the debug messages. A couple notes:

-The failure to complete reading the characteristic is my problem - when the page is over 20 characters, the PWA, just continuously reads the first 20 bytes - so its reading the characteristic differently than the Nordic connect app (which somehow works fine), but I think I may be handling the characteristic read requests incorrectly anyway. At least I know where the problem is now.

-Clicking on a Fatbeacon notification still does nothing - I see nothing in the debug logs, so maybe it's just not being handled.

hayesjordan commented 8 years ago

@angst7

I have confirmed that there are bugs in Physical Web app concerning the notification #792 and debug view #793.

As for the behavior of the Physical Web app only reading the first 20 bytes:

I am curious to see if the Nordic connect app works if the characteristic is more than 600 bytes.
I want to stress that this is an experimental implementation and if FatBeacon ships it will likely have changed in some ways or another.
The reason why the app only reads the first 20 bytes is because on Android there is not an API call that allows the app to read a characteristic with an offset. Usually if the system receives a packet of the same size as the MTU the system intercepts and makes the request using the offset. The problem is that for some reason (most likely a bug) Android stops when the characteristic is 600 bytes.
For that reason I don't recommend using the current specification for any large scale deployments.

angst7 commented 8 years ago

I did a little more investigation into this. According to the Bluetooth Core v4.2 spec, the maximum length of an attribute value is 512 bytes. (Vol 3 Part F, section 3.2.9). So that's why Android won't read the larger values. (Nordic doesn't allow > 512 byte characteristic values either, for the same reason)

In order to have a largish web page (something over 512 bytes), I suggest something like the following:

The characteristic UUID currently used will return a list of 16-bit UUIDs (under the same Base UUID) that contain the full page data. The client will sequentially request these characteristics and build up the page contents 512 bytes at a time. Long reads can be used for this, so that the underlying API can handle things without offsets.

This should stay within the spec, yet still allow for larger pages. It should also work nicely with other BLE implementations, since you're just reading data from a list of characteristics.

So you'd have base uuid: d1a5xxxx-2499-46ca-9ccc-809bc1c966fa with uuid: 0x17f0 holding the list of other uuids that make up the page. Or it could start at 0x0000 and increment 16-bit uuid's for however many 512-byte buckets you'd need. It would only be 20 or so for a 10kB payload.

I hope this makes sense, just shooting from the hip. Maybe I should write this up as a new Issue? Let me know what you think.

jacobrosenthal commented 8 years ago

That sounds like a lot of overhead on the embedded side. What about something like embedded flash or something where every time you read a single characteristic it moves the index forward one page for the next read. Writing to that same characteristic to could reset or set the index.

On Thu, Aug 25, 2016 at 10:06 PM, Matt Roche notifications@github.com wrote:

currently used will return a list of 16-bit UUIDs (under the same Base UUID) that contain the full page data. The client will sequentially req

angst7 commented 8 years ago

So on the embedded side, capture the read event and manually fill/return the smaller chunks of data? I think that's essentially what the PWA implementation does now. I just didn't know if the spec allowed for read requests to have that type of side effect. Technically it should be fine.

angst7 commented 8 years ago

As a quick update, I've published an implementation of the current Fatbeacon spec for the Nordic nRF52 at https://github.com/angst7/Phatbeacon.

I've also built and tested a version of the PWA and nRF52 firmware that bundles pages in a set of 500-byte characteristics, as I describe above. It's nice, because it's readable by standard BLE discovery methods. It also transmits large pages a little faster. Downside is that my implementation sets a hard page cap at 10k bytes (but this can be modified).

If anyone wants to look at this, it's in the multi-char branches on my fork of PWA and the Phatbeacon repo.

philips77 commented 8 years ago

Hi, one comment. There is a limit of 40(?) characteristics in a service on Android. All 41+ are shown as descriptors to the 40th.

scottjenson commented 8 years ago

Sorry, I'm not sure I follow. You are describing a limit of Android correct? I'm not sure I follow how that affects the design...

philips77 commented 8 years ago

Issues reported: https://code.google.com/p/android/issues/detail?id=187139 https://code.google.com/p/android/issues/detail?id=76639

scottjenson commented 8 years ago

No, I get the limit, I'm just asking why you think that applies to this issue...

philips77 commented 8 years ago

An idea was given above, to have N characteristics that you read sequentially, each returning 512B, instead of reading one repeatedly with embedded offset. So it's just small fyi regarding this issue.

scottjenson commented 8 years ago

Ah, thank you. Sorry for missing that. Yeah, that wouldn't work very well ;-)

google / physical-web

Fatbeacon service and characteristic UUIDs #791