1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

An efficient way to implement bluetooth for an embedded product?

Discussion in 'Embedded' started by Peter, Dec 15, 2013.

  1. Peter

    Peter Guest

    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.
     
    Peter, Dec 15, 2013
    #1
    1. Advertisements

  2. Peter

    Tim Wescott Guest

    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, Dec 15, 2013
    #2
    1. Advertisements

  3. Peter

    Peter Guest

    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)
    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...
     
    Peter, Dec 15, 2013
    #3
  4. Peter

    John Larkin Guest

    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.

    https://dl.dropboxusercontent.com/u/53724080/Hug/DSC04003.JPG


    --

    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
     
    John Larkin, Dec 15, 2013
    #4
  5. Peter

    Don Y Guest

    Hi Peter,

    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...]
     
    Don Y, Dec 15, 2013
    #5
  6. Peter

    Don Y Guest

    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"]
     
    Don Y, Dec 15, 2013
    #6
  7. Peter

    Les Cargill Guest

    Not inherently, but there aren't a lot of long-range Bluetooth
    implementations.

    This:

    http://www.bluegiga.com/en-US/products/bluetooth-classic-modules/wt41-long-range-bluetooth--module/

    shows "1000+ meter line of sight". Sure, why not?

    http://www.engineersgarage.com/contribution/zigbee-vs-bluetooth
     
    Les Cargill, Dec 15, 2013
    #7
  8. Peter

    krw Guest

    There's also Bluetooth/Low Energy, in there somewhere. It's good
    there are so many standards. Keeps the confusion higher.
     
    krw, Dec 16, 2013
    #8
  9. Do not use Bluegiga modules.
     
    Vladimir Vassilevsky, Dec 16, 2013
    #9
  10. Peter

    Paul Rubin Guest

    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.
     
    Paul Rubin, Dec 16, 2013
    #10
  11. Peter

    Paul Rubin Guest

    Any opinion of the Roving Network modules?
     
    Paul Rubin, Dec 16, 2013
    #11
  12. Peter

    Peter Guest

    Why?
     
    Peter, Dec 16, 2013
    #12
  13. Peter

    Peter Guest

    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!
     
    Peter, Dec 16, 2013
    #13
  14. Peter

    Nico Coesel Guest

    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.
     
    Nico Coesel, Dec 16, 2013
    #14
  15. Peter

    MK Guest

    On 16/12/2013 08:18, Peter wrote:

    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
     
    MK, Dec 16, 2013
    #15
  16. 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
    www.abvolt.com
     
    Vladimir Vassilevsky, Dec 16, 2013
    #16
  17. Peter

    Dave Nadler Guest

    I just finished debugging an application using the
    Blue Radio BT-BR-LE4.0-D2 - works well.
    This replaced an Amp’ed RF BT43 which did not work as advertised.

    I'm just using SPP (serial port profile, looks like a COM
    port on Windows for example).

    Hope that helps,
    Best Regards, Dave
     
    Dave Nadler, Dec 16, 2013
    #17
  18. Peter

    Don Y Guest

    Hi Peter,

    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)?
     
    Don Y, Dec 16, 2013
    #18
  19. Peter

    Peter Guest

    (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

    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.
     
    Peter, Dec 17, 2013
    #19
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.