Is Bluetooth 4.0 right for me?

[newtonoid]

Hello,

I have an analog voltage signal coming from a low-power proprietary sensor that I would like to monitor wirelessly from a local computer or smart device. My objective is to wirelessly log this data, from a short range, while maintaining low power consumption.

Bluetooth 4.0 (aka bluetooth low-energy) seems to meet the power requirements of my design goals, but I have no experience in wireless communications and am wondering if anyone could offer an opinion as to whether it would be appropriate for my application. This is the product I'm considering:

https://www.ti.com/product/cc2540#doctype1

Can anyone offer resources to facilitate such a development, or links to similar projects? I just purchased this book but haven't gotten very far into it. Any advice will be appreciated.

Thanks

Edit: If anyone would like to recommend an alternative wireless standard, I am open to considerations.

 

[newtonoid]

Thanks for the response. I have in fact found some great technical support from a company called Emmoco based in Austin, Texas. As of now, I think i'm going to start with the following hardware:

Emmoco development board: **broken link removed**

MSP430 Launchpad: https://www.ti.com/tool/msp-exp430g2


Emmoco offers some demo projects to get you started. Hopefully, it won't be too difficult to transition from their demos with the MSP430 launchpad to development with the embedded MCU in the CC 2540.

 

[ROB2222]

The CC2540/41 doesn't have much space left for user code once the BLE stack is inside the device in terms of user RAM. Also when the 8051 is performing the BLE function there is little or no performance left over for anything else. It might serve you to keep a small MSP430 outside to handle the sensor and merely wake up the CC2540 when you need to transmit the data, plus the MSP430 has far better Active mode & Low Power mode operation than the CC2540.

Also, BLE isnt enabled on many PDAs or Cell Phones yet so your limited to where the data can be sent at the moment.

From a Wireless choice, its a bit limited if you want to talk to a PC or mobile device moving forwards since these solutions only support Bluetooth and WLAN, so you've picked the right one out of the two. Other standards like Zigbee, RFCE, etc would require you to make a dongle to plug into the PC/mobile end, which is something that is easily lost or forgotten.

 

[newtonoid]

The CC2540/41 doesn't have much space left for user code once the BLE stack is inside the device in terms of user RAM. Also when the 8051 is performing the BLE function there is little or no performance left over for anything else. It might serve you to keep a small MSP430 outside to handle the sensor and merely wake up the CC2540 when you need to transmit the data, plus the MSP430 has far better Active mode & Low Power mode operation than the CC2540.

Also, BLE isnt enabled on many PDAs or Cell Phones yet so your limited to where the data can be sent at the moment.

From a Wireless choice, its a bit limited if you want to talk to a PC or mobile device moving forwards since these solutions only support Bluetooth and WLAN, so you've picked the right one out of the two. Other standards like Zigbee, RFCE, etc would require you to make a dongle to plug into the PC/mobile end, which is something that is easily lost or forgotten.

Rob, thanks for the response, great feedback. I did notice that BLE isn't widely implemented at the moment. I'm hoping this will change in the near future. As it happens, about half of the employees in our lab own a Samsung Galaxy S4 which reportedly supports BLE. So for in-house purposes at least, we'll be okay. In terms of space in the 2540, I hope to incorporate all of the signal processing functions into the receiving device (cell phone, laptop, etc) in order to reduce computational expense in the sensor/transmitter circuit.

However, I'm not sure what would be more power efficient:

1) A circuit which is simply streaming data continuously to a mobile device. Without doing much processing.

Or,

2) A circuit which collects large frames of data (requiring perhaps a supplementary MCU like the MSP430) for which it then process in some way (calculates statistical descriptions of the data for example) and then transmits periodically.

My assumption is that most of the current draw would come from data transmission, so I'm leaning towards option 2. Any thoughts?

This is all pretty new to me, but so far it's been very interesting. Thanks again for your responses.

 

[ROB2222]

Yes, the data transmission will take 10's mA for the RX & TX combined plus BLE is limited to about 100kbs of raw data (ignoring the packetisation and error handling in the transmitted stream). BLE connects very quickly to its pairing partner, so you need to think about how much data is going to be sent to work out whether pre-processing is needed to keep the battery small. Also small batteries might not last their full capacity since the transmission Current might clamp the battery to 80% of its useful charge since the available current tends to fall towards the end of the Battery (battery size & technology dependent).

Since you've not said what your measuring or what processing is needed, I'll make two suggestions based on the need for continuous comms to the sensor

The MSP430 series can be placed into LPM3 using a 32kHz crystal and use this to keep the SPI port active up to a few kilobaud, so you could continue to take in readings at alow baud rate waking up the MSP430 when the SPI buffer is full and storing the data in external serial Flash. LPM3 draws about 3uA. If you wake up to one of the default DCO settings of 8MHz, then the supply current is ~2mA, but you'll only be in this mode for a few cycles while you store the data. Once you've got sufficent data to carry out the processing simply wake up the MSP430 for a longer period of time.

Use an ARM Cortex based processor. The Freescale Kinetis L series is quite similar to the MSP430 in that it can operate its peripherals in a deep power down modes (uAs), when other Cortex processors have turned off all of their peripherals only leaving the RTC active.

However, all the Cortex processors (Atmel, Infineon, Energy Micro, Freescale, NXP, ST, TI, etc, etc) are seriously affected by ambient temperature and their supply current escalates upwards very quickly in the presence of rising temperature in Low Power modes towards +85C since they are mostly made on a silicon process below 90nm which has extremely high leakage currents (you can see a rise of 20 fold in Current from 25C to 85C in some cases when these micros are in Low Power modes). This is less of an issue when these parts are CPU active mode, but even in these modes some of them go up 3-4 times in Current from 25C to 85C.

The MSP430 doesn't suffer this issue and only changes by a small amount as temp rises since its made on a very low leakage process.

So the route towards a Cortex processor depends on your ambient temp since if its usually around room temp, then they can offer more performance in your product.

Since these are 32-Bit processors you can carry out integer mathematics quite easily and in many cases in one cycle.

 

[newtonoid]

Thanks for all that information, Rob. I can't wait to start getting parts in. Here is some more information about the general design goals and sensor output.

The sensor is an accelerometer. Its design is comprised of a single suspended-gate field effect transistor that can be powered at length with a CR1216 coin-cell. The only information we need to gather from the device is output voltage magnitude and frequency. Currently we're measuring its output as voltage across a resistor, and then passing this voltage to an op-amp for some conditioning.

The sensor is optimized for lower frequency applications (<1 kHz), so sampling rate doesn't need to be too high. If I do signal processing on the peripheral device with a supplementary processor, as you mentioned, perhaps I could frame a second or two of voltage samples and then calculate/transmit frequency and RMS magnitude. If I leave the "g-force" calculations to the host device I can calibrate it on the fly rather than using a hard-coded calibration.

Using a supplementary processor, whether its the MSP430 or an ARM cortex based processor, in conjunction with the CC2540 seems a little daunting with my limited programming experience but I'm looking forward to learning.