The product that is in development could be used by the 100s at the same venue, if we let customers picks their device from a list there will be a lot of wrong connections and as such we decided to automate the connection process by making each device uniquely identifiable (by using NRFs 64bit manufacturing id as the unique key).

Assume that a device we picked out at random, has nrf manufacturing id as 0x12FAAACDFADE3478. We would have this unique key printed on it's boxing as a QR code which the app will scan.

We currently came up with these two ways to implement the app side automation,

1) Append nrf's manufacturing id to device name so that, it will advertise as say 'KOI_12FAAACDFADE3478' and we scan and connect to a device with this name
[problem, there is no 'scan with name' API in iOS and it needs to be implemented via code]

2) Advertise a fake 128bit uuid like '00000000-0000-0000-12FA-AACDFADE3478', and then have the app scan and connect to a device advertising with this fake uuid
[this is the preferred method as both iOS and android has a 'scan with uuid' API and time taken to connect to the device with the 'scan with uuid' API in iOS lower than the 'scan with name' code implementation]

Questions
Is both methods allowed? Will the product qualify bluetooth SIG qualification if we implement either of them? specifically step 2?

Is there a better way than this?

PS: For step 2, we only add that fake uuid in advertising packet, there won't be any actual service with that uuid.

1 answer

Both ways are allowed. But I would recommend that you advertise using manufacturer specific data for the unique id. That is ad type 0xFF Manufacturer Specific Data. However to use this you need a company identifier.

Edit: Thinking about it I'm not 100% sure about option 2 above so I will have to check. At least you can use the name, Manufacturer specific data or service data for custom information. From CSS "If a device has no Service UUIDs of a certain size, 16-, 32-, or 128-bit, the corresponding field in the extended inquiry response or advertising data packet shall be marked as complete with no Service UUIDs." Not sure how or if this is enforced in any way.

Yes, the 2 bytes of header is needed. Length and ad type. This means you should use one of the specified ad types.

As for Manufacturer specific data. I'm afraid that is misleading. You should look at the supplement to Bluetooth core specification, CSS v7:
The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier code from the Assigned Numbers - Company Identifiers document. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier.

@roger Clark, I am still learning about the declaration & qualification procedures of SIG, so please correct me if I am wrong. From what I know, to be able to legally sell any product that uses bluetooth, it has to be qualified by SIG first & to get qualified, the product has to be bluetooth compliant.

@rogerclark I guess it would be an issue for open source projects. But I reckon that for commercial use, you would create a company and list your product before selling it. So you could apply for a company id using that company. For hobbyists I guess they could use 0xffff as long as it's not a "shipping end product".

@mithunmathew1990 : As for selling a bluetooth product you license the technology when you pay the declaration fee to list your product on the end product listing. And yes, the product has to be complieant to be listed. Not sure if what the bluetooth sig will do if you fail to list a commercial product, but I guess there is a significant risk (at least if you have a successfull product) you could be sued by one of the member companies holding patents in the technology.

Yes, I agree. Unfortunately it is a bit confusing. As for manufacturer specific data there is a test case: GAP/ADV/BV-04-C. Pass Verdict: The advertising or scan response data contains the Manufacturer Specific Data AD Type with the first 2 octets containing the Company Identifier Code followed by additional manufacturer specific data.

You probably know this but adding it for reference. As for declaring a product. If the intention is to use the Bluetooth trademark you have to declare your product.
If you are not using the trademark you still need to be an adopter member (free) and follow the Patent & Copyright License Agreement. If anyone has questions about this I would say they should contact the Bluetooth sig for any clarifications.

Yes, the Ruuvi tag is listed. If someone else wanted to manufactur and sell this as their own product they would have to create their own declaration. Details here. The exception is: If you are a retailer or supplier simply selling or distributing another company’s Bluetooth product and not branding or representing the product as your own, you do not need to qualify or declare the product.

However there are open source products that isn't qualified. I would say that's a bit risky, but not sure where the line is drawn here.

I was only able to find the part I already copied from the css, where is says "advertising data packet shall be marked as complete with no Service UUIDs", but I could not find a test case that enforces this. Regardless I would recommend using manufacturer specific data.