Re: [web-bluetooth] Wrong handling of property 'name' for BLE devices (#570)

Hi,
Thanks all for your reply.

@reillyeon :
I understand fully your point as from a workstation dev perspective, cleaner and well organized is better even if consuming more (memory, energy...). Unfortunately BLE is tight to uControlled world where both few bytes and mAh count (no 32kb buffers and power plugs there). In my situation the BLE spot needs :

    1) to be visible from a wide range of handsets (including those still featuring only the BLE stack in v4). Thus, it's important to keep away from extended advertisements and keep using smaller ones allowing only 31 bytes of data.

    2) to avoid dealing with several connections (and even a single one) when it is not necessary to do. For tiny environmental and not critical information broadcasting, better to do it through the advertisement than via a full connection and data exchange handling. This makes the device less sensitive to DOS attacks (most of BLE modules cannot manage more than a few simultaneous connections), and let it keep the only connection available for maintenance procedures.

Given the constrains below, we get only a 31 bytes (minus IDs and payload bytes) in which to carry an information changing from time to time. Putting custom data in other extra AD "fields" reduces the space left to place such an information.
For example, putting user data in serviceData, will consume 4 extra bytes: (1)[8BIT_PAYLOAD_LENGTH] + (1)[0x16] + (2)[16BIT_UUID]

Anyway I sacrified 4 bytes just to try, adding an AD block of type SERVICE_DATA (0x16):

[09 16 1C2A] + [000102030405]

Mobile application 'nRF Connect' displays correctly all the broadcasted payload, but using Web BLE in the browser, event.serviceData.get('0x2A1C') returns a 0 size BluetoothServiceDataMap.
Is there any particular requirement to get it?


@emill :
I agree also your point, but isn't this statement just about how should be the local name in its general definition? When explained within the context of advertisement data structures (AD type COMPLETE_LOCAL_NAME) it is not told we should place UTF8 so it's a bit confusing. Anyway I agree since we are talking about the same object, its format should apply everywhere it stands.
Any Idea, where in implementation you suspect the null terminated char rule to apply? Once again when I run mobile application 'nRF Connect', it handles correctly retrieval for both dynamic content and pure random binary content (both in AD blocks COMPLETE_LOCAL_NAME and SERVICE_DATA) and I believe the app just makes use of the underlying BLE stack implementation.


Thanks,

Phil


-- 
GitHub Notification of comment by Z80sp
Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/570#issuecomment-994834202 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 December 2021 14:18:49 UTC