Monday, July 25, 2005

Topic of the day: Open Source PIC Bluetooth device

I've been interested in Bluetooth for awhile now, tried to understand it and everything like that, and I think I've done a reasonable (yet still not complete) job. From day one though, I was causing trouble. I asked the "wrong" questions, and people corrected me on them...'no, you use a host controller' instead of a microcontroller, things of that nature.

Now that I've figured out a lot of the components involved, I find myself asking some of those same questions, but this time I think I know some answers.

For example: "Why can't I just tell a PIC microcontroller to speak Bluetooth and hook up an antenna to it". The short answer is, there's no reason why not. The long answer is, it hasn't been done yet, and it would be hard to get the antenna right (because there are very exacting requirements for the antennas and most of that information is considered trade secrets).

So, next question: "If I had the right antenna, matched properly, etc., why can't I just connect it to a pin on the PIC and use to PIC to communicate with other Bluetooth Devices?" The short answer: technologically, the radio is hard to do. Bluetooth devices are courteous in the sense of Device A and tell Device B "Hey, no need to shout so loud, talk quieter", and Device B can respond by turning down it's output power. With a PIC, all we have is 0s and 1s as pin outputs, so it would be hard to reduce the radio power unless we had a separate system (note: this is why a lot of wireless devices from radio modems to Bluetooth are generally packaged away from microcontrollers).

