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 btdesigner.com 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.

Almost.

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.

Saturday, July 23, 2005

Two new ideas today: Googlesaurus, and Wisp.

Googlesaurus: A Firefox extension that replaces a Googlebar. Basically, the problem with Google searches is that you have to know the words you're searching for, otherwise you don't get a good search. While many of us may have excellent search skills, a large number of people put in terms that are too vauge or generic to produce good results. Googlesaurus would provide the standard Google search box, but when you perform a search, your search results are displayed word-by-word in the toolbar, each with their own dropdown list. You can click on the dropdown list for any word and see a number of synonyms (maybe even some antonyms) for the words. If you find a word that is more specific than your original one, you can click it and do a new search.

Wisp: Kinda like Lisp, but better for AI. At a fundamental level, brain cells have a number of branches that reach out to other brain cells. Lisp (list processing) is like a brain cell that has only one branch that goes out to another cell. Wisp (web processing, with the "is" part borroed from l"is"t) would have an object and a series of pointers to another object. The idea is still very fresh in my mind, so I've got a lot of hammering out and figuring out to do, but that's the gist. Heck, it may even be implementable in Lisp. Time will tell...

Wednesday, July 20, 2005

I've been doing lots of reading lately...basically getting into the details of some programming, especially regarding the Mozilla Framework. Something I think that would be neat/good/etc is a new kind of Mozilla suite with a different purpose: to provide a range of open source cross-platform engineering tools. Things from 3D CAD systems to FEA tools to mapping tools, and maybe even some Matlab/Labview style tools. I was thinking a good name for it might be Vizilla, to emphasize the graphical nature of the program. I've been reading a lot about XPCOM, but I haven't gotten far enough yet to see exactly what needs doing. I understand Gecko does the web browsing for Mozilla products, so I'm not sure if that'll be something to replace with a more suitable graphics tool, or if it's so deeply embedded in Mozilla that it'll be hard to get out.

Anyways, in other news, I started thinking that it would be nice to run Lisp scripts in Mozilla products, kinda like Javascript, but have it set up like Autolisp where you can issue commands to do this or do that, or a whole buch of thises and thats. I did a quick search in Google for something like that, and I actually came up with something...NYC lisp is doing a Summer of Code project called Firelisp, but it was already past the deadline. So, I applied anyways, but nothing so far.

Back to reading...

Saturday, July 09, 2005

I've been going deeper into Java, trying to figure it all out, and the more I do, the more it looks inherently different from Lisp. Basically, I'm not so sure it's a good idea to do a direct-to-.class file Lisp. It might work, but I've got more learning to do, for sure.

In the meantime, I found a nice (actively developed) Java-based lisp interpreter called Armed Bear Common Lisp (ABCL).

Something else I've been thinking of lately is how much wasted code there is. I've heard the quote:

"Programs must be written for people to read, and only incidentally for machines to execute."

- Abelson & Sussman, SICP, preface to the first edition

But I'm not so sure I believe it. If I were to be quoted, I think it would sound better as:

"Readers (a.k.a. compilers) must be written for people to program, and only incidentally for others to make sense of."

The fundamental difference is the purpose of the program. The first implies that the first purpose is for other people to read programs. However, I can say with certainty that the large majority of people prefer to use programs rather than read source code. That said, the fundamental purpose of the program is to be used. And if it is easy for people to write programs, it is easy for people to communicate concepts and ideas to others in an easy-to-digest manner. The programs that help us do this, I classify as compilers.

Under this definition, we find that not only are C compilers and the like within the definition, but we also find word processors and email programs. Indeed, these programs help us compile our thoughts into discrete words, which we can transmit to others to widen their breadth of information.

But I digress...while it makes sense to have some readability of code, it also makes sense to have more compact code. For example, the latest download of the Fedora Core iso files takes 4 discs. I cannot possibly imagine that all of that is really necessary. I imagine that somewhere, some program wrote from scratch a necessary function which duplicated another function for another program. In fact, I imagine this happens hundreds of times, if not more. What if instead this series of statements was recognized as "common" and put into a library. Indeed, what if this were done for thousands of functions and programs. With today's availability of memory, it might be possible to significantly lower hard drive accesses, because only user data and program-specific code would need to be fetched. Also, handheld devices would benefit, as they could hold a lot more programs per megabyte.

If anyone knows of such a program, please let me know, as I'd be interested in it...