An efficient way to implement bluetooth for an embedded product?

All of the BlueTooth modules that I've looked at have been primarily serial bridges. It appears that some allow some sort of bit-banging, but I haven't need more than a serial bridge, so I never dug into that aspect of them. If you can live with the Blue Tooth module appearing as a serial port on the PC, then you're done.

Of the two that I've actually dropped onto boards, the Blue Radio BR- C46AR appears better by far.

If you want a long term commitment to embedded, with a decent continuity of development tools, I suggest that you check out the ARM core. Either Microchip or Atmel could terminate tool development on the whim of a CEO trying to boost this year's bottom line, or choke it off with a new CFO who dismisses it as a "marketing expense". The ARM core, on the other hand is backed by several compiler vendors and the whole Open Source steamroller. The Oceans will need to rise enough to flood San Jose before people stop working on ARM compiler development.

--
Tim Wescott 
Control system and signal processing consulting 
www.wescottdesign.com

Tim Wescott wrote

Many thanks. It looks like a 3.3V UART

Probably uses AT commands! (not looked yet)

Sure, although once a tool works you can just keep running it. I am still on Orcad SDT/386 (1994?) and Protel PCB 2.8 (1995). It works...

We did one batch of demo Zigbee electric meters, "smart power strips", using the AVR Raven module. We used the on-board ADC. The customer was a startup that had a wealthy .com guy who wanted to save energy and change the world. I explained AC power metering to him, and the algorithms that we use, and he coded it all up in a few days.

I think Zigbee has more range than Bluetooth.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators

I'm not sure of your rationalization, there. The advantage of the FTP profile is that it allows for *browsing*, name space hierarchies, etc. in addition to data transfer (pull *and* push!).

Do you have a *set* of A/DC's (or, other I/O's) from among which you would like to be able to *select* specific "devices"/channels?

Once selected, are you expecting to transfer *an* A/DC reading/sample?

Is latency an issue? Bandwidth? I.e., can you "batch" A/DC readings and pull them all at one? Or, does each sample correspond with an observed process variable, etc. (in which case, it typically wants to be seen and acted upon by a control loop before the next sample is taken)

[Sorry, my preconceived notions of industrial CONTROL are creeping into how I am approaching your question...]

Different usage model. Zigbee tends towards lower data rates, longer battery life, etc. BT runs at the higher end of data rates and "expects" batteries to be recharged regularly.

E.g., you use Zigbee in a distributed (physical) access control application (low data rates, nonexistent power requirements) but BT in a high fidelity stereo headset (high data rate, battery will be replaced/recharged RSN)

[Of course, lots of other differences security models, network topology, etc. but that's the "executive summary"]

There's also Bluetooth/Low Energy, in there somewhere. It's good there are so many standards. Keeps the confusion higher.

Do not use Bluegiga modules.

Look at rfduino.com and the Nordic Semi chip that it uses. They are also planning to do an SMD version of that board for easier embeddability.

Any opinion of the Roving Network modules?

Vladimir Vassilevsky wrote

Why?

Don Y wrote

I just want to be able to read maybe 5 16-bit values, and just keep reading them. Speed won't be a problem - BT is plenty fast enough. I have seen megabits per second on file transfers. I think even the original BT was about 500kbits/sec.

If these modules interface serially, the UART may be the limiting factor. A while ago I had to bit-bang an I2C interface for an A-D and even in assembler, and spending a whole week on it, the transfer time was still 90% of the total conversion time!

IMHO you are wrong here. ARM is the way to go if you want to move forward.

No, mostly serial bridge.

How about Wifi? I'd go that route and have a small webserver. Networking on a small ARM controller is very doable. You'd need to have a user interface to let the user choose SSID and enter the pass-phrase but peaople are used to that from their smartphones and tablets.

I have mucked with Bluetooth in the past but it is really hard to get it working reliably. I'be seen several dongles which need flow control to communicate reliably (their buffer seemed to be 10 bytes or so) and some need to be power cycled to break a connection.

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

snipped

This is why you should consider a modern processor which you can code in C. There are several ARM M0+ chips clocked at 24MHz and above for less than £1 in small numbers. There is usually no gain in writing your bit banging code in assembler (certainly at I2C speeds) so you could have spent an extra 4 days with your family :-)

Michael Kellett

1. Performance is much worse then expected for stated BT Class.
2. Power level is not actually regulated.
3. Synchronous transfer modes do not work properly.
4. There is a lot of features in the datasheet which aren't actually supported by modules.

Vladimir Vassilevsky DSP and Mixed Signal Designs

You want to be able to *randomly* read them, individually? I.e., "select ADC #1", "select ADC #4", etc.?

My "speed" questions were with regard to how you are *using* them. I.e., if in a control loop, then *when* you get the data can vary relative to when the data "occurred" (i.e., accounting for possibility of retransmissions means delay between "when sampled" and "when delivered" isn't a constant)

Would you be better off using a *streaming* protocol (profile) and packing the 5 values into an 80 bit object that you "source" continuously (at some rate)?

Yes, it does. However it has some mojo associated with it such that you can set it up so that it just works right without any intervention from the processor. (Which, unfortunately I don't know how to do -- my customer said "use this part", I said "yessir", and from time to time I get populated boards that just work.)

The other one that I've used also uses the AT command set, but you have to help it to establish a connection. On the one hand this is a PITA -- but on the other hand, it lets you use the more secure forms of pairing with a BlueTooth device, if you're willing to make your code smart enough.

--

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

snipped-for-privacy@puntnl.niks (Nico Coesel) wrote

OK - I have noticed that. The dreaded Bluetooth COM port function, yeah... :)

It's a fair point. This is a new product and I feel BT has a niche for what I want to do. But WIFI is also an interesting option. It needs more power but in the first planned product we are not short of power.

I have a part-time software guy (I don't time to do it myself, due to a time consuming other life ;)) who will be doing this and it turns out he has existing expertise with the CC2541

which is highly relevant.

I have mucked around with BT too and it always was a very unreliable technology, but I think largely due to crap drivers (at both ends). Nowadays, it seems to work really solidly on a pile of Thinkpad laptops I have, connecting (via the COM port function) to mobile phones. What you must not do is mess with it once it is working, and in an embedded system one is controlling one end totally, and the computer end will be the existing BT drivers which nowadays seem to work OK.

WIFI is more reliable but there are still issues, with e.g. some versions of IOS supporting infrastructure only (not adhoc), all kinds of issues surrounding these two modes under windoze (especially if there are other UNencrypted APs in range) and I think BT can be rigged to have fewer options for support hassle. We would supply a simple PC app which would scan every COM port and find the one on which our thingy is sitting - something traditionally missing.