Maker Pro
Maker Pro

An efficient way to implement bluetooth for an embedded product?

P

Peter

Jan 1, 1970
0
I am looking at developing an industrial product which will have BT.

Obviously there are numerous ways to do it, with any microcontroller
and one of the BT modules.

My preference is towards the Atmel ATmega128 because we have some
other projects, currently using a Hitachi H8/323, which will
eventually be migrated to that. Atmel, along with Microchip, seems to
be the only company committed to a long term embedded business, with a
decent continuity of development tools.

But I wonder if anyone here has done it before and found some really
easy way.

Preferably the software should be written in C, maybe with a bit of
assembler for things like interrupt service routines (the product will
also have an RS485 port, 1200-115k baud) and we will need to write
some simple PC software to send out with it, for testing it.

I presume that the BT profile would be something like an FTP server -
it is for transferring values from an A-D converter.

Currently we use a TI A-D which is 12-bit, with an I2C interface, and
we do actually need the 12 bits (not 10 bits plus rubbish which is
usually the case with on-chip A-D converters).

I'd much appreciate any pointers to some low cost proven stuff which
is widely used.
 
P

Peter

Jan 1, 1970
0
Tim Wescott said:
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.

Many thanks. It looks like a 3.3V UART
http://www.blueradios.com/BR_C40_Reference_Design.pdf

Probably uses AT commands! (not looked yet)
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.

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...
 
D

Don Y

Jan 1, 1970
0
Hi Peter,

I am looking at developing an industrial product which will have BT.

Obviously there are numerous ways to do it, with any microcontroller
and one of the BT modules.

My preference is towards the Atmel ATmega128 because we have some
other projects, currently using a Hitachi H8/323, which will
eventually be migrated to that. Atmel, along with Microchip, seems to
be the only company committed to a long term embedded business, with a
decent continuity of development tools.

But I wonder if anyone here has done it before and found some really
easy way.

Preferably the software should be written in C, maybe with a bit of
assembler for things like interrupt service routines (the product will
also have an RS485 port, 1200-115k baud) and we will need to write
some simple PC software to send out with it, for testing it.

I presume that the BT profile would be something like an FTP server -
it is for transferring values from an A-D converter.

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...]
 
D

Don Y

Jan 1, 1970
0
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.

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"]
 
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.

There's also Bluetooth/Low Energy, in there somewhere. It's good
there are so many standards. Keeps the confusion higher.
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"]
 
P

Paul Rubin

Jan 1, 1970
0
Peter said:
I am looking at developing an industrial product which will have BT.
Obviously there are numerous ways to do it, with any microcontroller
and one of the BT 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.
 
P

Peter

Jan 1, 1970
0
Don Y said:
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)

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!
 
N

Nico Coesel

Jan 1, 1970
0
Peter said:
I am looking at developing an industrial product which will have BT.

Obviously there are numerous ways to do it, with any microcontroller
and one of the BT modules.

My preference is towards the Atmel ATmega128 because we have some
other projects, currently using a Hitachi H8/323, which will
eventually be migrated to that. Atmel, along with Microchip, seems to
be the only company committed to a long term embedded business, with a
decent continuity of development tools.

IMHO you are wrong here. ARM is the way to go if you want to move
forward.
But I wonder if anyone here has done it before and found some really
easy way.

Preferably the software should be written in C, maybe with a bit of
assembler for things like interrupt service routines (the product will
also have an RS485 port, 1200-115k baud) and we will need to write
some simple PC software to send out with it, for testing it.

I presume that the BT profile would be something like an FTP server -
it is for transferring values from an A-D converter.

No, mostly serial bridge.
Currently we use a TI A-D which is 12-bit, with an I2C interface, and
we do actually need the 12 bits (not 10 bits plus rubbish which is
usually the case with on-chip A-D converters).

I'd much appreciate any pointers to some low cost proven stuff which
is widely used.

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.
 
D

Don Y

Jan 1, 1970
0
Hi Peter,

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.

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)?
 
P

Peter

Jan 1, 1970
0
[email protected] (Nico Coesel) wrote
No, mostly serial bridge.

OK - I have noticed that. The dreaded Bluetooth COM port function,
yeah... :)
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.

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

http://e2e.ti.com/blogs_/b/connecti...for-bluetooth-low-energy-and-proprietary.aspx
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.
 
Top