Anybody got Bluetooth experience?

I'm curious too. At the doctor's office this morning, a nurse used a Bluetooth-coupled combination O2 sensor and pulse rate detector straight to her laptop ;-) ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

      Remember: Once you go over the hill, you pick up speed

I'm in kind of a bind because it looks like a really fun project, and I think it'll take me far less than I'm estimating, but unless I talk to an expert, I don't know.

And if there's any one lesson that gets ground into your skin over and over again when you're an engineer, it's that any time you let yourself get talked down from a high estimate by the product marketing types without benefit of hard data, the whole project is going to go down in flames one way or another.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

a a

it

t of

ound.

ll

d text -

Without knowing your application requirements I can't say for sure, but the easiest way to get a Bluetooth enabled app up an running is to buy one of the integrated modules that you can just solder on to your board and be done with it. Like these guys

HTH

Bob Stephens

We did one project using the AVR Raven board, without much trouble. It's an eval board for their processor/bluetooth parts. Maybe a good starting point.

John

It's a high-volume, low BOM-cost product. No can do.

Good thought, though -- I hadn't specified that in my initial post.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

of

nd.

seem like most of the the small modules, like the one mentioned below use the same CSR bluecore + flash in more or less the same layout. I'm sure theres a CSR dev-kit with working code for serial port profile and even gerber files for a suggested pcb layout, that they all tweaked a little

for a simple button application I'd guess the Audio/Video Remote Control profile is the place to start

An O2 sensor, pulse rate monitor that speaks rs232, a module like this:

done ...

-Lasse

Tim:-

Suggest you google on Bluetooth modules. There are some with serial I/O that should be pretty easy to get going (I'm in the process of doing this for a telescope encoder interface but not working actively on it atm). There might be some complications to do with setting PIN number etc.

Thanks, but this is way-high volume stuff. More or less, the customer is asking me to design a _module_, and their volumes will pay for the trouble.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

a a

it

t of

ound.

ll

You should look into the EM357 single chip RF SOC. Around $5 in volume, plus some passive components. It got:

ARM M3 Cortex core

192K Flash 12K Sram 2.5GHz RF 250KHz data rate. 48 pins QFN

Everyone is suggesting chips, which I really appreciate -- but what I'm trying to get a handle on now is how much _time_ I can tell the customer it'll take. How much muss and fuss is there associated with getting someone's Bluetooth stack working? How much muss and fuss is there associated with getting the Bluetooth SIG's stamp of approval?

That's what I'm looking at, now.

--
http://www.wescottdesign.com

Bluetooth is typically meant for a lot more data than a mere passing of a button press event.

You might start with attempting to obtain schematics of the Sony PS3 wireless remote though. Or one of the joysticks. That is how they hook in. There is a handshake and a registration on the PS3, so your host would have to be enough of a computer to perform those tasks.

Bluetooth sucks. I'd avoid it if possible. A few years ago I did a project with some gizmos that use the serial port profile. Finding a RS232 bluetooth dongle which actually works is a nightmare. In the end we used $300 dongles and switched them off with a relay to terminate the connection. This was the most reliable solution.

And ofcourse there is the issue with pairing and PIN codes. I don't know how they ever imagined to make it simple for users.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

If you can buy a stack which has been approved on the platform you are going to use, things should be easy. If its just a stack which comes with a chip count on >6 months debugging to get it right.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

How about White Tooth experience? Apples crunch good...

via

g a

t it

lot of

around.

s

tell

a I f

The bluetooth IP costs and stack overhead can be negligible in a higher-functionality data acquisition application where you have a little micro in the loop anyway, but they loom large at the very low end you're being asked to work at.

I don't see how you avoid those without doing an end-run around the marketing: Do it better and cheaper than bluetooth, by not doing it in bluetooth.

Tim.

around.

BlueTooth Low Energy(BLE) and ANT chips are currently the rage.

May want to look these up.

hamilton

around.

Unfortunately that's not in my power. It's Bluetooth, because that's how cell phones and handhelds talk to peripherals. There's no money in trying to shift the whole industry away from that.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim,

Since your product is essentially a pushbutton, what about using a bluetooth "mouse ic". Something like the IS1616NM from ISSC

will relay up to 7 GPIOs (as mouse buttons). You'll probably only need to fake a dummy optical sensor in some simple micro to make it always return a position delta of zero (so the "mouse" never actually moves the cursor).

Mice are about as common as it gets and driver support will likely be available almost everywhere. Since software apps rarely use buttons beyound "MB3" (and except for some games) almost never beyound "MB5", you'll still have buttons "MB6" and "MB7" that you can map to the button(s) on your gizmo that your software can recognize while other running programs will happily ignore them.

Of course, that's a somewhat crazy idea, but mouse ICs are cheap in quantity :)

Hope this helps