This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC26xx and Audio Sampling, External Flash?

Other Parts Discussed in Thread: CC2650

Hello all! I am currently working on a research project and we are interested in using the CC26xx for low-frequency audio sampling.  Specifically, we are looking to continuously monitor sounds in the 0-4kHz range.  

I was wondering two things:

(1) What kind of power consumption would I be looking at if the data was constantly streamed to a device like a smartphone? I am planning on using the same MEMs mic that is found inside the CC2650 SensorTag.

(2) Alternatively, I have considered saving the data to external flash and then "dumping" it periodically throughout the day to the device.  However, if we sample at a rate of 8kHz with 16-bit resolution, this would be around 2 GB (if my calculations are correct, they might not be).  Are there any type of external flash chips that are usually used with the CC26xx?  I have considered lowering the resolution to 10-bits.

  • 1. It depends on the TX power you use.
    2. CC26xx is designed for low data rate application. I think it is not a good idea to transmit such a large data with it.
  • Thanks for your reply!

    What if we are only saving / sending data when "trigger" events occur?  Such as sudden noises, like a cough? Is compression an option?

    I am a novice to MCUs like this one and thought it would have been ideal for our application.

    If not the CC26xx, then which TI chip family would be better suited for this?  

    I saw that the SensorTag included a MEMs mic and was going to use that to get some baseline data.  Now I'm not to sure. 

  • Can you specify how many data you want to save/send when a trigger event occurs? If it is like you mentioned in original question, 2 GB, it is not possible to do it.
  • Sorry I wasn't very clear.

    We are looking to do the following:
    (1) constantly stream the audio information to a bluetooth device when it is in range
    (2) when out of range, we want the MCU to write the audio data to an external flash chip. The next time it is in range, the MCU will "dump" the data to the other device.
    (3) if it will save power, we perhaps want to leverage both of the above options.

    We also require some onboard processing (I figured the M3 on the cc2650 or 40 would be fine)

    We are sampling at 8kHz with either 8-bits or 10 (since we want to detect sounds from 0 to 4kHz).
  • Since you don't do live Audubon streaming application, I think it is OK to use BLE. However, you have to keep in mind that it would take a long time if you want to streaming bulk offline audio data because BLE is low data rate in transmitting.
  • Hello YiKai,

    I am also interested in this thread as it refers to off loading of data via BLE from an external storage device.

    The CC2650 SensorTag hardware contains a 4Mb flash storage device. I view this as an ideal place to store data gathered from the on-board sensors to be off-loaded via BLE at a later time.

    I know that BLE is more suited to the periodic transfer of small amounts of data but I am curious to know if in developing the SensorTag hardware, did TI carry out tests in which the contents of the 4Mb external storage were off-loaded via BLE to a paired device (phone/tablet or such like) in one burst and if so is there code or an API available for that purpose?

    Thanks for any information you can supply.

    Regards,

    Steven.

     

  • Hello Steven. The off-chip flash communicates via SPI so you should be able to use the SPI driver included with the installer. Functionality-wise, there should be no problem in what you are trying to do.
  • Hello Tim,

    Thanks for your reply - much appreciated.

    So to conclude, it is feasable to use the BLE interface to off-load 4Mb worth of sensor data (which could be days or months worth of logged samples) in one transaction?

    Best Regards,
    Steven.
  • I'm not sure what you mean by one transaction. If you mean one connection event than no, this is not possible. However, you can certainly send the entire data chunk continuously on consecutive connection events. This is how general BLE communication occurs.

    -Tim
  • All,

    Has anyone been successful in implementing the common thread here (i.e., writing sensor reads to local storage, and optionally even off-loading at a later "trigger" event?)? If so, have you documented your process or done your development in the open? If so, would you be willing to share a pointer? Would be happy to contribute with what I can add for my own particular goals.

    Nick
  • I appreciate this is an old thread but I hope I can get some up to date information. TI have now released good examples of recording audio using the mems mic on the sensortag2 and sending this to a PC over BLE in real time - great. What about recording this audio to the serial flash when BT is unavailable. Can anyone advise on how to do this? I have both the sensortag2 and the remote control hardware platforms, so instructions for either would be fine.

    Thanks

  • Hi Martin,

    We don't have an out of the box demo that demonstrates saving the audio data to the external flash.

    However, you might be able to develop one based one of TI-RTOS examples. Within TI-RTOS 2.20.00.06 there is a pdmstream example for the SensorTag(note this is without BLE enabled, just PDM driver and RTOS). The pdmstream example shows how to stream data from PDM mic on STK to the CC2650, from there you could pull in the ExtFlash module (\packages\ti\mw\extflash) and use this to write the PDM frames to external flash.

    Just as a word of warning, the BLE stack has not been tested or ported with TI-RTOS 2.20 version yet, but it is also very possible to backport the PDM example to TI-RTOS 2.18 for use with BLE Stack v2.2