1
\$\begingroup\$

I was looking to add Bluetooth connectivity to some embedded design, and I was surprised to see that all modules available have a complete protocol stack included, that (as I see it) seem to limit you in what you can do with it. Depending on what you want to do, you have to choose the right module implementing the profiles you need, and you'll talk with the module using fairly high-level commands.

I was actually expecting there was some basic modules taking care of only the physical layers (just "sending raw packets" over the air), and with which the upper stack layers would be implemented in software on a MCU (the current design has a powerful one running Linux available). This is what is usually done for USB, ethernet, and pretty much everything else. It seems to me that it would be much more flexible this way (you could even, let's say, create your own proprietary Bluetooth profiles). But unless I missed something, it seems it doesn't exist.

Even though I can accomodate with this, I was wondering why is it this way?

\$\endgroup\$
2
  • 2
    \$\begingroup\$ My guess would be that this ensures compatibility between BT devices from different manufacturers. Also for example BLE needs some higher level management of the RF part to implement BLE. Sure you could do that in a different MCU/CPU but maybe that is too timing sensitive and/or power consuming. Maybe for BT certification, the device needs to be able to do all BT functions on its own. Implementing part of the stack elsewhere could mean that the complete product has to go through the certification instead of only that module. \$\endgroup\$ Sep 12, 2016 at 15:00
  • \$\begingroup\$ Certification is one guess, the other would be latency. I suspect if you want to bypass the modularity you could talk to CSR and see what they can offer - but obviously this route is much more work. \$\endgroup\$
    – pjc50
    Sep 12, 2016 at 15:23

2 Answers 2

2
\$\begingroup\$

For certification, the hardware and the software must adhere to the Bluetooth specification.

The whole point of modules is to make integration of Bluetooth as easy as possible. So the module gets certified according to Bluetooth specifications and local radio specification (FCC and all that stuff all around the world). With this, you can integrate the module very easily into your product and save a lot of costs (>50k for certifications).

But to get the Bluetooth certificate, the Bluetooth stack has to be integrated into the module already as it is part of the tests (there are strict timing specifications for example).

So if you want to write your own stack you end up with a custom solution which you have to get certified. In that case you'd rather buy a chip and design your own module, so you can save at least some money on the hardware side in the long run.

\$\endgroup\$
1
\$\begingroup\$

FakeMoustache has it right. There are a few radios out there that are just a physical layer interface and require that you implement the Bluetooth stack on your own device. However if you do that then in order to be able to use the Bluetooth name and logo you have to do a LOT of certification testing and register the device with the Bluetooth SIG. You then have to maintain that certification by informing them of any later firmware or hardware updates to the product.

All of this adds up to a lot of time, effort, paperwork and cost.

A ready built module with the stack on board eliminates all of that work.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.