Moving on: "Ok, so I've got a controllable radio and I've got a matched antenna. Now can I hook up a PIC and make it talk in Bluetooth?" Short answer: Maybe. Here's where things start getting fuzzy. Let's assume we can talk to the radio in 0s and 1s (which is a reasonable assumption). If we see an incoming transmission that says "turn up the broadcast power", we can use 0s and 1s to tell the radio to adjust power levels (to be in the other device's Golden Receive Power Range, as they call it in the Bluetooth spec). Anyways, so that aside, yes, when everything is a 1 or a 0, the PIC can do it. But the PIC may not be able to do it fast enough. I haven't thoroughly investigated it, but there are some things that need to be done with those 0s and 1s that are easily done with hardware, such as using Linear Feedback Shift Registers. To ask the PIC to do such low-level processing would take up clock cycles, and it could not be interrupted during this time, because Bluetooth timing stuff is VERY sensitive. All these operations (the time sensitive things that typically lend themselves to hardware implementations) are called Baseband operations. And for Baseband operations, its probably for the best (but by no means necessary) if it's implemented separately from your primary processor.

Let's do a quick summary...We need an antenna, radio, and (preferably) baseband to do ANYTHING Bluetooth. There's more we need on top of that, but we'll get to that later. First we have to take care of licensing issues. Bluetooth is trademarked, which means you can't even sell Bluetooth toothpicks without talking to the BQB (Bluetooth Qualification Body), an organization sets up by the Bluetooth SIG (Special Interest Group) with the sole purpose of distributing licenses that allow the use of the name Bluetooth. Obvious question: "Can I make something that interacts with a Bluetooth device that is not qualified through the BQB?" Yes you may, but you can't sell it, or if you do, you cannot use or have the Bluetooth trademark, logo, word, etc. anywhere in your stuff. Why might someone want to go around the BQB then? Money. I understand it costs about $10,000 to certify/qualify something as a Bluetooth Product. That ain't pocket change for Joe Electronman who tinkers PIC microcontrollers at home in his free time. Bad news: Bluetooth is only for the big boys. The American notion of making a fortune when you start with only a dollar in your pocket and an idea in your head...that doesn't happen much with Bluetooth stuff.

There is a middle ground though: Bluetooth modules. These things use standard communication protocols (so PICs can talk to them), offer a variety of features, are fully qualified (so you don't have to) with the BQB. You can put one of these babies in your product, slap the Bluetooth logo all over it, and nobody can stop you. The problem: (right now) they cost about $60 to $70. That might be alright for small experiments at home, but if you want to mass produce a cheap device, it might be a problem.

So there is a decision to be made: are we going to play serious and make something that sells like hotcakes, or are we home hobbyists? Home hobbyists currently have no recourse other than buying expensive modules. If we want to play serious, we better have some money, because here's what we can do...we can (for example) buy an antenna from gigaAnt or another provider and then go to and buy radio+baseband+otherstuff single-chip solutions that provide up to RFCOMM (whatever that is). Great! These chips are only $14 each (min order of 5), and if you buy 100 of them, it's only $8 each. Now we're talking. (note: I haven't priced the antennas). These chips have 90+ pins on them, but that's ok because we can read a datasheet and do all the cool stuff we want.


Going this route, we still need to go through the Bluetooth qualification process (yep, $10,000). Why? Well, aside from the fact that the chip and antenna could be mismatched, Bluetooth devices in general aren't controlled from the RFCOMM level. Huh?

Ok...analogy time. We know radio and baseband, but what is the Link Controller, Link Manager, L2CAP, HCI, RFCOMM, OBEX, WAP, TCS, SDP, and these Profiles I keep hearing about? They are all layers of abstraction. Think of the English language. A book is composed of chapters, chapters contain paragraphs, paragraphs contain sentences, sentences contain words, words contain letters, and letters are specially shaped globs of ink on a page (or pixels on a screen). When someone asks you about a paragraph you read, you give a nice summary of it. It wouldn't make sense to say "Well, it started with the word 'It' followed by the word 'was'." It would make even less sense to say it was the letter "I" followed by the letter "t", and so on. For that matter, it would be impossible to say the first letter on the page looked like this--at which point you motion in the air what the letter looked like on the page. Why don't we do this? Because it's unnecessary. We all know what the letter looks like, and we all know how to combine the letters into words. There is a standard way of interpreting these things.

Therein lies the beauty that is Bluetooth. Bluetooth standardizes the shapes of the letters (a.k.a wireless signaling). Bluetooth standardizes the communication on many levels, and in doing so, the ensure interoperability--that is, they make sure that if one person can read the book, everyone can read the book. All the acronyms earlier are just named levels, just like we could name the levels "letter", "word", "sentence", and "paragraph". To have a sentence, you MUST have letters and words, but you don't need a paragraph--in fact, the concept of a paragraph in a sentence doesn't even make sense.

When they say that the CSR single-chip solutions implement everything from the radio to RFCOMM, it means that it needs an antenna (a lower level) to be useful at all (without it it's like a book without any alphanumeric symbols in it), and it needs some higher up levels to perform reasonable communication with other devices. Specifically, the higher up levels it needs are profiles. Profiles are the lingua franca of Bluetooth. They are software protocols that allow for a variety of operations, from object (file) exchange, to discovering what services other Bluetooth devices offer, to allowing real-time audio broadcasts. Some profiles even use other profiles, essentially creating new layers that abstract the underlying process.

For what it's worth the RFCOMM layer can be treated like bunch of RS232 serial ports, which means you can pretty much send all the data you want over them. Note that if that's what you were planning to do with the PIC, these single-chip solutions are pretty suitable, because you can treat them like a RS232 port, which is where the notion of "wire replacement" with Bluetooth comes in. Note that because

So, we get an antenna, we get a chip, now we can write some code. We implement any profiles (and any unimplemented underlying layers/profiles) we need, and we can happily do this on a PIC or wherever. I haven't looked much at the Linux BlueZ protocol stack (protocol stack = a collection of the layers. The rules for sentence structure and paragraph structure could be considered a protocol stack), but you could probably use some of it to implement what you need. However, if you modify it, you'll have to get re-qualified with the BQB. Fortunately, the BlueZ stack has undergone qualification as-is, so that's one less thing to worry about.

Now we just assemble the antenna, chip, and (optionally) a microcontroller (note: if your program is small, you can use the on-chip microcontroller), and make sure your program operates with a profile, send it to the BQB if it needs it, and you've got a fully qualified Bluetooth device. Do keep in mind that you'll probably need a surface mount machine to assemble the chip to a board.

So why did I write all this? I think because I had so many questions that I wanted answered, and I didn't find any answers directly. The level of investment (financially) required for Bluetooth is generally enough to exclude hobbyists, but all good hobbyists insist that there MUST be a way to do what you want. And so there is. And hopefully I was clear enough that I could help someone else understand how to do it.

Another reason I wrote it was because it may be possible to have an open-source PIC device with Bluetooth, but for technical reasons it will still need something separate for the radio and antenna, unless Microchip does something cool (and maybe a bit out of their league) and produces a Bluetooth-enabled PIC microcontroller. Heck, if they could even integrate and/or have an add-on antenna, that would be awesome. I imagine if they did, they'd dominate a lot of the market, open up Bluetooth to hobbyists, and basically bring in a revolution for Bluetooth products. They'd also probably do it at the right price too--$60 to $70 for a Bluetooth module is too high, but it's just because of the technical expertise necessary to make and match an antenna, add profiles, and assemble, all for a (currently) low volume product.


Blogger Atletismo343 said...

I was wondering if you had done any further investigation of Bluetooth modules. I am actually looking to create a Bluetooth device that would communicate with a computer or PDA and do some computation, ie, a PIC (or micro) + Bluetooth. Thanks.

2/18/2008 1:31 PM  Edit
Blogger said...

Did you eventually write that PIC bluetooth code?
I've began writing one some time ago and abandoned it because I've lacked time.
I would love to have a copy to finally finish an old project that's just sitting half done.

11/07/2009 11:23 PM  Edit

Post a Comment

<< Home