What is the best way to automate bluetooth connection?

mithunmathew1990 gravatar image

asked 2017-08-12 12:04:37 +0100

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.

edit retag flag offensive close delete report spam

1 answer

Sort by » oldest newest most voted
run_ar gravatar image

answered 2017-08-15 09:47:42 +0100

updated 2017-08-16 09:32:29 +0100

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.

edit flag offensive delete publish link more


I am planning to go with fake uuid method, as it is the easiest one to implement. Thank you for responding.

Mithun Mathew ( 2017-08-15 13:09:50 +0100 )editconvert to answer


There seems to be conflicting information from Nordic in regards to what can be in the advertising packet as a whole and also the manufacturer data specifically

e.g. see the answers from Nordic to this question


Has an example showing that the whole advertising packet can be taken up with 2 bytes of header and 29 bytes of

"// now fill the 29 bytes with whatever you want"

Roger Clark ( 2017-08-15 13:14:06 +0100 )editconvert to answer

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.

run_ar ( 2017-08-16 09:22:59 +0100 )editconvert to answer

I'll wait for your update! Thank you.

Mithun Mathew ( 2017-08-16 11:00:16 +0100 )editconvert to answer


I'm not sure is this matters unless @Mithun Mathew wants to sell a product that is listed as Bluetooth compliant.

I'm also wondering how any open source devices could use manufacturer data, as these would not have a manufacturer ID, as there is no manufacturer.

Roger Clark ( 2017-08-16 11:40:07 +0100 )editconvert to answer

@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.

Mithun Mathew ( 2017-08-16 17:04:41 +0100 )editconvert to answer

Edit. Removed my comment, as I miss understood your question in this regard

Roger Clark ( 2017-08-17 00:48:52 +0100 )editconvert to answer

@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.

run_ar ( 2017-08-21 14:12:23 +0100 )editconvert to answer

@run_ar I find the whole patent and licensing for open source etc confusing.

Prior to Nordic's recent clarification about the Manufacturer data, they said in numerous previous answers that you can put whatever you want in those bytes.

Also,various answers on this forum seemed to imply, that as you are buying hardware from Nordic and using their API, that the payment for the hardware covered the cost of licensing the technology.

However, on closer inspection, this doesn't seem to be true.

Hence the entry cost into this market quite high, and small volume products would need to be expensive to cover the licensing fees.

Of course, there is a large country which does not adhere to any of this ;-)

Roger Clark ( 2017-08-22 01:10:06 +0100 )editconvert to answer

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.

run_ar ( 2017-08-22 13:47:22 +0100 )editconvert to answer

For smaller project you might qualify for the Innovation Incentive Program (IIP). But I agree it would add a significant cost to smaller low volum projects.

run_ar ( 2017-08-22 13:50:27 +0100 )editconvert to answer


Thanks for the clarification.

The adopter member is interesting, but only seems to apply to companies who are a legal entity.

So I don't see how its possible for any open source project to release hardware and software.

I see there are open source bluetooth sensors e.g.


But ruuvi must be registered with Bluetooth SIG.

However if anyone else manufactured and sold this "Open Source" device, I'm not sure the legal position of that company

PS. I have no interest in making or selling ruuvi tags, I'm interested in the open source and maker movement in general.

Roger Clark ( 2017-08-23 01:30:24 +0100 )editconvert to answer

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.

run_ar ( 2017-08-23 11:10:14 +0100 )editconvert to answer


Very interesting...

Looks like BLE and open source do not mix ;-)

Roger Clark ( 2017-08-24 03:03:06 +0100 )editconvert to answer

And on that, I think we should leave this digression for now. At least in this thread :)

run_ar ( 2017-08-24 08:41:17 +0100 )editconvert to answer

Absolutely... And hopefully, @Mithun Mathew now has a clear idea of the licensing / registration etc thats required for his product.

Roger Clark ( 2017-08-24 09:45:35 +0100 )editconvert to answer

Thank you for the extra inputs you guys have given me. @run_ar : I take it that there is hardly any conclusive data out there for step 2. Thanks for digging into it.

Mithun Mathew ( 2017-08-24 10:43:45 +0100 )editconvert to answer

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.

run_ar ( 2017-08-24 10:51:24 +0100 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

1 follower


Asked: 2017-08-12 12:04:37 +0100

Seen: 184 times

Last updated: aug. 16