Bluetooth low energy vs. Zigbee/ZWave for the future - Page 1
Forum section: electronics / projects

author: Corporate666
author_rank: Unknown
timestamp: July 28, 2013, 05:58:10 pm
content: I'm sure some guys are working with these technologies here... we make a couple of doodads that would lend themselves to being networked for home automation. Originally, it looked like between Z-Wave and Zigbee... ZWave seems more easy to get stuff working reliably, because ZWave is closed.. but you gotta pay $$$$ for the SDK to be able to make ZWave parts. Zigbee seems to be much more popular among the open source/hobby guys, and maybe more popular in industry/commercial applications.Been reading about Bluetooth Low Energy - Android just announced support for it in the latest revision... Apple got behind BLE, so it's in every iPhone since the 4S, and in the other top phones like Galaxy S3, S4, many BB's, HTC's, etc.On another engineering forum, a lot of people are saying they are not getting requests for projects using Zigbee, and it's been mostly BLE. But whereas there are Zigbee modules out the wazoo available, there aren't too many BLE chips out there.It seems that BLE would be poised to absolutely dominate in consumer applications because it's already built into hundreds of millions of handheld devices. Anyone designing in BLE today?

author: andyturk
author_rank: Frequent Contributor
timestamp: July 29, 2013, 04:38:44 am
content: Quote from: Corporate666 on July 28, 2013, 05:58:10 pmSure, lots of folks.It's great if you've already sipped the Bluetooth Kool-Aid because only the software stack is different, and it's got great branding. Plus, if you want to talk to iOS through BLE, you don't need to jump through the iAP hoop.The downside is that you still need a bunch of code to make it work which usually means a dedicated chip or a whopping big chunk of firmware. It's also fairly slow, as everything is chopped up into 23-byte packets. BLE is great for occasional bursts of data. But if you need to send a lot of data frequently, you'll be better off with Bluetooth classic and use less power doing so.

author: Corporate666
author_rank: Unknown
timestamp: July 29, 2013, 05:11:01 am
content: Quote from: andyturk on July 29, 2013, 04:38:44 amThanks Andy.Pretty much mirrors what I've read online. I haven't done anything with classic BT before, but the "great chunk of firmware" thing is slightly concerning. I was looking at what is available from Digikey, and the Laird modules look pretty good - support I2C, SPI, UART and have built in MCU with GPIO and a software stack - and they claim they are bluetooth approved for incorporation in end-user devices and need no further BT qualification.When you talk about the burden of firmware, I'm guessing you are talking about starting from scratch rather than using off the shelf modules?

author: andyturk
author_rank: Frequent Contributor
timestamp: July 30, 2013, 12:09:14 am
content: I haven't used any of the Laird modules, but it looks like they take care of the HCI stack for you. HCI stands for "Host Controller Interface", and it's one of the things defined in the Bluetooth spec.If you use a raw Blueooth chip, it will typically send and receive HCI packets through a serial interface (e.g., UART or SPI). Dealing with those HCI packets is that "big chunk of firmware". One open source stack is called btstack (btstack.org). It implements most of the classic BT interface and some of BLE. There are a bunch of commercial/proprietary options too, but they're all in the same ballpark as far as complexity. You might also take a look at the Bluetooth spec. It's actually fairly readable, if long (~2600 pages for V4.0).Some Bluetooth modules have their own mcu and an internal HCI stack. They present some other (hopefully simpler) interface to the application. They also tend to be pre-certified by the FCC and also by the Bluetooth organization, so the end product doesn't have to go through quite as much official testing. The tradeoff is that you pay a lot more for a module than you would for a bare chip.For prototyping, it definitely makes sense to go with a module. The big Bluetooth players (e.g., Broadcom and CSR) probably won't even talk to you unless you're shipping millions.If you're building something really small, there are some system-on-chip Bluetooth solutions that already take care of the HCI stack for you. The mcu has some extra code space and a little bit of RAM so that you can put your own application right next to the low-level Bluetooth stuff. TI's CC2540 uses an 8051 core. Nordic's nRF51822 has an ARM Cortex M0. There's a pretty interesting kickstarter project (link)that uses the nRF51822 as the mcu and includes an arduino compatible software layer. You can also buy the bare modules (without the arduino stuff) from the same company.

author: AlfBaz
author_rank: Super Contributor
timestamp: July 30, 2013, 02:05:00 am
content: A recent amp our (last one?) had a guy that was saying/using/supporting BluGiga modules, complete with mcu and stack. From the sound of things they actively respond to support requests from just about anyone

author: kaz911
author_rank: Super Contributor
timestamp: July 30, 2013, 08:22:53 am
content: all up to BLE Bluetooth has been utter crap and incompatible products. After 10 years they still can't get headset profiles to work, reconnect to work, high quality audio in both directions. The only things that seem to work reliable are keyboards and mice.Anyway - ANT/ANT+ is Garmin - and I'm not too impressed by that. Z* - not even that impressed by those either.So what is next?